Comment by Retr0id

> When two people interact there’s a trust/risk calculation on both sides.

You should never base your trust on the other party having a piece of hardware that has restrictions that you approve of. That is fragile, especially in a world where some people are better at making or modifying hardware than others. It is also a fundamental violation of basic freedoms to prevent people from modifying hardware that they own, and not something you can reliably police, and thus is a terrible way to establish trust from a technical perspective.

It's much better to base trust on established cryptographic methods on a protocol level. You treat them as a black box, and the trust is established by the inputs and outputs, not what's inside the box. An example of this would be handing them an image of a digital ID paired with a cryptographic signature that only the government holds the private keys to. They have no computationally viable way to edit the image and still have it match the paired signature. It's easily verified based on the government's public key, and they cannot re-sign it without the government's private key. It doesn't depend on hardware restrictions.

The fact that there is so much focus on hardware means there are likely deeper motives here, e.g. surveillence being dressed up as convenience.

I cannot think of any company that has appropriately used attestation as a trust/risk calculation. I work in major game studio; there is never calculation only a binary.

It never „let`s check if the mobile user has purchased in-game content server side to prevent pirating it“, its „suspend any account that has signed in with a device that fails safetynet, permanently ban any account that has failed a jailbreak or root checks“

It never „let`s check and calculate statistically cheating probability and move damage calculation server-side so that player cannot godmode or modify their APK“, its „all non-stock phones are cheaters and fraudsters, ban all of them, use invasive anti-cheat, while continuing to have client sided damage and health and energy because it is easier“

Something else has to change first otherwise the only option for businsinses do will be, after 2 is implemented : „while yes it is now possible to allow a neutral third party to control attestation, someone higher-up such as legal has said ONLY google can and we will ban everyone else“

As long as it is easier to don't give a fuck, that is the option that will be taken. z.B. the only reason our publisher allow the removal of play services was finding out that chinese players on definitely not google certified phone spends the most by orders of magnitude and even then it is only relaxing the check for specific region, forcing all EU players to continue to have this checking.

I would be wholly unsurprised if the result was to continue to require attestation but allow GrapheneOS f.e. only in Motorola factory shiped phones and disallow it if the user was involved in any way in the installation of it.

It's an anti-competitive concern all the time.

If we gatekeep service access to specific implementation attestations, it becomes much harder for new implementations to emerge. It doesn't really matter who controls the process.

In that sense, it's always bad. In this specific scenario for example it directly blocks emergence of alternative Android ROMs and Android-mostly-compatible devices like the various Linux phones.

There may be times where that downside is worthwhile, but it's always a downside, and we should very strongly discourage attestation wherever possible on that basis for the health of both the tech ecosystem and the business market around it.

Only acceptable use of attestation is when done on behalf of device owner. So if they let me submit list of keys allowed for my account, fine, but any other use is just evil restriction of what software I can run on my own devices.

Definitely not bad all the time. For instance, GrapheneOS provides the Auditor app, with which you can verify from another phone or from a server that the OS is not tampered with. It also uses remote attestation.

So, there are certainly useful applications.

A hypothetical useful use of attestation is that a company promising to process personal data securely could actually prove it to end-users, by open-sourcing their server-side code and using reproducible builds combined with remote attestation, to prove to the client that the server-side is running unmodified within a secure enclave.

I struggle to think of a useful use for it on the end-user client side, though.

Not to mention self-signed custom builds of GrapheneOS.