Security of Qubes OS vs GrapheneOS

I originally posted this in the GrapheneOS Discussion Forum, but for obvious reasons I think it might be useful to get a perspective about this from this community as well. Be aware I’m not a Qubes user, so please excuse (but definitely correct!) anything I might have gotten wrong. I hope this will not be understood as an attempt to generate hate; my intention is only to learn about the benefits of two great options. I’m curious about what you have to say!

Much has been said about the increased security that mobile OS like Android and iOS offer over desktop OS. They are designed from the ground up for a hostile environment, which makes them much better suited for the reality we’re facing now. I’ll refrain from repeating what others have already expressed better than I could here; for example in this video by THO.

Now, mobile OS are more secure than desktop ones, and GrapheneOS is the most secure mobile OS, so Graphene wins, case closed? Not quite, at least not obviously so. Of course, the security of a system depends partly on how it is used. A user knowledgeable enough about these systems and their threat model might be able to design a relatively secure overall concept even when using relatively insecure tools to do so. But this is always true and doesn’t say much about which OS should actually be used. In my opinion, the only real challenger for GrapheneOS to the crown of most secure OS, seems to be Qubes OS.

First, I think it makes sense to say that for many people, Qubes OS is simply not suited. GrapheneOS provides the absolutely luxurious option of using something that’s as easy as Stock Android, and even very inexperienced users can switch relatively easily. Qubes OS doesn’t have that option, especially if you use it in the way it needs to be for its security to really shine – by heavily compartmentalizing. For most, I’d recommend GrapheneOS in a heartbeat because it’s extremely unlikely they will a) actually use Qubes and b) use it in a way that even has the potential of beating GrapheneOS. However, the question of which provides better security for a user who utilizes the OS in a way making use of its potential (within realistic bounds), remains valid. Or, if the strengths and weaknesses of the two are different enough to make such an “overall” security assessment nonsensical: Which OS has which advantages, what are its go-to use cases?

Something that seems obvious to me, is that GOS will generally be way more secure than a Qubes VM. If you use Qubes with one VM in which you always do everything, I doubt your security will be that much improved over whichever OS you use inside that VM, which will be less secure than GOS. Qubes strength lies in its use of compartmentalization between different VMs with different levels of trust, that can be erased and created on demand. This means that even though it might be easier to break into a VM on Qubes, that will not necessarily get you far. To truly compromise the system, there needs to be a way for the attacker to infect other VMs, or even the Xen hypervisor itself. Doing so will be much more difficult.

However, GrapheneOS provides options for compartmentalization itself: User profiles. They are a useful tool in general, but can also be utilized at least somewhat similar to how Qubes uses its VMs. With different profiles with different level of sensitivity or different application scopes, the attack surface can be decreased for each while giving an attacker more hurdles to overcome. This can also be extremely useful when there’s a threat of physical attackers grabbing your phone, as not-running profiles will be encrypted. Installing apps into the owner profile also enables quick creation of a fresh user profile with (for example) nothing more than Tor Browser installed additionally, that can easily be deleted again after use.

I elaborated on my thoughts quite a bit, but please don’t confuse this with giving an answer. I hope I was able to identify some general themes or maybe provide some base for complete beginners, but evaluating and comparing the exact level of security is far beyond what I can do on my own. For example, would it generally be more difficult for an attacker to a) on GOS break into a user profile, infect it and spread to other profiles or b) on Qubes break into an untrusted VM, infect it, and spread to other more trusted VMs? I have no idea, and I’m not even sure there’s a definite answer – how do you even objectively measure difficulty?

To be fully transparent, I think most of the time, Qubes just isn’t an alternative to GrapheneOS, and that’s okay. What they focus on achieving is quite different, even though both have security as one of their main goals. Still, I think this question is interesting to ponder and provides great grounds to learn about what makes both of them secure, which in turn increases knowledge of security in general. So, for security, science, or maybe just for fun:

Which is the most secure, Qubes OS or GrapheneOS?

How do you produce any real work on a smartphone device?


Of course, if you need a desktop for work, GrapheneOS isn’t an option. That’s what I meant by the two having a different focus – both have some distinct use-cases which the other simply can’t replace.

But to provide an actual answer: GrapheneOS is available for the Pixel Tablet. With the right setup, this can be a suitable option for work. If it is, depends on what work, and personal preferences.

How strong is the compartmentalization between different profiles? Is it comparable to Xen VMs? In other words, how difficult would it be for an attacker who compromises one profile to gain access to a different profile?

Can you use a full-size keyboard with it securely? I’m guessing the keyboard would have to connect via Bluetooth or something, which doesn’t seem very secure compared to a wired connection.


Yeah, that’s one of the reasons I’m asking this question.

I’m not using this setup myself, but I don’t see why you wouldn’t be able to connect it over USB. USB peripherals would have to be enabled, but that’s simply a toggle in settings.

How does clipboard sharing work in GrapheneOS? Is the situation similar to Android, where all applications have access to it for reading?
If it is, then you have no reasons to compare security of these systems any further.

While I’m not expert enough to offer an opinion on the security of each OS, I can offer some insights on the related topic of data privacy. I use both Qubes and Graphene because I care about OS security as a necessary condition to achieve control over my data.

While Graphene does offer scopes and the ability to disable networking on an app by app basis, I have to reset all of these permissions each time I create a guest profile. This is a huge hassle compared to customizing disposable templates in Qubes and being able to use them on the fly as needed. The outbound firewall, opensnitch, also allows much greater control over my data than I can get in Graphene.

When it comes to data privacy, distro templates and disposable templates offer a flexibility and customization advantage that Graphene simply cannot match. This advantage alone causes me to favor the reasonable security of Qubes over Graphene in my day to day use.

That said, it’s useful to have both avaiable. For example, I recently had to make an online purchase and could not, despite many relaxation attempts, get past the Google captcha stage of the transaction with my disposable Firefox and Brave vms, the former with arkenfox hardening. So I finally resorted to creating a guest profile in Graphene and flew through the process in the Vanadium browser without any hiccups whatsoever. While this may amount to comparing apples and oranges, it did suggest to me that Qubes was providing me with more control over my data than Graphene.


There is some limitation of clipboard access (though mainly due to stock Android limitations). From the Graphene OS FAQ:

As of Android 10, only the configured default input method editor (your keyboard of choice) and the currently focused app can access the clipboard. Apps without focus cannot access the clipboard.


As of Android 12, the user is notified when an app reads clipboard content which was set by a different app. This notice is enabled by default


Very interesting to get this brought up, I definitely agree! GrapheneOS could benefit a lot from some form of User Profile Templates.

One major component of my “threat model” is all of the data mining and tracking that goes on. (I also am concerned with hackers in basements, botnets, and ransomware type things; I’m not concerned about state actors.)

As such I’d love to get a phone that doesn’t share everything with google or apple or whoever.

Graphene sounds good…until I realize I pretty much have to give even more money to the enemy (google) to buy the phone it works on.

Yes, I could buy a used one off the internet, but I’ve had very bad luck with buying used electronics; it’s often being sold because it’s a lemon. (The one and only used phone I bought over the internet had a defective microphone that couldn’t be replaced reasonably…and a bad antenna to boot.) Nope, if I buy a phone it will be face-to-face, not some clown on the internet who can ignore emails and/or not issue an RMA.

Graphene still sounds good…I just wish it worked on different phones.


I see, thank you for info. So, GrapheneOS is no good from this point of view. And took Android so many years and version to finally understand that completely sandboxed apps should not share clipboard by default.

By the way, in Android user can have root access and limit firewall settings quite flexible and per app using something like:

You can consider phones supported by LineageOS project.

…aaah yes that reminds me about a pet gripe I have with android.

Apps will routinely demand (as in, refuse to run without) access to all of my storage.

All they really need is access to whatever directory they want to store their configuration and data in. Instead, you have to go whole-hog and give it permission to access everything. Of course that would let the app access everything on your phone and possibly send it back home.

I gather (and please, please correct me if I’m wrong) the permissions aren’t “granular” enough to let you grant only permissions to access one folder. If they were I’d be a lot more willing to install apps.

(The peak of insanity was when the OEM photo gallery would, after an update, refuse to run at all unless you gave it access to your contacts. The theory being you can’t share your photographs without that, but what if all I want to do is look at my own pictures? You won’t let me do that, you arrogant piece of crap? Uh, that’s a hard NO.)

OK, with that side-rant out of my system I’ll look at Lineage. Thanks for the tip!


How strong is the compartmentalization between different profiles? Is it comparable to Xen VMs?

The Linux kernel handles device admin
which is responsible for multi-user.

This is weaker than a Xen domain, although some GrapheneOS
mitigations like the hardened user-space heap allocator will make
many bugs more difficult to exploit.

Read more about the problems of the Linux kernel

GrapheneOS does say that they’d like to move to
virtualization-based isolation in the future

OK, with that side-rant out of my system I’ll look at Lineage.

Don’t bother

How does clipboard sharing work in GrapheneOS? Is the situation similar to Android, where all applications have access to it for reading?

Within a profile, I think yes. There is a setting (IDK what the default is) that can notify you when an app reads the clipboard fwiw.


Once again, after many years google realized that users like you and me want to give access to only some directory, not whole flash storage. Starting from ~ Android 10 it works differently, it opens dialog for directory you want to give access to.

And what can be done if e.g. whatsapp or other proprietary app is reading clipboard all the time on every change? They would say that they do it to make some rare cases more comfortable for users.

Is not convincing. Looks like something written by general Google developer for Android who does not understand enough about security and privacy.
I cannot agree with the statement that having some original Samsung or Xiaomi stock Android on the phone is better for security and privacy than LineageOS with root access (e.g. allows to install firewall and other stuff). Android sucks in security and especially privacy, it was like that for many years.

It’s written by one of the Whonix devs, I’m fairly confident they understand security and privacy better than you do.


13 posts were merged into an existing topic: GrapheneOS vs Qubes OS security

Fixed by

1 Like

Great article, well written, and valuable given that it’s coming from the point of view of a Whonix dev. LineageOS provides a good strawman argument in favor of GrapheneOS for mobile, but I wonder how a fork like DivestOS would fare in their analysis. In terms of privacy, I’ve heard some FOSS advocates argue in favor of DivestOS over GrapheneOS, but without a clear discussion of the security tradeoffs like madaidan’s article provides. The former has one clear advantage over Graphene in that it provides a FOSS alternative to Google’s eSIM management, while also addressing some of madaidan’s criticisms of Lineage.

Getting back to the OP question… It seems to me that, at a high level, prioritizing security hardening makes sense in the mobile context, while prioritizing virtualization/compartmentalization makes more sense in the x86 world, not that these strategies are mutually exclusive.


DivestOS is good if you can’t use GrapheneOS, but you can’t compare the two.

If all you care about is privacy and FOSS then DivestOS is a good choice, if you want the most secure Android device you run GrapheneOS.

You can compile GrapheneOS for any Android device, but only Pixel is officially supported because it’s the most secure platform. It’s not the OS alone that makes the device secure, the device needs to have specific security features, it needs to receive fast firmware updates, and you need to be able to lock the bootloader.

1 Like

Bootloader relocking is one of the Lineage security issues that DivestOS addresses. From the website: “Bootloader relocking is restored and has been tested working on 23 devices and is available for 26 more. Verified boot is also restored on 36 of those devices and is enforcing once locked.”