/e/OS is Android, meaning it's still critically dependent on goodwill of Google to continue releasing their work as part of AOSP.
So if you're trying to be a silly purist, then /e/OS doesn't fit either. If you're not, getting a Pixel will significantly enhance your safety since they're better supported for security patches and better designed in hardware when it comes to security.
At least GrapheneOS is releasing up to date OS versions and patches very quickly, quicker than all the vendors except Google.
And in terms of the security, they release binary patches for the exploits under embargo until...... mid-2026. Remember November 2025 security bulletin? Multiple RCEs, media wrote articles about that.... Meanwhile GOS was long patched.
What is the most recent version? 3.5. What Android revision is it based on? Lineage 22.2, which is Android 15.
It also claims that it includes "all Android security patches available as of February, 2nd 2026" .....but not all patches get back ported, meaning they miss many fixes and improvements.
And that's just the start.
Tbh I'd rather run Lineage Os on the older phone that this.
I think it is legitimate to be a purist about smartphones, but I don't think the GP is. So, let's talk about the non-purist situation: Users like us want to de-google. But we are not willing to make all of the sacrifices that purists do. The question is then, what can we use (and - what projects can we support financially).
Now, we can use GrapheneOS if we have Google Pixel's. But - most people don't have those phones, for any number of reasons. One of them is price, by the way: You can get a decent smartphone for under 100 USD and even a half-decent one for 70 USD. And most people in the world are not in an economic situation where you can tell them "shell out 300 USD and buy a Google Pixel".
Moreover - suggesting we strengthen our ties to Google in order to de-Google is fundamentally problematic. Even if we're not going all the way, we are striving to distance ourselves from them.
So, an imperfect software solution for a wider selection of phones does sound quite useful. Change my mind! :-)
Could you not do this? There's no need to be hostile to people who purer than you are.
It's fine if you want to make a pragmatic decision to do what works now, but you depend on people who to some degree don't want to compromise. But I always suspect this type of hostility comes from guilt being directed outward; what you actually should want to do instead is support people who are refusing to compromise and building alternatives (even if those alternatives are just ways to get things done without phones.) You will need them one day.
The idea about being dependent on Google to continue to allow you to be hostile to Google on their hardware is intrinsically not sustainable.
You're basically the same as an somebody using whatever the phone company installs mocking somebody who would dare install GrapheneOS, or even an iPhone person ridiculing somebody for using Android at all. What's the use of that?
Remember that economists think that this process you're talking about is healthy, good and this is how companies should be run. Take massive loans, hire, then discard people when you don't need them.
"over-hired" seems like mostly copium of engineers being very afraid that their company will discard them like this and are trying to rationalize why they won't follow.
There was obvious over-hiring in the couple years after COVID while interest rates were low. A lot of companies corrected and laid off staff when that stopped.
This was before LLMs writing code was a daily discussion topic. Blaming every layoff on AI is mostly people connecting trending headlines together.
I don't think it's copium because it doesn't really matter if it's due to AI or COVID-era ZIRP-infused overhiring. If your company hasn't done multiple rounds of layoffs since 2022, they're going to come.
Graphene doesn't really try to stop you. They just don't spend their own efforts on making it possible. It is OSS so, your free to spend your efforts where you want to.
It would require a significant commitment of limited resources to broadly support insecure devices with very little upside, and to do so would constitute gross mismanagement of the project.
Meanwhile, others are completely free to fork numerous GrapheneOS improvements or benefit from their upstream improvements (as some have, including Google).
I never mentioned any commitment except accepting pull requests, did I? Qubes can do that and doesn't require a fork. Are you saying they have much more resources?
The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want.
"Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain.
Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of.
So I understand why the GrapheneOS folks do what they do.
See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!)
As one who has lived out of both operating systems for years, I struggle with the way you invariably make value judgments about GrapheneOS every time it comes up in a thread, based on your (justifiable) appreciation for Qubes OS. The same thing happens in reverse on the GrapheneOS forums, by the way.
Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project.
Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches.
In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects.
If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge.
GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like.
"The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."
GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones.
In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible.
Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.
> In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
I critisize precisely because I don't understand what you're talking about.
The last relevant VM escape was in 2006, discovered by Rutkowska herself. Since then, nothing could access my secrets in an offline vault VM. I would appreciate a clarification, how GrapheneOS can be more secure without reliable virtualization.
AFAIK Xen security relies on 100k LoC. And this is in addition to the virtualization. How many LoC does GrapheneOS require to provide its security? How can it have less attack surface than Xen? Developers replying to me here never provided an understandable reasoning, only keep repeating that it's "very, very secure", without even mentioning any threat model.
Doesn't GrapheneOS rely on closed Google's hardware to provide its security? I would never trust Google with that. How can I not critisize such approach?
Just because something is mandatory, doesn't mean it's enforced. You got 6 million trucks registered in the EU alone [1], plus fleets of trucks registered in adjacent states such as Turkey or Serbia, or old trucks out of the new Eastern European states that predate their EU membership and, with it, mandatory governors. And loggers can be manipulated as well, if you do it right there is no chance of finding that out without taking apart the truck.
Not every country is as thorough as Germany is in technical inspections, trucks from outside the EU don't need speed governors, and as long as you don't race your truck in Germany, France or Austria, chances are high no one will be bothered enough to pull your truck over for a detailed inspection on an examination wheel. Or you simply have two datalogger cards, that you swap out when going into one of these countries.
The enforcement and verification of tachographs grew significantly in last 20 years across whole EU, even in our eastern european countries.
So, again, I very much doubt that there's a mass scale, country-level, tachograph fraud happening in Baltic states without anyone else noticing.
And having been part of EU business that does trucking, police REGULARLY pull over trucks for tachograph inspections (including rest and speeding) even in southern and eastern europe. Any truck business owner would be rather insane to risk the fines tachograph fraud gives at any consistent rate.
Do companies and drivers try to break the law? Yeah, I believe that. Do trucks systemically, constantly drive above speed limit in Baltic states and noone is checking that? BS.
So if you're trying to be a silly purist, then /e/OS doesn't fit either. If you're not, getting a Pixel will significantly enhance your safety since they're better supported for security patches and better designed in hardware when it comes to security.
reply