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.
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.
Nice
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.
So, there are certainly useful applications.
I suppose if you've bought a device with GrapheneOS already installed, you can use it to verify the installation. But that could also be achieved by reflashing a known-good image yourself.
Admittedly, most of these are probably nation state-level attacks, but I think some GrapheneOS users are the target of such attacks. Also, it doesn't hurt to run Auditor after a fresh install to protect against the second scenario. It only takes a minute, better safe than sorry.
I struggle to think of a useful use for it on the end-user client side, though.
If you've installed RealActualBankApp (with the ID of real.actual.bank.app) once (from whatever source!) then there cannot be another app installed with that same id but signed with a different public key (oversimplified version of the story, there is a key rollover scheme).
You can however install an imposter app that's also called RealActualBankApp, with the same icon. It'll need to go by a different ID.
So then we're down to the same problem, or pseudo-problem, of identity confusion, as we have for banking website URLs. Where is the ID/URL shown, and does the user know that it should be mybank.com and not mybank-incorporated.com ?