upvote
My impression is that they are against remote attestation in apps/websites in general and if apps really want to do it, they should do it using the attestation API that AOSP already provides. The attestation API in AOSP allows companies to trust signing key fingerprints (such as those of GrapheneOS), which means that the attestation system is not controlled by a single company (Google).

The most damning part about Google Play Integrity is that, as the thread states, that Google lets devices pass that are full of known security holes, whereas they do not allow what is very likely to be the most secure mobile OS. This shows that they only use it as a method to shut out competitors and to control Android device manufacturers to pre-install Google software like Chrome (otherwise their devices do not get certified and won't pass Play Integrity).

IANAL, but anti-competition lawyers/bodies should have a field day with this, but nobody seems to care. Worse, the EU, despite their talk of sovereignty adds Play Integrity-based to their own age verification reference app.

I recommend every EU citizen, also if you do not use GrapheneOS, to file a DMA complaint about this anti-competitive behavior:

https://digital-markets-act.ec.europa.eu/contact-us-eu-citiz...

Also, every time this comes up, @ the relevant EU bodies, commissioners and your government's representative on Mastodon, etc.

reply
> The attestation API in AOSP allows companies to trust signing key fingerprints (such as those of GrapheneOS), which means that the attestation system is not controlled by a single company (Google).

I wonder if this would exclude rooted OSes, non-relocked bootloaders and things like that? Sorry for stupid question, still not quite understanding how this works.

reply
Currently probably not, because there are leaked keys, etc. But otherwise it would, since the verified boot state, etc. is added as part of the signed material.
reply
> very likely to be the most secure mobile OS

> IANAL, but anti-competition lawyers/bodies should have a field day with this, but nobody seems to care

I'm gonna take a wild guess that proving the above statement in court (and then its necessary impact) might be a significant obstacle here?

reply
You don't really "prove" statements like that. You get some "expert witnesses" to testify one way or another, and your opposition gets some "expert witnesses" to testify the opposite, and then the judge/jury decides who they think was more credible.

I imagine the way to do this effectively would be to get some well-regarded infosec firms to audit both OSes (from source as much as possible), and also compile lists of vulnerabilities found, fixed, not-fixed, etc. over time. Then you need a witness who can explain all of it in a way that's accessible to and likely to sway a jury.

reply
> Am I understanding correctly that [...]

What I took away from the thread is that they're against services forcing attestation in general, and also pointing out that Play Integrity isn't about security, but rather about control, because Google could trivially make it work with GrapheneOS (which is more secure than any other Android OS on the market) but they won't.

reply
> …Google could trivially make it work with GrapheneOS (which is more secure than any other Android OS on the market) but they won't.

But if Google did support third-party attestation, would the GrapheneOS Foundation be happy? Most of the thread seems to be a call for attestation to die, which feels impractical and unachievable. But "Google could use it to permit GrapheneOS for Play Integrity if that was actually about security" seems to be the real ask, and that seems reasonable and achievable. If that's true, I think it would’ve been more effective to lead with that and focus on it.

reply
Why should Google decide which devices are safe enough to pass remote attestation? Seems to me that if we want this at all, it should be an independent body that approves signing keys of vetted vendors (e.g. vendors roll out security updates timely, etc.).

As long as this is in Google's hands, they can abuse it to control the market.

That said, Play Integrity accepting GrapheneOS would be a step forward, but they will never do it, because then other vendors might also want to pass attestation without preloading Google apps.

reply
> Seems to me that if we want this at all, it should be an independent body that approves signing keys of vetted vendors (e.g. vendors roll out security updates timely, etc.).

This is also a horrible idea. If an OS can be vetoed for untimely security updates, it can also be vetoed for not having something like clientside scanning.

reply
Then you’re just replacing one DRM cartel with another.

What would even be the criteria for approval? Pinky promise to not let the end user have full control of their own device? That’s all “integrity” really means in practice. Don’t be fooled by appeals to security.

reply
No. That would be a relatively better circumstance, but we would still have the root problem.

> Most of the thread seems to be a call for attestation to die, which feels impractical and unachievable.

I disagree, and I expect GrapheneOS devs do, too. Hardware attestation is a new thing, that isn't even really here yet. It absolutely can and should meet its demise.

reply
It is not only about Google. Its also about the App developers. Nothing prevents them to use the non-google attestation, however they decide not to use it (for many reasons). First time you actually notice this is when you installed GrapheneOS (attestation OK and bootloader locker) and some apps complain about a modified/rooted/... device. Another thing is, that you are warned by your Google device while booting that something is "not OK".
reply
It's impossible to say. But as a reminder from Cory's first talk on enshittification... When Google and Facebook were small, they would argue for open protocols and competition. Facebook would reverse engineer MySpace's protocols to allow people to migrate away. Once FAANG became dominant, they went the opposite direction to built monopolistic practices.

GrapheneOS is still small and appears honest. Despite them being in the right in this fight and them deserving our support... We gotta keep them honest in the long run!

I don't think there's any way to tell if a small company will keep their values if they succeed in getting enough market share.

reply
> I don't think there's any way to tell if a small company will keep their values if they succeed in getting enough market share.

That is why all companies should be small and no company should ever have a huge market share.

reply
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

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

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

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

reply
There's a thread awhile back where there were VERY angry at someone trying to setup their own attestation project database (essentially a list of known Android builds and their signatures).

They want apps to add their signing hashes manually just for them and don't want to join projects that would aggregate and act as a database or certificate authority.

reply
You mean Universal Attestation, which is from a vendor cartel, of which most of the individual vendors are typically waaaaay behind security updates, etc.
reply
No, it wasn't those. It was another EU org.
reply