Browser fingerprinting

Re-identifying a visitor from the properties their browser exposes to any page, without storing anything on their machine. ip-reconnaissance listed it as the third of three leaks a VPN does not close; nothing-private demonstrates it, and eckersley-browser-uniqueness and laperdrix-amiunique measure it.

The defining property, and the reason it sits in an OSINT wiki rather than a web-development one: the identifier is derived, not issued. A cookie is something a site gives you and you can delete. A fingerprint is computed from what your browser already tells every page it loads, so there is nothing to clear. Private-browsing mode clears local state, which is precisely the part that does not carry the identity.

How identifying it actually is

Two peer-reviewed measurements, six years apart, on different technology, agreeing:

Instability is not protection. Fingerprints do change — 37.4% of Eckersley’s returning users showed at least one change over 24 hours — but a simple heuristic re-linked the changed fingerprint to its earlier version with 99.1% accuracy at a 0.86% false-positive rate.

Mobile stopped being a refuge. In 2010 “certain smartphones” were among the three resistant groups. By 2016, 81% of mobile fingerprints were unique, reaching that from the opposite direction: plugin lists are unique for 1% of mobile browsers against 37% of desktop ones, and the user agent takes over because it carries the device model (40% of Chrome mobile UAs unique, against under 4% for Firefox).

Both samples are self-selected — people who sought out a fingerprinting test — and both papers say so. The agreement between two biased samples on different stacks is corroboration, not a fix.

The surface

nothing-private hashes sixteen properties via Client.js: user agent, screen print, colour depth, current and available resolution, device XDPI and YDPI, plugin list, font list, local storage, session storage, timezone, language, system language, cookies, and canvas print.

Most of that list is low-entropy on its own — plenty of people share a timezone and a screen size. The discriminating power comes from the combination, and in practice from the canvas: rendering the same text or shape to an off-screen canvas and hashing the pixels picks up the GPU, driver, font rasteriser and anti-aliasing stack underneath the browser.

Two defences, both aimed at the canvas

The countermeasure table nothing-private carries treats the canvas as the load-bearing signal and splits on what to do about it:

1. Randomise the readout — return slightly different pixels each time, so the fingerprint never matches itself. firefox from v78, Tor Browser from 10.0, brave from v1.11.104, plus Ungoogled Chromium, Bromite, Pale Moon and BriskBard.
2. Blank the readout — return a constant, so every browser looks the same on that property and it carries no information. Tor Browser 8.0–9.5, firefox v58–77.

The two encode opposite theories of anonymity: randomising makes you a different person on every visit, blanking makes you indistinguishable from everyone else running the same browser. Randomisation is detectable (read twice, compare) unless the browser caches per-site; blanking is not, but it only works while enough people do it.

Neither defence touches the other fifteen data points, and the source says as much: the list “only covers one aspect.”

What the measurements say about defences, and it is not what a user wants to hear. laperdrix-amiunique models the removals instead of asserting them, and the ordering is the finding: dropping Flash moves uniqueness from 95% to 88%; generic HTTP headers plus no plugins cuts desktop uniqueness by 36%; disabling JavaScript entirely takes 89.4% down to 29%, and to 7% if user agents also go generic. The two large effects are platform decisions, not user installs.

eckersley-browser-uniqueness adds the trap underneath all of them: a countermeasure used by few people makes its users more distinctive. That is why the blanking defence above works only while enough browsers blank identically, and why 378 browsers in the 2010 sample that forged an iPhone user agent while reporting Flash were easier to pick out, not harder.

Where it sits in this spoke

• Against ip-reconnaissance: address-level recon tells you where a connection comes from; fingerprinting tells you it is the same visitor after the address changes. That is why the page there says a fingerprint “makes the IP almost redundant.”
• Against mysterium-node: the spoke’s counter-reconnaissance source changes whose address you borrow and leaves this surface untouched. The pairing is now sourced on both sides rather than asserted on one.
• Against myip: that tool runs a fingerprint test as a self-audit. nothing-private runs the same capability as a demonstration against the visitor. Same mechanism, opposite framing — the dual-use shape this spoke keeps finding.

Open

• No entropy figures anywhere in the corpus. Closed 2026-08-13 by the research pass: eckersley-browser-uniqueness, laperdrix-amiunique and cover-your-tracks, all T1.
• Nothing measures the 2026 web. The two studies are sixteen and ten years old. Plugins have since disappeared (NPAPI is dead), which was one of the two attributes carrying the most entropy in both — and no source here says what replaced it. cover-your-tracks runs live and publishes no dataset.
• Server-side and network-layer fingerprinting (TLS/JA3, HTTP/2 frame order) — a different layer, unheld.
• Nobody has run the test from this hub. cover-your-tracks was read, not executed; what a Termux-hosted browser scores is unknown and cheap to find out.

Related

nothing-private · eckersley-browser-uniqueness · laperdrix-amiunique · cover-your-tracks · peter-eckersley · ip-reconnaissance · myip · mysterium-node · osint · synthesis