Notifications
Clear all
Topic starter
15/08/2026 6:08 pm
TL;DR: Firefox-based browsers exposed a process-lifetime identifier through indexedDB.databases() ordering, letting unrelated sites link activity across origins and even persist that signal through private browsing and Tor Browser New Identity within a running process, according to Fingerprint. The bug shows how deterministic implementation details can become high-capacity tracking vectors when privacy boundaries depend on browser state, not just storage access.
NHIMG editorial — based on content published by Fingerprint: Firefox IndexedDB ordering exposed a stable browser fingerprint
By the numbers:
- The signal is not just stable, it also has high capacity: with 16 controlled database names, the theoretical space is about 44 bits.
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: What breaks when browser APIs expose deterministic metadata across sessions?
A: Deterministic metadata can turn an otherwise harmless API into a stable identifier, allowing sites to correlate activity across origins and sessions.
Q: Why do private browsing and anonymity features still need runtime-state controls?
A: Private browsing and anonymity tools can only protect the state they actually reset.
Q: How do security teams know whether privacy controls are actually working?
A: Look for evidence that discovery, classification, DSR routing, and consent enforcement update when the environment changes.
Practitioner guidance
- Review APIs for deterministic output leaks Audit browser, client, and SDK APIs that return ordered metadata, hashes, or enumerations, and verify that implementation details cannot produce stable cross-session identifiers.
- Test reset features against process-level persistence Validate whether private browsing, logout, or identity reset features actually clear process-scoped runtime state, not just cookies and storage.
- Canonicalise exposed metadata before release Return sorted or otherwise normalised values when an API might reveal internal ordering.
What's in the full article
Fingerprint's full article covers the implementation detail this post intentionally leaves for the source:
- The exact IndexedDB ordering behaviour and why Gecko’s internal hash structures made it stable
- The proof-of-concept logic used to demonstrate cross-origin linkability in affected Firefox-based browsers
- The Firefox and Tor Browser remediation context, including the fix tracked in Mozilla Bug 2024220
- The reasoning behind canonical sorting as a privacy-preserving implementation change
👉 Read Fingerprint's analysis of Firefox IndexedDB fingerprinting and browser linkability →
IndexedDB fingerprinting in Firefox-based browsers: what changed?
Explore further
15/08/2026 6:16 pm
Stable browser metadata is an identity problem, not just a privacy bug. When deterministic API behaviour can be observed cross-origin, the browser itself becomes an identifier source. That matters for digital identity governance because isolation controls are only effective if the runtime does not leak persistent signals. The practitioner conclusion is that privacy engineering and identity assurance now overlap at the API boundary.
A question worth separating out:
Q: Who is accountable when a privacy feature preserves linkability after reset?
A: Accountability sits with the product and platform owners who define reset semantics, the engineers who expose runtime state, and the reviewers who approve the API behaviour. Privacy claims must match actual state lifecycles, especially in browsers and identity-sensitive tools. If a reset feature does not break linkability, the control design is incomplete.
👉 Read our full editorial: Firefox IndexedDB ordering exposed a stable browser fingerprint
