Digital Compartmentalization: Separate Identities Without Leaking Metadata

You open Tor Browser for the research persona, but the system clock reads GMT-3 and the keyboard layout is pt-BR ABNT2. Three requests later, the fingerprint tells the story: Brazilian, Linux, Sao Paulo timezone, 2560x1440 monitor. Compartmentalization broken before the first login. The Basilisk team lives this daily: separating identities is not about a fake name on a form, it is about every bit leaving the machine telling the same coherent story for that persona. This post walks the full stack, from hardware to DNS to payment, without illusions and with commands you can run today.

Threat model tiers before you install anything#

Start with the threat model, not the tooling. A public bug-bounty persona on LinkedIn does not need the isolation of a researcher tracking a state APT group, and over-engineering the easy case wastes the discipline you need for the hard one. Define three tiers: public persona (attributable to you), professional persona (pseudonymous, linkable to employers) and research persona (non-attributable). For each tier, list adversaries, their capabilities, and what you lose if the compartment falls. Without this you will install Qubes and still log into personal Gmail from the wrong qube. Use the template in personal threat model and keep it to one page.

The core principle is unlinkability: no observable attribute should connect two personas. Attributes are not only names and emails; they are timezone, locale, browser fingerprint, exit IP, writing style, posting schedule, payment rails and even hardware serials. A single shared attribute across two personas is a join key an analyst uses to collapse them into one. Treat every persona as a set of attributes and audit the intersection between sets; anything in the intersection that should be empty is a leak to close.

Hardware and device isolation#

Hardware is the first boundary. ThinkPad X1 with Coreboot, a MacBook in Lockdown Mode, or a dedicated Framework: the rule is that a device does not cross personas. If you use the same laptop for banking and offensive research, compromising one end kills both. When the budget cannot fit three machines, run Qubes OS with disposable qubes per persona, or Whonix inside a dedicated VM. Physically separate a burner phone for SMS and 2FA of throwaway accounts; never enroll a research account's recovery on your daily phone, because the recovery number is itself a durable cross-persona identifier.

OS and VM isolation: Tails, Whonix, Qubes#

The three amnesic and compartmentalizing systems solve different problems. Tails is amnesic by design: boot from USB, leave no trace on disk, route everything through Tor, ideal for a single high-risk session. Whonix splits a Gateway VM (Tor) from a Workstation VM so the workstation can never learn its real IP even if compromised. Qubes OS is the daily driver for compartmentalization: each persona is a colour-coded qube with its own NetVM, and sys-whonix routes selected qubes over Tor. The comparison in Tails, Whonix or Qubes picks by scenario; the short version is Qubes for daily compartmentalized use and Tails for single amnesic sessions.

Browser fingerprint and the entropy trap#

Browsers deserve their own chapter. Firefox with separate profiles is not enough: cookies, cache and fingerprinting leak across windows and can be correlated by a determined site. Use Mullvad Browser or Tor Browser for the research persona, Brave with profiles for the professional one, and Safari for personal, each in its own VM or at least in Firefox Multi-Account Containers. Disable WebRTC, normalize resolution via letterboxing, and keep the User-Agent identical to the Tor crowd. Never install custom extensions in the non-attributable persona: each add-on adds entropy, and entropy is what a fingerprinting script turns into a unique ID. On Tor specifics, read real Tor anonymity before assuming three hops fix everything.

Network and DNS: where most people slip#

Network and DNS are the classic failure. A research persona exiting the same residential IP as the personal persona collapses the separation in 30 seconds of correlation. Use Mullvad or IVPN with WireGuard inside distinct VMs, or route the research persona over Tor by default. Send DNS-over-HTTPS to the VPN provider's resolver, never the ISP one. In Qubes, configure sys-vpn and sys-whonix as separate NetVMs per qube so a leak in one cannot reach another. Verify with dnsleaktest.com and, more reliably, run tcpdump on the physical interface before you trust anything: VPN marketing lies, packets leaving the NIC do not.

Metadata hygiene: the invisible heel#

Metadata is where a flawless persona dies. You can have perfect network isolation and still publish a PDF with your real name in the Author field, or a photo carrying EXIF GPS pointing at your balcony. Before any publication, run exiftool -all= on the file, linearize PDFs with qpdf and review properties in LibreOffice. Office documents carry persistent GUIDs across versions that quietly link files from the same machine. See metadata hygiene for the cleaning workflow by file type, and wire mat2 as an automatic scrub step before every upload so cleaning is the default, not a thing you remember to do.

Communication and payment must follow the compartment#

Communication must obey the same boundary. Signal with your personal number on the research persona is operational suicide; use SimpleX Chat or Session with per-persona identities, installed in separate Android profiles or GrapheneOS work profiles, and never cross contacts between personas, not even by a stray notification. Pick the messenger by threat model using the technical comparison. Payment is the axis people forget: a card, a PayPal, or a KYC exchange binds a persona to a legal identity permanently. Fund the research persona's VPS and relays with Monero, or with a well-isolated privacy workflow, because a single traceable payment unmasks everything upstream of it.

Common mistakes#

The recurring failures are boring and lethal. Logging into a personal account 'just once' from the research qube; reusing a profile picture across personas that reverse-image search links instantly; posting from two personas on a schedule that matches your real timezone and sleep pattern; carrying the same writing quirks and signature phrases; and letting a password manager sync all personas so one breach reveals the whole map. Each is a shared attribute, and shared attributes are the only thing an analyst needs. The tool stack is not the control; the routine that keeps the sets disjoint is the control.

Monthly audit and checklist#

Operate separation as routine, not a one-off project. Monthly, list every persona, account, device, and IP used, then look for cross-overs by running OSINT on yourself following ethical OSINT with Spiderfoot aimed inward. If the output links two personas that should be isolated, the flaw exists and is exploitable now. Checklist: one device or qube per persona; distinct exit IP per persona; matching locale, timezone and keyboard per persona; no shared avatars, usernames or recovery numbers; metadata scrubbed before every publish; payments unlinkable; and contacts never crossed. Green on all eight or the compartment is theatre.

A worked example: standing up a research persona#

Put it together concretely. Create a new Qubes qube named research-alpha, colour it red, attach it to a fresh sys-vpn that terminates on a Mullvad WireGuard endpoint bought with Monero, and set the qube timezone and locale to match the persona's claimed location. Inside it, install Mullvad Browser with no extensions, register a dedicated ProtonMail reached only from this qube, and mint a SimpleX identity with a self-hosted relay. Fund nothing from a card that touches your name. Before the persona ever posts, run tcpdump on the host NIC to confirm the only egress is the VPN endpoint, then linearize and scrub every file with mat2. Only after all observable attributes are consistent does research-alpha go live; the discipline is front-loaded, because a leak on day one is unrecoverable.

FAQ#

Do I really need separate hardware, or are VMs enough? VMs are enough against remote web adversaries, but a kernel or hypervisor escape, or physical seizure, defeats software isolation; separate hardware is the control when the adversary can run code on the host or hold the device. For most researchers, Qubes gives strong isolation without three laptops, and you add physical separation only for the highest tier. Is a VPN plus Tor better than Tor alone? Only if you understand the trust you are moving; a VPN-before-Tor setup hides Tor use from your ISP but shifts trust to the VPN, so choose based on which observer you are actually defeating, not by stacking tools for comfort.

How do I keep writing style from linking personas? Vary sentence length and vocabulary deliberately, avoid signature phrases and emoji habits, and consider drafting research-persona text in a different language then translating, since stylometry tools key on consistent idiosyncrasies. And what about timezone leaks in metadata and posting times? Set each persona's VM to a timezone consistent with its claimed location, schedule posts to match that region's waking hours rather than your own, and never let a 3am local-time burst betray the human behind three 'independent' accounts.

Conclusion#

Compartmentalization is not a product you install, it is a discipline you run. The failure mode is never the cryptography; it is a shared timezone, a reused avatar, a traceable payment, or one lazy login from the wrong qube. Pick your tiers, isolate hardware and network per persona, normalize every observable attribute, scrub metadata by default, and audit the intersection of your own personas monthly with the same OSINT tools an adversary would use. Practical takeaway: today, map one persona on a sheet with three columns, device, network, identity, and mark every cell it shares with another persona; each marked cell is technical debt to close within two weeks.