Comment by HybridStatAnim8
6 hours ago
GrapheneOS requires a locked bootloader and supports using deveice attestation via the generic attestation functionality in the Android Open Source Project.
Play integrity is an anticompetitive tool that ignores this, and artificially limits itself on GrapheneOS. It is not due to any incompatibility.
The GrapheneOS supporters are not on our sides, apparently. The seem to actually like remote attestation. They just don't like that they are not in on Play Integrity. But what is won if attestation includes official GrapheneOS releases but would still otherwise be exactly the same evil stuff that takes control of the user's device?
I still am hoping that at one point they understand the full consequences of remote attestation. There are some signs they start to notice, but it's slow...
Note that I am a GrapheneOS supporter. You seem to have a few misconceptions.
GrapheneOS is one of, if not the most vocal organization against the abuse of attestation mechanisms. GrapheneOS and its userbase feel the consequences of play integrity every single day.
Im not sure where you got the idea that all GrapheneOS wants is to be accepted by play integrity, because that is not the case. GrapheneOS has been working with regulators to get play integrity banned. Being accepted by play integrity, but nothing else changing, is not good enough for GrapheneOS. It would only be a small victory along the path of abolishing this nonsense.
So, no, GrapheneOS and its community are definitely against play integrity. The "signs" that they are "starting to notice" are not there. They are already fully aware of what attestation is and how it can be abused. They are definitely not ignorant on the subject.
You might be confusing root based attestation with pinned attestation. Root based attestation is flimsy and allows tools like play integrity to ban operating systems they do not like. Pinned attestation, on the other hand, has real security properties and cannot be abused to block certain operating systems. GrapheneOS uses pinned attestation as a part of their Auditor app, and it has other cool uses we could see in the future.
My opinion: Any kind of attestation that is delivered to a non-user-controlled server about the state of a user's end device that the user (possibly using means outside of the end device) cannot change will be abused, e.g for anti-competitve purposes. I am hearing lots of arguments that grapheneOS is more secure (it is) and should therefore be included in remote attestation.
The pinning you are proposing, does it imply that there is again some certification of the "official" GrapheneOS, versus e.g. the user's own fork of GrapheneOS?
How would any of the existing proponents of remote attestation agree to anything like this, given what we consider abuse is exactly their reason of implementing it in the first place? Here, VW wants to stop use of the API by anything else than their App, in order to stop hobbyists and sell API access to commercial middle men. If the user could pin their own software's attestation or even register an arbitrary public key to cover updates, then the user would as well be able to code his own API client that just emulates the attestation. Is there any write up or discussion of the pinning you propose?
I am really not yet convinced how you want to counter the inevitable abuse that app developers and service providers will subject the user to if the OS security model gives them that kind of power over the user's end device.