HN Fixates on the Firefox and Tor IndexedDB Bug That Turned Private Sessions into a Stable Fingerprint

Why Hacker News saw this as a serious privacy break

This story landed hard because it attacks the exact boundary private browsing and Tor users assume is protected. By crawl time, the HN submission had 906 points and 279 comments. The discussion was not framed as an ordinary browser bug. Readers saw it as a reminder that privacy can fail through something much smaller than cookie access or explicit cross-site storage. If a site can derive a stable identifier from a supposedly harmless API response, then the browser itself becomes the tracking channel. That is why commenters kept returning to Tor Browser’s New Identity feature: the problem was not merely that Firefox leaked state, but that a reset users rely on for unlinkability could remain linkable while the process was still alive.

What the research says the bug actually did

The Fingerprint.com write-up says all Firefox-based browsers exposed a deterministic process-lifetime identifier through the order returned by indexedDB.databases(). In private contexts, database names are mapped to UUID-based filename bases via a global hash table. Later, when database metadata is collected, Firefox iterates internal structures without canonical sorting. The result is that the returned ordering reflects stable process-scoped state rather than a neutral presentation. The researchers say a site can create a fixed set of database names, inspect the resulting order, and derive a fingerprint that persists across private windows, across unrelated origins, and in Tor Browser even through New Identity, as long as the process has not fully restarted. They also quantify the signal: with 16 controlled names, the theoretical permutation space is roughly 44 bits.

What changed and why it matters

The report says Mozilla fixed the issue in Firefox 150 and ESR 140.10.0, with the mitigation idea being straightforward: do not expose internal storage ordering. Canonical sorting is enough to remove the entropy. HN liked that the write-up was specific about both mechanism and fix. One top comment praised the clarity of the research note itself. Another pushed an important nuance: fingerprinting across Tor is not the same thing as full deanonymization. That is true, but it did not reduce the perceived severity much. For the Tor threat model, persistent pseudonymous linkability inside a browser runtime is already a meaningful failure, because the product promise is built around reducing linkability in the first place.

What the community angle adds

The most practical HN responses were conservative. Some commenters immediately said the real operational advice, until patched, was to fully exit Tor Browser between sessions rather than rely only on closing windows or hitting New Identity. Others used the thread to argue that browsers still expose too many low-level behaviors without meaningful guardrails. The deeper lesson is less about IndexedDB specifically and more about privacy engineering. A browser API does not need to expose names, values, or permissions to leak identity. A stable ordering pattern can be enough. That is what made this thread feel high-signal: it was a clean example of how implementation detail, not obvious feature design, can reopen a tracking channel users thought had already been closed.

Sources: Fingerprint.com research note · Hacker News discussion