You're saying the quiet part out loud: that the AOSP/GrapheneOS security model is designed not only to protect users from attacks, but also to protect apps from

You're saying the quiet part out loud: that the AOSP/GrapheneOS security model is designed not only to protect users from attacks, but also to protect apps from users, which I find quite abhorrent. You may disagree, and some others may disagree, but I think your users should at least be aware of your stance on this. It's my hunch that most of your users would agree with me that this is not a good thing, if only they realized that it was happening and actively encouraged by your project. > They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Or they can just let me run whatever I want on the device that I bought. Anyone should have the ability to spin up their own fork of GrapheneOS or AOSP and make changes that improve their experience. This is one of the basic principles of free and open source software (FOSS). There is a fundamental difference between "open source" and "free and open source". If you want your project to fall into the latter category, it must respect the user's freedom "to study how the program works, and change it so it does your computing as you wish". Users cannot do this if hardware attestation as promoted by GrapheneOS is implemented on a large-scale. See https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html > anti-cheat, anti-fraud There are better, more effective ways of enforcing these things that don't rely on apps policing which OS users are allowed to use, like server-side checks. They're already using these approaches and have been for a long time on platforms without guaranteed access to hardware attestation, which is most platforms besides mobile phones. I don't think it's worth giving up user freedom entirely just so there are less cheaters in Fortnite, or so app developers have excuses to be lazy with regards to anti-fraud, anti-reverse-engineering, etc. > 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. I didn't suggest that you disable it. The problem is that you're using your website and platform to promote usage of the feature in an anti-user way. > GrapheneOS uses attestation as one of the major included security features via our Auditor app. This is a valid use case of hardware attestation. It allows the user to verify that they're running the OS that they think they're running. That's a good thing. When I say "SafetyNet hardware attestation" I'm solely referring to the anti-user practice of enforcing a list of "approved" operating systems via hardware attestation. SafetyNet explicitly provides an API for this. I'm not sure if the AOSP attestation API does, but it's not difficult to implement one as you describe in your article. > 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. If PayPal would stop doing pointless hardware attestation verification in the first place, you wouldn't have that problem, and neither would any other Android fork. As you said it's not likely that PayPal will do anything you recommend anyway. So why not use your platform to promote better, non-anti-user solutions to the problems that hardware attestation is unfortunately used to solve? > 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. I appreciate that you've worked to support ways to use the feature that are the opposite of anti-user and actually enhance user security. That is definitely a positive contribution. But keep in mind that the underlying motives behind implementing such features in the first place are not always "to improve user security". As it stands, most Android applications do not use hardware attestation to check if you're using an approved OS. My point is, that we should encourage developers to keep it that way, rather than encouraging them to use it, but add specific alternate operating systems to their list. I honestly think it's a little more likely that they drop hardware attestation altogether, if presented with good arguments for why it's not only an inferior approach to traditional methods, but also atrocious for user freedom. It's also less burden on them than developing their own system where they have to keep up to date with the latest signing keys as described in your article.