Firefox Tor IndexedDB Fingerprinting Vulnerability Privacy Breakdown

A browser marketed as anonymous just got caught leaking a stable identifier across every private session you thought it was protecting. That’s not a minor edge case — it’s a foundational failure.

Key Takeaways

• A stable Firefox identifier persists inside IndexedDB storage and survives Tor Browser’s identity isolation mechanisms, linking separate browsing sessions back to the same user.
• The vulnerability affects Tor Browser specifically because it’s built on Firefox’s engine, and Firefox’s IndexedDB implementation doesn’t reset storage origins the way Tor’s threat model requires.
• Fingerprinting via browser storage APIs is harder to detect than canvas or WebGL fingerprinting — it produces no visible output and leaves no obvious audit trail.
• Users relying on Tor for high-stakes anonymity — journalists, activists, whistleblowers — face measurably higher de-anonymization risk until a verified patch ships and propagates.
• This incident fits a pattern: browser fingerprinting surfaces keep expanding faster than privacy-focused projects can audit them.

Background: How Firefox, Tor, and IndexedDB Collide

Tor Browser isn’t a custom browser built from scratch. It’s a hardened fork of Firefox ESR, which means every quirk in Firefox’s storage layer is a potential attack surface in Tor. That dependency is both practical — Tor doesn’t have the engineering resources to build a full browser engine — and inherently risky.

IndexedDB is a client-side storage API built into all modern browsers. It lets web apps store structured data locally: offline-capable apps, cached user preferences, large datasets. Chrome, Firefox, and Safari all implement it. The spec is a W3C standard, so there’s nothing exotic here. It’s been in Firefox since version 10, back in 2012.

Tor Browser’s core privacy promise is new identity isolation. When you click “New Identity,” Tor wipes cookies, clears session state, rotates the Tor circuit, and hands you a fresh slate indistinguishable from a new user. The attack surface for de-anonymization is supposed to shrink to near zero between identities.

According to research published by Fingerprint.com in early 2026, IndexedDB entries created under one Tor identity weren’t being fully cleared during identity rotation. A stable identifier — consistent across identity changes — remained accessible to sites that knew where to look. The Hacker News thread discussing the disclosure (item #47866697) drew hundreds of comments from security engineers, many of whom flagged that Firefox’s origin partitioning for IndexedDB doesn’t map cleanly onto Tor’s circuit-based identity model.

This isn’t a new class of attack. Canvas fingerprinting — where a site renders hidden graphics and reads pixel-level GPU output to fingerprint a device — was documented publicly by researchers as far back as 2012. What makes the IndexedDB variant different is persistence and stability. Canvas fingerprints shift with driver updates and GPU changes. An IndexedDB identifier doesn’t change unless explicitly deleted.

That distinction matters more than it might seem at first.

The Technical Mechanism: Why IndexedDB Survives Identity Resets

Firefox’s IndexedDB storage is keyed by origin — the combination of scheme, hostname, and port. Tor Browser modifies Firefox’s networking stack to route traffic through Tor circuits, but the browser’s storage layer still uses the standard Firefox origin model underneath.

When Tor rotates an identity, it clears cookies and session storage. But according to the Fingerprint.com research, certain IndexedDB entries associated with specific origins weren’t getting wiped. A site visited under Identity A could write a value to IndexedDB. After a “New Identity” rotation, revisiting that site under Identity B could read the same value — because the underlying storage key hadn’t changed.

The identifier isn’t something a site injects deliberately, though it could be. It can emerge from routine browser behavior: background sync operations, cached API responses, or browser-internal housekeeping that writes to IndexedDB without any user action. That makes it a passive fingerprint, not an active attack. Passive fingerprints are harder to block because there’s no suspicious network request to intercept.

Why This Attack Class Is More Dangerous Than Canvas Fingerprinting

Canvas fingerprinting is well-understood at this point. Tor Browser ships with canvas fingerprinting defenses — it either blocks canvas reads or adds noise to the pixel output. Fingerprint.com’s own research has catalogued canvas as a known, partially-mitigated vector.

IndexedDB fingerprinting sidesteps those mitigations entirely. No pixel data. No GPU call. Just a storage read that returns a string.

The “Survives Identity Reset” column is what makes IndexedDB uniquely problematic. Every other vector in the table either gets blocked, gets noised, or gets cleared on identity rotation. IndexedDB doesn’t. That single column tells you everything about the severity here.

The Scope of Affected Users

Tor Browser’s user base skews heavily toward people with genuine anonymity requirements. The Tor Project’s own metrics (metrics.torproject.org) showed roughly 2–3 million daily Tor users as of late 2025. Not all use Tor Browser specifically, and not all use Firefox-based builds. But a significant portion do.

The risk isn’t evenly distributed. A casual user browsing anonymously for general privacy loses something real, but the practical consequence is limited — an advertiser links two sessions. For a journalist communicating with a source in an authoritarian country, or a whistleblower accessing document-drop infrastructure, linking two “separate” Tor identities can have physical-world consequences.

That asymmetry matters when you’re assessing severity. A vulnerability that inconveniences one group while endangering another deserves to be treated at the level of the higher-stakes user.

Practical Implications: Three Scenarios Worth Examining

Scenario 1: High-risk anonymity users — journalists, activists, whistleblowers

The immediate recommendation is to stop treating Tor Browser’s “New Identity” function as a hard anonymity boundary until this is patched and independently verified. Use separate Tor Browser instances on separate machines or separate VMs if session isolation is genuinely critical. SecureDrop’s documentation already recommends air-gapped workflows for the most sensitive communications. This vulnerability reinforces that approach — it doesn’t create it from scratch.

Scenario 2: Web developers building Tor-compatible sites

If you’re building anything that privacy-conscious users access via Tor, auditing your own IndexedDB usage is worth doing now. Sites that write to IndexedDB — even for benign reasons like caching API responses — are inadvertently creating linkable identifiers for Tor users. Consider not writing to IndexedDB at all for anonymous sessions, or explicitly clearing storage on session end using indexedDB.deleteDatabase(). This approach can fail when developers assume browser defaults handle cleanup — they don’t, not reliably, not here.

Scenario 3: The Tor Project and Mozilla

The fix isn’t trivial. Properly isolating IndexedDB storage per Tor circuit identity requires changes at the Firefox storage layer, not just in Tor Browser’s configuration scripts. Mozilla would need to expose a storage-clearing API that Tor Browser can hook into during identity rotation — or Tor Browser needs to implement its own IndexedDB interception layer. Neither is a one-line patch. This isn’t always the answer people want to hear, but rushing a partial fix creates a false sense of security that’s arguably worse than no fix at all.

Watch for Tor Project security advisories and Mozilla bug tracker entries (bugzilla.mozilla.org) tracking this fix’s progress.

What to watch next:

• Whether Mozilla treats this as a Firefox bug with broader impact or defers to the Tor Project
• Any updated Tor Browser release notes citing IndexedDB storage isolation
• Independent verification from security researchers confirming or adjusting the vulnerability’s scope

Conclusion: A Symptom, Not an Isolated Bug

The Firefox Tor IndexedDB fingerprinting vulnerability isn’t an isolated edge case. It’s a symptom of a deeper structural tension: Tor Browser inherits Firefox’s storage architecture, and that architecture was never designed with Tor’s strict per-circuit identity model in mind.

IndexedDB identifiers survive “New Identity” resets, creating a stable cross-session fingerprint. The attack requires no network trace and bypasses existing canvas and WebGL mitigations. High-risk users should treat “New Identity” as insufficient isolation until a verified patch ships. The fix requires real coordination between the Tor Project and Mozilla at the browser storage layer — not a config tweak.

Over the next 6–12 months, expect more storage API surfaces to face similar scrutiny. The Cache API, Service Worker registrations, and OPFS (Origin Private File System) all share structural similarities with IndexedDB. Researchers who found this one are almost certainly checking those next.

The broader pattern from 2024 through 2026 is consistent: as traditional fingerprinting vectors get blocked, researchers find stable identifiers in unexpected storage layers. Privacy tooling perpetually plays catch-up with the browser’s expanding API surface. That’s not a criticism — it’s the nature of the problem. But it means the work never stops.

If you’re maintaining infrastructure that high-risk users access via Tor, audit your storage API usage today. Don’t wait for the patch.

References

1. We Found a Stable Firefox Identifier Linking All Your Private Tor Identities
2. We found a stable Firefox identifier linking all your private Tor identities | Hacker News
3. Canvas fingerprinting - Wikipedia

Photo by Sri Widayanto on Unsplash