upvote
> it would be better if they removed the claim “It doesn't provide a useful security feature” because, even if it does,

What evidence is there that it does?

Attestation purports to prove the code is running on an "approved" device. There are multiple reasons that has no real security value.

The first is that "approved" not only has no relationship to "secure", they're actually anti-correlated. As the article points out, GrapheneOS has better security than normal Android. Moreover, as a general rule the stock firmware that can pass attestation is more likely to be outdated and have security vulnerabilities than a custom ROM, and also as a general rule devices (like PCs) with more open hardware have the ability to be updated. A four year old attestation-passing Android phone may already be out of support and unable to be updated while still passing attestation; a 20+ year old PC can run the latest supported release of e.g. Debian.

The second is that "secure" and "runs code the service doesn't want" are likewise unrelated. Suppose there is an Android device which is still receiving updates. A local privilege escalation vulnerability comes out and that device will get the patch, but hasn't yet. So now any attacker with any of those devices can get root on it until they apply the patch. Which means they can get root after the main filesystem is unlocked, modify the filesystem so they continue to have root by changing something that isn't part of the attestation hash but still causes code or scripts to run as root later, and then update to the latest kernel and continue to have root on a device that passes attestation. The device is secure -- fully patched -- but it's the attacker's own device and they can run arbitrary privileged code on it. Requiring every device to be "secure" against the person who has ownership and permanent physical possession of it is a ridiculous thing to take as a security assumption.

And the third is that attestation doesn't actually do what you want it to anyway. Banks want to make sure the user isn't entering their credentials into a compromised phone, but having the official bank app refuse to run on that phone doesn't actually prevent that, because the fake bank app which is stealing the user's credentials on a compromised device won't require attestation to pass regardless of whether the real one does.

reply
> Attestation purports to prove the code is running on an "approved" device. There are multiple reasons that has no real security value.

BART (San Francisco Bay Area Rapid Transit), as a real world example, recently installed "evasion-proof" fare gates, and observed a 90% drop in vandalism-related maintenance expense. An overwhelming majority of fare evaders are not vandals, but apparently nearly all vandals were fare evaders. Bayes' theorem in action.

I don't have any data to back this up, but my sense is that attestation is an analogous situation.

In other words, banks and governments and other such institutions have noticed (and they probably do have data to back this up) that very few of their customers use "unapproved" devices and a very large majority of fraud comes from "unapproved" devices. They view banning unapproved devices as a high-ROI means to reduce fraud.

So, any argument predicated on "attestation is not security" is doomed to fail, just like saying "most fare-evaders aren't vandals". Yes, most people running GrapheneOS aren't trying to commit bank fraud, but the banks don't care about that if nearly 100% of fraudsters are using unapproved devices.

reply
> In other words, banks and governments and other such institutions have noticed (and they probably do have data to back this up) that very few of their customers use "unapproved" devices and a very large majority of fraud comes from "unapproved" devices.

What would cause you to think that to be the case?

There are two primary ways that bank fraud happens. The first is that the attacker steals the user's credentials, at which point they can sign into the user's account and transfer funds, and can use any device the bank requires because they already have the credentials. The second is that the attacker convinces the user to transfer the money and then once again the user is using an approved device if that is required, and requiring it in no way prevents the attack.

Moreover, even if there was a statistical correlation -- which there is no reason to expect in this case -- that doesn't help you when the attackers could just use their stolen credentials on an approved device anyway, regardless of what they were doing before.

Vandalism can be reduced by excluding fare evaders because that's a class of people rather than a class of devices. Requiring the attackers to use an approved device when the approved device still allows them to commit the fraud accomplishes nothing.

reply
I feel like the complaint about this not adding to security could be read in a really wrong way. Instead of "this is some hypocritical BS", could be interpreted as "lol let's lock EOL devices from even lower integrity tiers". Doubt this is possible because so, so many people use EOL phones, but still.
reply
Doubt this is possible because so, so many people use EOL phones, but still.

Because many people have fortunately realised that "EOL" is just an excuse to create lots of e-waste and push even more hostile unwanted changes.

reply
Eh, not really. Using EOL devices is genuinely a bad idea, it's just that with phones you have no choice due to the updates usually being only like 2-3 years and alternative OSes not being as accessible as Linux. And most people don't even care or know anyway.
reply
That's one of the two main claims made by in favor of hardware attestation; so it makes sense to argue against it. Of course, the other claim (that categories of people must be kept "safe" from categories of content) is more insidious, so it does deserve more attention.
reply