upvote
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.
reply
This is however not their main argument. I doubt they would accept such pull request.
reply
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).

Why can't you understand that?

reply
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?
reply
No pull request necessary, forks don't require approval.
reply
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!)

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

reply
I use Qubes with TPM and Heads and with a hardware key. All based on FLOSS, so its possible.
reply
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.

reply
> 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?

reply