Comment by bri3d

> 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.