Firefox’s IndexedDB returns database names in a process-scoped hash-table order, creating a stable cross-origin fingerprint that survives private windows and Tor’s “New Identity” reset.
Key Takeaways
The bug lives in dom/indexedDB/ActorsParent.cpp: private-mode DB names are mapped to UUIDs in a global StorageDatabaseNameHashtable, and indexedDB.databases() iterates an unsorted nsTHashSet, leaking that layout as a fingerprint.
With 16 controlled database names the ordering yields ~44 bits of entropy (16! permutations), more than enough to uniquely identify a browser instance among realistic concurrent users.
The identifier is process-scoped, not origin-scoped: two unrelated sites see the same permutation in the same browser run, enabling cookieless cross-origin linkage.
In Tor Browser, the fingerprint survives the “New Identity” action (clears cookies, history, circuits) until a full process restart, directly defeating the feature’s unlinkability guarantee.
The fix is a one-line sort: canonicalize indexedDB.databases() output lexicographically before returning it. Shipped in Firefox 150 and ESR 140.10.0, tracked as Mozilla Bug 2024220.
Hacker News Comment Review
Commenters broadly acknowledged the reset boundary: the identifier resets on full browser restart, which limits attacker utility to within-session tracking but still defeats Tor’s intra-session “New Identity” isolation.
A thread of skepticism emerged around threat model scope: fingerprinting across Tor pseudonymizes rather than deanonymizes, so high-risk users (e.g., hidden-service operators) may face different practical risk than casual private-browsing users.
Several commenters raised the disclosure incentive question: a fingerprinting company that responsibly disclosed a tracking vector is destroying its own competitive advantage, prompting speculation about motives.
Notable Comments
@lpapez: flags the business-model paradox – a fingerprinting vendor voluntarily burning a zero-day it could monetize.
@bawolff: notes the restart boundary directly, arguing it “significantly reduces usefulness to attackers.”
@1vuio0pswjnm7: raises the JavaScript-disabled edge case – the attack requires JS execution, which Tor’s safest security level blocks.
