GrapheneOS does not support SafetyNet or Play Integrity hardware attestation and there isn't a way to use them on GrapheneOS. The whole point of that article is encouraging developers to move away from those Google services to the standard Android Open Source Project hardware attestation API which includes support for alternate operating systems. Once developers switch away from the Google attestation API to the Android attestation API, they can freely add support for alternate operating systems by adding their signing keys to an allowlist if they meet the requirements. They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Starting by adding GrapheneOS would make sense since it's the most widely used alternate mobile OS with properly signed releases supporting attestation. Our article does not recommend only supporting GrapheneOS and if developers change their implementation as we recommend, they can easily add support for many other operating systems. Convincing developers not to unnecessarily lock down which operating systems can use their apps is a separate thing from convincing them to support alternate operating systems meeting their standards. Some apps are required to check for this due to expectations from financial services or even governments, and while most usually do a poor job today they will eventually mostly move to the Play Integrity API and will eventually enforce the strong verification level requiring hardware attestation. It would be much better if they instead used the Android attestation API supported by the Android Open Source Project which is also available in any alternate OS based on AOSP.

Basic hardware-based attestation is available on every device launched with Android 8. An alternate OS such as GrapheneOS disabling the feature for user installed apps simply means it won't pass checks based on it. Disabling it would not accomplish anything useful. It doesn't leak any information that can't be otherwise obtained but rather provides a way to cryptographically verify the information that's available including verified boot mode, OS signing key, OS hash, OS patch level, device model and also non-hardware-based things verified by the OS like the app id and signing key.

GrapheneOS contributed to upstream hardware attestation improvements by making a proposal for much better pinning support which was accepted and implemented in the Android 12 attestation API. Our proposal makes attestation work much better as a user-oriented feature for securing devices with our Auditor app. Pinning has no use when using this feature for anti-cheat, anti-fraud, DRM, etc. since those simply depend on verifying based on the root certificate which will always be vulnerable to bypass via leaked keys from insecure devices.

Supporting verified boot and hardware-based attestation is not anti-FOSS or anti-user. GrapheneOS uses attestation as one of the major included security features via our Auditor app. Other apps can also use it to protect user security. What users see as hostile is not universal. Most users want to play competitive games without having other people using software/hardware to cheat. Hardware-based attestation can be used to build much stronger anti-cheat, and some games are doing exactly that with the feature. It's unfortunate that they're currently doing it with the Play Integrity API (or legacy SafetyNet attestation API) since it locks out users on alternate operating systems. If they used the Android attestation API instead, they could avoid locking out users on operating systems like GrapheneOS and others. It's entirely possible for those games to implement this in a way where people with hardware attestation are placed in games together and people without it are kept separate, which is one of the ways this is being implemented. That means at the moment, GrapheneOS users will have a worse experience due to being grouped with nearly all of the people using cheats. We want to get this fixed. It is not anti-user to want a better experience and broader app compatibility for GrapheneOS users. It is not GrapheneOS choosing to use attestation to lock anything down. GrapheneOS only uses attestation if the user chooses to use our Auditor app and that's entirely based around the user protecting their device. It is other developers who want to use attestation in ways that can be seen as hostile to users, and that will be the case regardless of what GrapheneOS does. GrapheneOS does not have significant influence over Android app developers. If we can get a single major app to switch to the Android attestation API and support GrapheneOS and other alternate operating systems, that will be a major accomplishment. PayPal seems to be gradually adopting using Play Integrity attestation and perhaps we can convince them as a starting point. Our users are certainly not going to be unhappy if PayPal continues working on GrapheneOS instead of breaking. Not clear how you get the idea that this is anti-user.

> Tragically GrapheneOS doesn't tend to view any Google decisions through a critical lens, which would allow them to see through some of Google's "security features" for what they really are: user-control features implemented solely to ensure that most people do not switch away from the stock OS and continue to consume Google services, handing over their user data in the process.

There have been massive privacy and security improvements in each major release of Android for many years. The hardware attestation API released prior to Android 8 is a single feature. SafetyNet attestation and the Play Integrity API are not part of Android itself but rather Google Play. Those were ported to using the hardware attestation API when available but they mostly aren't based on it and don't take much advantage of it. GrapheneOS itself is one of the only projects using Android's hardware-based attestation directly via our Auditor app. We're likely the ONLY software project using the app-generated attest key feature introduced in Android 12 based on our proposal and first shipped on the Pixel 6 because we found issues making it unusable at first which had to be reported and fixed. App-generated attest keys are a different approach to attestation based around generating hardware backed attestation signing keys and pinning those instead of verifying based on a trusted root certificate. This pinning-based approach is not useful for user hostile features and can be supported even on a device not including a trusted attestation root certificate in the secure element. We helped to make hardware-based attestation into a feature that's much more useful for protecting users and which can exist without the part that allows building user hostile features. The attestation root is still useful for verifying the initial pairing for our Auditor app or other use cases based on Trust On First Use via pinning.