Consent Theatre: Reject-Leak Forensics Exposes Cookie Banner Lies

The Compliance Illusion Built Into TCF's Architecture

The IAB Europe's Transparency & Consent Framework was designed to operationalize GDPR consent at scale. In practice, it operationalizes the appearance of consent. The landmark study by Matte, Bielova, and Santos (2020) — "Do Cookie Banners Respect my Choice?", IEEE S&P 2020 — audited 560 websites implementing TCF v1.1 and found that Retain with citation to original paper; flag as requiring primary source verification. This is not a marginal compliance gap. It is structural: the framework's reliance on client-side JavaScript and publisher-controlled consent strings creates audit surfaces that are trivially bypassed and rarely inspected.

For forensic privacy practitioners, this study is not merely an academic data point. It defines a methodology — reject-leak forensics — that every DPO and technical auditor should deploy before signing off on any vendor's cookie consent implementation.

What "Reject-Leak" Actually Means at the Network Layer

A reject-leak occurs when a data subject exercises a negative consent choice — clicking "Reject All" or closing a banner without opting in — and the website nonetheless initiates data transmissions to third parties that require a valid legal basis under Art. 6(1) GDPR. The gap manifests in several technically distinct forms:

• Pre-consent firing: Tracking pixels, beacon requests, or third-party JavaScript load before the consent UI renders. Detectable via HAR file analysis — look for requests to known tracker domains (e.g., pixel.advertising.com, sync.rtbhouse.com) with timestamps preceding the DOMContentLoaded event or any __tcfapi callback.
• Consent string manipulation: Matte et al. found instances where the TC String stored in the euconsent-v2 cookie recorded a positive consent signal despite a user selecting rejection. This is detectable by decoding the TC String using the IAB's reference decoder and cross-referencing the PurposesConsent bitmap against observed network activity.
• Zombie consent: A previously stored positive TC String is re-read from localStorage or a first-party cookie and transmitted to third parties, overriding a fresh rejection. This persists across sessions unless explicitly cleared.
• Post-reject continuation: Tag managers (Google Tag Manager, Tealium) fire vendor tags based on their own internal consent state that lags behind the CMP's updated state. The window.__tcfapi('addEventListener', 2, callback) listener is not always respected by all tag configurations.

The CJEU and EDPB Context: Why This Is Legally Explosive

The CJEU's judgment in IAB Europe v. APD (Case C-604/22, February 2024) confirmed that IAB Europe acts as a joint controller for TC String processing. This ruling, combined with the Belgian APD's underlying decision (APD/GBA, Dossier nr. DOS-2019-01377), establishes that a technically defective TC String is not a shield for downstream processors — it is evidence of a consent mechanism that was never legally valid.

The EDPB's Guidelines 05/2020 on consent (adopted 4 May 2020, revised 4 May 2020, ref. EDPB-2020-GL-05) explicitly state that consent must be unambiguous and that pre-ticked boxes or systems where inaction implies consent are prohibited. A CMP that fires trackers before receiving a positive signal violates this standard directly under Art. 7 GDPR, not merely as a procedural defect.

Critically, the accountability principle under Art. 5(2) GDPR places the burden of demonstrating compliance on the controller. A reject-leak, once documented in a forensic network capture, inverts that burden operationally: the controller must explain why data left the browser without a valid legal basis. In the absence of a contemporaneous, cryptographically verifiable consent record, that explanation will fail.

Forensic Methodology: How to Document a Reject-Leak

A defensible reject-leak investigation requires reproducible, timestamped evidence. The following protocol produces court-admissible artifacts:

1. Isolate the environment: Use a clean browser profile (Chromium in incognito, or a dedicated Playwright/Puppeteer session) with no existing cookies or localStorage. Disable browser-level tracking protection to avoid confounding variables — you are testing the CMP, not the browser.
2. Capture a full HAR trace: Open DevTools Network tab, enable "Preserve log", navigate to the target URL, interact with the consent UI (reject all), and export the HAR file. Tools like mitmproxy or Charles Proxy provide richer TLS-decrypted captures including request bodies.
3. Timestamp analysis: In the HAR file, compare the startedDateTime of each third-party request against the timestamp of the consent interaction event. Any tracker request to a vendor listed in the TCF GVL (Global Vendor List) with a startedDateTime before the rejection callback confirms a pre-consent fire.
4. TC String decode: Extract the euconsent-v2 cookie value immediately after rejection. Decode it at https://iabtcf.com/#/decode or using the @iabtechlab/consent-string npm library. Verify that purposeConsents bits 1–10 are all 0 and that the vendor consent bitmap shows no positive signals.
5. DNS and TLS fingerprinting: Use Wireshark with TLS SNI logging to capture the server names contacted during the rejection flow. SNI data in the ClientHello message is unencrypted even in TLS 1.3 and reveals tracker domains before any HTTP-layer content is visible.

What the Data Reveals About TCF's Structural Failure

Matte et al.'s finding that 32% of sites set positive consent in the TC String regardless of user choice points to a specific implementation pattern: CMPs that write the consent string synchronously at page load with a default-positive state, then update it asynchronously after user interaction — with no guarantee that downstream tag managers wait for the update. The __tcfapi API's event-driven model assumes that all consumers implement the addEventListener callback correctly. Most tag manager templates do not.

This is compounded by the CMP vendor incentive structure. CMPs are commercially dependent on publishers, who benefit from higher opt-in rates. An "accidental" pre-fire that establishes a tracking cookie before rejection is processed is economically rational for both the CMP vendor and the publisher. Forensic auditors should treat this alignment of incentives as a prior when interpreting ambiguous network captures.

Action Items for DPOs and Technical Auditors

• Run reject-leak tests on every CMP deployment before go-live and after any CMP version update. Automate this with Playwright scripts that interact with the consent UI and assert zero third-party requests in the subsequent HAR output.
• Decode TC Strings programmatically as part of your quarterly consent audit. A positive purposeConsents bit after a documented rejection is a GDPR violation ready-made for a supervisory authority complaint.
• Demand vendor attestations under Art. 28(3)(h) GDPR: your DPA with your CMP vendor and tag manager provider must contractually require that their systems honor negative consent signals within a defined latency (recommend <50ms).
• File evidence packages, not screenshots. HAR files, TC String decoded outputs, and Wireshark pcap files constitute a forensic record. Screenshots of cookie banners do not.
• Cross-reference against the GVL: Every third-party domain contacted post-rejection should be checked against IAB's current Global Vendor List. Non-GVL vendors receiving data post-rejection have no TCF basis whatsoever — this is a straightforward Art. 6(1) GDPR violation with no mitigation pathway.

The distance between a cookie banner that says "Reject All" and a network stack that acts on that rejection is where enforcement cases are won and lost. Reject-leak forensics closes that distance — and transforms compliance theater into verifiable evidence.

This article was produced with AI assistance and fact-checked against verified GDPR case law (GDPRhub). For legal advice, consult a qualified data protection expert.