There's no way to verify the integrity of the system, and any malicious app can just grab your banking credentials or enable criminals to unlock and drive away with your car.
Play integrity is an anticompetitive tool that ignores this, and artificially limits itself on GrapheneOS. It is not due to any incompatibility.
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...
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.
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.
GrapheneOS points out how its improved privacy and security should mean that it is accepted in a system like play integrity. But this is just to outline how flawed the logic of play integrity is. It is by no means an endorsement of play integrity. GrapheneOS wants people to know that google is lying and breaking the law, and uses its own exclusion as that evidence. Even if GrapheneOS were accepted into play integrity, it would still exclude any and all forks and self-signed builds of GOS, which is unacceptable. If companies absolutely insist on using this approach despite its flaws, they should use the generic attestation available in android, and permit using 3rd party roots of trust in some form, rather than outsourcing this verification to 3rd parties like google.
As for the pinned attestation approach, that is Trust On First Use, and is used to verify the integrity of a device based on the security of the devices early bootchain. The initial attestation is what future attestation is pinned to. This allows you to verify a device is the same one, it has not been downgraded, has not been tampered with, etc. This is awesome, and lets you do things like what GrapheneOS does with Auditor. But this is not used to restrict what operating systems are used. Root based attestation somewhat tries to resolve the Trust On First Use approach, but is used to arbitrarily ban operating systems in practice. It is super flimsy as any leaked keys can bypass it.
My only concern is your claim that GrapheneOS is for this technology when it is most certainly against it. The nuance is that pinned attestation is a different approach with different properties, and advocating for it does not mean GrapheneOS is not an ally against play integrity.
Auditor also functions as a proof of concept for the potential of attestation, check here for more info: https://attestation.app/about
- Remote attestation is bad, anti-competitive, and reduces privacy.
- Given in a world where remote attestation exists, GrapheneOS should pass attestation, since there are no security reasons not to.
Both battles should be fought at the same time, because if governments do not want to ban remote attestation, you want to make sure that at least it's not in the hands of companies that abuse it to maintain their duopoly.
Focusing on only one of them can lead to worse outcomes.
I get that Google doesn't want to be sued for failing to protect its users and indirect users of the mobile phones sold by other companies, but for advanced users there should be an option to update the signing keys used by the bootloader, so that you can unlock, flash your custom ROM, update keys, and relock bootloader. Such a phone should still be considered "trusted" by Google Integrity APIs. But currently there's no way to do this, so basically you don't really own your hardware.
I gave up on custom ROMs trying to extend my devices' lives and bought a Fairphone instead, so I have the assurance from the vendor that I will have software updates for a very long time.
Fairphone doesnt make their own phones, its outsourced to an ODM and Fairphone has very little input on how its designed. They havent "sourced" anything. Fairphone also stops providing kernel updates very quickly and delays userspace/driver/firmware backports for months. They delay yearly updates for years too. This doesnt even touch upon the fact they used public signing keys in the past.
It is not derogatory to say that it is e-waste out of the box, it is simply accurate. Choosing to continue using it despite how unsafe it is does not change the abysmal support it is given. A modern iPhone/android used from launch to the end of its 7 year support time, then properly recycled, would be far better for privacy, security, and for the environment. A support window that long would also provide a strong used market to continue using these devices. Cheap ODM phones with short support windows, and not benefiting from economies of scale, is a waste.
Fairphone 2 came out in December 2015 and saw the last release in March 2023. That's 8 years of software updates when Android devices from that era barely got 3, and you had to pick the flagship.
Kernel updates used to be bound to Android versions because of how the kernel modules development was handled, not really limited by the company or the hardware. I owned a OnePlus 5 and the custom ROM was stuck with older kernels for a while too, until the community stepped up to port it, because there just wasn't an easy way to build kernels with updated custom vendor modules for the hardware. Google addressed at least that part thanks to the Kernel Module Interface (read e.g. https://arstechnica.com/gadgets/2021/09/android-to-take-an-u... ). So newer kernels may still lag a bit based on the manpower available and priorities, but they should be easier to do.
Now that replacement cycles have become longer because hardware is good enough that you don't need to change phone every year, and Android supports KMI and other features that make maintenance easier, more vendors decided to extend support, so at least there's some more choice.
From the environment point of view, I can now finally easily repair my phone. A friend of mine always had bad luck with pixels, so bad that he went through 4 phones in ~5 years (2 bought, 2 replacements). I am at my third phone in 12 years (OP1, OP5, Fairphone).
I don't see how the second half of the sentence follows from the first half.
Has this ever happened?
I do not know the VW app, but other electronic key systems do not require you to have physical access to the car in order to make copies. The keys are meant to be device bound and to have policy (such as I'm giving out access for a week), but that can only be assured via a chain-of-custody attestation system from the boot loader to the app and a hardware attestation that the secure element is proper.