Comment by microtonal
Comment by microtonal 4 days ago
Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
> If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.