Field Notes

synthesis

Desktop operating system security comparison

StatusWorkingReviewdue UpdatedStands on11 sourcesSupportsnotes

Qubes OS, secureblue, Kicksecure, Whonix, and Tails are the five desktop systems this wiki treats as serious answers to the question of how to run a computer under threat. They pursue three distinct strategies: hypervisor-enforced compartmentalization, hardening a single persistent OS, and refusing to persist at all. They are complementary more than competitive, and the strongest deployments combine elements of more than one.

The useful question is not which is most secure, because the five do not defend the same thing. Each accepts a different loss when its assumptions fail.

System Strategy What the design protects What a root compromise costs
Qubes OS Compartmentalization in Xen VMs Everything outside the compromised qube One qube’s data, unless the hypervisor is escaped
secureblue Single-OS exploit mitigation The odds of reaching root at all The whole session and its persistent disk
Kicksecure Single-OS defense in depth The odds of reaching root at all The whole session and its persistent disk
Whonix Gateway/Workstation network split The user’s real IP address The Workstation’s data, but not the IP
Tails Amnesia and enforced Tor The record left on the machine The session, including the real IP

Read the last two columns together. Whonix survives a compromised Workstation with its anonymity intact and its data exposed; Tails survives with its data gone at power-off and its anonymity broken while the session runs. That is the central trade in this comparison, and no system in the set escapes it except by running two of them at once.

Prevention and containment are different bets

Qubes is routinely called the most secure desktop system, and the claim does not survive contact with a threat model. Isolation and hardening reduce different terms in the same risk. Hardening lowers the probability that an exploit lands; compartmentalization lowers what it reaches once it does. Neither dominates, and which matters depends on where the valuable data sits.

Compartmentalization helps least when the asset is inside the compromised unit. A browser holds sessions, cookies, and saved passwords, so a browser exploit in a Qubes app qube takes the things worth taking whether or not the attacker ever touches another qube. The isolation protected the rest of the machine, which was not the target. Against that same exploit, a more resistant browser is worth more than a stronger boundary, and the default browsers differ: Qubes app qubes ship Firefox from their template distribution, while secureblue ships Trivalent, a hardened Chromium. Chromium’s Linux sandbox and site isolation are generally judged stronger than Firefox’s, though Firefox has narrowed the gap with Fission, and the comparison is of defaults rather than ceilings — nothing stops a Qubes user installing a hardened browser in a qube.

Qubes has two real answers, and they are answers about configuration rather than architecture. Splitting by activity means the compromised browsing qube holds nothing the attacker wants, because banking and work live elsewhere. Disposable qubes go further: a browsing session that is destroyed on close bounds the compromise in time, which hardening cannot do at all. Both are strictly stronger than what a single hardened OS offers. Both also depend on the user actually partitioning that way, and a Qubes install where one qube holds the browser, the mail, and the documents has bought much less than its reputation suggests.

The isolation primitive has also failed in practice. Xen isolation failures affecting Qubes OS records a 2017 Xen bug whose proof of concept ran code as root in every other paravirtualized guest including dom0, and Qubes’ own bulletin states that such a bug lets a browser exploit “compromise a whole Qubes system.” Qubes removed the implicated subsystem in 4.0, replacing paravirtualization with hardware-enforced memory virtualization. That moved the guarantee’s foundation from Xen’s software into the processor, where transient-execution issues account for 23 of 73 post-2018 bulletins and are not fully fixable in software.

Identity separation is a different axis again

Compartmentalization does two jobs that are worth naming separately. The security job is bounding a compromise. The privacy job is keeping identities from being linked, and Qubes is stronger at the second than the comparison above suggests, for a reason that has little to do with exploits.

Ask what a persona actually consists of. Storage and cookies are the visible part, and they are the part browsers can separate. The rest — the source address a request arrives from, the fingerprint the browser presents, the timing of when two accounts are active — lives below the browser, and no browser-level mechanism reaches it.

That is why the layers rank the way they do:

Boundary Separates Shares
Browser container or profile Cookies, storage, logins Address, fingerprint, browser build, process space
Operating-system user profile Application data and keys Address, device fingerprint, kernel
Qube with its own network VM All of the above Only the hardware and the hypervisor

Only the third separates the network path, which is usually the binding constraint. Two accounts used from one machine are correlatable by address and timing however carefully their cookie jars were partitioned, and a Qubes user can give each persona its own network VM, its own virtual private network circuit, or its own Whonix gateway with a distinct Tor circuit. That capability has no equivalent on a single hardened OS, and it is the strongest form of the claim that Qubes is a privacy tool as much as a security one.

What Trivalent offers, and what it does not

Trivalent is Chromium, so ordinary browser profiles are available, with the usual separation of cookies, storage, and history.

It has no equivalent of Firefox’s Multi-Account Containers, and the gap is structural rather than an omission. Chromium has no native per-tab contextual identity, so on Chromium the feature is an extension — and Trivalent disables extensions by default and permits only Manifest V3, which closes that route twice over.

What it does instead is partition aggressively, inheriting most of it from Vanadium: third-party cookies blocked by default, network cache split per site, connections partitioned, strict origin isolation, origin-keyed process isolation, and sandboxed iframes isolated per site. Trivalent adds preferences to launch sessions and open external links in Incognito.

The practical consequence for the configurations above: Fedora plus Trivalent is the better answer to whether a browser exploit lands, and it does nothing for persona separation that Qubes was not already doing better. On the privacy axis the qube boundary is the product, and the browser inside it is close to interchangeable.

How to read the sources

The comparison is built largely from each project’s own documentation: Qubes OS architecture documentation, secureblue features and FAQ, Kicksecure security features documentation, and Tails official documentation. Every claim below about a project’s design intent is that project’s account of itself.

Where two projects describe each other, as in Kicksecure vs secureblue development comparison and Whonix comparison with other anonymity systems, the description is a competitor’s and is treated as an argument rather than a finding. The characteristic failure is not invention but decay: a project maintains its own rows and lets its rival’s rot. The Whonix comparison still evaluates Tails 2.4 from 2016 and records Tails as lacking deterministic builds, which stopped being true in 2017.

The one non-project source, Qubes OS Security in the Public Record, measures what Qubes disclosed rather than what Qubes contained, and its author says so explicitly.

There is nothing else to weigh these accounts against. As of July 2026 the scholarly literature holds no independent security evaluation of any of the five systems, and searches of the major indexes return no academic work on them at all beyond that single preprint.

Isolation architecture

The fundamental distinction is isolation strategy.

Qubes OS isolates every application in a separate Xen VM. A compromise of one qube does not propagate to others unless the attacker escapes the hypervisor. The TCB is hundreds of thousands of lines of C, orders of magnitude smaller than mainstream OSes, but the architecture is unusually dependent on the security of Xen and the CPU microarchitecture: 87 of 109 public QSBs, or 79.8%, are attributable to upstream dependencies rather than Qubes-core logic.1 That number describes the disclosure record, not the defect population, so it cannot settle whether Qubes-core is sounder or merely less studied than Xen.

secureblue and Kicksecure both harden a single OS without VM-level isolation. secureblue layers defenses on Fedora Atomic with SELinux enforcement, hardened_malloc, and a sudoless privilege model. Kicksecure layers defenses on Debian with AppArmor, user-sysmaint-split, and extensive kernel and network hardening. Neither provides the inter-application isolation that Qubes achieves through virtualization.

Whonix and Tails both enforce Tor, and split on where the Tor client runs. Whonix puts it in a separate Gateway VM, so a compromised Workstation has no real IP address to leak. Tails runs it on the same machine as user applications, and accepts that a root compromise can rewrite the firewall and read the address. Tails describes its own application isolation as “minimal,” implemented with AppArmor and bubblewrap.

Hardening depth

These three are the persistent hardened desktops, compared on the dimensions where they are genuinely rivals. Whonix inherits Kicksecure’s column, since it is built on it, and Tails is compared separately below because most of these rows do not describe what it is for.

Dimension Qubes OS secureblue Kicksecure
MAC system Xen + SELinux in dom0 SELinux (enforcing) AppArmor
Memory allocator Standard hardened_malloc globally Deprecated hardened_malloc
Browser Firefox in app qubes Trivalent (Chromium, SELinux-confined) Browser choice tool
Privilege model Root only in dom0 Sudoless (run0 + polkit) user-sysmaint-split
User namespaces N/A (VM isolation) SELinux-confined Disabled (sysctl=0)
Time sync Standard NTP NTS sdwdate
Update routing Standard Standard Tor
SUID reduction Minimal in dom0 Extensive + capabilities SUID disabler + permission hardener
RAM wipe No No Yes
FDE default Optional Optional (tooling provided) Yes (ISO installer)
USB protection USB in unprivileged VM USBGuard USBGuard
Supply chain Signed updates, Anti Evil Maid SLSA, Cosign, Trivy Digital signature policy, warrant canary

Both secureblue and Kicksecure apply KSPP-aligned kernel hardening via sysctl and boot arguments. The Kicksecure vs secureblue development comparison documents their convergences and divergences in detail.

Which of the two is harder to exploit

The table shows the differences without ranking them, and on exploit mitigation specifically the answer is secureblue. It runs hardened_malloc globally, enforces SELinux rather than AppArmor, and ships a hardened Chromium. Label-based mandatory access control covers a system comprehensively where AppArmor’s path-based profiles cover what someone wrote a profile for, and Fedora ships a full enforcing policy where Debian’s coverage is partial.

Kicksecure’s position is a reasoned trade rather than neglect, which matters for how much weight the difference carries. It deprecated hardened_malloc in November 2025 on the grounds that it would never be stable enough to enable by default, that it breaks Firefox, Tor Browser, and Chromium, and that its AMD64-only support blocks the project’s ARM64 and PPC ambitions. secureblue can carry the allocator partly because it builds its own browser: the breakage Kicksecure cites is breakage secureblue is positioned to fix.

The ordering also inverts on other axes. Kicksecure wipes RAM at shutdown, encrypts by default in its installer, routes package updates over Tor, offers a live mode, a panic key, and recovery-mode lockdown, and publishes a warrant canary. Those are anti-forensic and physical-custody defenses that secureblue does not claim, and they matter against device seizure rather than against remote exploitation.

Amnesia, anonymity, and verifiability

These axes separate the set differently, and are where Tails and Whonix earn their place.

Dimension Qubes OS secureblue Kicksecure Whonix Tails
Amnesic by default No No No No (optional Live Mode) Yes
Tor enforced for all traffic Via Whonix template No Updates only Yes, structurally Yes, structurally
IP survives workstation root N/A N/A N/A Yes No
Documented image-reproduction procedure None found None found None found None found Yes, since 3.3
Privilege escalation by default Root in dom0 only run0 + polkit sysmaint account Standard None; admin password is opt-in

Two rows deserve emphasis.

Amnesia is a default, not a feature list entry. Kicksecure offers a live mode and Whonix offers Live Mode, so all three can run without writing to disk. What differs is what happens when the user chooses nothing, and that is the case that matters because it is the one that occurs under stress.

Reproducibility is the only row an outsider can check. Every other claim here rests on reading a project’s documentation and believing it. Tails publishes images that any third party can rebuild from a Git tag and compare byte for byte, which converts “the shipped system matches the published source” from an assertion into a test anyone can run. Source-to-binary correspondence is strictly stronger than a signature, and Reproducible builds is the mechanism.

The other four publish no comparable procedure that this wiki could find, which is a weaker statement than saying their builds are not reproducible. Debian and Fedora both do substantial reproducibility work upstream, so components may well rebuild identically even where no project-level image check is offered. What is missing is the documented route by which a user could perform the check, and that absence is itself the finding: the systems whose entire value rests on trusting their build mostly ask to be trusted on it.

Hardware and usability tradeoffs

Dimension Qubes OS secureblue Kicksecure Tails
Min RAM 6 GB (16 GB recommended) ~2-4 GB Lightweight 3 GB recommended
CPU VT-x/EPT + VT-d (Intel recommended) Any x86_64 Any x86_64 x86-64 only; no ARM or Apple silicon
GPU Intel IGP recommended Full Nvidia support Standard Debian Nvidia and Radeon often fail
Gaming Impractical Supported Not a focus No
Learning curve Steep (weeks) Moderate Low Low to use, subtle to use safely
Desktop environments Xfce GNOME, KDE, Sway LXQt (Wayland) GNOME
Installation Bare metal Bare metal Bare metal or VM USB stick, no installation

Qubes demands hardware supporting IOMMU-based device isolation and enough RAM to run multiple VMs simultaneously. secureblue runs on any hardware Fedora supports and provides the best GPU and gaming experience. Kicksecure is the lightest of the persistent systems and works on the weakest hardware, but its Debian base can lag on application library versions. Tails requires no installation at all, which is what lets it be carried to a machine the user does not own.

Tails’s learning curve is the one most often misjudged. Booting it is easy; using it without linking identities across a session, stripping document metadata, and understanding that Persistent Storage is an exception to every guarantee the system offers is not. Its documented failure modes are disproportionately failures of use rather than of software.

The floor under all five

Every system here depends on firmware it does not control. Tails states the general case plainly: all operating systems depend on firmware to start and run, so none can defend against a firmware attack. Qubes offers Anti Evil Maid with a TPM, Kicksecure offers deep-scan readiness for external inspection, and neither closes the gap so much as makes tampering detectable. An Evil maid attack against any of them begins below the layer the comparison above describes. For Tails this is not a remote scenario but the intended deployment: the system is designed to run on borrowed machines.

When to use each

Qubes OS when the threat model demands inter-application isolation no single-OS hardening provides: journalists handling sources, security researchers analyzing malware, activists under targeted surveillance. Accept the hardware requirements and learning curve.

secureblue when the goal is the strongest single-OS hardening available on Fedora without VM overhead: security-conscious daily drivers needing modern hardware support, GPU acceleration, and application compatibility.

Kicksecure when the goal is a hardened Debian that works on almost any hardware, especially as a host for Whonix VMs or for users wanting security-by-default without Qubes complexity.

Whonix when anonymity must survive the compromise of the machine doing the work, and the user can keep a persistent system inside a hypervisor.

Tails when the session is bounded, the hardware is not yours or should show no trace, and the cost of a persistent workspace outweighs its convenience. It is the right tool for a source contacting a journalist and the wrong one for a daily driver.

Complementary deployments

The strongest configurations combine approaches:

  • Qubes + Kicksecure templates: VM isolation from Qubes with Kicksecure’s hardened Debian inside each qube.
  • Qubes + Whonix: VM isolation with enforced Tor routing. This is the configuration that declines the Whonix/Tails trade, paying for it in hardware.
  • Kicksecure host + Whonix VMs: hardened host OS with anonymity-capable guest VMs, without Qubes’s hardware demands.
  • secureblue daily driver + Tails for sensitive sessions: a modern desktop for routine work, and a USB stick for the tasks that must leave nothing behind.

secureblue inside Qubes is not available, but its browser is

There is no secureblue Qubes template. The blocker usually named is display server: Qubes’ GUI agent is X11, and secureblue disables Xwayland by default across its images. Two artifacts track the Wayland work, and both suggest it is not close. QubesOS/qubes-issues#8997, “Wayland proxy compositor,” has been open since February 2024, carries default priority and no milestone, and was last updated in January 2025. The reference implementation, QubesOS/qubes-gui-agent-wayland, sits on a for-review branch with one contributor and no push since October 2023. The issue also shows the motivation is Qubes’ own: Wayland is described as a requirement for GPU support, not as a compatibility project for other distributions. Qubes forum discussion adds a simpler reason alongside the technical one — someone wrote a Kicksecure template and nobody wrote a secureblue one.

The browser, however, is not locked to secureblue. Trivalent is an ordinary Fedora package published from the project’s own repository at repo.secureblue.dev, built for Fedora 42 through 44 on x86_64 and aarch64, so it installs in a stock Fedora template with dnf or layers onto an atomic spin with rpm-ostree. The project describes installation outside secureblue as unsupported, meaning untested rather than prohibited. Two things do not come with it: Trivalent is documented as intended for use with hardened_malloc as secureblue packages it, which a stock Fedora template does not provide globally, and none of secureblue’s system-level hardening — the sudoless model, the SUID reduction, the boot parameters — arrives with the browser.

That makes the practical configurations these:

Configuration Strong at Weak at
Fedora template + Trivalent Resisting the initial browser exploit Baseline template hardening
Kicksecure template + Chromium or LibreWolf Slowing escalation after one The exploit landing in the first place

The two cannot be combined in one qube. Trivalent is packaged for the Fedora family only, with no Debian build, and Kicksecure is Debian. Choosing between them is therefore choosing which link to attack: a hardened browser lowers the chance of the first compromise, while a hardened template lowers the chance that a browser compromise reaches qube-root and from there the hypervisor surface that Xen isolation failures affecting Qubes OS documents.

Inside Qubes the browser is the better place to spend, because Qubes already supplies the containment that template hardening partly duplicates, and supplies nothing that reduces the odds of the browser falling. The Qubes-shaped answer is not to pick one template for everything: run browsing on Fedora with Trivalent, and keep Kicksecure templates for qubes whose risk is escalation rather than hostile web content.

A hardened Debian used carefully is more secure than default Qubes used carelessly. The choice depends on the threat model, hardware, and the user’s willingness to learn a non-standard workflow.

Open questions

  • Whether secureblue’s SELinux-confined user namespaces provide equivalent protection to Kicksecure’s global disable when a Chromium-based browser is in use.
  • Whether the Qubes advisory record’s upstream concentration reflects genuine architectural safety or simply lower research attention on Qubes-core. Correction channel gives the reason this cannot be read off the record itself, and Qubes OS Security in the Public Record declines to try.
  • Whether Kicksecure’s planned migration to a hardened kernel with linux-hardened patches would close the gap with secureblue’s kernel hardening.
  • Why systems this widely relied on have attracted no independent academic evaluation. The answer bounds what this note can ever claim.
  • Whether any of the four persistent systems can in fact be rebuilt reproducibly, given that none documents a procedure for it and Tails demonstrated in 2017 that it was achievable. The wiki has established the absence of a published check, not the absence of the property.

See also

  1. Qubes OS Security in the Public Record (Alfonso De Gregorio, preprint posted to arXiv 16 July 2026, arXiv:2607.14587); saved PDF. Of 109 bulletins issued between 2011 and 2025, 87 are attributable to upstream components and 22 to Qubes-core logic. A preprint, not yet peer reviewed. ↩

Built on 11 sources (11 external).

Working out connections…