We found a stable Firefox identifier linking all your private Tor identities

Researchers uncovered a Firefox IndexedDB flaw that allowed websites to create a stable, high-entropy identifier shared across origins, linking activity in private browsing and Tor Browser even after using Tor’s “New Identity” feature, though it disappeared on full browser restart. Commenters note Mozilla and the Tor Project shipped rapid fixes, but argue the episode highlights deeper problems: the web’s growing fingerprinting surface, the ethics of commercial fingerprinting companies, and the difficulty of balancing usability, JavaScript-heavy sites and true anonymity. Many advocate stronger compartmentalization practices (separate VMs, Tails, Qubes) and stricter browser design or regulation to curb fingerprinting beyond just patching individual bugs.

Tor Browser & Firefox Response

  • Commenters note Tor Browser quickly rebases on Firefox ESR; an updated Tor Browser was released the day after Mozilla’s fix.
  • Some see this as evidence of a healthy responsible-disclosure process; others criticize the article’s alarmist title given the bug’s limited lifetime (process only, reset on restart).

Nature and Impact of the Vulnerability

  • Identifier is:
    • Process-scoped, not machine/profile persistent.
    • Shared across origins via a global mapping of database names to UUIDs.
    • Stable for the lifetime of the Firefox/Tor Browser process and survives “New Identity” in Tor Browser.
  • Key risk: linking multiple Tor identities or private/public sessions within the same browser process; several note this is serious for high-risk users but not a “forever ID.”

Ethics and Business of Fingerprinting

  • Debate over why a fingerprinting company would disclose:
    • One side: disclosure builds trust, avoids depending on a single bug, and denies competitors an advantage.
    • Others suspect marketing or downplay the severity.
  • Some argue all fingerprinting is inherently exploitative and should be treated as a vulnerability; others distinguish between “side effects of normal APIs” and true bugs.

Fingerprinting vs. Vulnerabilities

  • Long back-and-forth over whether fingerprinting equals “exploiting a bug.”
  • One camp: any non–opt-in identifier is a privacy vulnerability.
  • Another: using exposed info (headers, fonts, canvas) is not automatically an exploit unless it bypasses explicit technical countermeasures.

Mitigations & Opsec Practices (Tor, Qubes, Tails, JS)

  • IndexedDB ID is cleared on full browser restart; several emphasize always closing Tor Browser between distinct identities.
  • Tails (without persistence) and fresh disposable VMs are highlighted as strong mitigations; however:
    • Misuse of Qubes (reusing the same disposable VM) remains vulnerable; separate VMs per identity are required.
  • JavaScript:
    • Some say disabling JS increases fingerprint uniqueness but removes many tracking vectors.
    • Others argue Tor should default to JS off; disagreement remains on the net benefit.

Browser Design, Web Standards, and Permissions

  • Many criticize expanding web APIs (IndexedDB, canvas, etc.) as fingerprinting surface with marginal user benefit.
  • Suggestions:
    • Stricter origin scoping and permission prompts for potentially identifying APIs.
    • Standardized or randomized responses for fonts, timezones, window size.
    • “Ultra-minimal” or read-only browsers with no storage, JS, or forms, though others note this itself becomes a niche, fingerprintable profile.

User Attitudes, Tracking, and Law

  • Discussion on whether “most users don’t care” about tracking:
    • Some argue users are unaware or feel powerless, not truly indifferent.
    • Others point to support for surveillance-style legislation as evidence of low concern.
  • In the EU context, one side claims fingerprinting without consent is already illegal under GDPR; another calls for explicit bans and active anti-fingerprinting duties for browsers.

Research & Alternative Architectures

  • Commenters mention active academic work on fingerprinting at privacy conferences and anonymization bibliographies.
  • Remote browser isolation / “browser in a box” setups are proposed as another way to keep state ephemeral and off the user’s machine, though trade-offs and trust issues are noted.