zlacker

>>dagurp+(OP)
This is especially rich coming from google's, who's 'safetynet' for android results in a significant reduction in security (contrary to its stated purpose): it locks out 3rd-party up-to-date and secure ROMs while allowing horrificly insecure manufacturer-provided ROMs to still pass, because to disable those would cause a massive user outcry. So it functions as a vendor lock-in but no meaningful increase in security for the average user, while preventing more advanced users from improving their security without needing to buy more hardware. This needs to be called out more to push back against the claim that this kind of attestation somehow has a legitimate benefit for the users.

>>rcxdud+5F1
This is especially rich coming from google's, who's 'safetynet' for android results in a significant reduction in security (contrary to its stated purpose): it locks out 3rd-party up-to-date and secure ROMs while allowing horrificly insecure manufacturer-provided ROMs to still pass, because to disable those would cause a massive user outcry.

That's not the case with GrapheneOS:

https://grapheneos.org/articles/attestation-compatibility-gu...

SafetyNet is deprecated anyway:

https://developer.android.com/training/safetynet/deprecation...

>>ThePow+oN3
I think you’ve misunderstood both posts.

SafetyNet is deprecated, but it’s just been rolled into Play Integrity which does all the same things. All the same concerns still apply to Play Integrity.

GrapheneOS is asking developers not to use SafetyNet/Play Integrity (because they presumably block GrapheneOS), but instead to use the native hardware attestation API so they can specifically allow GrapheneOS keys. If a developer doesn’t allow their keys, they’ll be blocked.