@GrapheneOS I have been thinking about what could be the legitimate cause the developers choose Google Play Integrity API, besides their probable ignorance and misinformation. I see the following reason why they could be reluctant to use Hardware Attestation API and even ban GrapheneOS alongside other OSes:
In the event that a malicious actor gets access to the app's private signing key, if the server mandates the "appLicensingVerdict": "LICENSED" value from GPIA, it ensures the delivery chain of trust and creates some sort of two factor security, requiring the hack of the store or the hardware attestation itself to make use of the key. As a bonus, Google has the biggest store to rely on and if they fail, the whole world is on fire, all the blaming fingers would be pointed at Google, not at the app's developer. The shift of responsibility and accountability is convenient for both, no matter big or small company.
In case of only using HAA, it's trivial to spoof the installation source and bypass other means of detecting that the key has leaked, the app is not genuine. This eases the attack on high value targets, abuse of the service, usage of stolen credentials, scams...
If the HAA could include and guarantee the sourcePackageName and sourceSignatureDigest from the moment of last installation/update, it would offer parity with the GPIA feature mentioned above.
I wonder if it would incentivize more adoption of HAA by the app devs.
I am interested in your thoughts about this. What did I miss? What did I get wrong?
Also "Play Protect verdict" could be of interest to some devs. I do not imagine a viable alternative, only combining HAA and GPIA by the app.