The Digital Omnibus proposal, published in November 2025, introduces Article 88b to the GDPR. For the first time, EU law will require websites to accept automated, machine-readable consent signals from browsers. Users would set their preferences once, their browser would communicate those preferences to every site they visit, and controllers would be legally obliged to respect them. No more banners. No more clicking. No more dark patterns.

But here is the catch: the standards for how these signals should work have not been written yet. Article 88b delegates the technical specification to implementing acts and standardisation bodies. The decisions made in that process — what signals can express, who controls the interface, how much granularity users get — will shape consent for a generation of internet users.

That is why we published Conditional Consent: an open concept paper and technical specification proposing what Article 88b signalling should look like, designed from the user’s perspective.

The core idea: consent as conditions, not clicks

Today, consent is binary. Accept or reject, site by site, visit by visit. Conditional Consent proposes that users define rules across three dimensions:

• Cookie purpose: functional, analytics, advertising, social media, personalisation
• Website category: e-commerce, news, government, banking, healthcare
• Third-party processor: first-party only, exclude specific companies, allow named providers

A user might say: “Allow functional cookies everywhere. Allow analytics on shopping sites, first-party only. Deny all advertising cookies. Block any processing involving Meta.”

This level of granularity does not exist in any consent tool today. Current Consent Management Platforms offer purpose toggles at best. Global Privacy Control — the most successful browser privacy signal, now mandated in twelve US states — can only express a binary “do not sell.” The Advanced Data Protection Control specification developed by noyb and the Vienna University of Economics and Business came closest to what we propose, supporting granular purpose-based HTTP header signalling, but never achieved real-world adoption and lacks the website category and processor dimensions.

Conditional Consent builds on all of these. It proposes an open HTTP header protocol for Article 88b signalling, combined with automated CMP interaction as a fallback — so it works on existing websites from day one, without requiring website operators to change anything.

What we published

The concept paper sets out the problem, the legal basis in Article 88b, six core principles for user-centric consent signalling, a detailed comparison with existing tools (GPC, ADPC, Consenter, Consent-O-Matic, IAB TCF), and a proposed architecture for a browser extension MVP.

The technical specification (pending) goes deeper: browser extension architecture, a preference engine for evaluating conditional rules, an HTTP header protocol, a CMP automation layer, chatbot-guided onboarding, and a compatibility analysis with every relevant existing standard.

These are (or will be) published under CC BY 4.0 at conditionalconsent.com. They are designed to be forked, extended, critiqued, and adopted by anyone — browser vendors, CMP providers, privacy advocates, standardisation bodies.

Why now

Article 88b has a staged timeline. Controllers must accept automated signals within 24 months of entry into force. Browser providers must enable signalling within 48 months. But the implementing standards — the technical specifications that define what those signals can actually carry — need to be developed now. Once a standard is set, it will be extremely difficult to change.

The risk is that the advertising industry shapes these standards toward the simplest possible signal — a binary accept/reject that perpetuates the current model in machine-readable form. The opportunity is to establish that the standard should support genuine conditional granularity: rules that reflect how people actually think about their privacy.

What we are asking for

We are not launching a product. We are putting a proposal on the table — early, openly, and with full documentation — so that the conversation about Article 88b implementation includes a concrete, user-centric option.

If you work in privacy, policy, browser development, or consent management, we would like your input. Read the papers. Challenge the assumptions. Propose improvements. Tell us what we got wrong. The specification is deliberately open because getting this right requires more perspectives than any single consultancy can provide.

The concept paper and technical specification are available at conditionalconsent.com.

The post Conditional Consent: an Open Proposal for How Article 88b Consent Signalling Should Work appeared first on TechGDPR.

This is especially true after the GDPR came into effect, as it provides specific requirements for the legal basis of consent, which also applies to the processing of non-necessary cookies. Reason being, that these text files that our devices read and write upon interacting with a website, oftentimes include information that, once associated with your interactions, is categorised as personal data: such as IP addresses, username, unique identifier codes or even email addresses and metadata.  

That is where Consent Management Platforms (CMP) come into play. They can be described as systems by third-party vendors that help controllers manage users’ cookie preferences and help them meet their transparency obligations under data protection laws. It is thus very likely that when anyone visits any website and a cookie pop-up appears, that is managed by a CMP. You might be familiar with some of the following: OneTrust, Quantcast or Cookiebot.

What are dark patterns and how do they relate to cookies? 

A CMP that relies on the IAB Europe Transparency and Consent Framework Policies (IAB TCF) is required to meet several criteria. However, these mostly refer to the need to include the purposes and features of the cookies. Thus, they are provided a relative amount of freedom in terms of design of cookie banners and consent pop-ups. 

Several studies conducted on the standard templates that CMPs offer, show that many of the designs provided actually hide manipulative strategies intended to sway users into providing consent. These designs are often referred to as dark patterns. 

Some common types dark patterns in the context of cookie banners are known as interface interference and sneaking. An example for the former is presenting the “Accept all” option on top of a banner, whilst the “Reject all” option can only be found after scrolling down, also labelled as false hierarchy.

Another example of false hierarchy is drawing attention to the desired choice, in comparison to the opther options. For instance, the “Accept all” option might be brightly colored or stand out from the background. Meanwhile, the “Reject” or “Settings” options, will oftentimes the same color of the background of the cookie banner, rendering it less noticeable.

Meanwhile, sneaking refers to the hiding of the relevant information, usually behind a far less visible and unformatted link. This is commonly designed with a smaller text providing “more options” or “manage settings” in the corner of the banner, which then allows the user to gain more information and finally reject all cookies. 

Read more about other types of dark patterns in the article “The Dark (Patterns) Side of UX Design” from Purdue University, IN.

Does the GDPR or ePrivacy Directive prohibit the use of Consent Management Platforms? 

There is no direct mention of CMPs or dark patterns in the GDPR or the ePrivacy Directive, which directly governs the use of cookies. Nonetheless, one can still draw some conclusions based on the consent requirements under the GDPR. For example: Article 7(4) GDPR states that withdrawing consent should be as easy as providing it. Thus placing the options on unequal level, as for the case of false hierarchy designs, would be a non-compliant approach. Case law also confirms this: The Advocate General in the case of Planet49 specifically mentions that for consent to be valid, the options to reject and accept should be placed “optically on the same footing.”

Despite these academic findings and conclusions, the use of CMPs has but increased since the GDPR came into force. To add to that, data protection authorities deem CMPs an appropriate tool to use when a compliant design is rolled out. Important to note though, is that CMPs cannot be compliant until they start assuming their data controller or joint controller obligations (GDPR Art 24 and 26, respectively). This was highlighted in the recent €250.000 fine awarded by the Belgian supervisory authority to IAB Europe.

Thus, whilst the use of CMPs is not prohibited, it is always best to take into account that not all of their template designs might actually reflect the requirements for valid consent. Therefore, increasing the possibility that the cookie banner will be deemed non-compliant.

What does a compliant cookie banner look like? 

Under the the framework provided by GDPR Article 7 and Recital 32, consent must be “freely given, specific, informed and an unambiguous indication of agreement”. Ideally, a compliant cookie banner should reflect all of those exactly, and should avoid the dark patterns described above, which likely contradict the freely-given nature of consent. 

As a practical example, in 2022, NOYB, the non-profit presided by Max Schrems, the activist of international fame, placed 226 complaints with data controllers over cookie banners rich in dark patterns, arguing that the only compliant option was to outright offer a accept all and reject all button. Therefore, a good starting point would be to ensure both options are provided and equally accessible, by designing the “Accept” and “Reject” buttons to look identical and perhaps even placed side-by-side on the banner.

Lastly, when implementing a banner design, consider the more stringent requirements in terms of design, such as the prohibition of pre-ticked boxes, and the requirements around requesting unambiguous consent, rather than accepting scrolling as having accepted the use of cookies. 

To recap, when providing cookies, there are several interests and legal requirements that website operators, as data controllers, need to balance before considering Consent Management Platforms as the ideal solution. Studies have shown that many of the current cookie banner designs provided by these platforms, still place more weight on gaining consent rather than ensuring compliance. This is not surprising, considering that CMPs are in the business of selling software solutions to a problem many marketing teams refuse to fully grasp. 

The existence of “dark patterns” in consent pop-ups is perceived by everyone yet not often discussed. For implementers, it is understandably tempting to place full trust on a CMP’s design and overlook the details and turn on options that actually render their banner non-compliant. However, being mindful of the flaws in the designs that Consent Management Platforms offer, and knowing how to avoid dark patterns, might be the only way to ensure that a cookie banner or consent pop-up is fully compliant with the GDPR, that way, your time and money are not a complete waste.

TechGDPR is a consultancy based in Berlin offering GDPR compliance assessments, DPO-as-a-service retainers and hourly consulting. TechGDPR consultants help assess the vendors you wish to purchase your solutions from, navigate the complexity of international data transfers as well as guide you through the most compliant roll-out of the solutions you have purchased. TechGDPR routinely trains marketing and procurement teams in understanding data protection requirements and offers an online training course for software developers, system engineers and product owners.

The post Consent Management Platforms’ misleading cookie banner designs: how to recognize and avoid dark patterns appeared first on TechGDPR.