Tor Browser’s core promise is compartmentalization. Every time you click “New Identity,” the browser closes your tabs, rotates your Tor circuit, and clears the session state accumulated since you opened it. The model is straightforward: each identity is a clean slate. A recent disclosure from Fingerprint.com shows that Firefox, the engine underneath Tor Browser, had been quietly maintaining a stable identifier in its IndexedDB storage that “New Identity” never touched. That identifier linked every session back to the same browser installation, regardless of how many times the user cycled their identity.
This is not a story about a sophisticated exploit. It is a story about the gap between what a browser’s privacy surface claims to clear and what its internal storage architecture actually clears.
What IndexedDB Is and Why Firefox Uses It Internally
Most developers encounter IndexedDB as a client-side storage API for web applications. It is a transactional, key-value object store built into the browser, capable of holding structured data much larger than what localStorage handles. Web pages use it for offline caching, drafts, and local-first application state.
What is less commonly known is that Firefox itself uses IndexedDB for internal browser data, not just for the websites you visit. Firefox’s own UI components, extension storage, and subsystems write to IndexedDB databases stored in the profile directory. These databases live alongside, but are architecturally separate from, the IndexedDB data tied to individual origins that get cleared when you wipe site data.
On disk, Firefox stores IndexedDB data under the profile folder in a path like:
~/.mozilla/firefox/<profile>/storage/default/Each origin gets its own subdirectory. But Firefox’s own internal databases, used by privileged browser code running at moz-extension:// or internal origins, do not necessarily fall under the same cleanup routines that user-facing privacy controls invoke.
The “New Identity” Assumption
Tor Browser layers its own isolation logic on top of Firefox’s existing privacy mechanisms. When you trigger New Identity, the browser:
- Closes all open tabs and windows
- Requests a new Tor circuit from the local
tordaemon - Clears cookies, cache, and session storage for visited origins
- Resets the HTTP authentication cache
The implementation lives in Tor Browser’s torbutton code, which calls into Firefox’s nsICookieManager, nsICache, and related interfaces. The assumption is that after this sequence, no information from the previous session survives to correlate with the next.
The assumption holds for the data those interfaces cover. The problem is that Firefox’s internal storage, maintained outside of those interfaces, was never in scope for the cleanup.
A Stable Identifier Across Sessions
What Fingerprint.com found is that Firefox generates and persists a unique identifier, stored in an IndexedDB database under a privileged internal origin, that is not cleared by New Identity. The identifier is created on first run or first use of the relevant Firefox subsystem, written to the database, and then read back on every subsequent session. Because it is stable across restarts and across identity rotations, any party that can read it across two different sessions can conclude that those sessions came from the same browser installation.
This class of bug has historical precedent. In early 2022, WebKit’s IndexedDB implementation was found to expose database names across origins, letting any site enumerate the IndexedDB databases created by other sites the user had visited. That vulnerability, CVE-2022-22594, worked differently from this Firefox issue but shared the same root dynamic: the browser’s IndexedDB infrastructure leaked information the same-origin policy was supposed to contain.
The Firefox/Tor case is more targeted in scope but worse in impact for the specific user population it affects. Users of Safari with cross-site tracking protections enabled were exposed to a privacy leak. Users of Tor Browser who clicked “New Identity” to escape surveillance were exposed to identity correlation, which is a much more severe consequence given why those users chose Tor in the first place.
Why Internal Browser Storage Is a Persistent Problem
Browsers are large, complex applications with many subsystems that have their own storage needs. Telemetry, sync state, extension data, UI preferences, form autofill, certificate pinning state, and dozens of other subsystems all need to persist data across restarts. The challenge is that this internal storage is developed by different teams, under different review criteria, with different threat models than the ones governing user-facing privacy features.
When a privacy engineer specifies what “New Identity” should clear, they enumerate the storage types they know about and that fall within the threat model they are reasoning about. Internal browser databases often do not appear on that list, either because they are not documented in the right place, because the team that built them did not consider the privacy implications of identifier persistence, or because clearing them would break functionality that the feature depends on.
This creates a structural problem. A complete privacy reset would need to clear or regenerate every stable identifier Firefox holds, not just the ones websites see directly. That is a much harder problem than clearing cookies.
The Threat Model Tor Browser Operates Under
Tor Browser’s design document lays out the threat model explicitly. The primary adversary is a global passive adversary who can observe traffic at multiple points on the network, combined with a local adversary who controls some of the websites you visit. Against that adversary, Tor provides circuit-level anonymity. But the browser’s local state is a separate attack surface.
The threat model distinguishes between “unlinkability” (ensuring that your activity cannot be linked across sessions) and “unobservability” (ensuring that an observer cannot tell you are using Tor at all). The IndexedDB identifier vulnerability breaks unlinkability without touching the network layer at all. A website operator who can correlate two visits sees that they came from the same browser, regardless of the IP address shown.
This matters particularly for users who cycle identities within a single browsing session, for example when accessing a whistleblowing platform, then resetting and accessing an unrelated service. If both services are operated by the same adversary or share a common third-party tracker, the identifier creates the link the user was trying to prevent.
Mitigations and What Comes Next
The Tor Project operates with a patching process that applies fixes to Firefox ESR, the upstream base for Tor Browser. Vulnerabilities that affect Tor Browser’s specific privacy guarantees are generally handled through Tor Browser’s security advisories and coordinated with Mozilla.
For this specific class of issue, a full fix requires identifying every Firefox subsystem that persists a stable identifier and ensuring those identifiers are either not stable across identity rotations or are cleared as part of the New Identity procedure. That is non-trivial because it requires auditing internal storage across the entire Firefox codebase, not just the web-facing storage APIs.
A partial mitigation available to users right now is to close and reopen Tor Browser entirely rather than relying solely on New Identity. A full restart recreates the Firefox profile from the clean base profile that Tor Browser ships with, which eliminates most persistent internal state. This is less convenient than clicking a button, but it provides stronger isolation guarantees until the underlying issue is patched.
For users at high risk, the Whonix architecture, which routes all traffic through a Tor gateway VM and uses a separate workstation VM for browsing, provides a stronger isolation boundary. If the browser is compromised or leaks identifying information through internal state, the gateway still prevents the network-level correlation that would make that information useful to a remote adversary.
The Broader Lesson
This vulnerability is a concrete example of something that browser privacy engineers have known abstractly for years: the surface area for identity leakage in a complex browser is much larger than the set of APIs exposed to web pages. Tor Browser does an impressive job of hardening Firefox against the most common fingerprinting and tracking techniques. Patches are regularly applied to disable APIs that have no legitimate use for Tor users but do provide fingerprinting signals.
But Firefox is a large codebase with internal state management that predates the modern era of fingerprinting research. Every internal identifier, every cached UUID, every stable value written to a non-website-facing database is a potential linkage point that requires explicit attention in the context of Tor’s privacy model.
The Fingerprint.com researchers found one such identifier. It would be surprising if it were the only one.