← SNITCHTEST PRIVACY GLOSSARY
> canonical definitions

browser privacy glossary: the nine terms that matter

Nine terms that explain how websites identify you across sessions, across devices, and across VPNs. Definitions are pulled from the measurements SNITCHTEST actually runs, not marketing copy. Each term is linked to the pillar article and test that demonstrates it live.

last updated 2026-04-22 · part of the snitchtest reference

Browser fingerprint

A combined identifier built from dozens of technical details a browser reports, unique to most individual browsers without cookies.

Every browser reports screen size, timezone, installed fonts, GPU renderer string, audio stack configuration, hardware concurrency, device memory tier, language preferences, and more — in total, 30+ independent data points. Combined, these produce an identifier that is unique to approximately 1 in 280,000 browsers. A fingerprint cannot be deleted because it reflects the hardware + software combination, not stored state.

Fingerprinting works across sessions, across cookie clearing, and across incognito mode. The only effective defenses are anti-fingerprinting modes that either standardize values across users of the same browser build (Firefox resistFingerprinting, Tor Browser) or randomize values per site per session (Brave Strict Shields).

Canvas fingerprint

A unique hash produced by rendering an HTML canvas image and reading its pixel data; different GPU + driver + OS + browser combinations produce subtly different pixel output.

A tracker asks the browser to draw a small image with specific text, gradients, and anti-aliasing. The browser renders via its graphics stack and returns a bitmap. The exact pixel values depend on every component in that stack — GPU model, GPU driver version, OS sub-pixel rendering rules, browser font engine, color profile. The resulting pixel bitmap is hashed; the hash is the canvas fingerprint. It is stable across page reloads and typically stable for weeks or months on a given device.

Canvas fingerprinting is the single most identifying signal in most browsers. Defense options: Firefox's privacy.resistFingerprinting randomizes the canvas output; Brave Strict Shields adds per-site per-session noise; Tor Browser returns a standardized value that all Tor users share.

Audio fingerprint

A unique hash produced by synthesizing audio via the Web Audio API and reading the resulting waveform.

Similar to canvas fingerprinting but using the audio stack. A tracker uses the Web Audio API's OfflineAudioContext to generate a short synthetic waveform (e.g., a specific oscillator + compressor chain). The precise floating-point values that result depend on the CPU's IEEE-754 implementation, the audio driver, and the browser's audio engine. The values are hashed; the hash is the audio fingerprint.

Audio fingerprinting typically produces less unique identifiers than canvas fingerprinting, but the hash is resistant to canvas defenses — an anti-canvas browser setting does not protect audio unless audio is also randomized. Brave randomizes both; Firefox's resistFingerprinting spoofs both to standardized values.

WebRTC leak

Exposure of a user's local LAN IP and often real public IP through the WebRTC API, bypassing active VPN tunnels.

WebRTC is the browser API for real-time peer-to-peer communication (video calls, file transfer). To find direct paths between peers, it asks the operating system for every network interface and its associated IP address. This query happens at the OS layer, not the browser's HTTP stack, so it routes around any VPN software that operates above the network layer. A page can open a WebRTC peer connection silently and read the gathered IP candidates, revealing both the local LAN IP and — on many setups — the user's real public IP even while a VPN is connected.

Fixes: on Chromium, install the WebRTC Network Limiter extension; on Firefox, set media.peerconnection.ice.default_address_only = true in about:config. Most consumer VPN clients do not address WebRTC leaks on their own.

TLS fingerprint (JA3 / JA4)

A server-side identifier derived from the TLS ClientHello packet's cipher suite list and extension order.

When a browser initiates an HTTPS connection, it sends a TLS ClientHello packet listing the cipher suites it supports, the TLS extensions it uses, the order in which extensions appear, and other handshake parameters. Every browser version has a recognizable signature. JA3 is the original hashing format (2017); JA4 is the 2023 replacement with better separation between mobile and desktop variants. TLS fingerprints identify the software, not the device, but combined with IP + browser fingerprint they strongly identify a session.

TLS fingerprinting is fundamentally server-side: the server records the ClientHello before any JavaScript runs. Browser extensions cannot block it. The only mitigations are using a browser whose TLS signature is widely shared (e.g., a default Chrome install among billions of other default Chrome installs) or routing traffic through a proxy that re-initiates TLS with its own signature.

Do Not Track (DNT)

An HTTP header a browser can send indicating the user does not want to be tracked; compliance is voluntary and almost always ignored.

DNT was standardized in 2011 as an opt-out signal. The browser sends DNT: 1 with every request when the user enables it. Servers are supposed to honor the signal and reduce tracking. In practice, the standard was never enforced, major ad networks announced they would ignore it, and some jurisdictions argued its voluntariness made it legally irrelevant. Modern browsers (Safari, Chrome) have removed or deprecated the setting entirely.

Global Privacy Control (GPC) is the 2020 successor, with the same voluntary-compliance model but legally enforceable under California's CCPA for sites that fall under the law. GPC is sent via the Sec-GPC: 1 header.

Client Hints (sec-ch-ua)

HTTP request headers introduced by Chromium browsers that report structured browser, platform, and form-factor information — effectively a replacement for User-Agent.

Traditional User-Agent strings are opaque and full of legacy tokens. Client Hints split that information into a set of structured headers: sec-ch-ua for browser identity, sec-ch-ua-platform for OS, sec-ch-ua-mobile for form factor, and optional hints for version, bitness, and more. Chromium browsers send the low-entropy hints by default; sites request additional hints via the Accept-CH response header.

Firefox and Safari do not send sec-ch-ua. This makes the presence or absence of the header a strong browser-family signal: if a request claims a Chrome User-Agent but omits sec-ch-ua, the User-Agent is spoofed. SNITCHTEST's "UA ↔ headers agreement" test catches this exact pattern.

privacy.resistFingerprinting

A Firefox about:config flag that enables Mozilla's Tor-derived anti-fingerprinting mode, standardizing reported values so Firefox users look identical to one another.

Enabling privacy.resistFingerprinting = true in about:config activates a suite of defenses inherited from the Tor Browser project: timezone is reported as UTC, screen size is forced into discrete buckets, system fonts are suppressed, canvas and WebGL output is randomized per page, audio fingerprints are spoofed, and high-precision APIs are throttled. The goal is not to hide information — it is to make all resistFingerprinting users report the same information, collapsing the user population into a single indistinguishable cluster.

Cost: a few sites render incorrectly because their layout depends on precise screen metrics or system fonts. Most users don't notice. For the stricter variant, see privacy.fingerprintingProtection (Firefox 114+); for the most thorough anti-fingerprinting Firefox fork, see Mullvad Browser and LibreWolf.

WebRTC Network Limiter

A Google-published Chrome extension that blocks WebRTC from enumerating non-VPN network interfaces, preventing WebRTC leaks without breaking video calls.

Published by Google as a first-party extension, WebRTC Network Limiter modifies Chromium's WebRTC ICE candidate gathering policy. Setting it to "Use my proxy server (if present); otherwise use any other routes" forces WebRTC to use only the default network route, which in a VPN-connected setup is the VPN interface. Non-VPN interfaces are never enumerated, so their IPs never leak. Video calls still work because the default route remains usable.

Equivalent protection on Firefox: media.peerconnection.ice.default_address_only = true + media.peerconnection.ice.no_host = true in about:config. Safari closes the WebRTC local-IP leak by default on non-HTTPS origins.

> measure what this glossary describes
run the audit

SNITCHTEST runs 25+ live tests covering every term in this glossary — canvas, audio, WebRTC, TLS, Client Hints. Nothing is logged server-side.

> RUN SNITCHTEST →