This reads shockingly bad, but most of that won't apply to the new devices.
Like, it will be Qualcomm, it will support unlockng, relocking, custom keys and will not have a secret debug key - otherwise there simply would be absolutely no deal with GoS.
IMO these new flagships will not be fully impacted by these issues (if at all), considering how much of the partnership initiative started* at Motorola.
It was likely them providing the GOS team with source code of some of the most critical patches, when Google withheld it for months waiting for Samsung to release patches.
Why? I guess to get the bragging rights to have the most secure android handsets in the world, to improve their own codebase (GOS pushed a lot of patches upstream and perhaps the hardware).
I'm cautiously optimistic - given how allergic the team are to the notion of the enforced compliance imposed by Google, I think it's likely these new flagships will be automatically unlocked in the same way pixels are.
It was likely them providing the GOS team with source code of some of the most critical patches, when Google withheld it for months waiting for Samsung to release patches.
I'm pretty sure reading on Mastodon that it was another OEM that provided them with embargoed patches, but I can't find the Toot now.
Another more important angle: GrapheneOS creates an appliance, where the user has no freedoms, in that freedom aspect not better than stock Android: The users cannot realistically change any aspect of the OS. Sure, technically they could edit the source, but then they need to compile the whole system, reset their device and lose all data, be cut off from easy updates, and additionally lose remote attestation (which GrapheneOS devs call anti-competitive when used against them, but then gladly provide a variant that inevitably will be used against users.) Users cannot wield any more power over their apps than the apps admit. They cannot patch a binary app that misbehaves. They cannot reroute the environment of that app. And so on.
With AOSPs and Graphenes "security model" there is nothing in-between "dumbest user" and "full-blown developer who cannot even be a proper user of that development system". The user to "advanced user" to "power user" to "tinkerer" to dev pipeline is kept dry. Most of power-user's potential self-defense mechanisms against abusive and monopolist app and service providers are intentionally neutered by Android as well as GrapheneOS.
And hopefully less so by "Linux Phones"
Gnunet was and is incredibly advanced technology, solving many problems better than most p2p systems that came after, who never bothered to even look at those ideas, and implemented worse concepts from scratch (IPFS, veilid, libp2p...) However, it is exclusively academic, and the authors let themselves be distracted too much. The system was mainly developed by grad students who mostly leave after they have completed a barely working proof of concept for their thesis.
It never had enough functionality running smoothly enough to attract a meaningful community, which would have been a prerequisite for a p2p network. It is so sad.
Correction: GrapheneOS is concerned with their so called "Android security model" more than anything else, and where that security model gives guarantees to app developers and service providers that harms the user's security, they merrily side with the developer's security against the user, at best give some more or less questionable reasons why that unfortunately currently cannot be changed, and at worst insult you for suggesting anything else.
Here, the Pixel 10, especially in more niche variants like Pro and with larger flash has almost disappeared from the market, or is as expensive as the equivalent Pixel 11 offers.
With direction Google has chosen to go with the Pixel 10, it might as well be that GrapheneOS will never be available on the Pixel 11. They started by not publishing device trees anymore, squashing commits in AOSP, publishing open source drivers as a tar ball dump only after the requester has entered personal data in a web form, instead of having them public in an version control system. I wonder what dumb ideas they come up with next in order to make the GrapheneOS people suffer even more.
Which was not the point. Each one of these changes made it harder, not yet impossible to make a custom Android or Linux variant. The harder it is the more likely people will continue. At some point it might be too hard. Or, one of these changes will finally make all of that impossible.
I think Meneth was basically correct but a bit imprecise: Boot integrity itself is only user respectful as long as the user can freely decide and change the integrity reference values, without consequences to the latter usefulness of their system. But attestation (based on boot integrity) as a principle directly contradicts "respect user ownership".
This is not a question of technical feasibility, but of principle. Attestation is directed against users. The main purpose of attestation is to make sure that the local user can be forced to use a specific software (and not run other software at the same time that could influence this specific software) to access a certain remote service.
Remote attestation means by definition "vendor lock", in that the vendor and their contractual partners lock and control the device's software.
Therefore an attestation model that fully respects the user simply cannot exist.
No, this would just require a publicly verifyable signature of the software, and the user would just choose to have their operating system verify it. No remote attestation or other hand-over-your-controls necessary.
Nope. It is still not possible to give someone else (the government, or the bank) control over your phone while at the same time run software that you alone control with higher privileges.
Please don't mix that up with "is practically hard to implement because of sloppy code.
Also your attacker model is still "occasional evil government agency or evil private corporation wants to crack and read your messages", while what is discussed here is more fundamental "evil government or abusive corporation controls your phone in the first place, and can just remote control it you can't use really secure apps"
I want governments and banks to allow open-source software, not control my phone.
For example, I essentially trust the ROM I download from the GrapheneOS website. What I want is for governments, banks, or some independent open foundation to be able to approve that ROM too, so attestation can work with it.
More like how CA certificates work: not perfect, but not locked to one vendor either.
So now you have the choice between two approved ROMs. Not a lot of improvement? And as soon as GrapheneOS implements something beneficial to the users that the government does not like, the approval will be taken back. That's also why GrapheneOS will probably not even think about doing that.
So you want some OS functionality neither Google nor Graphene offer, you're, again, out of luck.
CA is something completely different, and much more limited in what can be centrally controlled. Everybody can go to a CA, get a certificate for their domain, and use it with any server software, even with software they compiled themselves.
reply