Security Best Practice: Shift All Online Activities to Disposables (Except E2EE Messengers)

In our last post, we fortified the foundation. We established that Whonix Workstation is the only acceptable baseline for online activity. We agreed that Debian and Fedora are unfit for web browsing.

But a hardened template is only half the battle.

If you run a Whonix-based App qube persistently, you are still carrying a state. Cookies accumulate. Browser history grows. Session tokens linger. Even if the OS is hardened, the environment is becoming a unique fingerprint over time. A persistent VM, no matter how secure its base, is a target that exists across multiple sessions.

Qubes OS offers a superior architectural solution: Disposables.

This post is not about finding a better lock for your door; it is about realizing that the door itself should vanish after you walk through it.

The Philosophy: Damage Limitation via Ephemeral Existence

Qubes OS is built on isolation. Virtual Machines (VMs) separate tasks. But isolation has a limit: if a persistent VM is compromised, the attacker gains access to everything stored within that VM's lifetime.

Disposables take the concept of isolation to its logical extreme. They are temporary, single-use environments that are:

1. Wiped Clean: Every session starts fresh. Every session ends with total destruction.

2. Stateless: No cookies, no history, no temporary files survive the shutdown.

3. Untraceable: It is mathematically impossible to build a long-term profile of you if your digital footprint is erased every time you close the window.

The Goal: Move all online activities, except those requiring persistent state, to disposables.

The Scope: What Moves to Disposables?

If your threat model includes avoiding tracking, preventing malware persistence, or limiting the blast radius of a zero-day exploit, the rule is simple:

If it doesn't need to remember you, it runs in a disposable.

This includes:

• Web Browsing: The primary vector for drive-by downloads and fingerprinting.

• File Downloads: Treat every download as a potential Trojan.

• Social Media: X (Twitter), Telegram, and other platforms where session hijacking is a risk.

• Untrusted Interactions: Any chat or forum where you interact with unknown entities.

The Implementation: The Fresh Start Protocol

Critical Warning: Do not convert your existing "daily driver" browsing qube into a disposable template.

If you have been using a qube for months, it has accumulated cookies, cache, and potentially lingering malware traces. Converting a "dirty" qube into a template means every disposable you launch inherits that dirt. You aren't getting a fresh start; you're just cloning the contamination.

The Architectural Rule:

A Disposable Template must be pristine, containing only the most necessary data and settings you require every time you launch a disposable instance. It should have no accidental history, no stray cookies, and no lingering processes from previous sessions.

Step 1: Create a Fresh App qube

1. Open Qubes Manager.

2. Click Create New Qube.

3. Name: disp-web-template (clearly indicating its purpose).

4. Template: Select whonix-workstation-18 (or your latest version).

5. Net qube: sys-whonix.

6. Click OK.

Step 2: Verify and Harden

Launch the new qube once to verify your setup and configure your "baseline state."

• Install Extensions: Add your essential privacy tools (e.g., uBlock Origin, Privacy Badger or VPN).

• Configure Accounts: Log in to accounts that you want to be automatically logged in every time you start a disposable instance.

• Set Bookmarks: Bookmark or open tabs for websites you frequently visit and want pre-loaded.

• The Cookie Rule: Do not accept cookies for any site during this setup phase. Ensure your browser settings reject third-party cookies by default.

• Clean Up: Once configured, close all windows and shut down the qube.

This state is now "frozen". Every disposable you launch will start with these exact settings, but will never save new changes.

Step 3: Enable Disposable Mode

Now that you have a sterile, configured container:

1. Right-click your new disp-web-template qube.

2. Go to Settings > Advanced.

3. Check Disposable Template.

4. In the Default Disposable Template dropdown, select whonix-workstation-18-dvm.

5. Click OK.

Note: Your App qube now appears in italics in the Qubes Menu, signaling it is a launcher for disposables.

Understanding the Two Modes

Once converted, you have two ways to operate. Choose the one that fits your threat model.

Mode A: Unnamed Disposables (The "One-and-Done" Approach)

1. Click the application (e.g., Brave) from the italicized App qube menu.

2. A new disposable VM (e.g., disp1234) launches instantly.

3. The Catch: Settings from the template carry over (e.g., you are logged into Twitter, bookmarks are present). However, anything you do in this session, new logins, downloads, history, is wiped the moment you close the window.

4. Isolation: Opening a second app from the main menu launches a different disposable instance. They cannot talk to each other.

5. Multi-App Workflow: If you need two apps together (e.g., a browser and a file manager), do not launch the second app from the main menu. Instead, open the second app from the submenu of the running disposable instance's random name in the menu. This ensures both apps run in the same disposable instance.

6. Termination: Close all windows in the instance, and the VM is instantly destroyed. No trace remains.

⚠️ WARNING: Do not close your working window until you are done. Once all windows in a disposable instance are closed, that disposable instance is instantly destroyed. If you are in the middle of a task, closing the last window will wipe your work.

Mode B: Named Disposables (The "Persistent Session" Approach)

1. In Qubes Manager, go to Create New Qube > Named Disposables.

2. Select your Whonix template.

3. Set the Net qube to sys-whonix.

4. Select the applications you need (Browser, Terminal, etc.).

5. Launch it.

How it differs:

• The VM keeps its name (e.g., social-disposable).

• You can keep it running for hours, opening multiple tabs and apps within the same instance.

• Crucial: When you manually shut it down, the instance is completely destroyed. The next time you launch social-disposable, it is a brand new, clean instance.

The Exception: E2EE Messengers

There is one category of software that defies the disposable model: End-to-End Encrypted (E2EE) Messengers like Signal, WhatsApp, and SimpleX Chat etc.

Why? These applications store private keys, contact lists, and message history locally. If you run them in a disposable, you lose your keys and your history every time you close the window. They are functionally useless without persistence.

The Middle Ground: Custom Persist As we cannot use standard disposables here, and persistent App qubes pose a risk, Qubes OS offers a middle ground: Custom Persist.

This is an advanced feature allowing the creation of a minimal-state App qube. The purpose is to avoid unwanted data persisting as much as possible by disabling the ability to configure persistence from the App qube itself. After this, /home and /usr/local are not persistent unless explicitly configured.

We can surgically bind only the specific directory needed (e.g., Signal's config folder) while keeping the rest of the system ephemeral.

Configuring Custom Persist for Signal

This requires command-line interaction in dom0.

• Enable the service:

qvm-service -e custom-persist

(Replace with your actual VM name)

• Define the persistent directory: For Signal, we only want to persist the config folder containing keys and history:

qvm-features custom-persist.signal_config /home/user/.config/Signal

• Re-enabling standard persistence (if needed): If you ever need to revert to full /home persistence:

qvm-features custom-persist.home /home

The Result: Your Signal qube behaves like a disposable for everything except the specific directory holding your keys. If the OS is compromised, the attacker gets nothing but a blank slate. If you close the qube, your keys remain safe in the bind mount, but the rest of the system is wiped.

The Architectural Takeaway

This shift represents a fundamental change in mindset.

• Traditional Security: "How do I protect my data from being stolen?"

• Architectural Security: "How do I ensure that even if my data is stolen, it is worthless?"

By shifting to disposables:

1. Malware dies with the session. A trojan downloaded today cannot infect you tomorrow because the environment it lives in no longer exists.

2. Tracking is broken. There is no long-term cookie jar to fill.

3. Human error is contained. A mistake in a disposable costs you a few minutes of reconfiguration, not your entire digital identity.

The Hierarchy of Safety:

1. Whonix Workstation (The hardened base).

2. Disposables (The ephemeral execution).

3. Custom Persist (The surgical exception for necessary state).

Stay vigilant. Stay ephemeral.