Fingerprint.com's research demonstrates that a stable internal storage identifier in Firefox's IndexedDB implementation persists across Tor Browser's 'New Identity' resets. They show that this artifact allows websites to link browsing sessions that users believe are completely isolated, undermining Tor's fundamental privacy promise.
The editorial emphasizes that this is not a cookie or localStorage that failed to clear, but an internal database connection fingerprint used for bookkeeping that survives identity resets. This distinction matters because it represents a class of vulnerability in browser internals that privacy-focused browsers may not anticipate when implementing storage clearing routines.
The editorial highlights the architectural dependency: Tor Browser is built on Firefox ESR and inherits its rendering engine and storage APIs wholesale. This means implementation details in Firefox's IndexedDB — designed without Tor's threat model in mind — become attack surfaces that Tor's identity reset was never designed to address.
Researchers at Fingerprint.com — the browser fingerprinting company that has built a business on identifying users across sessions — published findings showing that Firefox's IndexedDB implementation contains a stable internal identifier that survives Tor Browser's "New Identity" function. The identifier persists across what Tor users believe are completely isolated browsing sessions, creating a linkage channel that defeats Tor's core identity separation guarantee.
The discovery landed on Hacker News with a score of 543, signaling significant community concern. And the concern is warranted: Tor Browser is built on Firefox ESR, inheriting both its rendering engine and its storage APIs. When you click "New Identity" in Tor Browser, it's supposed to nuke everything — cookies, cache, session storage, and IndexedDB databases. The new circuit gives you a fresh IP. The cleared storage gives you a fresh browser state. In theory, website A visited before the reset has zero way to connect you to website B visited after.
Except IndexedDB has internal bookkeeping that doesn't get the memo.
IndexedDB is a low-level browser API for storing structured data client-side. Unlike cookies or localStorage, it's a full transactional database with object stores, indexes, and cursors. Under the hood, Firefox's implementation uses a storage identifier to manage database connections and enforce origin isolation.
The vulnerability lies in the fact that this internal storage identifier — essentially a database connection fingerprint — remains stable even after Tor Browser performs its identity reset. A website that opens an IndexedDB connection before a "New Identity" reset can observe the same internal identifier when the user revisits after the reset. The browsing contexts that were supposed to be cryptographically and storage-isolated are now linked by a persistent browser-internal artifact.
This isn't a cookie that failed to clear. It's deeper than that. It's a structural property of how Firefox manages IndexedDB at the engine level, sitting below the layer where Tor Browser's cleanup routines operate. The Tor Browser team diligently clears the *contents* of IndexedDB — the databases, the object stores, the data. But the internal plumbing that Firefox uses to manage those databases retains state.
For Fingerprint.com, finding these kinds of identifiers is literally their business model. They sell browser identification services to companies that want to detect fraud and bot traffic. Their research team has a track record of finding persistent identifiers in browser APIs — they've previously published work on favicons as supercookies and other storage-layer tracking vectors. When a company whose revenue depends on fingerprinting tells you they found a way to track you, the technical credibility is high.
The severity here depends entirely on your threat model, but for the people who need Tor the most, it's serious.
For journalists and sources: If a state-level adversary controls both a honeypot site and a target site, this identifier could link a journalist's research browsing to their communication sessions. The "New Identity" button was supposed to be the firewall between those activities. For users whose physical safety depends on identity separation — journalists, dissidents, whistleblowers — this is not an academic concern.
For security researchers: Anyone using Tor Browser to probe infrastructure, visit suspicious domains, or conduct OSINT just learned that their "clean" sessions may not be clean. If a target can correlate your reconnaissance visits across identity resets, your operational security has a hole.
For the broader privacy ecosystem: This vulnerability is part of a recurring pattern. Browser storage APIs were designed for web application functionality, not for anonymity. IndexedDB, the Cache API, service workers, favicon caches — each has internal state management that may not align with Tor's threat model. Every time Tor Browser inherits a new Firefox feature, it inherits new attack surface that wasn't designed with unlinkability as a requirement.
The Hacker News discussion reflects genuine technical concern. The community has seen this movie before. In 2021, a similar issue with IndexedDB leaking the Google User ID across origins in Safari made headlines (that one was CVE-2022-22594, reported by — you guessed it — Fingerprint.com). Firefox and Tor have a more complex relationship than Safari and privacy, because Tor Browser is downstream of Firefox ESR and needs to patch against a codebase whose maintainers have different priorities.
If you're building applications that interact with privacy-sensitive users, or if you're a practitioner who uses Tor:
Immediate action: Do not rely on Tor Browser's "New Identity" as a complete isolation boundary until a patch ships. If you need true session isolation, use separate Tor Browser instances (separate installations, not just new identities) or use Tails OS, which boots from a clean state each time. Whonix with disposable VMs is another option — each VM gets a genuinely fresh browser installation.
For web developers: If your application handles sensitive users, be aware that IndexedDB usage on your site could inadvertently participate in cross-session tracking. Consider whether your IndexedDB usage is essential, and document it in your privacy model. This doesn't mean you're the attacker — but a third-party script on your page that opens IndexedDB could be.
For Firefox contributors: The deeper issue is architectural. Tor Browser needs Firefox to either provide a "nuke everything including internal state" API that's genuinely comprehensive, or to expose enough internals that the Tor Browser team can build their own. The current model — where Tor Browser tries to clean up after Firefox but can't reach internal implementation details — will keep producing these vulnerabilities.
For threat modelers: Add "browser storage API internal state" to your list of side channels. This sits alongside timing attacks, resource loading fingerprints, and CSS-based tracking in the category of "things the browser does that leak identity even when the application layer is clean."
This finding will likely accelerate the Tor Project's ongoing evaluation of whether Firefox ESR remains the right foundation for Tor Browser. The Tor team has discussed alternatives before, but the engineering cost of switching is enormous. More likely in the near term, expect a patch from the Tor Browser team that adds IndexedDB internal state to the cleanup routine — but the cat-and-mouse dynamic is the real story. As long as Tor Browser is a privacy layer bolted onto a browser engine built for a different threat model, these vulnerabilities will keep appearing. The question isn't whether there's another one — it's how quickly it gets found and fixed.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.