The 36 techniques running on this site: what each one exposes, the mechanism behind it, and where browser defenses currently stand. Every one is implemented — nothing here is hypothetical.
Written to be read alongside the data page: each entry links to the table it produces.
Browser and platform, preferred languages in ranked order, compression support, and the page you came from.
Every HTTP request carries a header block. The server reads it directly; the page never has to ask for anything.
Where defenses stand · No mitigation possible
Unchanged and unchangeable — headers are how the web works. The user-agent string itself has been frozen and reduced in Chrome and Safari to limit what it leaks.
Processor architecture and bitness, exact browser build to the patch number, operating system version, device model, color-scheme preference, viewport size.
The server replies with an Accept-CH header listing what it wants. The browser then attaches those values to every subsequent request. Critical-CH makes it retry the very first request so nothing is missed.
Where defenses stand · Expanding in Chromium
Actively expanding in Chromium. Presented as a privacy improvement over the user-agent string, because the values are requested rather than broadcast — but a site that asks receives more precise data than the old string ever carried.
Which browser engine you really are, regardless of what your user-agent string claims.
Each engine emits its headers in its own fixed sequence. Reading the raw order requires access below the framework layer, which is why this page runs a custom HTTP server.
Where defenses stand · No mitigation
No mitigation exists or is planned. The same principle applies further down the stack in TLS handshake fingerprinting, which this page does not perform.
Color scheme, pixel density, window size, input device, accessibility settings, color gamut, and which rendering engine you use — plus whether JavaScript is disabled.
A stylesheet declares one rule per condition, each loading a different background image. The browser only fetches an image when its rule matches, so the pattern of requests tells the server which conditions were true. A @media (scripting: none) rule fires precisely when scripts are off.
Where defenses stand · Survives script blocking
No mitigation. Blocking or disabling JavaScript does not affect it, which makes it the standard counter-example to script blocking as a privacy measure.
Fingerprinting — identity without storage
These techniques recognize a returning visitor with nothing saved on their machine. They survive clearing cookies, private windows, and in some cases a change of browser.
A stable hash unique to your combination of graphics driver, fonts and rasterizer.
The page draws identical text and shapes off-screen and reads the pixels back. Anti-aliasing and font rasterization differ minutely between machines, and the difference is consistent for any one of them.
Where defenses stand · Randomized in Firefox and Safari
Firefox and Tor Browser randomize or prompt; Safari returns a value that changes per session. Chrome does not mitigate by default.
One identifier stable across sessions, combining dozens of individually weak signals.
Each signal splits the population; combined, they usually isolate one browser on one machine. The open-source library used here reports its own confidence.
Where defenses stand · A commercial industry
A commercial industry. The open version is deliberately public so its accuracy can be audited.
How you type and move a pointer — usable to tell whether the same human is present.
Key hold times, gaps between keystrokes, pointer speed, acceleration and path curvature are collected from ordinary events and compared against a stored profile.
Where defenses stand · In production use, ungated
In production use for fraud scoring and continuous authentication. No permission prompt exists for it.
Device class, and whether the machine is throttling, on battery saver or already busy.
A fixed benchmark is run several times; absolute speed and the way it degrades are both characteristic.
Where defenses stand · Timers coarsened
Timer precision has been coarsened across browsers to blunt timing attacks, which limits precision but not device classification.
Persistence — identifiers that come back
Storage is not one thing. It is a dozen compartments cleared by different controls, and an identifier only has to survive in one of them to be restored into all the others.
That deleting cookies alone does not make you a new person.
The same identifier is written to cookies, localStorage, sessionStorage, IndexedDB, Cache Storage, a service worker cache and window.name. On the next visit whichever copy survived repopulates the rest.
Where defenses stand · Cleared together, if you clear all
Browsers have unified 'clear site data' controls, which does clear these together. The technique survives partial clears, which is what most people actually perform.
A returning visitor even after cookies and site data are cleared.
The server labels a response with a unique ETag. The browser caches it and returns it in If-None-Match on every revalidation, handing the identifier back without ever storing site data.
Where defenses stand · Cache now partitioned
Mitigated only by clearing or partitioning the HTTP cache. Browsers now partition the cache per site, which stops cross-site use but not recognition by the same site.
How many tabs of a site you have open, and lets state propagate instantly between them.
BroadcastChannel, SharedWorker, Web Locks and storage events all provide same-origin communication between tabs.
Where defenses stand · Working as designed
Working as designed; no mitigation applicable.
Cross-site — how tracking becomes a profile
A single site learning about you is one thing. The commercial system depends on the same party appearing on thousands of sites and joining what it sees on each.
Whether an embedded party can recognize you from elsewhere, and whether your browser stops it.
This page embeds a frame from a genuinely different origin — the same server reached by its other hostname — which then sets and reads its own identifier from inside your visit, exactly as an advertising tag does. No outside company is involved.
Where defenses stand · Blocked or partitioned
Third-party cookies are blocked by default in Safari and Firefox and being phased down in Chrome; remaining storage is partitioned per embedding site. This is the most substantial privacy change of the last decade.
Exactly which fields real tags transmit about a visitor.
The page constructs the genuine request shapes used by Google Analytics 4, the Meta Pixel and an OpenRTB bid request, filled with the values collected from you — and displays them without sending anything.
Where defenses stand · Ubiquitous
Ubiquitous. A real-time bidding request is broadcast to hundreds of bidders per ad slot, all of whom receive it whether or not they win.
Display geometry, density, refresh rate, OS accent color, and whether you use reduced motion, increased contrast or forced colors.
Media queries and resolved CSS system colors, all readable synchronously.
Where defenses stand · Disclosed by design
Disclosed by design so pages can adapt. Accessibility settings are effectively health-adjacent data shared with every site, with no way to receive the accommodation while withholding the signal.
Which capabilities you have already allowed or denied elsewhere on the site.
The Permissions API reports current state without prompting.
Where defenses stand · Intentional
Intentional, and useful — it also means a site can tell how cautious a user is before asking for anything.
Permission-gated — what a prompt unlocks
These require an explicit approval. They are included to show the size of the step between 'no prompt' and 'one prompt' — and how little the prompt usually explains.
The browser is asked to open each application's private URL scheme; a hit is inferred from the window losing focus. Kept behind an explicit warning here, because a hit can genuinely launch the application.
Where defenses stand · Repeatedly tightened
Repeatedly tightened after public disclosure. Results are heuristic and vary by browser.
Deliberately not built
A demonstration of surveillance should not itself be surveillance. These techniques are real, documented, and would have worked here. Each was left out for a stated reason.
Hidden autofill harvesting
Invisible form fields that browsers fill with a name, address or card number are a working exploit for extracting personal data, not a demonstration of one. Nothing is learned by building it that this page does not already show.
History sniffing side channels
Timing and paint-based attacks that recover which sites you have visited are attacks on the browser itself, and current techniques are live vulnerabilities rather than settled behavior.
Live commercial trackers
Embedding a real analytics or advertising tag would transmit each visitor's data to those companies. This page builds the exact payloads and displays them instead, which teaches the same lesson without the collection.
Silent cross-site login detection
Probing third-party endpoints to determine which services you are signed in to sends requests carrying your cookies to companies you did not choose to contact during this visit.
IP geolocation lookup
Turning an address into a city means sending it to a third-party database. Every value on this page is computed locally, and that rule was worth keeping.
Built with
FingerprintJS, ua-parser-js and detectIncognito alongside direct platform probes. Every value on the data page is computed and displayed locally; nothing is transmitted, and no part of this site contacts another company.