GrapheneOS is focused on privacy but that must come from a secure baseline.
GrapheneOS is much more privacy focussd than any other mobile operating system. Accrescent is the end goal for a secure and private app store but it's still in alpha. GrapheneOS is also the best for degoogling (eliminating all google services) because it comes with zero Google services unlike all the other ones listed here: https://eylenburg.github.io/android_comparison.htm
How can you call other OSes more privacy focused when they haven't closed as many VPN leaks as GrapheneOS? That's like bare minimum for privacy.
Verified boot does indeed make this more complicated, but it's totally possible to build Graphene with your own signing key and get full control over the OS that way (i.e. https://github.com/schnatterer/rooted-graphene).
Looking at their public statements on the matter, it seems like the problem isn't exactly that they treat the user as a potentially hostile actor so much as that they treat the system UI and persistent storage as a potentially hostile actor (though I admit from a practical perspective that's nearly the same thing): https://www.reddit.com/r/GrapheneOS/comments/13264di/is_root...
I believe you misunderstand what "software freedom" means. You can compile and install GrapheneOS yourself, and you can grant yourself admin access. This is software freedom.
Software freedom does not mean that you should run everything as an admin, always. And just in case: software freedom does NOT mean that you should remove your firewall and let everybody SSH into your server by having a blank password.
You can't grant yourself admin access with the official build. Only the Graphene devs have the ability to push changes to the OS on your phone. Yes you can fork the software and build a version with your own signing key, then wipe your phone and install your custom build and thereby take back control, but then is that really still Graphene?
I think it's fair to say that that's at least borderline anti software freedom, even if it's true they have good security reasons for doing things that way.
Thinking about possible ways they could retain the same security properties without impinging software freedom... maybe there's a way they could make the root of trust default to a signing key embedded in the device's own secure hardware? Then by default that key could sign Graphene's own signing certificate to allow them to push updates, but the user would retain the ability to revoke that signature and sign someone else's certificate instead (or their own certificate) if they decided they didn't trust Graphene anymore, or wanted to give themselves root.
I am confused, why were your messages flagged? I disagreed with you, but I didn't see a reason to flag them? Also I don't know how to flag a message, but that's another topic.
It's not flagged now. But yes, way too many people use flags as an "I disagree" button these days. I feel like that used to be very rare (even down-votes aren't supposed to be used that way) and is becoming more common, though maybe it's always been this way and I just hadn't been on HN long enough to notice the pattern until now.
> I think it's fair to say that that's at least borderline anti software freedom
Then you don't understand software freedom either.
Software freedom doesn't mean AT ALL that random projects on the Internet MUST implement the features YOU want. Never, not at all, it's not borderline, it's not up to debate.
Software freedom is about being able to use the software the way you want, as in "you get access to the sources, you modify them, build them and run them". You can do that with GrapheneOS (well except for the binary blobs situation, but that's not in GrapheneOS' hands at all). Software freedom is NOT about GrapheneOS giving you root access on official builds because you want it. And it's also NOT about GrapheneOS installing Doom on the official builds because I want it.
> Software freedom is about being able to use the software the way you want
You can't use the software in the way you want if it uses hardware backed cryptography to block you from doing so.
> you get access to the sources, you modify them, build them and run them
This is completely infeasible for 99% of the population. If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
You could argue "but someone else could modify it for you, build it, and make an easy way for you to install it", and normally I'd accept that, but given that installing that modified version would require you to completely reset your phone and install the new modified OS from scratch, I think it's debatable at that point whether you'd still be running Graphene, rather than a fork. And if exercising your freedom requires you to stop running Graphene and start running something else, is it really fair to say Graphene itself supports that freedom? Like I said, borderline.
If you're still not convinced, consider what would happen if companies started using remote attestation to verify you're running the official GrapheneOS build and block forks...
> You can't use the software in the way you want if it uses hardware backed cryptography to block you from doing so.
You can use the software the way you want, from sources. If I run an open source server at home, it does not give you the right to enter my house and come reboot my server, does it?
> This is completely infeasible for 99% of the population
Sure, it isn't. Still that's what software freedom is.
> If you technically have a freedom but have no practical way to exercise it, it may as well not exist.
I disagree, I'm very happy that free software exists.
> I think it's debatable at that point whether you'd still be running Graphene
It's not: you're running a fork at that point. That's precisely how free software works.
> And if exercising your freedom requires you to stop running Graphene and start running something else, is it really fair to say Graphene itself supports that freedom?
Yes! Again that's precisely what software freedom is about! When you run GrapheneOS, you have the freedom to fork it and run it however you want. When you run Windows or macOS, you don't.
> If you're still not convinced, consider what would happen if companies started using remote attestation to verify you're running the official GrapheneOS build and block forks...
Well GrapheneOS would still be free software?!?!? It's the software from those companies that wouldn't be. I hate remote attestation as much as the next person, and typically banks absolutely suck because they love doing that kind of bullshit. But because banks suck does not mean that GrapheneOS is not free software?
Note that I am not trying to contradict you for the sake of it. I believe too few people understand how open source works, and that is a pity because it is important to understand it. When I open source some code I wrote, I make it available for people to do whatever they want with the code. I don't give them ANY RIGHT on the products I sell (even if those products are running said open source software) or on the feature I implement.
Too many people believe that because it's open source, they have a right to tell the authors what features they should implement. This is wrong. You want root access on your GrapheneOS? Go fork it. I don't want it, I am happy with GrapheneOS. If GrapheneOS gave me root access, I would fork it to remove it. And that would still be free software!
> Well GrapheneOS would still be free software?!?!? It's the software from those companies that wouldn't be.
I think I have a broader definition of software freedom than you do. In this hypothetical scenario, GrapheneOS itself may technically be "free software" in the sense that the source code is open, but it would still be cooperating in a intentional scheme to prevent you, the user, from modifying it to work the way you want. Same deal if they started selling locked hardware with their signing key hard coded so you can't install a fork. You would legally have the ability to fork the software, but technical measures would be preventing you from running it.
Granted, they're not doing that, but it's one short step away. That's why I say it's borderline anti-freedom, not that it actually is.
I don't think it makes a difference whether the means employed to make a piece of software non-free are legal (copyright law) or technical (DRM, remote attestation, hardware locks). It's still restricting your freedom.
I really want to insist on this: when someone develops software, you don't get to choose what they develop. That's just life.
If they make their software open source, you get to fork it (sometimes contribute to it) and this is already very generous. But that's all.
I say that as an open source author and maintainer, and my experience is that the vast majority of developers do NOT understand that. I have been criticised, insulted, sometimes bullied by people who wanted me to implement whatever they wanted ON TOP of providing my work for free.
You can have your own definition of "free software" that means "the developers have to agree with my personal taste", and say that "Linux is borderline not free software because I want them to officially support Zig and they don't", but it doesn't bring much. What makes Linux free software is that you can fork it.
I guess I don't understand the need to have a definition that only serves for complaining about a free project not implementing a feature you want. I get it, you wish GrapheneOS gave you root access. But it is not the choice of the people who do the work and make it available for free. But because it is free software, you can fork it and modify it yourself, and this is great.
For what it's worth this isn't just my "personal taste". I think Richard Stallman and the Free Software Foundation, at least, would agree with my definition[1]:
> Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense rather than a practical reality. These binaries are not free software even if the source code they are compiled from is free.
I didn't say anything about what GrapheneOS devs must do. They don't have to do anything. I just think that some of what they are doing comes close to impinging on software freedom in the same way proprietary software does regularly (though again, Graphene doesn't quite cross that line, in my opinion).
I'm not asking for anything, I'm telling you what they are doing, and what they are doing is going right up to (but not quite crossing) the line of blocking you from modifying the software on your phone.
To re-iterate:
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known [...] in its practitioners' perverse terminology as “secure boot”—freedom 1 becomes an empty pretense
GrapheneOS literally implements secure boot, using a key you do not control. So if you install GrapheneOS, the Graphene devs have the ability to push updates to the code running on your phone but you yourself do not unless you completely uninstall GrapheneOS and wipe all data on the phone.
The only thing preventing this from being actually anti-freedom rather than merely borderline anti-freedom is that if you choose to completely un-install Graphene and wipe your phone there's currently nothing that will prevent you from installing another OS built with a different signing key (aside from the inconvenience and technical difficulty of doing so). If there were, then this would be a textbook example of what the FSF explicitly calls "not free software" in that quote.
Again you don't understand Stallman's quote. Let me try:
> If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours—a practice known as “tivoization” or “lockdown,” or (in its practitioners' perverse terminology) as “secure boot”—freedom 1 becomes an empty pretense
Tivoisation or lockdown or abusively calling it "secure boot" is, according to Stallman, "non free". GrapheneOS does not do that. GrapheneOS does not even own the hardware that could do tivoisation. GrapheneOS is the fork of the original project that has been updated and installed on the original device. That means that not only GrapheneOS is free, but AOSP as well!
> is that if you choose to completely un-install Graphene and wipe your phone there's currently nothing that will prevent you from installing another OS built with a different signing key
And that's exactly what Stallman calls "free". If it prevents you from doing precisely that, it's not free. But it doesn't, so it's free.
Secure boot is a security feature. One that I want. One that makes GrapheneOS more secure than, say, a Linux on mobile (or all the other Android flavours that break secure boot, like it was for /e/OS on my FairPhone 3). The whole point of GrapheneOS is that it is secure, and therefore it is designed around that. Thanks to secure boot, if an app manages to get root access and modify the system, it will be detect on the next boot, and therefore it won't persist. This is a desirable feature.
You apparently don't want that, it's your choice. You can use LineageOS, which allows it, or you can fork GrapheneOS and modify that part.
This is all free, this is all how it's supposed to work, this is all desirable. GrapheneOS is free to make the product they want, and that product doesn't allow you to have admin access.
You seem to misunderstand "owning your device". It does not mean "the software allows you to do everything you want", it means "you can install whatever you want on it". If you install something that does not give you root access (i.e. GrapheneOS), it is your choice.
I said it's borderline not-free, not actually not-free so I don't know why you just wrote 7 paragraphs arguing against something I didn't say and have explicitly and repeatedly disclaimed.
Yes, GrapheneOS is free, but it has implemented features that are designed to make it harder to exercise that freedom, namely secure boot which puts it one short step (of baking their key in hardware) away from being exactly what that paragraph describes as not free.
(And I think you are the one misunderstanding the FSF's quote. They're mocking "secure boot" as perverse terminology for what the FSF calls "tivoization" or "lockdown". They're saying those things are one in the same. I personally wouldn't go that far, as I agree with you the software is still free as long as the key used for secure boot is not baked in to the hardware, and I think the security benefits of secure boot are real and not perverse. But the FSF itself is arguing against the whole idea, at least in this article.)
> I don't know why you just wrote 7 paragraphs arguing against something I didn't say
I argue against something you keep repeating:
> GrapheneOS is free, but it has implemented features that are designed to make it harder to exercise that freedom
This is wrong. First because it does not make it harder to exercise that freedom, and second because GRAPHENE DID NOT IMPLEMENT IT IN THE FIRST PLACE.
People arguing the way you do is, IMO, one of the reasons the "free software" movement lacks credibility. You're just whining because you wish you could have root access on your system without having to install it yourself.
I'm confused. Are you saying Graphene doesn't implement secure boot? Or that you don't think requiring users to wipe their phone and install a custom OS build before exercising their freedom makes exercising that freedom harder?
> You're just whining because you wish you could have root access on your system
This is false, and I think it's intellectually unhealthy to use your perception of a person's motives as an excuse to avoid mentally engaging with the substance of their argument.
> Which is very much contrary to software freedom.
Yeah, the goal is privacy although the OS is completely open source.
They do improve user experience by allowing disabling emergency alerts, call recording without alerts, no mandatory camera noise in Japan, no extra warning popup from installing APKs from the web (it's the same permission in every app store iirc), increases password length to 128 digits. All the network services are open source afaict while all the other mobile operating systems listed in that android comparison connect to Google's closed source services, netowrk permission, sensors permission, storage scopes, contact scopes.
You can still easily install whatever Android app you want on GrapheneOS and you can install dangerous apps like shizuku and apps with way too many permissions. But yeah the goal is privacy so that everyday people can protect themselves as well as journalists can protect themselves. I want journalists to get the best privacy possible without having to know a ton of technical things or making many choices.
Accrescent has been quiet for a while, but had claimed in the past they would open the store up for new submissions again soon, it will perhaps happen by the end of the year. Its self-imposed requirements for this are to provide a better developer experience and more common app store features developers (should) expect. They recently announced they will be posting more about the progress made towards such goal, after the big announcements and releases of some months ago.
I'm more worried about the lack of a police to take apps down when it is very clear they should not be there. This is a present problem, presently solvable and that is not acknowledged despite the fact it harms the user.
No, GrapheneOS is a privacy project. The primary focus is providing usable privacy. GrapheneOS solely works on security to protect privacy.
We never said that about the SafetyNet Attestation API and that's a dead service. We've explained that we cannot provide a long term for the Play Integrity device integrity level because they can easily detect spoofing and very easily block it. The device integrity level is also gradually phasing in a requirement for hardware attestation. Apps already use the strong integrity level to enforce it.
>For example they have stated they won't try to spoof SafetyNet because "we don't lie about security features"
They said they don't want to do it because it would stop working in the future when Google move to enforcing hardware-based attestation and it is not sustainable.
We don't receive early access to Android releases or security bulletins from Google.
SafetyNet Attestation API was replaced by the Play Integrity API and has been shut down.
Spoofing the checks needed to pass the Play Integrity device integrity level would only be a temporary workaround. It would stop working and we'd have to keep expanding it. It's easy for them to detect spoofing and ban it. They choose to focus on it happening at scale rather than individuals doing it with rare modifications. GrapheneOS is too widely used to get away with it.
Spoofing the device integrity level will become far more impractical once it requires hardware attestation. Remote key provisioning will also make it a lot more painful to use leaked keys for bypassing root-of-trust-based hardware attestation.
The OEM is Motorola. The partnership was announced earlier this year.
You are correct about them not getting early access from Google. There was a post within the last few months saying that Google no longer releases a lot of the code via git, but instead requires submitting a form and downloading the code via Google Drive. Google are actively trying to make third-party development difficult.
We are told the OEM in question is not Motorola, and it's likely some benefits of the Mototola partnership aren't yet in effect due to silly bureaucracy. Not sure there is any reason to lie about this.
Embargoed ASB patches started being used in release 2025092500, but I can't find now the message where a Motorola employee (confirmed by a community moderator, spring-onion, in a Side of Burritos interview) first reached out publicly on the GrapheneOS Discord guild about how to obtain further technical guidance than the requirements list in the website which claims to be non-exhaustive, in order to confirm such message's date. Still, GrapheneOS claims (after the partnership announcement March this year) that ASB patches are provided by (effectively) a distinct undisclosed OEM, really meaning an employee is leaking them. Maybe even the person didn't disclose the OEM they work for but they must be associated to one in order to have access to this material.
GrapheneOS is much more privacy focussd than any other mobile operating system. Accrescent is the end goal for a secure and private app store but it's still in alpha. GrapheneOS is also the best for degoogling (eliminating all google services) because it comes with zero Google services unlike all the other ones listed here: https://eylenburg.github.io/android_comparison.htm
How can you call other OSes more privacy focused when they haven't closed as many VPN leaks as GrapheneOS? That's like bare minimum for privacy.