Four models for consent in Europe
All four models put consent at browser level. They differ in who controls the experience and how much granularity the user gets: a website’s CMP (today), a standardized HTTP header (GPC), browser vendors (Omnibus), or the user’s own chosen assistant (open architecture).
Comparison matrix
| Today | GPC (Jan 2027) | Digital Omnibus | Open Architecture | |
|---|---|---|---|---|
| Who designs the consent experience? Who controls the interface the user sees | Each website’s CMP, configured by the site owner. Huge variation in quality, from excellent to manipulative. | Fully automatic: a binary HTTP header sent by the browser before the page loads. Simple and frictionless, though users do not make per-site decisions. | Four browser vendors: Google, Apple, Microsoft, Mozilla. They design the UI for all EU users. | The user’s chosen consent assistant (e.g. Consent-o-matic, Taste, SuperAgent), communicating with the site’s CMP through a neutral browser API. |
| How specific is the consent? GDPR Art. 4(11): consent must be specific and informed | Depends on the CMP. Good implementations offer per-vendor and per-purpose choices. Poor ones present a wall of text and a single “accept” button. | Binary: a single "do not sell or share" signal applied uniformly. Designed for CCPA opt-out; does not express per-purpose or per-vendor preferences. | A blanket signal (accept/refuse) applied to all sites equally. Cannot distinguish between a trusted shop’s analytics and an unknown ad network. | Granular, context-aware. The assistant analyzes each site’s vendors and purposes, and applies preferences that can vary from site to site. |
| Is there competition? Can the user pick a different solution? | Users have no choice: they interact with whatever CMP the website uses. Some browser extensions exist but rely on reverse-engineering, which breaks frequently. | The signal is standardized by W3C and built into the browser. Users can toggle it on or off. The signal itself is uniform; there is no mechanism for alternative implementations or added granularity. | No. Each browser vendor implements its own approach. Users are locked into whichever browser they use. No choice screen. | Yes. A choice screen (modeled on the DMA search engine selection) lets users pick from competing consent assistants. Market incentives drive quality. |
| Conflict of interest? Does the consent operator benefit from the outcome? | CMPs are paid by websites, which may incentivize consent-friendly designs. Regulatory enforcement (CNIL, etc.) acts as a counterweight. | Indirect. Browser vendors decide the default state (on/off). The default choice has significant market implications, since platforms with first-party data relationships are less affected than those relying on consent-based access. | Significant. Browser vendors run their own advertising and data platforms. They retain first-party data regardless of the signal, while competitors depend on consent. | Reduced. Independent assistants compete on serving user interests. If one favors advertisers, users switch. Market discipline replaces structural conflicts. |
| What happens on mobile / in-app browsers? Webviews in Instagram, LinkedIn, news apps, etc. | Consent is lost on every visit. Webviews are sandboxed and cannot access stored consent. This is a major cause of consent fatigue today. | Works in webviews: the HTTP header is sent regardless of context. The signal remains binary, so it cannot reflect the user’s per-site or per-purpose preferences. | Not addressed. The Omnibus is silent on webviews. Browser extensions don’t run in in-app browsers. The biggest source of consent fatigue remains untouched. | Partially addressed. The neutral API (navigator.consent) is browser-level, not extension-dependent, making it forward-compatible with future mobile solutions. But the webview gap requires separate legislation. |
| What role do CMPs play? Contextual info, audit trail, vendor management, compliance | Central. CMPs collect consent, provide information, manage vendor permissions, and maintain auditable records. | Limited. The signal is sent before the CMP loads. CMPs can read the header and respect it, but there is no structured channel for the CMP to provide contextual information or offer granular choice in return. | Diminished. CMPs receive the browser signal and maintain records, but lose the ability to provide contextual information and granular choice at the point of decision. | Preserved and enhanced. CMPs continue to provide contextual info, granular controls, and audit trails. The assistant communicates with the CMP, not around it. |
| Impact on consent fatigue? The stated goal of the Digital Omnibus | Significant fatigue. Driven primarily by browsers erasing consent cookies (ITP, ETP), in-app browsers, and poor CMP quality. Not by the existence of CMPs themselves. | Effectively eliminates banner fatigue: the signal is automatic and requires no user action. The tradeoff is that users who want per-site or per-purpose control have no mechanism to express it. | Limited improvement. Banners disappear on non-media sites, but root causes (consent erasure, webviews) are unaddressed. Media sites, where fatigue is worst, are exempt. | Meaningful improvement. Consent assistants handle decisions silently for most sites. CMP banners disappear unless the user wants to decide manually. Root causes still need addressing separately. |
| Net assessment | Works, but uneven quality and real fatigue issues. The system needs improvement, not replacement. | Proven at scale and highly effective at reducing consent friction. The binary model fits CCPA well; for GDPR, a granularity layer on top would bridge the gap between opt-out simplicity and the specificity the regulation requires. | Trades one problem (fatigue) for another (concentration of power), while leaving the main causes of fatigue unresolved. | Reduces fatigue through user-chosen automation, preserves meaningful consent, and creates a competitive European market for privacy tools. |