[zb3]

It's a different thing if banking/government apps require a device certified for security, and a different thing if this certification certifies that the user's device has Google spyware preinstalled with elevated privileges..

Google doesn't certify devices basing on security, so that kind of attestation should have no place in banking/government apps, otherwise it just enforces the duopoly

[surajrmal]

It's hard to listen to arguments when everything is so hyperbolic. The stated rationale for attestation for captcha is to ensure there is a human on the other end and not a bot. This requires a system which is not capable of automated input. The other use case is for ensuring that an application is running on a system which protects the app from being tampered with (by the user, malware, or otherwise). While that seems to run counter to the preferences of the hn userbase, it is a legitimate desire from an application developer.

Neither of these situations are related to any so-called spyware. The fact that Google is involved here had to do with the fact that they are a trusted party for folks to rely on to ensure the desired properties are being met, nothing more. In theory it should be possible for other parties to provide similar attestation, but that party needs to be deeply involved in the OS and boot chain. Apple is obviously capable and is equally trusted. Graphene probably provides the necessary properties but lacks a good way to attest due to the reliance on Google specific attestation APIs. That could be remedied. Otherwise Graphene would need to create their own APIs and applications would need to use them, which would be a harder sell. In both cases the party asking for the attestation needs to decide to trust Graphene, which is still a barrier, but that's an easier way forward. Alternatively, Google could trust Graphene and everyone who already trusts Google would inherit such trust.

[nullc]

> it is a legitimate desire from an application developer

I want a pony! A legitimate desire. So it's okay if I rifle through your underwear drawer in case there are any ponies I could take?

Requiring there be a physical phone is a speedbump at best ( https://i.dailymail.co.uk/i/pix/2017/05/12/13/403C0D44000005... ) and so de-anonymizing every person using the internet by attaching them to a device and allowing google to track them is not sufficient, nor is the privacy loss necessary for the kind of improvement they could realistically hope to achieve.

But most over even if the panopticon were highly effective and even if were the only option to achieve that end we should still reject it because it's wrong.

[zb3]

> It's hard to listen to arguments when everything is so hyperbolic.

The frog is slowly being boiled so that people start to accept things which would be unthinkable in the past. Whoever refuses to bend nowadays sounds hyperbolic or insane, but I'm just using the "absolute temperature" here, you know...

> Neither of these situations are related to any so-called spyware. The fact that Google is involved here had to do with the fact that they are a trusted party for folks to rely on to ensure the desired properties are being met, nothing more.

They're NOT fullfilling that purpose here - read the post, insecure devices with Google Mobile Spyware pass that, while GrapheneOS doesn't. Yes, Google is trusted to ensure these security/ratelimiting properties are met, but instead uses/abuses that trust to ensure their anticompetitive business goals are met. Google is not an independent attestation authority and should not be treated as such, what Google is doing here should be (and most likely already is) illegal.

> Alternatively, Google could trust Graphene and everyone who already trusts Google would inherit such trust.

While far from perfect, that would be better, since we'll then only rely on having their hardware (legitimate business) and not their adware/spyware preinstalled with elevated privileges (illegitimate business, illegal monopoly).