Apologies if this has been posted elsewhere but I couldn't find it.

I have a question about what kind of Play Integrity GrapheneOS can pass or not.

Apparently, there's three types:

  • MEETS_BASIC_INTEGRITY
  • MEETS_DEVICE_INTEGRITY
  • MEETS_STRONG_INTEGRITY

According to this table, GrapheneOS can pass only BASIC integrity. However, there are also tools like this and this that claim to pass DEVICE integrity as well. Unfortunately they require root to work.

So my questions would be:

  • which level is used by apps that check for "integrity", like some banking apps do: is it device integrity or strong integrity?
  • which level can GrapheneOS pass?
  • if the answer is BASIC only, would the developers consider implementing a fix to meet DEVICE integrity as well? it seems to be doable?
  • if the developers are opposed to it, is it because of technical reasons (e.g. apps now require STRONG integrity so passing only DEVICE integrity is pointless) or political reasons (e.g. "we don't want to 'spoof' anything, hardware attestation is available for developers and if they insist on blocking GrapheneOS it's not our fault")?

    Viewpoint0232 which level is used by apps that check for "integrity", like some banking apps do: is it device integrity or strong integrity?

    The vast majority of apps, including Google Wallet, only require MEETS_DEVICE_INTEGRITY since devices running versions older than Android 11 (API level 30) cannot pass MEETS_STRONG_INTEGRITY which needs hardware-backed attestation. This accounts for approximately 33% of devices running Google's certified Android (very rough figure).

    Viewpoint0232 f the answer is BASIC only, would the developers consider implementing a fix to meet DEVICE integrity as well? it seems to be doable?

    Yes, GrapheneOS only passes MEETS_BASIC_INTEGRITY, but no, GrapheneOS will not spoof MEETS_DEVICE_INTEGRITY. You can read more about why here and here.

    Viewpoint0232 if the developers are opposed to it, is it because of technical reasons (e.g. apps now require STRONG integrity so passing only DEVICE integrity is pointless) or political reasons (e.g. "we don't want to 'spoof' anything, hardware attestation is available for developers and if they insist on blocking GrapheneOS it's not our fault")?

    Technical reasons: It is not possible to spoof MEETS_STRONG_INTEGRITY, and as is noted in the sources I linked above, Google also has the ability to trivially block attempts at spoofing MEETS_DEVICE_INTEGRITY using GPU fingerprinting. Google would certainly block spoofing it if GrapheneOS’ 250k+ users suddenly started doing it on a large scale. Purely politically, it would also undermine the GrapheneOS developers’ argument that the Play Integrity API is anti-competitive and illegal.

    I speak for myself.

            Viewpoint0232 afaik the older method of verification, Safetynet could only be spoofed by pretending the device had no secure element.

            Like the user above said, this would undermine security, adapting to the hillarious blocks that Google uses, while allowing insecure devices.

            I also think spoofing a value for MEETS_DEVICE_INTEGRITY could be done and would certainly be helpful for users.

            Would if make GrapheneOS look professional? No. Does Google look professional with their garbage integrity check? No either.

            So I don't really think this would harm any tries to get a function into the Integrity Check, that checks for hardware attestation which overwrites the weak integrity check. Like, the argument, the problem and the implementation are still fair, in front of the EU commission. Hardware attestation cannot be faked. So having such a workaround would even prove the point that the current method is insecure.

              I'm not familiar on how play integrity checks works but I think it they are a workaround to bypass it GrapheneOS will to include it then let users to decide if use or not, specially now than apps, like revolut, are moving to block GrapheneOS and other custom ROMs.
              If GrapheneOS cannot include it maybe can explain how auto compile a version of the software that includes it.

                cdflasdkesalkjfkdfkjsdajfd they would have to do it so, that the bypass recipe could not be linked to them in any way. They claim their software building process is clean, audited, so they cannot officially provide a hack. All is politics. For banks, unpatched old stock android is more trusted than graphene.. ehh. that's the way it is. Enshittification everywhere.

                  cdflasdkesalkjfkdfkjsdajfd I'm not familiar on how play integrity checks works but I think it they are a workaround to bypass it GrapheneOS will to include it then let users to decide if use or not, specially now than apps, like revolut, are moving to block GrapheneOS and other custom ROMs.
                  If GrapheneOS cannot include it maybe can explain how auto compile a version of the software that includes it.

                  I don't expect the GrapheneOS developers will include any such tool--if only because it would need privileges, and thus would need to be carefully audited, and that's aside from whether the developers would want to take the project in that direction, which I suspect they don't. I also wouldn't expect the GrapheneOS developers to publish/maintain a guide on how to do something that they don't believe is in the interests of the project.

                  For whatever it might be worth, a GrapheneOS fork won't attest as being a legitimate GrapheneOS build. The exact details of how the UK Starling Bank is accepting GrapheneOS are unclear, but it is at least possible that the Starling app will work on genuine GrapheneOS builds but not on private builds.

                  Overall, spoofing integrity checks is probably doomed. It arguably makes sense to use the current time window to educate app developers in the direction of reasonable policies before unreasonable policies become further entrenched.