Skip to content

How each of these works

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.

Techniques
36
Need no permission
28
Ask first
8
Left unbuilt
5

Passive — sent before any code runs

Nothing on this list requires JavaScript, consent, or any action by the visitor. The browser volunteers it as part of asking for the page.

Request headers

See the data →

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.

Client hints

See the data →

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.

Header ordering

See the data →

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.

Connection and socket facts

See the data →

Protocol version, source address and port, whether the connection was reused.

Read straight from the TCP socket carrying the request.

Where defenses stand · Inherent to networking

Inherent to networking. A VPN or proxy changes the address; it does not remove it.

CSS-only fingerprinting

See the data →

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.

Canvas rendering

See the data →

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.

WebGL and WebGPU

See the data →

The exact GPU model and driver build — effectively the model of computer and its rough price.

WEBGL_debug_renderer_info returns the unmasked vendor and renderer strings. A rendered scene is also hashed, capturing driver-level differences.

Where defenses stand · Restricted in Firefox only

Firefox restricts the unmasked strings. Chrome still returns them to any page with no prompt.

Audio processing

See the data →

A hash reflecting the floating-point behavior of your audio stack.

An oscillator is rendered through a compressor in an offline audio context — never audible — and the resulting samples are summed.

Where defenses stand · Randomized in Firefox

Randomized in Firefox's resist-fingerprinting mode and in Tor Browser. Otherwise unmitigated.

Font enumeration by measurement

See the data →

Which typefaces are installed, and therefore which software you own.

Text is measured in each candidate font against the three generic families. A different width means the font resolved, so it exists.

Where defenses stand · Limited in Firefox and Safari

Safari and Firefox limit the visible set to system fonts. No permission is involved anywhere.

Composite scoring (FingerprintJS)

See the data →

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.

Engine and maths tells

See the data →

The true JavaScript engine, independent of any claimed identity.

Error wording, stack formats and floating-point edge cases differ between V8, SpiderMonkey and JavaScriptCore.

Where defenses stand · Not mitigable

Not mitigable without breaking the language. Used mainly to catch browsers lying about what they are.

Worker cross-checking

See the data →

Whether values on the main page have been altered by an extension or anti-detect tool.

The same properties are read again inside a Web Worker and compared. Spoofing tools frequently patch one context and forget the other.

Where defenses stand · Detection, not collection

A detection technique rather than a collection one — and a demonstration that hiding can make you more conspicuous.

Behavioral biometrics

See the data →

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.

Performance and thermal profiling

See the data →

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.

Respawning across storage

See the data →

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.

ETag cache identifiers

See the data →

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.

Service workers

See the data →

A store that survives ordinary cookie clearing and runs after the tab is closed.

A registered worker keeps its own cache and intercepts network requests for the site.

Where defenses stand · Cleared with site data

Cleared with site data; otherwise long-lived by design.

Cross-tab channels

See the data →

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.

Third-party embedding

See the data →

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.

Analytics and advertising payloads

See the data →

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.

Referrer passing

See the data →

Which page you were on immediately before this one.

Sent automatically to each site, and to embedded third parties within it.

Where defenses stand · Trimmed by default

Default referrer policies now trim the value to an origin in most browsers, and this site sets a strict policy of its own.

Environment — the machine and its settings

Individually mundane, collectively identifying. Each of these splits the population into groups, and it is the combination that isolates a person.

Timezone and locale

See the data →

Your approximate region without any location permission, plus your language priorities.

Intl reports the resolved timezone, calendar, numbering system and locale directly.

Where defenses stand · No permission gate

No permission gate exists. Tor Browser reports UTC to everyone.

Screen, theme and accessibility preferences

See the data →

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.

Hardware reporting

See the data →

Processor core count, memory size, touch capability, battery level.

Plain properties on navigator.

Where defenses stand · Rounded; battery removed

Memory is rounded and capped; battery was removed from Firefox and Safari after it was found being used to correlate visitors across sites.

Storage quota

See the data →

An estimate of your free disk space.

navigator.storage.estimate() derives its quota from available disk.

Where defenses stand · Deliberately coarsened

Deliberately coarsened, but still a personal and slowly-drifting number.

Codec and DRM support

See the data →

Which media formats decode in hardware, which is close to a chipset signature, and which content-protection systems the device carries.

canPlayType, MediaSource.isTypeSupported, mediaCapabilities.decodingInfo and Encrypted Media Extensions queries.

Where defenses stand · Required for playback

Required for media playback to work at all; no mitigation proposed.

Device counting

See the data →

How many cameras, microphones and speakers are attached.

enumerateDevices() returns entries with blank labels before permission is granted — but the count is visible immediately.

Where defenses stand · Count is ungated

Labels and stable IDs are correctly gated behind permission. The count is not.

Permission state reading

See the data →

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.

Precise location

See the data →

Position to within a few meters: a building, not a city.

The operating system combines satellite, nearby wi-fi networks and cell towers.

Where defenses stand · Properly gated

Properly gated. Once granted, a site may keep asking on every return visit.

Clipboard reading

See the data →

Whatever you last copied — frequently a password, address or private message.

navigator.clipboard.readText() after approval.

Where defenses stand · Gated, but silent after

Gated, but nothing indicates afterwards that a read occurred.

Full local font list

See the data →

Every installed typeface, straight from the operating system — usually unique to a person.

queryLocalFonts() after approval.

Where defenses stand · Chromium only

Gated in Chromium; not implemented in Firefox or Safari, which regard it as too revealing.

Multi-screen details

See the data →

Every attached display: resolution, arrangement on the desk, manufacturer labels.

getScreenDetails() after the window-management permission.

Where defenses stand · Properly gated

Gated, and a fair description of a person's workspace.

Idle and lock state

See the data →

Whether you are at the keyboard and whether the screen is locked — continuously, in the background.

IdleDetector after approval.

Where defenses stand · Chromium only, opposed

Gated in Chromium; opposed by Mozilla and Apple as surveillance-shaped.

Camera and microphone identity

See the data →

Hardware model names and stable identifiers for every recording device.

Granting access once reveals labels and persistent device IDs, along with full track capabilities.

Where defenses stand · Gated; IDs persist

Gated. The identifiers persist across visits for the same origin.

Motion sensors

See the data →

Accelerometer and gyroscope readings whose calibration noise is unique to the individual handset.

Device orientation and motion events, requiring explicit permission on iOS.

Where defenses stand · Gated on mobile

Gated on mobile. The physical-device fingerprint it carries survives every browser reset.

Installed application detection (scheme flooding)

See the data →

Which desktop applications you have installed.

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.