Conditional Consent

A User-Centric and Privacy-First Approach to Cookies and Information Stored on End-User Devices

A concept by TechGDPR | Silvan Jongerius conditionalconsent.com

Executive Summary

Cookie consent is broken. The current system of per-site consent banners has produced one of the most universally disliked features of the modern internet: an endless stream of pop-ups that most users dismiss without reading. Europeans collectively spend an estimated 575 million hours per year interacting with cookie banners — the equivalent of 287,500 full-time employees doing nothing but clicking consent prompts (Legiscope, 2024). Research shows that the majority of users simply click “Accept All” to make the banner disappear — with acceptance rates varying from around 25% on privacy-friendly designs to over 80% on banners using dark patterns, which 72% of banners do (Advance Metrics Cookie Behaviour Study, 2023; Secure Privacy, 2025).

This is not informed consent. It is consent theatre.

The European Commission has acknowledged this failure. In its Digital Omnibus proposal of November 2025, it introduces Articles 88a and 88b to the GDPR, moving cookie governance from the ePrivacy Directive into the GDPR framework and — critically — requiring that consent be expressible through automated, machine-readable signals that controllers must respect (European Commission, Digital Package, 2025).

Conditional Consent is a concept that builds on this legislative foundation. It proposes that consent should not be a binary, site-by-site decision, but a conditional one: users define rules that express their preferences across dimensions of website categories, cookie purposes, and even specific third-party processors. These rules are configured once, applied everywhere, and communicated to websites through the standardised signalling mechanisms that Article 88b mandates.

This paper outlines the concept, its principles, its legal basis, and a proposed technical implementation.

The Problem

Consent Fatigue Is Not a Side Effect — It Is the System

The cookie consent mechanism, originally introduced by the ePrivacy Directive (2002/58/EC, amended 2009), was designed to give users control over what data is collected on their devices. In practice, it has achieved the opposite. The system suffers from three fundamental failures:

1. Volume overwhelms choice. The average European internet user encounters over 1,000 cookie banners per year (CookieScript, 2025). When confronted with this volume, users do not make informed decisions — they develop automated responses. Research shows that fewer than 25% of users in Germany and France accept cookies when given a genuine choice, yet acceptance rates are dramatically higher when dark patterns steer users toward “Accept All” (CookieYes, 2026).

2. Consent is not implemented honestly. An analysis of over 35,000 European websites found that 49% were in violation of consent requirements. A broader international study of 254,148 websites across 31 countries showed that only 15% of cookie banners met minimum legal requirements. Over 50% of websites set cookies before users had made any choice at all (Ignite Video, compilation of 26 studies). Even after users revoke consent, 57.5% of websites continue to maintain advertising and analytics cookies.

3. The per-site model is structurally flawed. Asking users to make individual, context-free decisions on every website they visit is a design that cannot scale. A user visiting 100 websites per month would need to evaluate potentially hundreds of cookie categories across those sites — a cognitive task no one performs. The result is the very opposite of what the regulation intended: users consent to everything, or nothing, without understanding either choice.

The Cost Is Not Only to Privacy

The European Commission’s staff working document accompanying the Digital Omnibus estimates that people in the EU spend approximately 334 million hours on cookie banners per year, resulting in approximately €11.2 billion in lost labour costs annually (IAPP, 2025). Independent analysis suggests the true figure may be higher, at 575 million hours and €14.4 billion when accounting for broader productivity impacts (Legiscope, 2024). For businesses, the cost of implementing and maintaining cookie banners is estimated at around €1,200 per website every three years, with some analyses putting compliance costs for small sites at over €10,000 annually.

The Legislative Opportunity: Article 88b

The Digital Omnibus proposal, published on 19 November 2025, introduces a new Article 88b to the GDPR titled “Automated and machine-readable indications of data subject’s choices with respect to processing of personal data in the terminal equipment of natural persons.”

The article establishes the following framework:

1. Controllers must allow automated consent and refusal. Online interfaces must enable data subjects to give or refuse consent, and to exercise the right to object under Article 21(2), through automated and machine-readable means (Article 88b(1)).

2. Controllers must respect these signals. Once expressed, the choices communicated through these signals must be honoured by controllers (Article 88b(2)).

3. European standardisation bodies will define the signal format. The Commission will request European standardisation organisations to draft standards for interpreting machine-readable preference signals. Conformity with these harmonised standards creates a presumption of compliance (Article 88b(4)–(5)).

4. Browser providers must enable preference signalling. Providers of web browsers (excluding SMEs) must provide the technical means for users to give or refuse consent through these automated mechanisms (Article 88b(6)).

5. Staged implementation. The obligations on controllers apply 24 months after entry into force. The obligations on browser providers apply 48 months after entry into force (Article 88b(5) and (7)).

The Media Service Provider Exception

Article 88b(3) exempts controllers that are “media service providers when providing a media service” from the obligation to accept automated signals. The stated justification is that independent media organisations depend on advertising revenue for their financial sustainability, and that a free press is essential to democratic pluralism (Iubenda, 2025).

This exception raises significant questions. If the goal of Article 88b is to give users genuine control over their consent preferences, carving out an exception for an entire category of controllers — and arguably the category where tracking is most pervasive — undermines the framework’s integrity. In practice, this means a user who has set a global preference to reject tracking cookies may still be confronted with traditional consent banners on every news website they visit (Ailance/2B Advice, 2025).

As the Osborne Clarke analysis notes, the exemption “merely disapplies paragraphs 1 and 2 […] What it does not do is establish an explicit legal basis for processing.” The legal robustness of this carve-out remains uncertain (Osborne Clarke, 2025).

The question must be asked: does protecting a media business model justify overriding an individual’s explicitly stated privacy preferences? TechGDPR maintains that user consent should be respected regardless of the controller’s sector. Alternative funding models — subscriptions, micropayments, contextual advertising — exist and can sustain quality journalism without requiring the surveillance of readers. The legislative process should scrutinise this exception carefully.

The Concept: Conditional Consent

From Binary to Conditional

Today, consent is binary: accept or reject, per website, per visit. Conditional Consent proposes a fundamentally different model: users define rules that express their consent as conditions, which are then automatically applied across all websites.

A condition combines three dimensions:

A user might express preferences such as:

• “Allow functional cookies on all websites.”
• “Allow analytics cookies on e-commerce sites, but only if processed by a first-party provider.”
• “Deny all advertising and tracking cookies on all websites.”
• “Allow personalisation cookies on streaming platforms.”
• “Deny any processing that involves Meta or Google as a third-party processor.”

This is a level of granularity that no current consent mechanism supports — yet it reflects how users actually think about their privacy when given the opportunity to express preferences beyond “accept” or “reject.”

Core Principles

1. Consent Must Be Conditional

Users should be able to specify clear conditions based on which consent may be granted or withheld. This includes conditions based on the purpose of processing, the category of the requesting website, and — critically — the identity of third-party processors involved. The ability to withhold consent specifically for processing that involves named data processors (e.g., “no processing via Google or Meta”) places meaningful control in the user’s hands.

2. Consent Must Be Understandable

The current consent landscape is defined by dense legal text, confusing toggle interfaces, and deliberately misleading design. Conditional Consent requires that the configuration process be guided, conversational, and bias-free. When new consent is requested for an undefined category or purpose, the user should receive a clear, plain-language explanation of what they are consenting to and why — not a wall of legalese.

3. The User Must Have Full Control

The user determines what they consent to, for how long, for what purpose, and for which categories of websites this applies. Consent duration should be configurable: a user may choose to allow analytics cookies on shopping sites for 30 days, while granting indefinite consent for functional cookies on government portals. The user may revoke any consent at any time, and this revocation must propagate automatically.

4. Decision-Making Must Be Unbiased

A high degree of control necessarily requires configuration effort. To make this accessible, an unbiased conversational interface (chatbot) should guide users through their initial setup and assist in subsequent decisions. This chatbot must be designed to serve the user’s privacy interests, not to maximise consent rates. Unlike current Consent Management Platforms (CMPs) — which are typically commissioned and paid for by the websites that benefit from high consent rates — this interface must be structurally independent from any party that benefits from the user’s consent.

5. Configuration Must Be Portable

A user’s consent configuration should be exportable, importable, and shareable. Users should not be required to repeat their configuration across devices. Privacy organisations, consumer advocacy groups, or trusted experts could publish recommended configurations that users can adopt as a starting point and customise.

6. Re-Prompting Must Be Controlled

Once a user has expressed a preference — whether consent or refusal — this preference must be respected. Repeated prompting is a tactic used to wear down refusal, and it should be treated as what it is: a form of coercion. Article 88a(4)(c) already proposes a minimum six-month cooling-off period after refusal. Conditional Consent aligns with this and extends the principle: if a preference has been expressed, it applies until the user changes it.

Comparison with Existing Approaches

Several tools and standards have attempted to address consent fatigue. Conditional Consent builds on their contributions — particularly Global Privacy Control, the most successful browser privacy signal to date — while addressing remaining gaps in granularity and conditionality.

Key Differences

Do Not Track (DNT) was a W3C-proposed HTTP header that communicated a binary tracking preference. It failed because compliance was voluntary, and the advertising industry chose not to honour it. It was formally deprecated as a W3C standard. However, in November 2023, the Berlin Regional Court ruled that DNT signals constitute a valid objection under GDPR Article 21(5), giving browser signals unexpected new legal weight in Europe.

Global Privacy Control (GPC) is the most successful browser privacy signal currently deployed and the foundation on which Conditional Consent builds. Developed by a coalition including the EFF, Mozilla, DuckDuckGo, Brave, The New York Times, and The Washington Post, GPC transmits a single HTTP header (Sec-GPC: 1) and DOM property signalling a “do not sell or share” preference.

GPC has achieved what DNT could not: real legal enforcement. It is mandated under the CCPA in California, and as of January 2026, twelve US states require businesses to honour it. Enforcement is active — Sephora was fined $1.2M (2022) and Tractor Supply $1.3M (2025) for ignoring GPC signals. California’s Opt Me Out Act (signed October 2025) will require all browsers — including Chrome, Safari, and Edge — to support GPC by January 2027. In Europe, the Berlin court ruling on DNT signals under GDPR Article 21(5) extends logically to GPC.

GPC proves that browser-level privacy signalling works — technically, legally, and in terms of adoption (50+ million users). Conditional Consent does not seek to replace GPC. Rather, it proposes the next step: from binary opt-out to conditional consent. GPC can express “do not sell my data.” It cannot express “allow analytics on shopping sites, deny advertising everywhere, block any processing involving Meta.” Article 88b requires a signal that can carry affirmative consent as well as rejection, with granularity that GPC was not designed to provide.

Compatibility: A Conditional Consent implementation should send Sec-GPC: 1 alongside its own conditional headers whenever a user’s rules amount to a general opt-out, ensuring backward compatibility with existing GPC-supporting websites. The conditional signal layer extends GPC rather than competing with it.

Consenter is a consent management service developed by Law & Innovation Technology GmbH (Berlin), recognised by the BfDI (Germany’s federal data protection authority) as the first approved consent management service under §26 TDDDG in November 2025. It is backed by over 10 years of interdisciplinary research at the Einstein Center Digital Future and the Alexander von Humboldt Institut für Internet und Gesellschaft, with funding from the German Federal Ministry for Research, Technology, and Space.

Consenter operates as a closed ecosystem: its browser agent communicates with its own proprietary Consent Banner, which website operators must install. On websites that have not installed the Consenter Banner, the agent does not function. This is a deliberate architectural choice driven by a legal constraint — §26 TDDDG’s implementing ordinance (EinwV) makes adoption voluntary for website operators, and existing CMPs do not implement the Consenter protocol. The system therefore depends on building a two-sided network of users and participating websites.

Conditional Consent differs in two key respects. First, it is designed to work on existing websites from day one through automated CMP interaction (similar to Consent-O-Matic), requiring no cooperation from website operators. Second, it proposes an open HTTP header protocol as direct input to the Article 88b standardisation process, designed for adoption by any browser, CMP, or consent agent — including Consenter. These approaches are complementary: Consenter has institutional credibility and regulatory recognition; Conditional Consent offers a rule model and signalling protocol that could strengthen any consent agent’s capabilities.

Consent-O-Matic is an open-source browser extension developed by Aarhus University that automatically interacts with Consent Management Platform (CMP) pop-ups based on five predefined preference categories. It is effective as an adversarial workaround (Nouwens et al., CHI 2022), but it operates by clicking through existing banners rather than signalling preferences in advance. It has no concept of website categories or third-party processor conditions.

IAB Transparency and Consent Framework (TCF) is an industry-developed standard that encodes consent as a structured string (TC String) against a taxonomy of purposes and a global vendor list. While technically sophisticated, it is fundamentally an industry tool: the interface is controlled by the website through its CMP, and the framework is designed to facilitate advertising consent, not to empower user choice.

Conditional Consent builds on the proven foundation of GPC’s browser-level signalling, extends it with the three-dimensional consent model (purpose × site category × processor), and places configuration entirely in the user’s hands. It combines forward-looking HTTP header signalling (designed for the Article 88b standard) with backward-compatible CMP automation (for immediate utility on existing websites). It is not a workaround, an industry framework, or a competing product — it is a proposed specification for what the Article 88b standard should support, designed from the user’s perspective.

Importantly, Conditional Consent is a concept and open specification, not a product. Existing tools — including GPC, Consenter, Consent-O-Matic, browser-native implementations, and even CMPs — could adopt the conditional model. The goal is to establish the right principles for the Article 88b implementation standard, not to replace what already works.

Proposed Technical Implementation

The following section outlines a proposed Minimum Viable Product (MVP) for a browser extension that demonstrates the Conditional Consent concept. This is intended as a proof-of-concept and a basis for discussion, not as a final technical specification.

Architecture Overview

The MVP consists of four core components:

1. Preference Engine — stores and evaluates the user’s conditional consent rules
2. Chatbot Onboarding Interface — guides users through initial configuration
3. Signal Dispatcher — communicates preferences to websites via HTTP headers and/or CMP interaction
4. Statistics Dashboard — tracks consent decisions and their outcomes

Website Category Taxonomy

Websites are classified into a nested taxonomy that users can navigate at their preferred level of granularity. A user may set preferences at the top level (“deny tracking on all media sites”) or at a specific subcategory level (“allow analytics on technology news sites”). The taxonomy is designed to be community-extensible.

Proposed taxonomy (illustrative excerpt):

The taxonomy is a nested tree. Users can set preferences at any level — from a broad top-level category down to a specific website — and override inherited preferences at any level below. This means a user who denies tracking cookies for all “Media & News” sites can still allow them specifically for a trusted individual publication, without reconfiguring the entire category.

📁 Media & News                              [deny tracking] ← user sets at category level
├── 📁 News Outlets
│   ├── CNN (cnn.com)
│   ├── BBC (bbc.com)                        [allow analytics] ← override at site level
│   ├── Reuters (reuters.com)
│   └── Al Jazeera (aljazeera.com)
├── 📁 Magazines
│   ├── The Economist (economist.com)
│   ├── Wired (wired.com)
│   └── National Geographic (nationalgeographic.com)
└── 📁 Entertainment News
    ├── Variety (variety.com)
    └── Deadline (deadline.com)

📁 E-Commerce & Retail                       [allow functional]
├── 📁 Marketplaces
│   ├── Amazon (amazon.com)                  [deny all third-party] ← override
│   ├── eBay (ebay.com)
│   └── Etsy (etsy.com)
├── 📁 Brand Stores
├── 📁 Comparison Shopping
└── 📁 Auction & Second-Hand

📁 Finance & Banking                         [deny all non-essential]
├── 📁 Banks & Building Societies
├── 📁 Investment Platforms
├── 📁 Insurance
└── 📁 Cryptocurrency

📁 Government & Public Services              [allow functional only]
├── 📁 National Government
├── 📁 Local Government
├── 📁 International Bodies
└── 📁 Public Health

📁 Healthcare                                [deny all non-essential]
├── 📁 Hospitals & Clinics
├── 📁 Health Information
├── 📁 Telehealth
└── 📁 Pharmacies

📁 Technology
├── 📁 Software Development
│   ├── GitHub (github.com)
│   ├── GitLab (gitlab.com)
│   └── Stack Overflow (stackoverflow.com)
├── 📁 Tech News & Analysis
├── 📁 Hardware & Components
└── 📁 SaaS Tools & Services

📁 Education
├── 📁 Universities & Research
├── 📁 Online Learning Platforms
└── 📁 Libraries & Archives

📁 Entertainment
├── 📁 Video Streaming
├── 📁 Music Streaming
├── 📁 Gaming Platforms
└── 📁 Live Events & Tickets

📁 Travel & Transport
├── 📁 Hotels & Accommodation
├── 📁 Flights & Booking
├── 📁 Travel Guides & Reviews
└── 📁 Ride-Sharing & Transport

📁 Social Media & Communication
├── 📁 Social Networks
├── 📁 Messaging & Email
├── 📁 Forums & Communities
└── 📁 Professional Networks

📁 Service Providers
├── 📁 Cloud & Infrastructure
├── 📁 Payment & FinTech
└── 📁 Internet Service Providers

Inheritance and override logic: Preferences cascade downward. A rule set at the “Media & News” level applies to all subcategories and sites within it unless explicitly overridden. A user who wants maximum simplicity can set preferences at only the top-level categories. A user who wants fine-grained control can override at any depth, including for individual domains. This hierarchy ensures that users are never forced to configure preferences site-by-site, but always can if they choose to.

Website Classification: The Categorisation Challenge

Maintaining an accurate, up-to-date database of website classifications is a non-trivial challenge and a legitimate concern for the concept’s feasibility. Several complementary approaches can address this:

• Curated base lists. Existing domain categorisation databases (used by content filtering services, parental controls, and enterprise security tools) provide a foundation covering millions of domains.
• Large language model classification. For websites not present in curated lists, modern language models can classify a domain with high accuracy based on its content, metadata, and structural features. This can be performed locally within the browser extension or via a privacy-preserving API, and presented to the user for confirmation.
• Community contributions. An open, community-maintained classification database — similar to how ad-blocking filter lists (e.g., EasyList) or Consent-O-Matic’s CMP rules are maintained — allows users and contributors to add, correct, and refine categorisations.
• User confirmation. When a website cannot be confidently classified, the user is prompted through the chatbot interface: “This site looks like a tech news site. Does that sound right?” The user’s response refines both their local configuration and, if they opt in, the shared database.

No single approach is sufficient. The combination of curated data, automated classification, and community governance offers the most robust path — and the governance model for this database is itself an important area for public discussion (see Open Questions).

Cookie Purpose Taxonomy

Cookie purposes are classified according to an established taxonomy aligned with common CMP categories and the IAB TCF purpose definitions:

Chatbot Onboarding

Rather than presenting users with a complex matrix of toggles, Conditional Consent uses a conversational interface to guide initial configuration. The chatbot asks simple, contextual questions and translates the answers into conditional rules.

Example onboarding dialogue:

🤖 “Let’s set up your cookie preferences. I’ll ask a few questions to understand what matters to you. You can always change these later.”

🤖 “Do you shop online?” 👤 “Yes, regularly.”

🤖 “Would you like shopping sites to remember your cart and preferences between visits?” 👤 “Yes.”

🤖 “How about letting those sites track your browsing to show you personalised ads?” 👤 “No.”

🤖 “Got it. I’ll allow functional cookies on e-commerce sites but block advertising cookies. What about analytics — are you comfortable with shopping sites measuring how you use their site to improve it?” 👤 “Only if they do it themselves, not through Google Analytics or similar.”

🤖 “Understood. I’ll allow first-party analytics on e-commerce sites but block third-party analytics providers. Let’s move on to news and media sites…”

This approach makes the configuration accessible to non-technical users while still producing granular, conditional rules. The chatbot interface can also be used when encountering a new, uncategorised website: rather than displaying a traditional consent banner, the user receives a brief conversational prompt explaining what the site is requesting and why, with a recommendation based on their existing preferences for similar sites.

Signal Dispatch: A Dual-Track Approach

The MVP must operate in a transitional period where Article 88b’s standardised signalling mechanisms do not yet exist. It therefore employs two parallel approaches:

Track 1: Proactive HTTP Header Signalling The extension injects custom HTTP headers into outgoing requests that communicate the user’s conditional preferences in a structured format. This anticipates the standardised signals that Article 88b(4) will define.

A proposed header structure:

Consent-Preference: purpose=analytics; site-category=ecommerce; decision=allow; condition=first-party-only
Consent-Preference: purpose=advertising; site-category=*; decision=deny
Consent-Preference: purpose=functional; site-category=*; decision=allow

This header-based approach can be adopted by willing controllers today, ahead of any formal standard. It serves as a practical reference implementation for the European standardisation process.

Track 2: Automated CMP Interaction For websites that do not (yet) respect header-based signals, the extension falls back to automated interaction with existing Consent Management Platform interfaces — similar to Consent-O-Matic’s approach, but with conditional logic applied. The extension identifies the CMP in use, maps its categories to the Conditional Consent taxonomy, and applies the user’s rules to toggle the appropriate preferences before submitting.

Statistics and Transparency Dashboard

The extension maintains a local dashboard that provides the user with visibility into their consent activity:

• Total cookies allowed/denied across all sites visited
• Breakdown by purpose (how many advertising cookies denied, how many functional cookies allowed, etc.)
• Breakdown by website category
• Sites where automated enforcement was not possible (manual intervention required)
• Projected impact — for cases where preferences could not be enforced automatically, the dashboard shows a simulated count of cookies that would have been accepted or denied, giving users a sense of their exposure

Smart Suggestions for Unknown Sites

When a user visits a website for which no specific preference exists, the extension uses the following logic:

1. Check category match. If the site can be classified into a known category, apply the user’s rules for that category.
2. Check similar sites. If the user has made explicit decisions for similar sites (same category, similar cookie profiles), suggest the same decision.
3. Apply default. If no match is found, apply the user’s global default (which is set during onboarding).
4. Prompt if ambiguous. If the site’s cookie profile is unusual for its category, or if the user has no applicable rule, prompt the user through the chatbot interface — not through a traditional banner.

Implementation Timeline and Relationship to Article 88b

The Article 88b obligations follow a staged timeline:

This timeline creates a window of opportunity. The standards that will define how machine-readable consent signals work have not yet been drafted. By developing and testing a reference implementation now, the Conditional Consent concept can inform and shape those standards — ensuring they are designed to serve user privacy rather than industry convenience.

Open Questions and Areas for Discussion

This concept is presented as a starting point, not a finished specification. Several important questions require further debate:

1. Who maintains the website category database? A centralised, curated database risks becoming a point of control. A community-maintained, open-source approach — similar to content filtering lists — may be more appropriate. How should disputes about categorisation be resolved?

2. How should the chatbot avoid introducing its own bias? The onboarding chatbot must not nudge users toward accepting or rejecting cookies. Its language, question framing, and default suggestions must be designed and audited for neutrality. Should this be subject to independent oversight?

3. Can conditional preferences be expressed in the standardised signal format? The Article 88b standards have not yet been drafted. GPC demonstrates that a single HTTP header can achieve legal recognition and broad adoption, but its binary format cannot express conditional rules. The Article 88b standard must support richer signalling — including affirmative consent, purpose-level granularity, and processor conditions — while remaining backward-compatible with GPC’s established Sec-GPC: 1 header. Engagement with the standardisation process is essential to ensure the standard can accommodate conditional logic without fragmenting the existing signalling ecosystem.

4. How should the media service provider exception be handled? If Article 88b(3) survives the legislative process in its current form, media sites may ignore browser signals. Should the extension force-interact with media site CMPs regardless? Should it warn the user that their preferences are being overridden?

5. What role should privacy organisations play? The concept of shareable, recommended configurations could be powerful — but it requires trusted organisations to publish and maintain them. What governance model ensures these recommendations remain unbiased?

6. How does this interact with legitimate interest? Article 88a preserves legitimate interest as a potential legal basis for some processing. Conditional Consent focuses on consent-based processing. How should the extension handle cases where a controller claims legitimate interest for processing that the user has conditionally refused?

7. What governance model should oversee the website categorisation database? A centralised database creates a point of control; a fully decentralised model risks inconsistency. What is the right balance, and who should arbitrate disputes about how a website is classified?

These are not rhetorical questions. They require answers from a community broader than any single organisation. If you have expertise, opinions, or concerns on any of these points, see the next section.

Get Involved

Conditional Consent is a proposal — not a finished specification. Its strength depends on scrutiny, debate, and diverse input. The standards that will govern how Article 88b is implemented have not yet been written. Now is the time to shape them.

If you believe that consent should serve users, not advertisers, we invite you to act:

Voice your support. If the principles outlined in this paper resonate with you — whether you are a privacy professional, a developer, a policymaker, a researcher, or simply someone frustrated with cookie banners — let us know. Public support signals to legislators and standardisation bodies that there is demand for a genuinely user-centric implementation.

Challenge and improve this concept. We have published this paper precisely because we do not have all the answers. The open questions section above identifies real design problems that require expertise from multiple disciplines: law, human-computer interaction, browser engineering, standardisation policy, and consumer advocacy. If you see a flaw, a gap, or a better approach — we want to hear it.

Collaborate on implementation. The proposed MVP is a starting point. If you are a developer, a browser vendor, a CMP provider, or a standards body representative interested in building or piloting a reference implementation, we welcome collaboration.

Engage in the legislative process. The Digital Omnibus proposal is entering the trilogue negotiation phase. The final text of Article 88b — including the scope of the media service provider exception, the granularity of the signal standard, and the obligations on browser providers — will be shaped by the input that legislators receive. If you represent a consumer organisation, a data protection authority, or a civil society group, your input during this process matters.

📧 Contact: conditionalconsent@techgdpr.com 🌐 Website: conditionalconsent.com

About TechGDPR

TechGDPR is a privacy consultancy specialising in helping technology companies achieve and maintain GDPR compliance, with a particular focus on companies expanding into the European market. The Conditional Consent concept draws on TechGDPR’s practical experience with consent implementation, data protection impact assessments, and the operational realities of privacy compliance.

This concept is published to advance a privacy-respecting implementation of Article 88b, to invite scrutiny and collaboration from privacy advocates, technologists, policymakers, and standardisation bodies, and to ensure that the technical standards that will govern consent signalling are designed to serve individuals — not the advertising industry.

Author: Silvan Jongerius, TechGDPR Contact: conditionalconsent@techgdpr.com Website: conditionalconsent.com

References and Sources

• European Commission, “Digital Package — Questions and Answers,” November 2025. digital-strategy.ec.europa.eu
• European Commission, Staff Working Document SWD(2025)836. eur-lex.europa.eu
• IAPP, “EU Digital Omnibus: Analysis of Key Changes,” 2025. iapp.org
• Taylor Wessing, “The Digital Omnibus: Cookies, Consent and Digital Advertising,” 2026. taylorwessing.com
• Osborne Clarke, “Digital Omnibus Reshapes EU Cookie Rules but Leaves Banner Fatigue Largely Intact,” December 2025. osborneclarke.com
• Kennedys Law, “The 2025 European Commission EU Digital Omnibus Package: The GDPR,” 2026. kennedyslaw.com
• Kennedys Law, “The 2025 European Commission EU Digital Omnibus Package: The e-Privacy Directive,” 2026. kennedyslaw.com
• White & Case, “EU Digital Omnibus: What Changes Lie Ahead for the Data Act, GDPR and AI Act,” 2025. whitecase.com
• White & Case, “GDPR Under Revision: Key Takeaways from the Digital Omnibus Regulation Proposal,” 2025. whitecase.com
• Iubenda, “Understanding the Digital Omnibus Regulation Proposal,” 2025. iubenda.com
• 2B Advice / Ailance, “GDPR Reform: These Are the Planned Changes to Cookie Banners,” November 2025. 2b-advice.com
• Gibson Dunn, “EU Digital Omnibus Package — A First Look at the Commission’s Draft Proposals,” December 2025. gibsondunn.com
• McDermott Will & Emery, “EU Proposes Sweeping Reforms to the GDPR, Cookie Rules, Data Act, and Breach Reporting,” November 2025. mwe.com
• Legiscope, “Europeans Spend 575 Million Hours Clicking Cookie Banners Every Year,” 2024. legiscope.com
• CookieScript, “Consent Fatigue Is Real: Strategies to Improve User Experience,” 2025. cookie-script.com
• CookieYes, “Cookie Consent Trends by Country: 2026 Global Compliance Guide,” January 2026. cookieyes.com
• Captain Compliance, “The EU’s Cookie Consent Saga,” October 2025. captaincompliance.com
• Ignite Video, “26 Studies on Cookie Banners, Consent Rates, Compliance,” 2025. ignite.video
• Nouwens, M. et al., “Consent-O-Matic: Automatically Answering Consent Pop-ups Using Adversarial Interoperability,” CHI Conference 2022. dl.acm.org
• Consent-O-Matic, Aarhus University CAVI. github.com/cavi-au/Consent-O-Matic

This document is published under CC BY 4.0 and is intended for public discussion and contribution. You are free to share and adapt this work, provided you give appropriate credit to TechGDPR. Version 1.0 — February 2026.