In parallel, Google has rolled out its Play Integrity API, which allows developers to limit app functionality when sideloaded, effectively pushing users to install apps only through the Google Play Store.
The issue is even bigger. Even when using Play Store on GrapheneOS with a locked bootloader (which is the recommended configuration by the GrapheneOS project), Google refuses to let apps use the hardware attestation support in the Play Integrity API [1], which blocks certain banking apps, Google Wallet, etc.
It's insane that Google lets Android vendors that have a lot of dubious security practices (months-late security updates, etc.) pass, while an OS that implements more security mitigations than PixelOS and is sometimes faster than Google rolling out security updates is excluded.
The move, developed in partnership with Singapore’s Cyber Security Agency, is designed to prevent fraud and malware-enabled scams.
Time to block the Facebook/Instagram apps then, given https://localmess.github.io ?
[1] https://grapheneos.social/@GrapheneOS/112878070618462132
The GrapheneOS devs are serious about security, probably more focused on it than 99% of end users. That they manage to release a project with the high level of usability that GrapheneOS achieves is impressive, even if it isn't as convenient to the end user as stock Android. Ultimately, nothing will ever be as convenient to the end user as stock Android or iOS, but that's not the point of the project.
That's my point, though. The projects security requirements don't need to be that stringent. By all means, take advantage of the hardware security on devices that offer it like pixel, but even on devices without that hardware security it would still be the most secure Android based OS available, and orders of magnitudes more people would benefit from having access to that.
GrapheneOS security requirements very much do need to be that stringent. That's the whole reason for the project. Have something that is maximally secure within the most aggressive limits of what is possible today.
It targets end users who either have an acute threat model (e.g. journalists, dissidents) or are willing to tolerate some level of inconvenience (compared to stock Android) to gain the security advantages. Not everyone is willing to make that trade-off, and that's okay. I don't want my daily use phone OS to adopt a more permissive security model to appeal to a broader audience. I suspect most GrapheneOS users share that stance.
There are other AOSP custom distributions that benefit from the security improvements GrapheneOS is able to get accepted upstream (though Google is making this more difficult than it used to be). I think, for people who aren't willing to make the trade-off, a better path is to use another AOSP distribution on the hardware they prefer, or to establish a separate project to build a downstream version of GrapheneOS (under a clearly distinct name) for other, less secure hardware... Trying to shadow each release as closely as possible and make best use of Graphene's generally excellent software customizations (e.g. storage scopes, deny network permission, etc) without pursuing a hard fork.
I'd certainly like something similar for NVIDIA Shield Devices, for example. But I know that's not what Graphene's mission is.
The GrapheneOS devs absolutely will not listen to anyone asking them to loosen their security model. And thank goodness they don't! That's why I use GrapheneOS. It's why many do.