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

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.