The GrapheneOS supporters are not on our sides, apparently. The seem to actually like remote attestation. They just don't like that they are not in on Play Integrity. But what is won if attestation includes official GrapheneOS releases but would still otherwise be exactly the same evil stuff that takes control of the user's device?
I still am hoping that at one point they understand the full consequences of remote attestation. There are some signs they start to notice, but it's slow...
GrapheneOS users can hold two opinions at the same time in a consistent way:
- Remote attestation is bad, anti-competitive, and reduces privacy.
- Given in a world where remote attestation exists, GrapheneOS should pass attestation, since there are no security reasons not to.
Both battles should be fought at the same time, because if governments do not want to ban remote attestation, you want to make sure that at least it's not in the hands of companies that abuse it to maintain their duopoly.
Focusing on only one of them can lead to worse outcomes.
Note that I am a GrapheneOS supporter. You seem to have a few misconceptions.
GrapheneOS is one of, if not the most vocal organization against the abuse of attestation mechanisms. GrapheneOS and its userbase feel the consequences of play integrity every single day.
Im not sure where you got the idea that all GrapheneOS wants is to be accepted by play integrity, because that is not the case. GrapheneOS has been working with regulators to get play integrity banned. Being accepted by play integrity, but nothing else changing, is not good enough for GrapheneOS. It would only be a small victory along the path of abolishing this nonsense.
So, no, GrapheneOS and its community are definitely against play integrity. The "signs" that they are "starting to notice" are not there. They are already fully aware of what attestation is and how it can be abused. They are definitely not ignorant on the subject.
You might be confusing root based attestation with pinned attestation. Root based attestation is flimsy and allows tools like play integrity to ban operating systems they do not like. Pinned attestation, on the other hand, has real security properties and cannot be abused to block certain operating systems. GrapheneOS uses pinned attestation as a part of their Auditor app, and it has other cool uses we could see in the future.
My opinion: Any kind of attestation that is delivered to a non-user-controlled server about the state of a user's end device that the user (possibly using means outside of the end device) cannot change will be abused, e.g for anti-competitve purposes.
I am hearing lots of arguments that grapheneOS is more secure (it is) and should therefore be included in remote attestation.
The pinning you are proposing, does it imply that there is again some certification of the "official" GrapheneOS, versus e.g. the user's own fork of GrapheneOS?
How would any of the existing proponents of remote attestation agree to anything like this, given what we consider abuse is exactly their reason of implementing it in the first place?
Here, VW wants to stop use of the API by anything else than their App, in order to stop hobbyists and sell API access to commercial middle men. If the user could pin their own software's attestation or even register an arbitrary public key to cover updates, then the user would as well be able to code his own API client that just emulates the attestation.
Is there any write up or discussion of the pinning you propose?
I am really not yet convinced how you want to counter the inevitable abuse that app developers and service providers will subject the user to if the OS security model gives them that kind of power over the user's end device.
To start, all attestation is remote. It fundamentally has to be remote, be it a server or another device.
GrapheneOS points out how its improved privacy and security should mean that it is accepted in a system like play integrity. But this is just to outline how flawed the logic of play integrity is. It is by no means an endorsement of play integrity. GrapheneOS wants people to know that google is lying and breaking the law, and uses its own exclusion as that evidence. Even if GrapheneOS were accepted into play integrity, it would still exclude any and all forks and self-signed builds of GOS, which is unacceptable. If companies absolutely insist on using this approach despite its flaws, they should use the generic attestation available in android, and permit using 3rd party roots of trust in some form, rather than outsourcing this verification to 3rd parties like google.
As for the pinned attestation approach, that is Trust On First Use, and is used to verify the integrity of a device based on the security of the devices early bootchain. The initial attestation is what future attestation is pinned to. This allows you to verify a device is the same one, it has not been downgraded, has not been tampered with, etc. This is awesome, and lets you do things like what GrapheneOS does with Auditor. But this is not used to restrict what operating systems are used. Root based attestation somewhat tries to resolve the Trust On First Use approach, but is used to arbitrarily ban operating systems in practice. It is super flimsy as any leaked keys can bypass it.
My only concern is your claim that GrapheneOS is for this technology when it is most certainly against it. The nuance is that pinned attestation is a different approach with different properties, and advocating for it does not mean GrapheneOS is not an ally against play integrity.
Auditor also functions as a proof of concept for the potential of attestation, check here for more info: https://attestation.app/about
They already add cryptographic authentication to some CAN messages, so you can't change them. It is only a matter of time until they add encryption.
This is mostly a corporate problem of risk aversion in my opinion. Some department
writes down a risk assessment with a list of miniscule risks, for example of some 3rd party app backend being hacked. Or just a headline "Tinkerer hacked his car to use with his home assistant" in the local press.
This list circulates, and since nobody in the middle management wants to be responsible for anything, and there is no officially approved positive use case, draconian countermeasures are drafted and constructed one by one.
> draconian countermeasures are drafted and constructed one by one.
Except when it’s about privacy or anything else we actually care about: then absolutely nothing is done because it would cost more than 0 to do anything.
Depends. In some sense EU companies are quite afraid of the GDPR. Privacy is used in a twisted way in that argument: if any privacy relevant data is exposed to another party, and there is any incident down the line, they fear they could be made responsible. So they to block you as a user to access your own data.
Of course, if that privacy risk came from them storing and selling your data, they happily accept that, you are right in that regard.
I suspect the manufacturer probably cares less about what you do to your own car and hacking it, than they do about the potential for security compromise of their products on a broader scale, where they will then get blamed and sued for not having closed said loopholes. It is a no-win situation when it comes to fault assignment.
It actually happened with Toyota around 2010: they went into a settlement regarding an unintended acceleration issue because it was proven the code was terrible and a single bit-flip could cause the behaviour.
Bit of context to this, it was demonstrated that it was a hypothetical possibility, but the issue couldn't be demonstrated in lab conditions. Stuck floormats, pedals, and confused drivers remain the only actual explanations for the real events behind the lawsuits.
“ A mobile phone with 500 kilobytes of memory might only have one error every 28 years, but a router farm, such as those used by Internet providers, with 25 gigabytes of memory could have one every 17 hours.”
I wonder if current AI devices have protection against this…
It’s a fair assumption that most of these things are trickle-down effects of CMS/R155 and CRA combined with very high risk aversion on the company side. The less you expose, the lower the risk.
Their security model requires remote attestation. So, open, user-controlled platforms cannot be used. Of course some other future locked-down linux-based OS might be usable.
Remote attestation in theory includes all aosp-compliant attestation implementations (in practice that's GrapheneOS already), but the current project plans and implementation openly reject it.
Only "open" in a twisted sense, and definitely not user-controlled: Remote attestation per definition means to accept only pre-approved operating systems. If anybody builds an implementation, regardless whether it is aosp-compliant or not, this will be excluded, until the App developer or someone in the chain explicitly approves that implementation.
That is the whole purpose of that technology.
Including GrapheneOS in that pre-approved list just shifts power from Google and the App Developer to GrapheneOS Developers and the App Developer. Nice for GraphenOS, still bad for users and devs of any other OS variant or platform.
Yeah but many devices still do not support it, and if they support it, then badly, or they hide it.
There is not even a USB-Bluetooth adapter that would enable LE Audio on Linux. (Besides the hacky ones that contain a full Bluetooth stack and present as USB-Audio, but those come with their own problems.)
Microwaves are a bad example. The cheaper ones are white labels basically all made in the same factory in China. The customer has no way to know if the slightly more expensive one is actually more durable or, much more likely, just the same, but generates more profit for the intermediaries. In this situation it is wiser to get the cheaper one.
Consumers have no way to tell that a phone gives "privacy" or even to understand the implications of that to their life. They have a significantly easier time understanding an error message that says "because your device has an unlocked bootloader, you can't use the <name of bank> app"
> Consumers have no way to tell that a phone gives "privacy" or even to understand the implications of that to their life.
This is the sort of thing anyone can look up on the internet before buying one.
The reason that doesn't work for white label microwaves is that the manufacturers don't want it to. The off brands exist so they can make sales to people who prioritize price, and they purposely change the company name every month so no one can find a review of the off brand and the same company can sell the same microwave with a higher margin to other people who will pay more for the name brand.
Whereas when your company makes a phone with better privacy etc., you want everybody to know that so they buy your phone instead of a competitor's.
> They have a significantly easier time understanding an error message that says "because your device has an unlocked bootloader, you can't use the <name of bank> app"
Indeed, it immediately lets them know that their bank sucks and they need a better one. (It's actually a pretty decent red flag that your bank has a cargo cult security team.)
> This is obviously false. It's the sort of thing anyone can look up on the internet before buying one.
It's not something that's quantifiable, and it's easily manipulable. The iPhone(tm) has a twelth-generation quantum superconducting wonderflonium chip that enables (pile of technobabble garbage) and "privacy".
This Motorola thing has (pile of technobabble garbage) and "privacy".
Consumers don't understand and they don't care. Even the ones with technologically savvy friends don't want the hassle, they want something that works.
How has 30 years of "Microsoft is anti-consumer and <pile of complaints>, you should use Linux" worked out for consumer market share?
> Indeed, it immediately lets them know that their bank sucks and they need a better one.
If you think even 0.1% of consumers would switch banks to buy some new phone, this conversation is not worth continuing as you and I don't live in the same reality.
> It's not something that's quantifiable, and it's easily manipulable. The iPhone(tm) has a twelth-generation quantum superconducting wonderflonium chip that enables (pile of technobabble garbage) and "privacy".
That's the marketing noise from the company itself. Then you go to Reddit or similar and ask technically competent people what they recommend.
> Even the ones with technologically savvy friends don't want the hassle, they want something that works.
The phone that supports open operating systems is the one that's less of a hassle. It doesn't go out of support even though there's nothing wrong with it, it isn't full of spyware and weird bugs because people can actually fix them when the OEM doesn't, it has a working ad blocker etc.
> How has 30 years of "Microsoft is anti-consumer and <pile of complaints>, you should use Linux" worked out for consumer market share?
Windows market share was >90%, now it's 67% and still falling. And that's just desktops; Microsoft was completely abandoned in the mobile market because they were so widely hated. By most accounts Windows Phone was actually decent but being from the notorious company whose OS nobody uses unless they're locked in was a death sentence.
> If you think even 0.1% of consumers would switch banks to buy some new phone, this conversation is not worth continuing as you and I don't live in the same reality.
You're not switching banks to buy a new phone, you're switching banks because when you bought a new phone it made you realize that your bank sucks. Which annoyed you enough to spend five minutes checking out other banks, at which point you realized there are credit unions that not only support your new phone but pay better interest rates and charge lower fees.
Then you remember that time when they charged you that fee for some BS reason last year and you swore you were going to get a new bank but never got around to it, and decide that you'd rather get on with what you always intended to do sooner rather than later instead of replacing your new phone that you otherwise like.
>Microsoft was completely abandoned in the mobile market because they were so widely hated.
This was not a factor. Windows phone lost because they didn't have apps. They didn't have apps because they rewrote between Windows Mobile 6 and WP7, and rewrote between WP7 and WP8, and rewrote between between WP8.1 and WP10. That's a lot of work for developers and they didn't have enough users to justify developers rewriting their apps that many times. Combine that with some companies refusing to build apps at all (YouTube refused to write an app and sued to block Microsoft from writing their own YouTube client) and users didn't want to put up with the lack of apps either.
> This was not a factor. Windows phone lost because they didn't have apps.
They didn't have apps because nobody likes them. If you're a user and you expect them to be well-liked then you buy the phone expecting others to buy the phone and developers to target it. If you're a developer then you make apps expecting enough users to buy the phone.
But if you don't like them and you're not sure anybody else is going to like them then you play wait and see instead, and so does everybody else, and so they have no apps and no users and people start to see that they have no apps and no users.
Which is why they kept changing things trying to force people to do it, giving Windows 8 that widely-disliked tablet interface on desktops etc.
> YouTube refused to write an app and sued to block Microsoft from writing their own YouTube client
Oh no, did someone with a dominant OS market share do an anti-competitive thing to Microsoft?
You're asking why people don't pick up Linux faster but you can see the symmetry when it's going the other way. It's not that they don't want to, it's that 80% of enshitification is lock-in.
Motorola omitted a magnetometer in some of their models. This was especially heinous as the "compass needle" can be emulated to some degree by fusion if gps and rotation/acceleration sensors, so the user wouldn't immediately notice the total lack of a compass.
Since then I am always wary of what seemingly essential part of a phone they will omit this time...
In fact Motorola did the opposite: they recently announced that in their opinion they found a loophole in the EU ecodesign regulation that they will exploit in order to not provide updates for some of their cheaper phone models.
After that, why would anyone trust any of their promises for other models?
I looked into this and it seems like Motorola is coming up with a contrived interpretation of the ecodesign regulation (EU reg. 2023/1670, annex II, "Design for reliability").
Specifically they seem to be interpreting this to mean that they only need to make the update available (i.e. downloadable) for 5 years iff they release an update.
> (a) from the date of end of placement on the market to at least 5 years after that date, manufacturers, importers or authorised representatives shall, if they provide security updates, corrective updates or functionality updates to an operating system, make such updates available at no cost for all units of a product model with the same operating system;
However recital 7 makes the intent crystal clear:
> It is currently not possible, or extremely difficult, for the owners of mobile phones, including smartphones, and tablets to change the operating system of their device, which is chosen and maintained by the manufacturer through regular updates. Such updates generally lead to the establishment of a range of major and minor versions. Updates may be used to ensure the continued security of a device, to correct errors in the operating system or to offer new functionalities to users. They may be offered voluntarily or might be required to be offered by Union law.
> In order to improve the reliability of devices, therefore, it needs to be ensured that users keep receiving such updates for a minimum period of time and at no cost, including for a period after the manufacturer stops selling the relevant product model. Such updates should be offered either as updates to the latest available operating system version that has to be installable on the device, or as updates to the operating system version that was installed on the product model at the moment of the end of placement on the market, or subsequent versions.
They're not getting any points for this, it's anti-consumer and makes a mockery of the law, but I don't think it's an actual loophole and they'll be punished for it if they don't comply.
However all other OEMs are acting equally poorly in other areas so this really shouldn't be the reason for anyone to pass on GOS-powered Motorola devices, especially since this is the one area that's ~guaranteed to be completely different in partnership with GrapheneOS.
Motorola Signature (2026) has 7 years of support. It's a subset of Motorola's future devices in 2027 and later which are going to support GrapheneOS since the current ones in 2026 didn't quite meet all of the requirements yet. The intent has never been to support their existing devices but rather for future devices to provide everything needed and official GrapheneOS support. There's a lot of work to do. Meeting all of our requirements on low-end devices is currently unrealistic but can be a goal further down the road.
Motorola, the one company that still tries to evade the EU ecodesign regulations?
Other vendors just provide the required 5+ years of updates, but Motorola loudly and publicity announced that they saw a loophole in the wording and would use it as an excuse to not provide updates for some models.
This is despicable and worthy of a boycott.
"Operating system updates: From the date of end of placement on the market to at least 5 years after that date, manufacturers, importers, or authorised representatives shall, if they provide security updates, corrective updates, or functionality updates to an operating system, make such updates available at no cost for all units of a product model with the same operating system."
Motorola has committed to 7 years of support for the 2026 variants of the devices which will provide GrapheneOS support in 2027. There's still a lot of work to do in order to meet the GrapheneOS hardware requirements and there isn't going to be support for the existing devices. The whole point is they're working with us to improve their updates and hardware-based security features so that all our requirements are met. The stock OS is also a different thing than the official GrapheneOS support where we'll be making builds with their help. We'll be continuing to provide security preview patches and intend to move to newer kernel LTS branches than Qualcomm if they don't do it themselves.
GrapheneOS won't have to use their stock OS to get firmware, etc. as we do for Pixels.
I still am hoping that at one point they understand the full consequences of remote attestation. There are some signs they start to notice, but it's slow...
reply