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.
Editorial analysis by NHI Mgmt Group, based on content published by Fingerprint: “We found a stable Firefox identifier linking all your private Tor identities”.
By the numbers:
- With 16 controlled names, the theoretical space is about 44 bits of fingerprint entropy.
Key questions
Q: What breaks when browser APIs expose deterministic ordering across origins?
A: They can become stable fingerprinting surfaces even when they do not expose cookies, localStorage, or explicit IDs.
Q: Why do private browsing modes still fail when process state survives?
A: Because the user believes the session ended when the window closed, but the browser process may still retain deterministic internal state.
Q: How do security teams detect browser fingerprinting risks in APIs?
A: Look for deterministic output, stable ordering, repeatable timing, and behaviour that depends on hidden internal state rather than user-visible data.
Practitioner guidance
- Canonicalize storage metadata output Sort or otherwise normalize IndexedDB metadata before returning it so internal ordering cannot reflect process-scoped state.
- Test privacy resets against process lifetime Verify that private browsing exits, identity resets, and similar controls eliminate observable signals even when the browser process stays alive.
- Review APIs for fingerprintable ordering Audit browser-facing APIs for deterministic ordering, timing, or enumeration behaviour that can be reused as a fingerprint across origins.
Bottom line: A browser privacy feature can fail even when it blocks conventional storage, if an API leaks stable process-scoped state through deterministic ordering.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:16 pm
Deterministic metadata is a privacy boundary failure, not a minor implementation quirk. When browser APIs leak stable ordering or other process-scoped detail, they create linkability without any obvious identifier. That shifts the problem from storage protection to runtime observability, which is a different governance challenge. Practitioners should treat any deterministic cross-session signal as fingerprint material until proven otherwise.
A question worth separating out:
Q: What should product teams change after finding a privacy side channel like this?
A: They should normalize the output, test reset flows against long-lived runtime state, and treat any process-scoped signal as a privacy defect. The goal is to remove observability of internal implementation details before users rely on a mode such as private browsing or identity reset.
👉 Read our full editorial: Firefox IndexedDB ordering exposed a stable browser fingerprint