This is the companion reference to Why Web Tracking Survives, which covers the structural forces that protect these techniques. For the legal and regulatory landscape, see The 2025-2026 Privacy Enforcement Landscape.
This guide covers every major web tracking technique in active use as of Q2 2026. It organizes them by category, explains the protocol-level mechanism for each, describes the current state of browser defenses, and gives you one concrete action to take this week. The arms race summary table at the top of the technical layer serves as a navigation roadmap. Start there to identify which techniques are most relevant to your environment, then jump to the technique sections for depth.
The guide addresses three practitioner questions:
- How does this technique actually work at the protocol level?
- What defenses exist, and what do they miss?
- What should I check or do right now?
The audience is practitioners who deploy, audit, or defend against tracking infrastructure: security engineers, privacy engineers, and infrastructure engineers. CISOs and engineering leaders will find the arms race table and Monday morning actions sufficient for decision-making without reading the full technical layer.
The guide covers twelve techniques across three categories. Trust-relationship techniques exploit browser primitives that cannot be removed without breaking legitimate web functionality: first-party cookies, URL parameter tracking, pixel tracking, ETags, and HSTS. Modern stack techniques operate on surfaces outside browser visibility: browser fingerprinting, CNAME cloaking, server-side tracking, favicon cache tracking, cross-device tracking, and session replay. The emerging category covers WebGPU fingerprinting, which has shipped in all major browsers as of 2026 but has not yet achieved wide advertising deployment.
Three techniques deserve the most attention because they represent novel attack surfaces or enforcement gaps. CNAME cloaking creates a security risk beyond tracking: authentication cookies transmit to third-party infrastructure. Server-side tracking has a structural consent propagation gap that most current architectures do not address. WebGPU fingerprinting achieves entropy levels and stability that render existing browser defenses ineffective.
For legal exposure analysis on any technique, see The 2025-2026 Privacy Enforcement Landscape. This guide does not repeat that analysis per-technique - one sentence at the end of each section points to relevant regulatory categories.
This guide does not cover the structural forces that make tracking persistent across browser generations - that argument lives in Why Web Tracking Survives. It does not cover the Privacy Sandbox, AI behavioral profiling, or the post-cookie identity infrastructure landscape. Those topics appear in the companion pieces.
The detection and audit toolkit section at the end covers what standard tools catch, what they miss, and a baseline open-source kit for auditing your own properties.
Arms Race Summary
Table 1 provides the current defender/tracker balance for each technique as of Q2 2026. Use it to triage which techniques deserve the most attention in your environment.
| Technique | Arms Race Verdict | Key Notes |
|---|---|---|
| First-party cookies | Partial mitigation | ITP caps script-set storage; server-set cookies largely uncapped |
| URL parameter tracking | Slight defender advantage (Apple only) | UTMs universal; click IDs stripped only in Apple Private Browsing |
| Pixel tracking (web) | Stalemate | Server-side pixels bypass all browser-layer tools |
| Pixel tracking (email) | Defender advantage (Apple Mail) | MPP proxy renders open rates unreliable for 50%+ of mobile opens |
| ETag supercookies (cross-site) | Defender advantage | Cache partitioning effective in Firefox and Chrome |
| ETag supercookies (within-site) | Stalemate | Within-site persistence not addressed by partitioning |
| HSTS tracking | Defender advantage | Mitigations make practical deployment impractical |
| Browser fingerprinting | Tracker advantage | Standard incognito and VPN ineffective; hardware signals are stable |
| CNAME cloaking | Tracker advantage in Chrome | Only Firefox + uBlock Origin detects at the extension layer |
| Server-side tracking | Tracker advantage | Browser has zero visibility into server-to-server transmissions |
| Favicon supercookie | Stalemate (mostly PoC) | Not confirmed in production; cross-site vector mitigated in Firefox |
| WebGPU fingerprinting | Tracker advantage (emerging) | 38-44 bits of entropy, hardware-stable, no meaningful browser defense |
Trust-Relationship Techniques
These techniques use browser primitives - cookies, URL parameters, HTTP caching, and security headers - that browsers cannot remove without breaking authentication, navigation, and content delivery. Browser vendors respond with partial mitigations, not full removal.
First-Party Cookies: Server-Set vs. Script-Set
Mechanism. First-party cookies set via Set-Cookie HTTP response headers or via document.cookie in JavaScript operate within the same-site trust boundary. Browsers cannot block them without disabling authentication, shopping carts, and personalization on legitimate sites. The architectural constraint forces partial mitigations only.[^1]
WebKit's Intelligent Tracking Prevention (ITP) caps all script-writeable storage - document.cookie, IndexedDB, LocalStorage, SessionStorage, Service Worker registrations - at 7 days from last browser use. The clock resets on each visit, so active users on high-traffic sites never hit it. When a user arrives via a link from a classified tracker domain (for example, a Facebook ad with fbclid= in the URL), ITP tightens the cap to 24 hours. The critical nuance: server-set cookies via Set-Cookie headers are not subject to the 7-day rule. Moving cookie-setting logic server-side bypasses ITP's cap - but only partially. Safari also checks whether the server IP shares the first two octets of the main domain's IP. If it does not, the cookie is treated as third-party regardless of any CNAME arrangement.[^1]
The SameSite attribute controls cross-site cookie transmission. SameSite=None; Secure creates a first-party cookie that behaves like a third-party cookie by design - it transmits with cross-origin subresource requests. SameSite=Lax has been Chrome's default since version 80 (February 2020). Misconfigurations - particularly SameSite=None without a genuine cross-site need - broaden exposure without functional benefit.[^1]
Browser countermeasures. ITP caps script-set storage. No countermeasure exists against server-set first-party cookies on the first-party domain. That is by design.
Arms race verdict. Very high effectiveness for site-scoped attribution. Limited for cross-site tracking. Defenders have partial mitigation at best on the script-set side; server-set is unconstrained.
Open source. OpenWPM (github.com/openwpm/OpenWPM) instruments cookie storage, network requests, and JavaScript API calls at scale across large site samples.[^2]
Monday morning action. Audit your Set-Cookie response headers. Identify any analytics or advertising cookies set server-side and confirm they have a consent gate that fires before the server issues those cookies, not after.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
URL Parameter Tracking and UID Smuggling
Mechanism. Query parameters appended to URLs transmit in the HTTP request path and log server-side regardless of browser state. They require no storage API and no JavaScript execution. UTM parameters (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are the universal attribution standard. Platform-specific click IDs (gclid, dclid for Google; fbclid for Meta; msclkid for Microsoft) carry session-level attribution data.
UID smuggling is the more consequential vector. A tracker issues a redirect URL with a unique per-user ID in a query parameter. The destination site's JavaScript reads the parameter and writes it to a first-party cookie, creating a persistent cross-site identity bridge. The identifier enters first-party storage via a single navigation event, laundering a third-party identifier through the first-party context.
Browser countermeasures. iOS 17 introduced Link Tracking Protection, which strips known click IDs (gclid, dclid, fbclid) in Private Browsing mode, the Mail app, and the Messages app. iOS 26 extended this to block known trackers from loading on Private Browsing pages. UTM parameters are not stripped - Apple targets platform-specific click IDs, not general campaign parameters. Standard Safari strips nothing.
URL parameters are part of the HTTP request itself. No browser API can block parameter transmission without preventing the navigation entirely, which would break OAuth flows, email campaign links, and affiliate programs. Any blocklist-based filter can be bypassed by renaming the parameter.
Arms race verdict. Slight defender advantage on Apple devices in Private Browsing. UTM attribution and UID smuggling remain near-100% effective everywhere else.
Monday morning action. Check your tag manager for any tags that read URL parameters and write them to cookies. Confirm those writes are consent-gated if the parameters carry personal identifiers.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Pixel Tracking: Email and Web
Mechanism. A tracking pixel is a 1x1 transparent GIF embedded in HTML: <img src="https://tracker.example.com/pixel?uid=XYZ&event=email_open">. When the client renders HTML and loads images, it issues an HTTP GET to the tracker's endpoint. The server logs: timestamp, IP address, User-Agent string, and any URL parameters. Each pixel URL is unique per recipient, enabling individual-level open tracking without any stored state.
Server-side pixels bypass client-side ad blockers. Ad blockers intercept browser network requests and compare URLs against blocklists of known tracker domains. A pixel served from a domain absent from blocklists - or served from the first-party domain via a server-side proxy or CNAME arrangement - is invisible to those blockers.
Browser countermeasures. Apple Mail Privacy Protection (MPP), introduced with iOS 15, proxies all image loads through Apple's servers. It prefetches images asynchronously after delivery rather than when the recipient opens the email. The "open" event fires when Apple's proxy fetches the image - not when the human reads it. The User-Agent and IP logged are Apple's infrastructure, not the recipient's device. For Apple Mail users (approximately 50%+ of mobile email opens), MPP makes open tracking signals unreliable.
For web pixels: no effective browser countermeasure exists without a DNS-layer blocker. Disabling remote image loading in email clients (Thunderbird: Settings → Privacy & Security → Allow remote content in messages) blocks email pixels.
Arms race verdict. Defender advantage in email for Apple Mail users. Stalemate for web pixels and non-Apple email clients.
Monday morning action. Check whether your email service provider routes pixel domains through your own domain (first-party pixel proxying). If so, document this in your privacy notice - you are using a technique that bypasses ad blockers.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
ETags as Supercookies
Mechanism. An ETag is an HTTP caching header that fingerprints a resource version. The browser caches the ETag and returns it in subsequent If-None-Match headers, letting the server return 304 Not Modified if content is unchanged. The tracking exploit: a server generates a unique per-user ETag (a UUID) instead of a content hash. When the browser returns the ETag in If-None-Match, the server receives the user's identifier without any cookie storage. The ETag persists in the browser's HTTP cache and survives cookie deletion, history clearing, and Private Browsing - it lives in a cache store most users do not know exists.
The KISSmetrics incident established the stakes. In 2011, UC Berkeley researchers found that KISSmetrics used ETags to respawn deleted cookies across sites including Hulu and Spotify. When a user deleted their cookies, KISSmetrics scripts retrieved the ETag value and restored the cookie. KISSmetrics settled a class action in 2012 for approximately $500,000 in attorney fees.[^3]
Browser countermeasures. Firefox 85 (January 2021) introduced full cache partitioning, isolating the HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, font cache, DNS cache, and TLS session identifiers by top-level site. An ETag set during a visit to analytics.com cannot be retrieved during a visit to news.com. Chrome implemented similar partitioning.[^4] The cross-site respawning vector is effectively neutralized. Within-site persistence remains: a user returning to the same domain can be reidentified via ETag after cookie deletion, since cache partitions by top-level site but does not clear on revisit. In 2026, ETag persistence paired with Service Worker cache interception has appeared as an emerging mechanism.
Arms race verdict. Defenders have the advantage on cross-site ETag tracking. Stalemate on within-site persistence.
Open source. Evercookie (github.com/samyk/evercookie) demonstrates ETag-based cookie respawning among 13+ storage mechanisms.
Monday morning action. Run a quick check: does your origin server generate ETags for resources that log requests with user-specific URL parameters? If so, confirm those ETags derive from content hashes, not per-user values.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
HSTS as a Binary Tracking Identifier
Mechanism. HTTP Strict Transport Security (HSTS) instructs browsers to connect only via HTTPS for a specified period. Browsers store this policy in an HSTS cache that persists independently from cookies and survives Private Browsing in some configurations. The tracking exploit: an attacker controlling N subdomains can encode an N-bit user identifier by selectively issuing HSTS headers for a subset. Each bit position - subdomain has HSTS state = 1; no state = 0 - encodes one bit of the identifier.[^5]
To illustrate: a tracker assigns user #909090, whose 32-bit binary representation is 00000000000011011101111100100010. It sets HSTS policies for subdomains at bit positions where the value is 1. On subsequent visits, the tracker loads 32 invisible subresources via hidden image tags. Subdomains where HSTS redirects to HTTPS equal 1; subdomains with no redirect equal 0. Reconstructing the 32-bit string recovers the user identifier - no cookies, no JavaScript storage, no server-side state the user can inspect.[^5]
Browser countermeasures. WebKit limits HSTS state to the loaded hostname or TLD+1 and caps redirectable chains. Firefox 85 partitions the HSTS cache by top-level site.[^4] A 2018 USENIX study found HSTS attacks worked on Safari with partial mitigations and that Tor Browser 7.5.6 permitted HSTS state bleeding between private tabs. Apple stated in March 2018 that it had found HSTS supercookie attacks against Safari users in the wild.
Arms race verdict. Defender advantage in fully patched Firefox and Safari. Practical deployment risk is low in 2025-2026. The technique remains a useful example of security mechanisms doubling as tracking vectors.
Monday morning action. This one is mostly resolved. If you run a security audit, include the HSTS cache in your supercookie checklist as a reference vector - not a live threat.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Modern Stack Techniques
These techniques operate on surfaces outside browser visibility or exploit browser primitives at the DNS and hardware layers. Browser vendors have partial defenses at best.
Browser Fingerprinting: The Signal Stack
Mechanism. Browser fingerprinting constructs a composite identifier by querying browser APIs that expose device characteristics. A mature implementation in 2025 collects signals from multiple layers:
- Canvas 2D rendering: The browser draws invisible text or shapes via
CanvasRenderingContext2D. GPU, OS graphics libraries, anti-aliasing implementation, and font rendering differences produce pixel-level variations that hash into a per-device fingerprint. - WebGL: Queries
WEBGL_debug_renderer_infoto extract the GPU vendor string (for example,"NVIDIA GeForce RTX 4090/PCIe/SSE2") and renderer string. Also captures supported extensions, precision values, and max texture sizes - directly identifying GPU model and driver version. - AudioContext oscillator processing: Generates a tone via
OscillatorNode, processes it throughDynamicsCompressorNode, and reads the output buffer. Audio stack, sound card driver, and audio processing variations produce a unique float array that hashes consistently per device. - Font enumeration: Probed via Canvas rendering fallback detection. The installed font set is highly unique on non-standard systems.
- CSS system metrics:
window.screen.width/height,devicePixelRatio, color depth, color gamut. - Math precision edge cases:
Math.tan(-1e300)and similar operations return implementation-specific floating-point results that vary by OS and CPU. - Navigator properties:
userAgent,platform,language,hardwareConcurrency,deviceMemory,maxTouchPoints.
These signals are individually probabilistic but highly correlated when combined. Their composite hash creates an identifier stable across cookie clears, Private Browsing sessions, and browser restarts - none of the signals involve stored state.
Detecting anti-detect browsers via consistency checks. Anti-detect browsers (Multilogin, GoLogin, Kameleo, AdsPower) attempt to spoof fingerprint signals by overriding JavaScript API return values. Detection cross-references multiple layers simultaneously: TLS cipher suites and client hello patterns; Client Hints and User-Agent; Canvas, WebGL, and AudioContext; mouse micro-movements, typing cadence, and scroll velocity. If the User-Agent claims Chrome 120 on macOS M3 but the Canvas fingerprint matches Intel integrated graphics and the TLS handshake uses atypical cipher ordering, the combination is detectable even if no individual signal is wrong. Some anti-detect systems intercept Canvas at the C++ level in forked Chromium builds to avoid JavaScript-observable changes, but consistency checks across layers still surface mismatches.
Browser countermeasures. Standard incognito mode, VPN, and cookie clearing provide no protection. Brave's API randomization and LibreWolf/Firefox Strict Mode reduce entropy by 40-60% per 2025 Cybernews benchmarks but do not eliminate the fingerprint. Tor Browser's uniform fingerprint approach is the only near-complete countermeasure, at significant usability cost.
The ICO responded directly to Google's February 2025 fingerprinting policy reversal: "We think this change is irresponsible." Google reversed its 2019 policy prohibiting advertisers from using fingerprinting, permitting it from February 16, 2025. The ICO stated that fingerprinting violates GDPR and PECR because users cannot consent to it in the way they can with cookies - there is no "delete fingerprint" button. The ICO published draft guidance in December 2024 clarifying that fingerprinting is subject to PECR storage-and-access rules.[^6]
Arms race verdict. Trackers have the advantage. Consistency-based detection of anti-detect browsers has matured to the point where naive API spoofing is often detectable.
Open source tools:
- FingerprintJS v5 (MIT license, 2025): client-side fingerprinting library - github.com/fingerprintjs/fingerprintjs[^7]
- CreepJS: fingerprint auditing and "lie detection," surfaces inconsistencies introduced by anti-fingerprinting tools - github.com/abrahamjuliot/creepjs
Monday morning action. Load CreepJS against your own browser profile. Note the entropy score and which signals contribute the most. If you run anti-fingerprinting infrastructure for your users, verify that consistency checks do not reveal the spoofing.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
CNAME Cloaking: How Third Parties Hide in DNS
Mechanism. CNAME cloaking exploits the DNS canonical name record to make third-party tracker requests appear first-party to the browser. The site operator creates a subdomain with a CNAME record pointing to the tracker's infrastructure:
metrics.example.com CNAME tracker.analytics-vendor.io
When the browser loads a script from metrics.example.com, it sees an origin sharing the base domain of the first-party site. The browser's same-site policy treats this as a first-party context.
Why Chrome extensions cannot detect it. Extensions running in the content script context receive network events at the HTTP layer - they see the request URL as written in the page source. The DNS resolution that reveals metrics.example.com actually resolves to tracker.analytics-vendor.io is transparent to the extension. Chromium does not expose a browser.dns API to extensions, making DNS-level CNAME lookup impossible from within the extension. This is a structural limitation, not a temporary gap.
uBlock Origin's Firefox-only countermeasure. Starting with version 1.25.0, uBlock Origin on Firefox uses Mozilla's browser.dns.resolve() API to perform DNS lookups before allowing network requests. When CNAME resolution reveals a known tracker domain, the request blocks. This capability is not available on Chrome or Chromium-based browsers due to the missing API.
The cookie exfiltration security risk. CNAME cloaking creates a security vulnerability that goes beyond tracking. When a browser sends a request to metrics.example.com, it includes all cookies with domain scope covering *.example.com - including authentication cookies, session tokens, and any other first-party cookie with a broad domain attribute. A 2021 NDSS study confirmed that CNAME-cloaked endpoints receive authentication cookies intended for the first-party site, enabling potential cookie exfiltration to third-party advertising infrastructure.[^8] The most commonly leaked cookies in that analysis were Google Analytics cookies (_ga, _gid). This is not a theoretical risk: your session cookies are in scope.
ITP's CNAME countermeasure. WebKit ITP detects CNAME cloaking by identifying when a first-party subresource resolves through a CNAME chain that differs from the first-party domain. It caps cookies set in the HTTP response to 7 days and detects third-party IP cloaking, where the tracking subdomain's IP does not share the first two octets of the main domain's IP.[^1]
Filter list limits. AdGuard's CNAME tracker list (published November 2022) catalogued 6,000+ cloaking trackers, the largest such list at the time. Filter lists require ongoing maintenance, lag tracker adoption, and are reactive. A new CNAME arrangement evades all filter lists until identified and added.
Arms race verdict. Tracker advantage in Chromium-based browsers (the majority of market share). Limited in Firefox with uBlock Origin and CNAME uncloaking enabled.
Open source tools:
- uBlock Origin with CNAME uncloaking on Firefox: github.com/gorhill/uBlock
- AdGuard CNAME blocklist: github.com/AdguardTeam/cname-trackers
- Control D and NextDNS both offer DNS-layer CNAME uncloaking
Monday morning action. Run a DNS lookup on any analytics or marketing subdomains your site uses (dig metrics.yoursite.com CNAME). If any CNAME to a third-party vendor, audit which cookies your browser sends to that subdomain on a typical session. Check whether authentication cookies are in scope via Domain=.yoursite.com attributes.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Server-Side Tracking: Moving Tags Off the Browser
Mechanism. Server-side tracking moves tag logic from client-side JavaScript to a server container controlled by the site operator. The architecture: browser sends events to a first-party server container (ss.example.com), which processes them and forwards to analytics and advertising platforms via server-to-server API calls - GA4 via Measurement Protocol, Meta via Conversions API (CAPI), and others.
GA4 Measurement Protocol requires a client-side GA4 tag to generate client_id and session_id values, which are then read from client-side cookies and forwarded server-side. Without the client-side tag, no stable user identifier exists to send. Meta CAPI operates similarly - it accepts hashed email (em) or phone (ph) as match keys, enabling the platform to join server-side conversion events to Meta's user graph via hashed PII. Both mechanisms depend on a client-side seed, but event transmission happens server-to-server, bypassing ad blockers.
Ad blockers operate by intercepting browser network requests. When event data transmits from the site's server to the analytics platform, it originates from an IP associated with the site operator, not the user's browser. No browser extension, no ITP, and no DNS-based blocker running on the user's device has any visibility into this transmission.
Detecting server-side tracking implementations. A server-side tracking implementation leaves specific signatures: the client-side tag bundle is far lighter than expected, containing only a thin collector script rather than full analytics libraries; network requests go to a first-party subdomain that returns tracking responses; the server container URL often appears in Content Security Policy headers; the GTM server container ID in the page source reveals sGTM configuration.
The consent propagation gap. Server-side tracking does not change the legal analysis of whether consent is required. GDPR applies to the processing of personal data regardless of where processing occurs. If a user declines analytics consent, server-side forwarding of their data to analytics platforms is still unlawful. The enforcement gap is architectural: user-side consent signals do not automatically propagate to server-side containers. This must be explicitly engineered - it is not the default configuration of any major server-side tag management system.
If your architecture includes a server-side container and your consent management platform sends consent signals only to the client-side tag layer, you have a consent propagation gap. Data transmits to platforms after a user declines.
Arms race verdict. Tracker advantage. The browser has zero visibility into server-to-server transmissions.
Open source. Snowplow Analytics: open-source event data pipeline for server-side tracking routing to your own data warehouse - github.com/snowplow/snowplow.
Monday morning action. If you run a server-side tag container (sGTM or equivalent), trace the consent signal path end-to-end. Does a user's "decline analytics" choice actually suppress server-side forwarding to GA4 and Meta? Instrument a test with consent declined and inspect your server container's outbound requests directly.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Favicon Cache Tracking
Mechanism. Browsers maintain a favicon cache (F-Cache) - a separate persistent local database distinct from the HTTP cache, cookie store, and LocalStorage - that stores site favicons for display in browser tabs. A technique by researcher Jonas Strehle exploits the F-Cache's binary state (loaded vs. not loaded) to encode a user identifier.[^9]
A tracking server assigns a user a unique N-bit identifier. For each bit position, the server creates a URL path that either serves a favicon (bit = 1) or returns 404 (bit = 0). On the first visit, the server loads all N paths. On subsequent visits - from a new incognito window, after a cache clear, after a VPN change, or after an OS restart - the browser's F-Cache reflects the previous visit's pattern. The server reconstructs the identifier by observing which URLs trigger F-Cache hits (no HTTP request) versus misses (new HTTP request).[^9]
Browser countermeasures. Firefox 85 cache partitioning partitions the favicon cache by top-level site, eliminating cross-site favicon tracking.[^4] Within-site return visit identification remains unmitigated. The technique works in incognito mode. As of 2025, no confirmed reports exist of this technique deployed in production tracking infrastructure - it remains a research proof-of-concept.
Arms race verdict. Stalemate (mostly PoC). Firefox partitioning addresses the cross-site vector. Within-site persistence and incognito bypass are unaddressed.
Open source. Jonas Strehle's proof-of-concept: github.com/jonasstrehle/supercookie[^9]
Monday morning action. Include the favicon cache in your supercookie audit checklist alongside ETags and HSTS. The technique is not widespread in production, but understanding it informs your overall supercookie risk model.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Cross-Device Tracking: Deterministic and Probabilistic
Mechanism. Deterministic cross-device tracking uses authenticated identity signals: a hashed email, a logged-in account ID, or a subscriber identifier the user provided. When a user logs into shop.example.com on both mobile and desktop, the backend resolves both sessions to the same identity record. This approach achieves near-100% accuracy for logged-in users and forms the basis of walled-garden measurement at Google and Meta. Hashed email matching - sending a SHA-256 or MD5 hash to an identity graph - enables cross-platform matching without transmitting cleartext email.
Probabilistic cross-device tracking uses ML-based signal correlation to infer that two devices belong to the same person without any shared authenticated identifier. Signals include: shared IP address (household-level), browser fingerprint similarity, behavioral patterns (browsing times, content preferences, typing cadence), and geolocation proximity. Probabilistic matching achieves 60-95% accuracy depending on data volume and model sophistication.
Browser countermeasures. No browser defense prevents deterministic matching for logged-in users - that requires the user to not log in, which breaks site functionality. No browser defense prevents probabilistic matching from IP and behavioral signals that are passively observable.
Arms race verdict. Trackers have the structural advantage. The signals needed for probabilistic matching are largely passively observable. Defenders can block deterministic matching only by not authenticating.
Monday morning action. Map your company's cross-device identity resolution scope: deterministic only (authenticated users), probabilistic (ML-based), or both. Confirm your consent suppression and opt-out architecture covers the full scope of identity resolution you perform for advertising purposes.
For legal exposure analysis (including the February 2026 California CPRA settlement on cross-device opt-out scope), see The 2025-2026 Privacy Enforcement Landscape.
Session Replay and Behavioral Tracking
Mechanism. Session replay tools (FullStory, Hotjar, LogRocket) inject a JavaScript SDK that captures mousemove, scroll, click, keydown, and keyup events with timestamps and DOM element context. The event stream transmits to the vendor's servers and reassembles into a visual replay of the user's session. Some implementations capture all input, including partially-typed form fields, which may include passwords, health data, and financial information, unless explicitly masked.
Browser countermeasures. No browser-native defense exists against session replay SDKs loaded from first-party domains. Ad blockers block known session replay vendor domains but not first-party-hosted versions.
A defensible configuration requires all five of the following:
- Mask all form inputs by default with explicit opt-in to unmask specific fields
- Process replay data locally within the operator's infrastructure rather than transmitting to third-party vendors
- Apply differential privacy noise to behavioral signals before analysis
- Enforce consent gating so replay activates only for users who explicitly consented to behavioral analytics
- Implement retention limits of 30-90 days with automatic deletion
None of the major commercial session replay vendors meet all five criteria in their default configuration.
Arms race verdict. No effective user-side defense. The risk is controlled by operator configuration choices, not browser defenses.
Monday morning action. Review your session replay vendor's default configuration against the five criteria listed in this section. Specifically: are form inputs masked by default? Does consent decline actually suppress the SDK from loading, or does it load but suppress transmission? The latter is not a compliant configuration under most interpretations of GDPR.
For legal exposure analysis (including Javier v. Assurance IQ, Torres v. Prudential, Mikulsky v. Bloomingdale's, and CIPA litigation trends), see The 2025-2026 Privacy Enforcement Landscape.
Emerging Techniques
WebGPU Fingerprinting: The Next High-Entropy Signal
Mechanism. WebGL exposes GPU capabilities through the ANGLE translation layer (OpenGL to Direct3D/Metal), which normalizes hardware differences. WebGPU exposes the underlying GPU APIs directly - D3D12 on Windows, Metal on macOS/iOS, Vulkan on Linux/Android - providing access to hardware-level characteristics that WebGL abstracts away.[^10]
The static fingerprint surface includes: adapter.info.vendor, adapter.info.device, adapter.info.architecture, adapter.info.description, the full feature set (adapter.features), and the complete set of limits (adapter.limits) - including max storage buffer sizes, max compute workgroup counts, texture format support, and WGSL shader capabilities.
The high-entropy dynamic vector uses GPU cache side-channel attacks via WebGPU compute shaders. A script creates a high-resolution timer using GPU hardware resources to measure cache occupancy and eviction patterns on the compute stack. On Intel integrated GPUs (the most common configuration in enterprise laptops), this achieves approximately 90% accuracy for website fingerprinting - identifying which sites a user visited in other tabs via microarchitectural leaks, bypassing JavaScript timer precision restrictions.[^10]
Preliminary analysis reports WebGPU fingerprinting at 38-44+ bits of entropy compared to WebGL's 20-30 bits, with stability estimated at 99.96%+ over 180+ days. Hardware characteristics do not change like software configurations do. A full WebGPU fingerprint collection takes approximately 150ms with negligible CPU/GPU overhead. Note: the specific entropy and stability figures come from a non-peer-reviewed vendor source and have no independent academic validation; the peer-reviewed work cited above covers the website-fingerprinting result only.
Browser countermeasures. WebGPU ships enabled by default in Chrome/Edge, Firefox, and Safari as of 2026. FingerprintJS Pro v4+, SEON, and BioCatch have integrated WebGPU signals into their anti-fraud stacks. WebGPU fingerprinting is not yet widespread in advertising tracking, but the entropy and stability characteristics make it the obvious next high-value signal.
Spoofing JavaScript API return values for Canvas or WebGL is detectable via consistency checks. WebGPU's dynamic compute vectors - the cache timing side-channels - cannot be spoofed via JavaScript API overrides. They operate below the JavaScript layer on actual GPU hardware. Meaningful evasion requires hardware-level isolation: a VM with GPU passthrough using a different GPU. No browser offers this as a user-accessible configuration.
Arms race verdict. Tracker advantage, emerging. No meaningful browser defense exists yet. The technique has shipped in all browsers but has not reached advertising tracking at scale. That gap will close.
Monday morning action. Check whether your fraud detection or analytics vendors have begun using WebGPU signals. If you operate a privacy-focused product, begin tracking whether Brave, Firefox, and Safari publish WebGPU entropy reduction timelines - none have published firm commitments as of Q2 2026.
For legal exposure analysis, see The 2025-2026 Privacy Enforcement Landscape.
Detection and Audit Toolkit
What Standard Tools Cover
OpenWPM (github.com/openwpm/OpenWPM) is the standard tool for web privacy measurement at scale, instrumenting JavaScript API calls, network requests, cookie operations, and storage access across large site samples. A 2022 CoNEXT paper found that OpenWPM is detectable by approximately 14% of front pages in a 100,000-site scan - scripts designed to detect the OpenWPM client exist in the wild. Privacy engineers using OpenWPM for site audits should know that sophisticated trackers may suppress their activity when they detect the measurement framework.[^2]
Manual inspection with browser DevTools (Network tab, filtering by third-party origins) identifies client-side tracking requests. For server-side tracking: inspect the GTM container URL configuration, check for thin beacon scripts, and review Content Security Policy headers for server container endpoint hints.
For DNS-layer CNAME detection: NextDNS and Control D offer CNAME detection in their DNS resolvers. Firefox with uBlock Origin and CNAME uncloaking enabled is the only browser configuration that performs this check natively at the extension layer.
What Automated Compliance Tooling Misses
Current automated tooling audits well: cookie declarations, consent banner presence, and known tracker domains on the client side. It audits poorly in four areas:
- Server-side tracking payloads: requires server access, not just browser observation
- Behavioral fingerprinting: requires understanding API call patterns versus functional use
- Consent signal propagation to server containers: requires end-to-end tracing through the server container
- CNAME-cloaked endpoints: requires DNS resolution, not HTTP-layer observation
A site can pass an automated compliance scan while still transmitting behavioral data server-side to advertising platforms after a user declines consent. The scan sees clean browser-layer behavior; the server container keeps firing.
A notable gap: consent banner bypass testing - verifying that tags blocked pre-consent are actually blocked. Automating consent banner interaction to test which trackers fire before versus after consent is an emerging area with limited mature open-source tooling.
Open Source Audit Toolkit
The following tools form a baseline audit kit for your own properties:
- OpenWPM - scaled measurement: github.com/openwpm/OpenWPM[^2]
- CreepJS - fingerprint signal auditing and lie detection: github.com/abrahamjuliot/creepjs
- uBlock Origin on Firefox - CNAME detection and network request inspection
- FingerprintJS v5 (MIT) - understanding the client-side fingerprinting signal set: github.com/fingerprintjs/fingerprintjs[^7]
- Evercookie - understanding multi-vector supercookie respawning: github.com/samyk/evercookie
- AdGuard CNAME blocklist - known CNAME-cloaking tracker inventory: github.com/AdguardTeam/cname-trackers
References
[^1]: Tracking Prevention in WebKit
[^2]: openwpm/OpenWPM: A web privacy measurement framework - GitHub
[^3]: Web-Analytics Firm KISSmetrics Reverses Course on Sneaky Tracking - Wired
[^4]: Firefox 85 Cracks Down on Supercookies - Mozilla Security Blog
[^5]: Protecting Against HSTS Abuse - WebKit
[^6]: Our response to Google's policy change on fingerprinting - ICO
[^7]: fingerprintjs/fingerprintjs - GitHub
[^8]: An Analysis of First-Party Cookie Exfiltration due to CNAME Redirections - NDSS Symposium
[^9]: jonasstrehle/supercookie: Browser fingerprinting via favicon! - GitHub
[^10]: Ferguson, E., Wilson, A., and Naghibijouybari, H. (2024). WebGPU-SPY: Finding Fingerprints in the Sandbox through GPU Cache Attacks. arXiv:2401.04349.