[public_defender]

I love GrapheneOS. Before trying it one should consider that unlike some "sister" projects, it does not support signature spoofing, so if you need SafetyNet or something similar, you will likely be out of luck.

On one hand I like the no spoofing position the devs took, on the other hand my banking app.

[kaba0]

They have a sandbox which can run google’s services. I read plenty of people saying that they could successfully run their banking app without spoofing.

[public_defender]

This is true, but it solves a different (though often related issue).

[Gasp0de]

I am able to run all banking apps from my 3 different banks that I use. Try it, you might be surprised.

[public_defender]

I think it's a fair point that compatibility pain is low, but it does exist and people should consider it.

Then there's also play services. A lot of things do work without it, but a lot either won't start (Uber) or become annoying with pop-up errors (Robinhood). It really makes me appreciate software that was designed to work without all that stuff.

[strcat]

GrapheneOS has the sandboxed Google Play compatibility layer. Most banking apps work fine on GrapheneOS. Certain banking/financial services check for a Google certified OS via remote attestation. SafetyNet attestation is deprecated and being shut down and the Play Integrity API is the current way. Both of these support hardware-based attestation available on every device launched with Android 8 or later which cannot be spoofed.

You should read https://grapheneos.org/usage#banking-apps and https://grapheneos.org/articles/attestation-compatibility-gu.... GrapheneOS has full hardware-based attestation support and we use it ourselves in a much more secure way than this weak anti-fraud approach. The long-term solution is convincing major apps wanting to deploy this to allowlist GrapheneOS via hardware attestation.

We currently choose not to ship patches spoofing the traditional software-based SafetyNet attestation / Play Integrity API attestation. The reason for this is because we don't really want to ship a set of hacks which will stop working when they improve it and will permanently stop working when a service starts checking for strong verification. Having users start depending on Google Pay NFC payments working and then having it go away would be a problem for a production quality OS in a way that it wouldn't for a hobbyist project where expectations are different. We don't want to essentially commit to providing something we know is impossible to keep providing due to hardware attestation.

You can only spoof the weak basic verification, and whether it passed strong verification is always there in the result. It's only a matter of time before those services require it. It's based on when they're ready to start phasing out support for devices launched with Android 7.x and earlier along with a few phones that shipped with broken verified boot / attestation support even after it was required such as OnePlus. They can require it only for certain features if they want. Android 10+ is needed for security updates, so if they truly do care about security, nearly 100% of devices launched with Android 7.x and earlier are irrelevant now since only a small portion got upgraded to Android 10 (almost none beyond it) and those are now losing security support. Android 10 will be losing security support soon.

We may reconsider and ship spoofing for the legacy software-based attestation (known as non-strong verification by those APIs) if not shipping it becomes an adoption issue due to others shipping it. It doesn't mean we think it's a good idea but we'd rather have people using a more secure OS than a highly insecure one often without proper security patches and a fake patch level displayed...

[public_defender]

First of all, thanks for the very detailed write up. Someone (maybe you) had explained this to me in a chat and it was convincing to me, but I didn't really do it justice in my comment.

> The reason for this is because we don't really want to ship a set of hacks which will stop working when they improve it and will permanently stop working when a service starts checking for strong verification.

This is what I really like about the project philosophy. I think you all are right even though the decision breaks some compatibility.