I spent a week auditing the tracking surface of a representative web stack - the kind of thing any mid-size company runs. Marketing site, authenticated app, analytics, session replay, a handful of ad platform integrations. The compliance scan passed. Consent banner present. No third-party cookies flagged. Clean bill of health.
Then I looked at what the stack actually transmitted. The server-side GTM container forwarded every page view to three advertising platforms regardless of consent state. A CNAME record routed tracker traffic through a first-party subdomain, and the cloaked endpoint received authentication cookies scoped to the parent domain. The session replay SDK activated before the consent modal rendered.
The compliance scan measured the browser-visible surface. The actual tracking surface extended well beyond it. Every tool designed to catch tracking problems operated at a layer where the tracking no longer lives.
The narrative that keeps not dying
"Cookies are dying" has been the dominant privacy story for five years. It was wrong in 2020 and it is wrong now. Google launched the Privacy Sandbox in 2019, spent six years building browser-based alternatives to third-party cookies, and retired virtually the entire initiative on October 17, 2025.[^1] Third-party cookies remain in Chrome with no deprecation timeline. Chrome holds roughly 65-69% of global browser market share.[^2]
The industry did not wait for the Sandbox. It built something else entirely - server-side containers, hashed identity graphs, modeled conversions - that achieves equivalent targeting outcomes outside the browser's threat model. The Privacy Sandbox failure is widely framed as a privacy win. The more accurate framing: it removed the one framework under active regulatory scrutiny, leaving the replacement system with less accountability.
What I found in the audit is not unique to one stack. It is a structural property of how tracking works now. Three forces explain why it persists, and understanding them matters if you are responsible for the security or privacy posture of web properties.
For protocol-level detail on each tracking technique mentioned here, see Web Tracking Techniques: A 2026 Field Guide. For the regulatory landscape, see The 2025-2026 Privacy Enforcement Landscape.
The Arms Race at a Glance
Table 1 maps the current state. The three forces in the sections below explain why each row lands where it does. The full per-technique breakdown - mechanism, countermeasures, Monday morning actions - lives in the Field Guide.
| Technique | Status | Dominant Force |
|---|---|---|
| First-party cookies | Partial mitigation | Trust relationship |
| URL parameter tracking | Slight defender advantage (Apple only) | Trust relationship |
| Pixel tracking (web) | Stalemate | Server-side migration |
| Pixel tracking (email) | Defender advantage (Apple Mail) | Trust relationship |
| ETag supercookies (cross-site) | Defender advantage | Trust relationship |
| HSTS tracking | Defender advantage | Trust relationship |
| Browser fingerprinting | Tracker advantage | Trust relationship |
| CNAME cloaking | Tracker advantage in Chrome | Browser-invisible surface |
| Server-side tracking | Tracker advantage | Browser-invisible surface |
| WebGPU fingerprinting | Tracker advantage (emerging) | Hardware surface |
| AI behavioral profiling | Regulatory gap | Consented inference |
Force 1: Tracking That Lives Inside the Trust Model
Some tracking techniques survive because they exploit the same mechanisms the web needs to function. Browsers cannot kill them without breaking legitimate sites.
First-party cookies are the clearest example. WebKit's ITP caps script-writeable storage at 7 days, tightening to 24 hours when a classified tracker domain appears in the referrer chain.[^3] But ordinary first-party cookies set via Set-Cookie headers are exempt; ITP applies its seven-day cap to response cookies only when it detects third-party CNAME or IP-address cloaking. Moving cookie logic to a genuinely first-party server - a standard sGTM configuration - sidesteps the cap. The browser cannot block server-set first-party cookies without breaking authentication on most of the web. That is the ceiling.
Browser fingerprinting exploits the same structural constraint from a different angle. Canvas rendering, WebGL GPU queries, AudioContext processing, and font enumeration all answer legitimate layout questions. A fingerprinting script reads the answers and hashes them into a composite identifier. The identifier survives cookie deletion, incognito mode, and VPN reconnection - because no stored state is involved, only device characteristics that the browser must expose to render content correctly.[^4]
This is also where defenders have real wins. Cache partitioning in Firefox 85 and subsequent Chrome updates killed cross-site ETag and HSTS supercookie tracking.[^5][^6] Those defenses work because cache partitioning does not break site functionality - it isolates state by top-level site, which aligns with the same-origin model legitimate sites already expect. The mitigation required no trust-relationship trade-off.
The pattern: when the defense aligns with the trust model, it holds. When it conflicts, it does not ship or gets reverted.
Force 2: Tracking That Moved Off the Browser
The second force is harder to audit because the browser cannot see it.
CNAME cloaking and the cookie leak
The CNAME arrangement I found in the audit is common. A DNS record routes metrics.example.com to tracker.analytics-vendor.io. The browser sees a first-party origin and applies first-party trust. The actual destination is a tracker's infrastructure - but DNS resolution happens below the browser's policy enforcement layer.
Chrome extensions cannot detect this. Chromium does not expose a browser.dns API, so extensions have no mechanism to resolve CNAME chains before allowing requests. Firefox with uBlock Origin 1.25.0+ can, using browser.dns.resolve() to look up the chain and block when it terminates at a known tracker.[^7] That capability exists only in Firefox. Chrome controls approximately 65-69% of the market.[^2]
The security risk goes beyond tracking. When the browser sends a request to metrics.example.com, it includes all cookies scoped to *.example.com - authentication cookies, session tokens, anything broadly scoped. A 2021 NDSS study confirmed that CNAME-cloaked endpoints receive authentication cookies intended for the first-party site.[^7] In the audit, I found _ga, _gid, and a broadly-scoped session cookie all leaking to the cloaked endpoint. The session cookie was the one that mattered.
Server-side tracking and the consent gap
Server-side tracking moves tag logic off the browser entirely. The architecture: browser sends events to ss.example.com. A server-side container processes those events, enriches them with server-side data, and forwards them to advertising platforms. The browser sees a first-party request indistinguishable from any other resource load.
No browser extension, no ITP, no DNS-based blocker running on the user's device has visibility into the server-to-server transmission. That is the point.
The consent propagation gap is what I found most concerning. GDPR applies regardless of where processing occurs. If a user declines analytics consent, forwarding their data server-side remains unlawful. But user-side consent signals do not automatically propagate to server-side containers. The stack I audited had a fully compliant client-side tag configuration and a server-side container that ignored consent state entirely. This is not a bug - it is the default behavior. Consent propagation to server-side containers must be explicitly built. No major server-side tracking implementation does it automatically.
What the industry built after Privacy Sandbox
Three production architectures now define the post-cookie infrastructure:
Server-side first-party collection. The browser fires a thin first-party beacon. All matching and enrichment logic runs server-side. Platforms receive server-originated event streams via Measurement Protocol, Conversions API, or equivalent endpoints.
Hashed identity graphs. First-party data - hashed emails, phone numbers - onboards to platform user graphs via LiveRamp, Neustar, or direct platform matching. Cross-site identity without cookies, built on PII users provided for unrelated purposes.
Modeled measurement. Google's Consent Mode v2 generates modeled conversions for users who declined analytics consent - inferring conversion behavior from non-consenting users based on patterns from consenting ones. Clean rooms (Amazon Marketing Cloud, Snowflake, Google's Protected Analytics Framework) join brand and platform datasets without raw data sharing.
None of this infrastructure is browser-visible. It achieves equivalent targeting outcomes while operating entirely outside the browser's threat model.
Force 3: Behavioral Inference From Consented Data
The third force is the one I think about most, because it sits in a regulatory grey zone that current frameworks do not resolve.
ML models trained on behavioral datasets can infer stable user identity from session-level signals: scroll velocity, typing cadence, mouse trajectory curvature, and session shape - the temporal pattern of page views, dwell times, and navigation sequences within a session. These models do not need a persistent identifier. They produce a probability distribution over known user profiles for any new session.
An anonymized session - no cookies, no login - can match against a library of behavioral profiles at 60-80% accuracy at scale. The re-identification runs continuously: every new session either matches an existing profile or seeds a new one.
The gap: mouse movements and scroll patterns are not traditionally classified as personal data. The user consented to analytics. The output is probabilistic, not identity-asserting. The decision downstream is an ad selection, not a significant life decision. That combination places behavioral profiling for ad targeting in a grey zone under both the EU AI Act and CPRA.
The EU AI Act's prohibited practices (Article 5, effective February 2, 2025) target social scoring, biometric categorization, and real-time remote biometric identification. Behavioral profiling for advertising qualifies as high-risk under Article 6 if it drives automated decisions with significant effects on individuals. Whether ad targeting meets "significant effects" is unresolved.
CPRA regulations effective January 1, 2026 require risk assessments for automated processing that infers personal traits. The regulation's enumerated examples - "preferences, reliability, or movements" - explicitly cover behavioral profiling from session data.
Both frameworks require assessment, not prohibition. Behavioral inference from consented first-party data likely survives both because the consent basis holds and the inference is probabilistic. The outcome - a detailed behavioral profile used to target advertising - is functionally equivalent to what cookies and fingerprinting produce. The legal framework does not equate functional equivalence with legal equivalence.
For the full regulatory landscape - ICO guidance, CPRA enforcement, CIPA litigation, the Disney DTC settlement - see The 2025-2026 Privacy Enforcement Landscape.
What a Defensible Posture Looks Like in 2026
Automated compliance scans measure the browser-visible surface. The threat surface extends well beyond it. I came out of the audit with five areas that need explicit attention - the things automated tools miss.
Consent signal propagation to server-side containers. A user who declines analytics consent on the client side must trigger a corresponding gate in the server-side container. This does not happen by default in GTM server container configurations. Document the propagation path and test it under each consent state. The stack I looked at had no propagation at all.
CNAME inventory and cookie leak audit. Enumerate every CNAME arrangement for tracking subdomains. Validate that cloaked endpoints do not receive authentication cookies or broadly-scoped session tokens. The authentication cookie exfiltration documented in the 2021 NDSS study[^7] is a security issue independent of the privacy concern.
Session replay consent gating. Session replay SDKs must activate only after consent. Masking rules must cover actual form fields - not just fields labeled "password." Retention periods for session recordings need documentation and enforcement.
Cross-device identity scope documentation. If probabilistic cross-device matching is in use, document the resolution scope and the opt-out propagation path. The February 2026 Disney DTC settlement established that opt-out obligations must match the scope of identity resolution a company uses for targeting - though the enforcement so far addresses account-level identity, not probabilistic graphs.
ADMT risk assessment. If any ML model infers user traits from behavioral data to drive targeting decisions, a CPRA-compliant risk assessment is required as of January 1, 2026. The assessment must weigh privacy risk against business benefit and document the decision to proceed, restrict, or prohibit.
A site that completes these five steps addresses the audit surface that automated tools miss. That is the scope of defensible in 2026. It is also the minimum - the regulatory surface is moving, and the techniques are not standing still.
References
[^1]: Google Privacy Sandbox retirement announcement, October 17, 2025. https://privacysandbox.com/news/
[^2]: StatCounter Global Stats. Browser market share worldwide, Q1 2026. https://gs.statcounter.com/
[^3]: Tracking Prevention in WebKit. https://webkit.org/tracking-prevention/
[^4]: fingerprintjs/fingerprintjs - GitHub. https://github.com/fingerprintjs/fingerprintjs
[^5]: Firefox 85 Cracks Down on Supercookies - Mozilla Security Blog. https://blog.mozilla.org/security/2021/01/26/supercookie-protections/
[^6]: Protecting Against HSTS Abuse - WebKit. https://webkit.org/blog/8146/protecting-against-hsts-abuse/
[^7]: An Analysis of First-Party Cookie Exfiltration due to CNAME Redirections - NDSS Symposium. https://www.ndss-symposium.org/ndss-paper/auto-draft-146/