0PN-lAB ANCR White Paper

Author: Mark Lizar, ISO/IEC 27560-1 Profile Editor, Kantara Consent Receipt Editor, ANCR - Transparency Performance Indicators Editor, Executive Director, Digital Transparency Lab, and co-founder of 0PN (Open Consent Group)

Date: January 24, 2026

Contact: m[email protected] | lab.0pn.org

Submitted to: European Data Protection Authorities and EU Policy Makers

Executive Summary

This paper provides technical and policy analysis demonstrating why the EU Omnibus consent framework cannot deliver valid consent under Convention 108+ Article 5.2 requirements. We document "permission fatigue by design"—the systematic engineering of consent theater that presents coerced permission-granting as valid consent while hiding international tracking and surveillance infrastructure.

Key findings:

• What browsers call "consent" is technically permission-granting, not valid consent (freely given, specific, informed, unambiguous)
• Security controls (GPC, cookie preferences) masquerade as privacy controls, obscuring that privacy was sacrificed before individuals could choose
• This misinformation externalises surveillance costs: billions of hours wasted annually on permission fatigue while surveillance profits remain privatized
• Web search and social media platforms exploit architectural opacity to hide controller identities behind "impossible to know by design" defenses
• The Chrome TPI-Report provides empirical evidence of surveillance architecture operating regardless of permission choices
• Transparency-by-default architecture—implemented before browser installation—offers enforceable alternative that eliminates security/privacy control confusion

We provide 12 specific transparency-by-default requirements from ISO/IEC 27560-1 Universal Notice Receipt Profile that enable regulatory enforcement at scale.

Abstract

This paper examines "Permission Fatigue by Design Masquerading as Consent"—the systematic misinformation that presents coerced permission-granting as valid consent while hiding international tracking and surveillance infrastructure. We demonstrate how security controls masquerading as privacy controls externalize surveillance capitalism costs onto society through time waste, cognitive burden, and systemic friction. We demonstrate why the EU Omnibus consent approach perpetuates this misinformation and argue that transparency-by-default architecture—implemented before browser installation and eliminating the fiction of "necessary cookies"—offers the only viable path to genuine accountability and individual control.

Introduction

Modern web browsers have been positioned as neutral intermediaries between individuals and the internet. Yet this characterization masks a troubling reality: browsers serve as surveillance infrastructure, enabling extensive tracking and data collection while maintaining the fiction of informed consent through proliferating permission requests and cookie banners.

What browsers call "consent" is technically permission-granting, often coerced through dark patterns. This is not consent as defined in Convention 108+ Article 5.2 (freely given, specific, informed, and unambiguous indication of wishes). It is permission fatigue by design—the intentional exhaustion of individuals through endless permission requests that hide international tracking and surveillance.

The EU Omnibus consent framework represents the latest attempt to solve this problem through improved consent mechanisms. This approach is fundamentally flawed because it perpetuates the core misinformation: treating coerced permission as valid consent.

This paper demonstrates why consent-based frameworks fail structurally, and why transparency-by-default architecture—implemented before browser installation—addresses the root cause rather than its symptoms.

The Structural Problem: Permission Fatigue by Design

Security Misinformation Externalizes Surveillance Costs

Before examining how browser surveillance operates, we must address the fundamental misinformation enabling it: security controls masquerading as privacy controls.

Modern browsers present Global Privacy Control (GPC), Do Not Track signals, and cookie preference settings as "privacy controls." This is misinformation. These mechanisms are security controls—damage limitation tools attempting to reduce surveillance after privacy has already been sacrificed through opaque data collection.

The distinction is critical:

• Privacy control = individual decides whether to share data before collection occurs (Controller-ID first, consent before processing)
• Security control = individual attempts to limit damage after surveillance architecture is already deployed (GPC, opt-out mechanisms, preference signals)

When browsers label security controls as "privacy controls," they shift accountability. The narrative becomes "individual failed to configure privacy settings properly" rather than "surveillance architecture violated privacy by design."

The Externalised Cost Pattern

This misinformation externalises the costs of surveillance capitalism onto individuals and society:

Time waste: Individuals spend estimated 40+ hours annually managing cookie banners, privacy settings, and permission requests—time unavailable for productive activity.

Cognitive burden: Constant low-level anxiety about "am I protected?" when protection is architecturally impossible without transparency-first design.

Opportunity cost: Resources spent on permission fatigue management rather than addressing root cause (opacity by design).

Regulatory burden: Enforcement resources investigating individual complaints rather than auditing systemic transparency infrastructure.

Systemic friction: Multiplicative cost across billions of individuals creates global productivity drain measurable in billions of hours annually.

Surveillance profits remain privatized while these costs are externalized to society. This is not accidental—it is the economic model.

Global Privacy Control: Security Theatre, Not Privacy Enablement

Global Privacy Control epitomises security-masquerading-as-privacy:

By the time GPC signals preference, the individual has already:

1. Installed browser with surveillance architecture built in
2. Loaded webpage that deployed tracking mechanisms
3. Been fingerprinted and identified
4. Had data transmitted to third parties internationally

GPC says "please stop surveilling me" after surveillance has begun. This is opt-out-of-surveillance (security control), not privacy enablement (privacy control).

Calling GPC a "privacy control" obscures this sequence and perpetuates the misinformation that individuals can "choose privacy" through post-installation settings. They cannot. Privacy requires transparency before collection, not damage limitation after capture.

Why This Misinformation Matters for EU Omnibus

The EU Omnibus framework perpetuates this misinformation by improving consent mechanisms within the security-control paradigm rather than requiring privacy-control architecture.

As long as browsers can label post-surveillance security controls as "privacy protections," regulatory frameworks will optimize permission theater rather than requiring Controller-ID first transparency.

Transparency-by-default eliminates this confusion: Controller Identification disclosed before any collection means privacy controls operate first, and security mechanisms serve their proper function (encryption, authentication, access control) without being misrepresented as privacy enablement.

How Browser Surveillance Operates

Despite privacy regulations like GDPR and Convention 108+, browser-based surveillance mechanisms remain deeply opaque to individuals. Browsers employ complex tracking technologies including:

• Third-party cookies and tracking pixels (falsely labeled "necessary cookies")
• Browser fingerprinting techniques
• Cross-site tracking identifiers
• Hidden telemetry and diagnostic data collection
• Opaque data-sharing agreements with advertisers and data brokers

These technologies operate to enable international tracking and surveillance, despite nominal "consent" mechanisms being present.

Permission Fatigue: Surveillance by Exhaustion

What individuals experience as "consent" is better characterized as permission fatigue by design—the systematic exhaustion of individuals through endless permission requests that wear down resistance to surveillance:

• Pre-selected "accept all" options that grant blanket permissions
• Asymmetric effort required to accept versus reject tracking
• Vague language that obscures the scope of international data transfers
• Renewal fatigue from repeated permission requests
• False dichotomy between "necessary cookies" and "optional cookies"

This is not consent. Consent requires free, specific, informed, and unambiguous indication. Permission fatigue by design produces the opposite: coerced, blanket, opaque, and ambiguous permission-granting.

The "Necessary Cookie" Fiction

There is no such thing as a necessary cookie when proper notice infrastructure exists. The category "necessary cookies" is misinformation designed to bypass consent requirements by claiming technical necessity.

What browsers claim is "necessary":

• Session management cookies
• Authentication cookies
• Security cookies
• Load-balancing cookies

What is actually necessary: Controller Identification Record (CIR) and Digital Notice Receipts that provide transparency before any tracking mechanism is placed on a device.

Cookies can be upgraded to Digital Notice Receipts easily—the technology is straightforward. The claim of cookie necessity obscures this simple technical reality.

The Transparency Gap

Even when browsers provide privacy settings and controls, critical gaps remain:

• Technical complexity prevents most individuals from understanding what data is collected
• Lack of clear disclosure about first-party data collection is by design
• Browsers obscure how collected data is used for international tracking
• No meaningful audit mechanisms exist to verify compliance with stated privacy policies

The "Impossible to Know by Design" Defense

Web search and social media companies exploit the architectural flaw of opacity-by-design to systematically hide required controller information. This pattern operates in three stages:

1. Capture Before Disclosure

Platforms capture individuals before providing Controller Identification. By the time an individual encounters a search engine or social media platform, tracking mechanisms are already deployed. The architecture inverts Convention 108+ Article 8 notice requirements: capture first, disclose never.

2. Hide Advertiser Controller Identities

Platforms claim it is "impossible to know" which advertisers are controllers of personal data because the advertising auction happens in real-time and varies by individual. This defense relies on architectural opacity: platforms designed the system to prevent controller disclosure, then claim disclosure is technically infeasible.

3. Platform as Controller Proxy

Platforms position themselves as the sole disclosed controller while hiding that advertisers are joint controllers or independent controllers with separate legal obligations. Individuals receive permission requests from "Google" or "Meta" but not from the dozens of advertisers who are actual data controllers.

The Controller-ID First Solution

This defense collapses under transparency-by-default architecture:

• Controller Identification Record retrieved from /.well-known/notice.txt before any tracking
• Advertising auction participants disclose Controller Identification Records before bid
• Individual receives notice of ALL controllers (platform + advertisers) before any data collection

"Impossible to know" becomes "trivially easy to disclose"

The claim that advertiser identification is impossible reveals deliberate architectural choice to hide controllers, not technical limitation. Transparency-by-default makes controller disclosure the prerequisite for data collection, eliminating the "impossible by design" defense.

Structural Conflicts of Interest

Major browser vendors face inherent conflicts of interest. Browsers developed by advertising companies operate within business models fundamentally dependent on surveillance. This creates structural impediments to genuine transparency, as revealing the full extent of international tracking might undermine the economic foundations of the browser itself.

Permission Fatigue Enables Mass Data Theft for AI Training Across Borders

The consent theater documented above has enabled systematic data theft at unprecedented scale. AI large language models are trained on scraped web data collected through the permission fatigue architecture this paper exposes.

The causal chain:

1. Browser surveillance infrastructure hides controller identities
2. "Consent" mechanisms present coerced permission as legal authorization
3. Web scrapers operate under this false consent architecture
4. Training datasets aggregate stolen personal data without valid legal basis
5. Agentic AI systems inherit both the data and the accountability gap

This is not a separate problem from permission fatigue—it is the inevitable consequence. When browsers enable data collection without transparency-before-consent, that data enters training pipelines that assume legal collection. The result: foundation models built on systematically stolen data, now deployed in agentic systems making consequential decisions about individuals.

The EU Omnibus framework perpetuates this theft. By consolidating invalid consent mechanisms rather than requiring Controller-ID first architecture, it provides legal cover for continued mass scraping. Every "accept all" click under permission fatigue becomes another dataset for AI training without meaningful authorization.

Transparency-by-default breaks this chain: When controllers must disclose identity and purposes before collection, web scraping for AI training requires explicit, informed consent. Notice Event Logs create audit trails showing whether training data had valid legal basis. The Chrome TPI-Report demonstrates that current architecture has 0% transparency compliance—meaning training datasets built on browser data have 0% valid consent foundation.

The emerging crisis of autonomous AI systems making consequential decisions without accountability infrastructure stems directly from this consent theater. The EU AI Act requires transparency and human oversight, but transparency-by-default architecture doesn't exist to implement these requirements at scale. Without Controller-ID first infrastructure, regulators cannot verify whether AI training data had valid legal basis, cannot trace data provenance through supply chains, and cannot enforce accountability when agentic systems cause harm.

Why the EU Omnibus Consent Framework Cannot Work

The EU Omnibus consent framework aims to streamline consent across digital services through standardized permission mechanisms. This approach fails for five structural reasons:

1. Consent Cannot Fix Permission Fatigue

The Omnibus framework assumes better-designed consent mechanisms will solve the transparency problem. This is backwards and perpetuates misinformation.

The framework calls coerced permission "consent." No amount of improved permission UX can transform permission fatigue into valid consent. When the underlying tracking infrastructure remains hidden and individuals are exhausted by endless permission requests, "informed consent" becomes a logical impossibility.

2. Consolidating Permission Amplifies Dark Patterns

By centralising in-valid consent decisions, the Omnibus approach creates a single point of failure for privacy. A one-time "accept all" decision—made under cognitive load, time pressure, or design manipulation—can authorise international surveillance across vast swaths of the web.

This consolidation increases the incentive for dark patterns, as the stakes of each permission interaction grow higher. The more that depends on a single permission grant, the more resources surveillers will continue to invest in manipulating that interaction.

3. Regulatory Capture Through Complexity

The Omnibus framework's complexity creates opportunities for regulatory capture. Large technology companies with extensive legal resources can navigate and shape complex consent standards, while technical requirements create barriers for smaller competitors.

The result is a system that appears protective while actually entrenching incumbent surveillance business models. Compliance becomes a competitive moat rather than a protective measure.

4. The Post-Installation Consent Trap

The Omnibus framework operates post-installation—after individuals have already installed browsers with surveillance infrastructure built in. By this point, the architecture of permission fatigue is already deployed.

Transparency must exist before browser installation for legally valid consent, not as post-hoc settings buried in preference menus. Pre-installation transparency allows individuals to see what they are installing before surveillance mechanisms are activated.

5. The Fundamental Category Error

Most critically, consent-based frameworks commit a category error: they treat surveillance as a consumer choice problem rather than a structural problem, and they misrepresent coerced permission as valid consent.

This framing suggests that if individuals just had better information and clearer choices, they would make "good" decisions about their data. But when surveillance is embedded in the infrastructure of digital life, and when permission fatigue is engineered by design, individual consent cannot address the systemic power asymmetries at play.

Why Transparency-by-Default Works

Transparency-by-default addresses the root cause of permission fatigue fiction: opacity itself. This approach inverts the current paradigm in six decisive ways:

1. Pre-Installation Transparency

Transparency must exist before browser installation. Individuals need to see what surveillance infrastructure is built into browsers before they install them. This requires:

• Clear disclosure of all tracking mechanisms enabled by default
• Explicit statement of international data transfer pathways
• Plain-language explanation of what "necessary cookies" actually do
• Comparison of browser surveillance architectures

Pre-installation transparency allows informed choice about which browser to install, rather than post-installation permission fatigue about what to allow within an already-surveilling browser.

2. Digital Notice Receipts Replace Cookies

Cookies can be easily upgraded to Digital Notice Receipts—the technology is straightforward:

Current pattern (permission fatigue):

1. Browser loads page
2. Cookie placed on device without notice
3. Individual encounters permission request after tracking has begun
4. "Necessary cookies" bypass permission entirely

Transparency-by-default pattern (Controller-ID first):

1. Browser encounters site
2. Controller Identification Record (CIR) retrieved from /.well-known/notice.txt
3. Individual receives notice of what will be tracked before any mechanism is placed
4. Digital Notice Receipt placed on device after notice is provided
5. No cookies are "necessary"—all tracking mechanisms operate with transparent notice

This inversion is technically simple. The resistance to implementing it reveals that "consent" mechanisms are designed to hide surveillance, not enable transparency.

3. Eliminating the "Necessary Cookie" Fiction

When proper notice infrastructure exists, no cookie is necessary:

• Session management: Digital Notice Receipt provides session binding with transparent notice
• Authentication: Notice Receipt includes authentication context with explicit disclosure
• Security: Cryptographic binding in Notice Receipt provides security with auditability
• Load balancing: Infrastructure choice disclosed in Controller Identification Record

The category "necessary cookies" exists to bypass consent requirements. Digital Notice Receipts eliminate this bypass by making all tracking mechanisms operate through transparent notice infrastructure.

4. Visibility Without Cognitive Burden

Transparency-by-default makes tracking mechanisms visible in real-time without requiring individuals to make constant decisions. Instead of asking individuals to grant permission to opaque practices, browsers expose what is actually happening: which entities are tracking, what data is being collected, where it's being sent internationally.

This shifts the burden from individual decision-making to system visibility. Individuals can see what is happening without being forced to grant permissions about every instance.

5. Accountability Through Exposure

When tracking becomes visible by default, surveillance practices face natural accountability pressures. Trackers that might seem acceptable in abstract privacy policies become viscerally troubling when individuals see dozens of third parties collecting data for international surveillance from a single page load.

This exposure creates reputational and market pressures that permission mechanisms cannot. Visibility itself becomes the regulatory mechanism, operating continuously rather than only at isolated permission moments.

6. Technical Feasibility and Simplicity

Unlike complex consent frameworks requiring new regulatory infrastructure, standardization committees, and compliance regimes, transparency-by-default is technically straightforward:

Transparency-by-default eliminates security/privacy control confusion:

Under current architecture, individuals cannot distinguish between:

• Privacy controls (enable choice before collection)
• Security controls (limit damage after collection)

Browsers exploit this confusion by presenting GPC and cookie preferences as "privacy" when they are functionally security mechanisms operating post-surveillance.

Controller-ID first architecture makes the distinction unnecessary:

• Privacy layer: Controller Identification Record disclosed before any collection = individual chooses whether to engage
• Security layer: Encryption, authentication, access control operate on data individual chose to share

No security control needs to masquerade as privacy control because privacy controls operate first. Security mechanisms serve their proper cryptographic and access-control functions without being mislabeled as privacy enablement.

This architectural clarity also eliminates the externalized costs of permission fatigue: individuals don't waste time managing "privacy settings" that are actually post-surveillance security controls, because surveillance requires transparent notice first.

Technical implementation remains straightforward:

• Browsers already have complete visibility into network requests, cookies, and tracking mechanisms
• Controller Identification Records can be retrieved from standardized /.well-known/ URIs
• Digital Notice Receipts can replace cookies using existing cryptographic primitives
• Pre-installation transparency requires only clear disclosure documentation

The technical capability exists. The resistance to transparency-by-default reveals that current "consent" frameworks are designed to hide international tracking, not enable individual control.

Empirical Evidence: The Chrome TPI-Report

The DTL-TPI-RR (Digital Transparency Lab - Transparency Performance Indicator - Record and Reporting) pilot on Google Chrome provides empirical evidence of permission fatigue by design masquerading as consent.[1]

Chrome's Surveillance Architecture

The TPI-Report documented Chrome's extensive data collection architecture that operates regardless of stated consent preferences:

• Network traffic analysis showing undisclosed data transmission to Google and third-party trackers
• API mapping revealing data collection endpoints that bypass ‘fake receipt aka Cookie’ permission controls
• Browser fingerprinting techniques that persist despite privacy settings
• Third-party integration mechanisms enabling cross-platform tracking without disclosure

The Disclosure Gap

Most significantly, the pilot revealed significant discrepancies between Chrome's stated privacy practices and actual data collection behaviors. This disclosure gap demonstrates permission theater in action: individuals are asked to grant permission based on incomplete or misleading information, then surveillance proceeds regardless of permission choices.

Cross-Jurisdictional Surveillance Laundering

The pilot identified regulatory gaps that allow "surveillance laundering" across different legal frameworks (GDPR, PIPEDA, CCPA). Chrome's architecture exploits jurisdictional differences to maintain surveillance while claiming compliance with regional consent requirements.

This is exactly the pattern the EU Omnibus framework will perpetuate: complex consent mechanisms that create the appearance of compliance while hiding international tracking infrastructure.

Conclusion: From Permission Fatigue Fiction to Genuine Transparency

The failure of consent-based privacy frameworks is not accidental—it reflects deliberate misinformation. What browsers call "consent" is coerced permission-granting through engineered fatigue. This is permission fatigue by design, masquerading as consent to hide international tracking and surveillance.

The Transparency Lab: Chrome TPI-Report provides empirical evidence of this pattern: surveillance architecture that operates regardless of permission choices, disclosure gaps between stated practices and actual behaviour, and exploitation of regulatory differences to launder surveillance across jurisdictions.[1]

The EU Omnibus framework represents sophisticated permission theater, but it remains theater. By focusing on improving consent mechanisms while leaving the underlying opacity intact—and perpetuating the misinformation that coerced permission equals valid consent—it asks individuals to make meaningful choices about systems they cannot see or understand. This is structurally impossible.

Common sense must prevail:

• Consent requires transparency first, not permission fatigue after installation, Advertised as Consent
• No cookie is "necessary" when proper notice infrastructure exists (Its a scam - a 4 year old knows its not a baked treat)
• A Record of Transparency must exist before browser installation, not buried in post-hoc settings, or consent is not valid
• Digital Notice Receipts can easily upgrade and replace cookies with transparent notice so that people control their own information without the surveillance capitalism.

Transparency-by-default offers a different path: making the invisible visible before installation, eliminating permission fatigue by design, replacing cookies with Notice Receipts after transparent disclosure, and creating the conditions for genuine accountability. It addresses the root cause—opacity and misinformation—rather than attempting to manage its symptoms through ever-more-complex permission rituals.

Until browsers embrace transparency-by-default architecture implemented before installation, "consent" will remain a performance that obscures international surveillance rather than preventing it. The choice is clear: we can continue refining permission mechanisms that legitimise opacity and hide surveillance, or we can demand transparency that makes genuine consent possible.

The EU Omnibus framework chooses the former without high risk dependance on third party software security. A truly protective approach requires the latter.

Appendix: Required Transparency-by-Default Steps to Make Browser Consent Fair

According to ISO/IEC 27560-1 Universal Notice Receipt Profile

For consent in a browser to meet Convention 108+ Article 5.2 requirements (freely given, specific, informed, and unambiguous), the following transparency-by-default steps are required:

Pre-Installation Transparency Requirements

1. Controller Identification Before Installation

• Browser vendor must disclose Controller Identification Record (CIR) before download
• CIR must include: legal entity name, jurisdiction, data protection officer contact, purposes of processing, legal bases, retention periods, cross-border transfer destinations
• Disclosure must be in plain language, not buried in terms of service

2. Surveillance Architecture Disclosure

• Complete list of all tracking mechanisms enabled by default (cookies, fingerprinting, telemetry, etc.)
• Network traffic patterns: which domains will receive data by default
• Third-party data sharing relationships and purposes
• Cross-jurisdictional data transfer pathways
• The greater the surveillance risk, the more permissions and notice needed

3. Comparison Transparency

• Standardized comparison format allowing individuals to compare surveillance architectures across browsers, make informed choices, and manage the browser with meaningful consent
• Transparency Performance Indicator score (TPI-R methodology) disclosed before installation

Post-Installation Transparency-by-Default Operation

4. Controller-ID First Architecture

• Before any tracking mechanism contacts a website, browser retrieves Controller Identification Record from /.well-known/notice.txt
• Individual receives notice of what will be tracked BEFORE any data collection begins
• No cookies or tracking mechanisms placed without prior Controller-ID disclosure

5. Digital Notice Receipts Replace Cookies

• After Controller-ID disclosure, Digital Notice Receipt placed on device (not cookie)
• Notice Receipt contains: controller identity, purposes, legal basis, retention period, timestamp, cryptographic signature
• Receipt provides bilateral proof: both controller and individual have synchronized record

6. Notice Event Log

• Browser maintains append-only Notice Event Log of all notice interactions
• Log entries include: timestamp, controller identity, purposes disclosed, action taken (accept/reject/defer), legal basis
• Log exportable and auditable by individual or regulator

7. Real-Time Visibility Without Cognitive Burden

• Browser displays active tracking in real-time: which controllers are collecting data from current page
• No permission request required for visibility—transparency is default
• Individual can inspect full Notice Event Log at any time

8. Eliminating "Necessary Cookie" Fiction

• No tracking mechanism labeled "necessary" without explicit disclosure of what necessity means
• Session management, authentication, security, and load balancing disclosed in Controller Identification Record
• All tracking mechanisms operate through transparent Notice Receipt architecture

Enforcement and Auditability Requirements

9. Verifiable Compliance

• Browser vendor publishes TPI-R assessment results quarterly
• Independent audit mechanism: regulators can inspect actual network traffic against stated Controller Identification Records
• Discrepancies between stated practice (CIR) and actual behavior (network traffic) constitute violation

10. Accountability Architecture

• When individual objects to processing, browser must honor objection immediately (no "processing until objection resolved" pattern)
• When individual withdraws consent, all processing must terminate immediately and Notice Event Log must record termination
• Cross-border transfers must honor most protective jurisdiction's requirements

11. Regulatory Access to Notice Event Logs

• With individual authorization or lawful warrant, regulators can access Notice Event Logs to verify compliance
• Logs provide audit trail showing: what notice was provided, when, by whom, what action individual took
• This enables enforcement at scale—regulators don't need to reverse-engineer surveillance, they inspect logs

12. Break-the-Glass for Lawful Access

• Any lawful access request (warrant, emergency disclosure, etc.) generates Notice Receipt Warrant Token
• Token disclosed to individual (unless lawful prohibition) showing: authority requesting, legal basis, scope, duration
• Front-door access with bilateral audit trail, not backdoor surveillance

Implementation Notes

These twelve requirements represent the minimum transparency-by-default architecture necessary to make browser consent fair according to ISO/IEC 27560-1 Universal notice receipt profile for implementing Convention 108+, Council of Europe Treaty. Convention 108 (the previous version) is already adopted by 55 countries + (regional jurisdictions like provinces and states that are common law founded.) Convention 108+ is already ratified (by implementing nationally enforceable privacy law in 33 countries, with 38 countries required for it to become internationally enforceable.)

Key principle: Transparency must exist BEFORE permission is requested. Current consent frameworks invert this: permission first, opacity forever. Controller-ID first architecture corrects the sequence.

Technical feasibility: All twelve requirements are technically straightforward using existing web standards (/.well-known/ URIs, cryptographic signatures, append-only logs). The resistance to implementation reveals that current "consent" frameworks are designed to hide surveillance, not enable transparency.

Regulatory enforcement: Notice Event Logs enable enforcement at scale. Instead of investigating each complaint individually, regulators can audit logs across thousands of interactions to identify systematic non-compliance patterns.

The Chrome TPI-Report demonstrates what happens without these requirements: permission fatigue by design, disclosure gaps, cross-jurisdictional surveillance laundering, and tracking that proceeds regardless of permission choices.[1]

References

[1] Digital Transparency Lab (2025). DTL-TPI-RR Pilot on Google Chrome: Transparency Performance Indicator - Record and Reporting Assessment. Transparency Lab Technical Report. Available: [0PN-Access Reference]

Standards and Regulatory Framework

ISO/IEC 27560-1 (in development). Privacy technologies — Consent record information structure — Part 1: Core.ISO/IEC JTC 1/SC 27.

Council of Europe Convention 108+ (2018). Convention for the Protection of Individuals with regard to the Processing of Personal Data. Modernized version, Article 5.2 (Consent requirements), Article 8 (Transparency and information).

Regulation (EU) 2016/679 (GDPR). General Data Protection Regulation. Articles 4(11), 7, 13-14 (consent and transparency requirements).

IETF Draft: Well-Known URI for Controller Transparency Records. Transparency Lab contribution to IETF standardization process (in development).

Kantara Initiative Standards Development

Kantara Initiative ANCR Work Group (2025). Transparency Performance Indicators: Kantara Recommended Report.Kantara Initiative. [Establishes TPI-R assessment methodology for quantifying transparency compliance]

Kantara Initiative Consent and Information Sharing Work Group (2010-2020). Foundational research on consent receipt architecture, notice infrastructure, and transparency-by-default principles. Includes development of PII Controller Notice Identification Record specification. [15-year research foundation for current standards work]

Technical Architecture References

Controller Identification Record (CIR) — Standardized disclosure format for data controller identity, purposes, legal bases, and retention periods. Retrievable from /.well-known/notice.txt before data collection begins. Developed through Kantara Initiative ANCR WG, building on the PII Controller Notice Identification Record specification from CISWG.

PII Controller Notice Identification Record — Foundational specification from Kantara Initiative CISWG defining standardized format for controller identification and notice disclosure. Evolved into the Controller Identification Record (CIR) used in ISO/IEC 27560-1 Universal Notice Receipt Profile.

Digital Notice Receipt — Bilateral proof-of-notice provided to both controller and individual, with synchronized records containing controller identity, purposes, legal basis, retention period, timestamp, and cryptographic signature. Evolution of Consent Receipt specification from Kantara Initiative CISWG.

Notice Event Log — Append-only audit log of all notice interactions, enabling regulatory enforcement at scale by providing verifiable record of: what notice was provided, when, by whom, what action individual took.

Transparency Performance Indicator (TPI-R) — Assessment methodology for quantifying transparency compliance, used in Chrome pilot to document disclosure gaps and surveillance architecture. Specified in Kantara Recommended Report (2025).

Related Work on Surveillance Architecture

Zuboff, S. (2019). The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power.PublicAffairs. [Context: Surveillance capitalism business model analysis]

Ryan, J. (2018-2024). Various reports on real-time bidding and advertising surveillance architecture. [Context: "Impossible to know" defense documentation]

Utz, C., Degeling, M., Fahl, S., Schaub, F., & Holz, T. (2019). (Un)informed Consent: Studying GDPR Consent Notices in the Field. ACM CCS 2019. [Context: Consent dark patterns empirical evidence]

About the Author

Mark Lizar serves as ISO/IEC 27560-1 Profile Editor, leading development of the Universal Notice Receipt Profile for the Minimum Viable Consent Receipt (MVCR) and Anchored Notice and Consent Receipt (ANCR) Digital Privacy information record exchange profile. As Executive Director of Digital Transparency Lab, he works with international regulators and standards bodies on digital transparency infrastructure for enforcement at scale.

Research Background: This work builds on 15 years of transparency standards research and development at the Kantara Initiative, originating in the Consent and Information Sharing Work Group (CISWG) and now continuing in the Anchored Notice and Consent Receipt Work Group (ANCR WG). The ANCR WG recently released the Kantara Recommended Report on Transparency Performance Indicators, establishing the TPI-R methodology referenced in this paper.

About the Open Public Network (0PN)

The Open Public Network (0pn.org) supports digital public transparency infrastructure enabling regulatory enforcement at scale. 0PN provides standards-based transparency architecture through:

• Controller Identification Records at /.well-known/notice.txt
• Digital Notice Receipts replacing surveillance-by-default cookies
• Notice Event Logs for bilateral audit trails
• Transparency Performance Indicators for compliance measurement

0PN operates as regulatory capacity infrastructure, providing the missing transparency layer between Convention 108+ legal requirements and technical implementation.

Recommended Citation

Lizar, M. (2026). EU Omnibus - Permission Fatigue by Design Masquerading as Consent. Transparency Lab White Paper. Available: 0pn.org

Document Status

Version: 1.0

Status: Submitted to European Data Protection Authorities

Publication: Posted at 0pn.org and available for public comment

License: Creative Commons Attribution 4.0 International (CC BY 4.0)

Feedback: Comments and technical feedback welcome at [email protected]