Firefox’s indexedDB.databases() returns results in hash-table iteration order, creating a stable 44-bit process-lifetime fingerprint that tracks users across origins and defeats Tor Browser’s “New Identity.”
Key Takeaways
indexedDB.databases() exposes database names in UUID hash-table iteration order, not creation order, leaking process-scoped state to any calling origin.
The UUID mapping in StorageDatabaseNameHashtable inside dom/indexedDB/ActorsParent.cpp is process-scoped, not origin-scoped, so unrelated sites independently derive the same identifier.
With 16 controlled database names the permutation space is 16! (~44 bits of entropy), easily enough to distinguish concurrent browser instances in practice.
Tor Browser’s “New Identity” feature does not clear the UUID mappings; only a full Firefox process restart resets the fingerprint.
Fix is lexicographic sorting of indexedDB.databases() output before returning, shipped in Firefox 150 and ESR 140.10.0 (Mozilla Bug 2024220).
Hacker News Comment Review
Commenters broadly agreed the attack’s real-world window is bounded by the browser process lifetime, but noted that a running Tor session can span hours of sensitive activity.
Discussion on threat model: fingerprinting pseudonymizes rather than deanonymizes Tor users, and commenters with high-risk opsec needs pointed toward Whonix, Qubes, GrapheneOS, and Kicksecure documentation instead of HN advice.
The disclosing company’s own fingerprinting product prompted skepticism about why they responsibly disclosed rather than quietly exploiting a differentiating capability, with no clear answer in the thread.
Notable Comments
@SirMaster: Questions why indexedDB.databases() requires no user permission prompt, arguing browsers should gate storage API access the way mobile OSes gate hardware sensors.
@yencabulator: Practical interim mitigation before patching: fully exit Tor Browser between sessions and never mix use cases within a single running process.
