Comment by NotPractical

I think root is precisely what most of these apps are trying to avoid. They think (at least the finance app I used to work for thought) that with root, user credentials the app stored would be accessible by whatever uses those root permissions and they didn't want the risk

But you can do that. You can go and root it with a fork. You just won’t run banking apps on it, because it introduces undue risk that they don’t want to absorb.

This ‘all or nothing’ attitude in the comments is a bit silly to be honest.

GPLv3 fixes this.

[dead]

This is the problem with remote attestation. The free software foundation has been talking about this endpoint since the late 2000s.

The fact that GrapheneOS digitally signs their releases doesn't make them not open source. This is indeed a bad situation, but the badness is 100% the fault of Google for having a hardware attestation "feature".

GrapheneOS is open source. This has no connection to open or closed source. GrapheneOS has heavily pushed back against apps using remote attestation to restrict which operating systems and hardware can be used. When apps are unwilling or unable to remove it such as due to government regulations, we try to convince them to permit GrapheneOS and other alternatives via a standard Android API instead of only using the Play Integrity API.

Banks are increasingly adding checks for Google certified devices. In the EU, there are regulations requiring banks to start verifying device integrity. It's headed that way worldwide with a growing number of regulations and industry standards requiring it. Apple's App Attest API and Google's Play Integrity API have repeatedly been the only options recommended by the EU which has contributed to the worsening situation in the EU in particular. We convinced the EU to remove those specific examples from several official standards. No one has been able to convince them to stop heading down this path despite a lot of people pushing back against it. We haven't been able to convince them to define actual requirements let alone to require permitting anything which meets those requirements. They give a vague description of what they require doing shaped around the Apple and Google integrity APIs.

We convinced around a dozen banks mostly in the EU to use the standard Android key attestation API included in the Android Open Source Project as an alternative. It allows apps to verify the OS verified boot key hash, patch level, app signing key hash(es) and app version code based on a root of trust. This meets the requirements for the EU standards and enables permitting any alternative with verified boot and a mandatory app sandbox with support for verifying the app's signing key and passing it to the hardware keystores. Other operating systems can publish their signing keys in the signed JSON format we published and ask the same companies to include their keys too.

Once apps implement an alternative to the Play Integrity API to permit a single OS, it's easy for them to add more. The hardest part is getting them to even consider doing it. It's nearly impossible to get in contact with the right people and to convince them to do it. Once we establish that contact and convince them to ship it, it's a lot easier. There has been an ongoing issue of these apps not adding our new verified boot keys which are per-device-model for security reasons similarly to the Pixel OS. We tried to solve that by creating a standard signed JSON format which can be automatically retrieved and used to automatically include the new signing keys. Exactly the same approach can be used to delegate certification and inclusion of arbitrary operating systems to other organizations. It can also be used for handling which roots of trust for non-Google-certified hardware are also permitted.

We would prefer if none of this existed but we don't live in that world and we're doing what we can to convince apps to permit GrapheneOS and other alternatives. We're heavily fighting against it being done in the first place and against more standards and regulations requiring it. We're also fighting against more centralized attestation systems such as the Play Integrity API as opposed to systems with actual standards where anything meeting those standards can be included. It would not be a good thing for there to an EU alternative to the Play Integrity API permitting specific operating systems and devices based on geopolitics and business interests. That would only accelerate adoption of attestation by EU apps which is already happening at a faster pace than elsewhere thanks to both EU regulations and what many of the countries are doing themselves.