11.5 Internet Monitoring and Web Tracking: Cookies, Fingerprinting, and GPC

11.5 Internet Monitoring and Web Tracking: Cookies, Fingerprinting, and GPC

Quick Summary: Digital tracking has evolved from simple HTTP cookies into a sophisticated ecosystem of stateful storage exploits, stateless hardware fingerprinting, and mobile ad frameworks. Understanding these tracking vectors—and engineering counter-mechanisms such as edge-honored Global Privacy Control (GPC) and privacy-preserving sandboxes—is a core technical responsibility in privacy engineering.

Modern web and mobile tracking operates across multiple architectural layers, spanning client runtime environments, DNS infrastructure, network proxies, and distributed ad-tech backends. Privacy technologists must understand the mechanical execution of these tracking vectors to design robust boundaries and ensure compliance with emerging statutory mandates.

---

Stateful Web Tracking Mechanics

Stateful tracking relies on persisting an explicit, unique identifier within client storage or network metadata that can be retrieved during subsequent network transactions.

1. First-Party vs. Third-Party Cookies

HTTP cookies are key-value pairs delivered via the Set-Cookie response header and returned in the Cookie request header. The critical architectural boundary is the origin domain:

• First-Party Cookies: Set by the domain currently displayed in the browser's address bar (e.g., publisher.com). They are primarily used for session management, user authentication, and shopping cart persistence.
• Third-Party Cookies: Set by a domain distinct from the one in the address bar, typically loaded through embedded resources such as <iframe>, <script>, or <img> elements (e.g., an ad script loaded from ad-network.com while visiting publisher.com). Third-party cookies allow tracking networks to correlate a user's browsing activity across hundreds of independent websites.

Browsers manage cookie access through the SameSite attribute flag:

Browser engines have restricted third-party cookies unevenly. Apple WebKit's Intelligent Tracking Prevention (ITP) blocks third-party cookies by default and caps some first-party cookies at seven days; Mozilla's Enhanced Tracking Protection (ETP) with Total Cookie Protection partitions cookie jars per site. Chrome is different: in April 2025 Google dropped its plan to phase out third-party cookies, and on October 17, 2025 it announced the retirement of most Privacy Sandbox APIs (including Topics, Protected Audience, Attribution Reporting, Private Aggregation, IP Protection, and Related Website Sets) because of low adoption. Chrome keeps CHIPS (Cookies Having Independent Partitioned State) and FedCM. Third-party cookies therefore still work in Chrome by default, which keeps consent, GPC, and cookie governance central to privacy engineering.

2. Cookie Syncing (Cookie Matching) Protocols

Because web browsers enforce the Same-Origin Policy (SOP), an ad exchange (exchange.com) cannot directly read a cookie set by a demand-side platform (dsp-bidder.com). To construct a unified cross-platform behavioral profile, ad tech networks execute cookie syncing (or cookie matching):

+-------------+               +------------------+               +-------------------+
| User Browser|               |   SSP / Exchange |               |   DSP / Data Broker|
+-------------+               +------------------+               +-------------------+
       |                                |                                  |
       | 1. GET /ad-tag.js              |                                  |
       |------------------------------->|                                  |
       | 2. Returns 302 Redirect        |                                  |
       |    Location: dsp.com/sync?      |                                  |
       |    ssp_id=SSP_USER_987         |                                  |
       |<-------------------------------|                                  |
       |                                                                   |
       | 3. GET /sync?ssp_id=SSP_USER_987                                  |
       |    (Browser automatically attaches existing Cookie: dsp_id=DSP_654) |
       |------------------------------------------------------------------>|
       |                                                                   | 4. Server maps:
       |                                                                   |    SSP_USER_987
       |                                                                   |    <-> DSP_654
       | 5. 204 No Content (Sync Complete)                                 |
       |<------------------------------------------------------------------|

1. While visiting a participating publisher, the browser loads an ad tag from exchange.com. The exchange reads its own third-party cookie (ssp_user_id = SSP_987).
2. The exchange responds with an HTTP 302 redirect targeting the partner's sync endpoint: https://dsp-bidder.com/sync?partner_id=exchange&partner_uid=SSP_987.
3. The browser follows the redirect to dsp-bidder.com, automatically transmitting dsp-bidder.com's existing cookie (dsp_user_id = DSP_654) in the request header.
4. dsp-bidder.com captures both identifiers and records an entry in its server-side identity resolution table: SSP_987 <==> DSP_654.
5. Both platforms can now trade bid requests and behavioral profiles referencing the same real-world browser instance, rendering domain-level cookie sandboxing largely ineffective.

3. Persistent Client-Side Storage & Evercookies

When browsers restrict HTTP cookies, tracking scripts leverage alternate HTML5 client storage APIs:

• LocalStorage and IndexedDB: Provide origin-scoped, persistent key-value and object storage with multi-megabyte capacity and no expiration date. Trackers store GUIDs within LocalStorage and copy them across frames.
• Cache Storage and ETags: Trackers generate an ETag HTTP response header containing a unique identifier when caching an asset (e.g., a 1x1 tracking pixel). On later visits the browser sends the If-None-Match request header with that ETag, re-identifying the browser until the cache is cleared. Modern browsers partition caches by top-level site, which limits this to same-site tracking.
• Evercookies (Zombie Cookies): Advanced tracking scripts write identical identifier tokens across dozens of storage vectors simultaneously (HTTP cookies, LocalStorage, SessionStorage, IndexedDB, Web SQL, Flash LSO, HSTS cache flags, and HTTP ETags). If a user clears their browser cookies, client-side scripts read the surviving token from LocalStorage or the cache and "respawn" the deleted cookie, frustrating user privacy choices.

4. CNAME Cloaking (DNS Aliasing)

As ad-blockers and privacy extensions began compiling blocklists of known third-party tracking domains (e.g., track.analytics-vendor.com), ad-tech vendors developed CNAME cloaking to disguise third-party endpoints as first-party subdomains.

• Mechanics: The publisher configures a DNS Canonical Name (CNAME) record on their own domain: metrics.publisher.com CNAME tracker.analytics-vendor.com. When the browser makes a request to metrics.publisher.com, the DNS resolver transparently points the connection to the external vendor's infrastructure.
• Architectural Privacy Threats:
  1. Bypassing Cookie Protections: Because the tracking endpoint shares the publisher's root domain (.publisher.com), the browser treats it as a first-party resource, bypassing Safari ITP and blocklists.
  2. Session and Token Leakage: All first-party cookies scoped to .publisher.com (which often include sensitive authentication bearer tokens, CSRF tokens, and internal user IDs) are automatically transmitted in the request headers to the third-party tracking vendor's servers.
• Defenses: Content blockers that can resolve DNS (e.g., uBlock Origin on Firefox) and privacy-focused DNS resolvers (e.g., NextDNS) uncloak CNAME aliases before applying filter lists. WebKit caps cookies set by CNAME-cloaked or third-party-IP subdomain responses to seven days.

5. Bounce Tracking (Redirect Tracking)

Bounce tracking occurs when a user clicks a link on siteA.com intending to visit siteB.com, but the navigation is momentarily diverted through an intermediate domain: tracker.com?dest=siteB.com.

During the fraction of a second that the browser loads tracker.com, tracker.com operates as a first-party context. It reads its existing first-party cookies, records the referral telemetry, updates the user's profile, and executes an immediate HTTP 302 or JavaScript redirect to siteB.com. Modern browser defenses (e.g., Safari's Bounce Tracking Protections and Firefox Redirect Tracking Protection) periodically inspect browsing history and purge client storage for domains that only appear in redirect chains without sustained user interaction.

---

Stateless Device and Browser Fingerprinting

As client-side storage mechanisms face increasing technical and legal restrictions, tracking systems transition to stateless fingerprinting. Fingerprinting measures unique hardware, operating system, and browser configuration quirks without storing any token on the client device.

The Mathematical Foundation of Fingerprinting

In 2010, Peter Eckersley published the landmark EFF study How Unique Is Your Web Browser?, introducing the metric of information entropy ($H$) to quantify fingerprint uniqueness:

$H = -\sum_{i=1}^{n} p_i \log_2(p_i)$

Where $p_i$ is the probability of a specific configuration appearing across the global population. Eckersley demonstrated that an entropy of approximately 33 to 40 bits is sufficient to uniquely identify a single device out of the entire global internet population ($2^{33} \approx 8.58 \times 10^9$). When multiple moderately unique attributes are combined, their independent entropies add together, creating a distinct, resilient fingerprint.

+-----------------------------------------------------------------------------------------+
|                                 BROWSER FINGERPRINTING VECTORS                          |
+----------------------------+-----------------------------+------------------------------+
| Graphic / Audio Rendering  | System & Hardware Profile   | Network & Protocol Quirks    |
| - HTML5 Canvas 2D          | - User-Agent Client Hints   | - TLS ClientHello Fingerprint|
| - WebGL Shader Precision   | - Installed System Fonts    |   (JA3 / JA4 hashes)         |
| - AudioContext Oscillators | - Screen Res & Color Depth  | - Clock Skew / NTP Drifts    |
| - WebGPU Pipeline Compiles | - Hardware Concurrency & RAM| - TCP Window Size & MTU      |
+----------------------------+-----------------------------+------------------------------+

1. Canvas Fingerprinting

Canvas fingerprinting leverages the HTML5 <canvas> API. A script instructs the browser to render an invisible, complex graphic combining 2D text, colored geometric shapes, emojis, and gradient overlays:

// Conceptual Canvas Fingerprint Routine
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
ctx.textBaseline = 'top';
ctx.font = "14px 'Arial', 'Helvetica', 'Times New Roman'";
ctx.textBaseline = 'alphabetic';
ctx.fillStyle = '#f60';
ctx.fillRect(125, 1, 62, 20);
ctx.fillStyle = '#069';
ctx.fillText('OpenExamPrep CIPT Privacy Canvas: <svg> 😃', 2, 15);
ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
ctx.fillText('OpenExamPrep CIPT Privacy Canvas: <svg> 😃', 4, 17);
const dataURL = canvas.toDataURL();
const canvasHash = crypto.subtle.digest('SHA-256', new TextEncoder().encode(dataURL));

Even though the code is identical across all machines, the resulting pixel bitmap differs at the sub-pixel level due to:

• Differences in GPU hardware architectures and floating-point computation units.
• Operating system font rasterization engines (DirectWrite on Windows, Core Text on macOS, FreeType on Linux).
• Anti-aliasing, font smoothing, and sub-pixel hinting algorithms.
• Graphics driver implementations.

Converting the raw pixel array into a Base64-encoded PNG data URL and hashing it with SHA-256 yields a deterministic identifier that remains stable across sessions.

2. WebGL and WebGPU Fingerprinting

WebGL expands canvas fingerprinting into 3D rendering. Trackers query the WebGL context directly via gl.getParameter() to extract high-entropy constants:

• gl.RENDERER and gl.VENDOR: Often unmasked via the WEBGL_debug_renderer_info extension, exposing the exact GPU model and driver version (e.g., ANGLE (NVIDIA, NVIDIA GeForce RTX 3080 Direct3D11 vs_5_0 ps_5_0)).
• Floating-point shader precision: Querying gl.getShaderPrecisionFormat() across vertex and fragment shaders reveals differences in internal mantissa and exponent bits.
• Fragment shader rasterization: Rendering a complex 3D geometric mesh with lighting, shadows, and clip planes reveals micro-discrepancies in GPU rasterization.

3. AudioContext Fingerprinting

AudioContext fingerprinting operates on the audio processing subsystem. A script instantiates an OfflineAudioContext, feeds an uncompressed audio signal through an oscillator, applies a dynamic compression node (DynamicsCompressorNode) or a biquad filter (BiquadFilterNode), and measures the output waveform:

const audioCtx = new (window.OfflineAudioContext || window.webkitOfflineAudioContext)(1, 44100, 44100);
const osc = audioCtx.createOscillator();
osc.type = 'triangle';
osc.frequency.setValueAtTime(10000, audioCtx.currentTime);
const compressor = audioCtx.createDynamicsCompressor();
compressor.threshold.setValueAtTime(-50, audioCtx.currentTime);
compressor.knee.setValueAtTime(40, audioCtx.currentTime);
compressor.ratio.setValueAtTime(12, audioCtx.currentTime);
osc.connect(compressor);
compressor.connect(audioCtx.destination);
osc.start(0);
audioCtx.startRendering().then(renderedBuffer => {
  const channelData = renderedBuffer.getChannelData(0);
  // Compute a SHA-256 or Murmur3 hash of the float array values
});

The resulting mathematical values differ across machines due to CPU digital signal processing algorithms, audio driver implementations, and floating-point mathematics optimizations.

4. Font Enumeration and Environmental Attributes

• Font Probing: Operating systems ship with distinct font sets, and specialized desktop applications (Adobe Creative Cloud, Microsoft Office, AutoCAD) install unique typography. Trackers measure the bounding box width and height of a test string rendered in fallback fonts versus target fonts to compile an inventory of installed system fonts.
• User-Agent Client Hints (UA-CH): In response to deprecation of the traditional monolithic User-Agent string, browsers introduced Client Hints (Sec-CH-UA-Model, Sec-CH-UA-Platform-Version). While basic hints provide low entropy, server-requested high-entropy hints can reconstruct unique device profiles if not governed by strict permissions.
• Side-Channel Vectors: The W3C Battery Status API once exposed precise battery charge levels and discharge times, an accidental short-term identifier; Firefox and Safari removed it, while Chromium still exposes it. Network timing attacks (measuring cache latency to deduce past browsing history) and clock skew measurements (analyzing microsecond deviations in local hardware clocks relative to NTP time) provide additional fingerprinting channels.

5. Technical Mitigations Against Fingerprinting

---

Mobile Advertising Identifiers and Frameworks

In mobile operating systems, native applications run in isolated sandboxes and lack access to shared browser cookies. Mobile ad tracking historically relied on centralized, OS-level pseudo-unique hardware identifiers.

1. Apple IDFA and the App Tracking Transparency (ATT) Framework

Historically, Apple assigned every iOS device an Identifier for Advertisers (IDFA)—a user-resettable UUIDv4 string that third-party ad SDKs embedded across apps to match user activity, build cross-app profiles, and attribute ad installs.

With iOS 14.5, Apple introduced the App Tracking Transparency (ATT) framework, fundamentally altering mobile privacy architecture:

• Mandatory Runtime Opt-In: Applications must call ATTrackingManager.requestTrackingAuthorization() before accessing the IDFA or tracking users across apps owned by other companies. If the user selects "Ask App not to Track" (or if tracking is globally disabled in OS settings), the OS returns a zeroed-out UUID: 00000000-0000-0000-0000-000000000000.
• Policy Enforcement: Apple's App Store Review Guidelines (Guideline 5.1.2) explicitly prohibit developers from utilizing device fingerprinting (e.g., combining IP address, device model, battery level) to circumvent an ATT opt-out, backing policy with app rejection or developer account termination.

SKAdNetwork (SKAN) and AdAttributionKit

To replace cross-app IDFA tracking while supporting ad conversion measurement, Apple deployed SKAdNetwork (and its successor, AdAttributionKit):

+-------------+               +------------------+               +-------------------+
|  Ad Network |               |   User Device    |               |    Apple Servers   |
+-------------+               +------------------+               +-------------------+
       |                                |                                  |
       | 1. Serves ad signed with ad    |                                  |
       |    network's private key       |                                  |
       |------------------------------->|                                  |
       |                                | 2. User installs advertised app  |
       |                                |    OS records the attribution    |
       |                                |    and starts a random timer     |
       |                                |                                  |
       | 3. Device sends Apple-signed install postback directly to the     |
       |    ad network after the random delay (no device ID, coarse or     |
       |    fine conversion value depending on crowd anonymity tier)       |
       |<-------------------------------|                                  |
       | 4. Ad network verifies Apple's signature with Apple's public key  |

• No Device Identifiers: Postbacks contain no device identifier; the ad network learns only campaign-level facts.
• Delayed Postbacks: The device sends postbacks after a random delay (24 to 48 hours for the first postback in SKAdNetwork 4) to prevent timing correlation.
• Crowd Anonymity Tiers: Fine-grained conversion values are only transmitted if the volume of installs for a specific campaign exceeds privacy thresholds, preventing advertisers from isolating individual conversion paths.

2. Google Android Advertising ID (GAID) and the Retired Privacy Sandbox for Android

In the Android ecosystem, the Google Advertising ID (GAID) is managed via Google Play Services. When a user deletes the advertising ID (Android 12 and later), apps receive a string of zeros instead.

Google built Privacy Sandbox on Android as a planned replacement for GAID-based tracking. On October 17, 2025, Google announced it was retiring these APIs (Topics, Protected Audience, Attribution Reporting, Protected App Signals, and the SDK Runtime) on both Chrome and Android because of low adoption. They remain useful exam examples of privacy-by-design ad technology, but they are not a current compliance path:

• Topics API: Replaces cross-app tracking with coarse-grained interest groups. The device uses an on-device machine learning model to categorize installed apps into high-level categories (e.g., "Fitness" or "Autos") derived from an open taxonomy. Every epoch (7 days), the top topics are calculated locally. When an ad SDK queries the API, it receives three topics (one from each of the last three epochs), with a 5% probability of returning a random topic to inject differential privacy noise.
• Protected Audience API (formerly FLEDGE): Moves remarketing auctions directly onto the mobile device. Advertisers define custom audience interest groups stored in on-device storage. When an ad space is available, the device executes a sandboxed JavaScript auction locally, selecting the winning ad without sending user browsing or app history to external ad servers.
• Attribution Reporting API: Measures ad clicks and conversions without persistent cross-app IDs. It outputs two types of reports: Event-Level Reports (linking clicks to conversions with limited conversion bits, randomized response noise, and reporting delays) and Aggregatable Reports (high-fidelity data processed through a cloud-based Trusted Execution Environment [TEE] that adds Laplace differential privacy noise).

---

Global Privacy Control (GPC)

Recognizing that managing individual consent modals across thousands of websites places an unreasonable burden on consumers, privacy engineers and advocacy groups developed the Global Privacy Control (GPC), now a W3C Privacy Working Group Working Draft on the Recommendation track.

Statutory and Regulatory Mandates

GPC is not merely a technical recommendation; it has statutory legal backing:

• California Consumer Privacy Act / California Privacy Rights Act (CCPA/CPRA): California regulations (11 CCR § 7025) explicitly mandate that commercial businesses treat user-enabled opt-out preference signals—specifically GPC—as a valid, enforceable consumer request to opt out of the sale or sharing of personal information, as well as an opt-out from cross-context behavioral advertising.
• Enforcement Precedent: The California Attorney General underscored this mandate in the landmark enforcement action against retailer Sephora (settled for $1.2 million in 2022), citing the retailer's technical failure to configure its website to recognize and honor GPC signals transmitted by consumer browsers.
• Other US State Laws: Colorado (Colorado Privacy Act Rules), Connecticut, Montana, Oregon, and Texas have similarly incorporated mandatory recognition of universal opt-out mechanisms.

Technical Implementation: Header vs. DOM API

GPC is implemented across two distinct technical vectors:

1. HTTP Request Header (Sec-GPC)

Client browsers automatically transmit the header with every outbound HTTP request:

GET /products/running-shoes HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Sec-GPC: 1
Accept: text/html,application/xhtml+xml

The header value is a single binary character: 1 indicates an active opt-out request; 0 is not used (if disabled, the header is omitted entirely).

2. JavaScript DOM API (navigator.globalPrivacyControl)

For client-side script execution, the browser exposes a read-only boolean property on the navigator object:

if (navigator.globalPrivacyControl === true) {
  // User has broadcast a Global Privacy Control signal
  disableThirdPartyTrackingPixels();
  setConsentState({ saleOrSharing: 'DENIED', targetedAdvertising: 'DENIED' });
}

Edge Proxy Inspection and Reverse Proxy Architecture

Relying solely on client-side JavaScript to honor GPC creates severe race conditions: third-party analytics pixels loaded via asynchronous script tags may fire before the Consent Management Platform (CMP) evaluates navigator.globalPrivacyControl. High-performance systems evaluate GPC at the edge reverse proxy or API gateway (e.g., NGINX, Cloudflare Workers, Fastly VCL, AWS CloudFront):

# NGINX Edge Configuration for GPC Handling
map $http_sec_gpc $gpc_opt_out {
    default "0";
    "1"     "1";
}

server {
    listen 443 ssl http2;
    server_name example.com;

    # Ensure downstream caches separate pages based on GPC status
    add_header Vary "Sec-GPC" always;

    location / {
        # Pass GPC state upstream to application microservices
        proxy_set_header X-User-GPC-OptOut $gpc_opt_out;
        proxy_pass http://backend_app_upstream;
    }
}

// Edge Worker (Cloudflare / Fastly) GPC Enforcement
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const gpcHeader = request.headers.get('Sec-GPC');
  const isGpcActive = gpcHeader === '1';

  // Forward request upstream with standardized privacy header
  const modifiedRequest = new Request(request, {
    headers: new Headers(request.headers)
  });
  modifiedRequest.headers.set('X-Privacy-OptOut', isGpcActive ? 'true' : 'false');

  const response = await fetch(modifiedRequest);
  const newHeaders = new Headers(response.headers);

  // Critical: Set Vary header to prevent cache poisoning across users
  newHeaders.append('Vary', 'Sec-GPC');

  if (isGpcActive) {
    // Example policy: drop any cookie-sync redirect the origin tried to issue
    if (response.status === 302 && (newHeaders.get('Location') || '').includes('/sync?')) {
      return new Response(null, { status: 204, headers: newHeaders });
    }
  }

  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: newHeaders
  });
}

Automated CMP Honoring Requirements

When a web property integrates a Consent Management Platform (CMP), the CMP must be programmatically configured to honor GPC automatically:

1. Friction-Free Opt-Out: Under CCPA regulations, a website cannot display a blocking pop-up or modal forcing the user to confirm their GPC choice. The signal must be applied automatically upon detection.
2. Category Mapping: GPC legally acts as an opt-out from "Sale", "Sharing", and "Targeted Advertising". CMP categories corresponding to these processing activities must immediately transition to OFF or DENIED.
3. Visual Confirmation: The CCPA regulations say a business should display whether it has processed the signal (for example, "Opt-Out Preference Signal Honored"); this is recommended rather than mandatory.
4. Conflict Resolution: If a user with GPC enabled previously provided explicit, verifiable consent to a specific business (e.g., via an authenticated loyalty account), statutory rules govern precedence: generally, a subsequent GPC signal overrides past consent unless the organization presents a compliant, explicit opt-in request asking the consumer to affirm their preference for that specific site.