zlacker

Thanks for the reply, yeah, my interest was to test compatibility when we add support for Play Integrity to our app.

>>neodyp+(OP)
Please read https://grapheneos.org/articles/attestation-compatibility-gu.... It's possible to support GrapheneOS by using the Android hardware attestation API either as an alternative to the Play Integrity API or instead of it. By using the hardware attestation API, you can make a list of allowed key fingerprints for the SelfSigned boot state for non-Google-certified operating systems. We list all our current keys for non-end-of-life devices on that page. Recently, Swissquote used this approach to add support for GrapheneOS to their Yuh app and may be adding it to their main Swissquote app soon.

You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/.

>>neodyp+(OP)
Please don't add play integrity to your app. There are many of us using custom ROMs, and it can relatively easily be worked around, but very much is often a giant screw you to technical users...

>>neodyp+(OP)
What problem do you think Play Integrity solve other than keeping the user's under Google's walled garden? Play Integrity is a fake marketing term for DRM fromGoogle . It does not guarantee security of the device in any way. My 6~ year old and unpatched Android 10 passes Play Integrity and can run banking apps. That explains everything about Play Integrity. I don't use apps from developers who think they know better than their users.

>>Algebr+ff
>What problem do you think Play Integrity solve other than keeping the user's under Google's walled garden?

It ensures requests to your backend are vaguely from actual devices, rather than a bunch of emulators. There's many reasons why developers might want this. It significantly raises the bar for credential stuffing attacks, for instance.

>>gruez+1K
Yes, developers are of course going to opt for APIs that allow them to be as lazy as possible, forego proper backend security, and reduce costs. But is allowing developers to be lazy worth the cost of destroying user freedom? If so, maybe we should work on bringing back the Web Environment Integrity API. That would really help out web developers and would make web apps a lot more secure. Nobody uses Linux on the desktop anyways besides weird nerds so it wouldn't have any real impact.

Can't wait until we finally kill hacker culture for good. Everyone and everything will be fully secured. It's going to be beautiful. The nerds can cry about it all day long, but they're powerless to stop it.