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?