Browser API
navigator.consent is a thin, neutral API, like navigator.geolocation. CMPs declare their vendors and purposes in structured data. No more opaque tracking: every actor reveals what they process and why.
Interoperability without centralization
Consent fatigue is real, and regulation helped create it. The Digital Omnibus wants to fix it. But the proposed remedy risks concentrating power in a handful of browser vendors who’d rather not have it. A third way is possible: an open interoperability layer where every actor reveals their cards and users choose who plays on their behalf.
Consent fatigue
334M hours/year. ITP erases consent cookies, webviews start from scratch, and banners reappear constantly. Business depending on cookie consent push for manipulative designs (dark pattern, habituation, guilt-tripping).
User privacy
Depends entirely on the CMP. Good ones offer real choice; poor ones use dark patterns to steer users toward “Accept all.”. Privacy-oriented extensions or techniques, like ATT or ITP, push vendors towards server-side and undisclosed tracking.
Open web sustainability
Publishers can operate with informed consent. The model works, even if it’s uneven.
Consent specificity
Good CMPs offer per-vendor, per-purpose choices. Bad ones present a wall of text and one big button. The scale of tracking is sometimes so large that it becomes overwhelming.
Auditability
Regulators must inspect each CMP’s proprietary records individually.
Power distribution
Fragile equilibrium between DPAs, CMPs, Professional Associations (IAB TCF), and Privacy Activists
Uneven quality. Good CMPs provide granular choice, poor ones use dark patterns. Users have no say in which CMP a site uses. Consent storage is fragile.
A competitive alternative: three layers
This architecture builds on GPC’s foundation and adds the granularity that GDPR requires: structured, machine-readable, and auditable consent coordination across three layers.
The integration effort falls on three browser vendors who already manage complex web platform APIs. For users, nothing changes, but they can optionally adopt a consent assistant to reduce their exposure to consent interfaces. For businesses, the CMP continues to orchestrate consent; some visitors will simply arrive with preferences already set. For legislators, the pitch is concrete: install an assistant, and cookie banners disappear. This model also dovetails with the EU digital identity wallet: a personal agent that carries your verified preferences across services.
Consent assistant extensions
Users choose a consent assistant from a selection screen (like the DMA search engine choice). Extensions like Consent-o-matic, SuperAgent, and Taste use the API to apply preferences granularly. This creates a competitive European market for privacy innovation.
CMPs as the compliance layer
CMPs remain responsible for contextual information, audit trails, vendor-level instructions, and regulatory compliance. The assistant communicates with the CMP, not around it. A browser signal alone cannot fulfill these functions.
All four models put consent at browser level. The difference is who controls the experience.
Browsers are already core platform services
The Digital Markets Act qualifies web browsers as core platform services (Recital 14). In September 2023, the European Commission designated Google Chrome and Safari as core platform services provided by gatekeepers. The Union recognizes that these browsers are major access points through which business users reach end users, justifying their regulation in the name of contestability and fairness.
The consent layer sits directly on top of these designated core platform services. If a browser vendor centralized or imposed a single consent model, it would exercise direct control over a condition of access to the digital market. Consent is not a peripheral feature: it is the gateway through which every data-processing relationship begins.
Consent management platforms are the technical extension of the requirements flowing from the ePrivacy Directive and the GDPR. In the same way,
navigator.consent can be understood as the technical extension of the interoperability and contestability principles enshrined in the DMA.This framing matters for Article 88b. Rather than creating a new consent regime that concentrates power in designated gatekeepers, the Omnibus should build on what the DMA already establishes: that browsers are critical infrastructure requiring open, pluralistic, and non-capturable interfaces. navigator.consent organizes precisely this: a neutral coordination layer that ensures the consent experience remains contestable even at the browser level.
A structural risk no one wants
Article 88b(6) asks browser vendors to build consent management into their products. The intent is sound, but the architecture creates concentration risks that are hard to undo, and that browser vendors themselves would rather avoid.
Consent design shapes outcomes
Whoever designs the consent interface influences the result. With four browser vendors designing the experience for all EU users, a small number of design choices would determine consent rates across the entire European internet.
Blanket signals fail GDPR specificity
A browser-level "accept/refuse tracking" toggle cannot satisfy Article 4(11), which requires consent to be specific and informed, tied to particular purposes and processors. A user who trusts their bank’s analytics has no reason to apply the same preference to an unknown ad network.
The open web loses disproportionately
Platforms with logged-in users retain first-party data regardless of any signal. Independent publishers, European SaaS, e-commerce, and analytics providers who rely on informed, specific consent bear the full burden.
Browser vendors inherit unwanted liability
Building consent UX means making design decisions that affect compliance outcomes. Browser vendors would prefer to provide neutral plumbing, not become consent gatekeepers with regulatory exposure.
Webviews remain a blind spot
The Omnibus’s own mechanism, browser-level signals, fails in in-app browsers where extensions don’t run. The biggest source of consent fatigue remains untouched by the proposed fix.
From binary signal to granular consent
Global Privacy Control proved that browser-level privacy signals can work at scale: over 150 million users, legal backing in California, and a W3C specification. AB 566 (signed October 2025) requires all major browsers to ship built-in GPC by January 1, 2027. That is a major achievement.
GPC is a binary opt-out signal: "do not sell or share my data." That maps well to CCPA’s opt-out framework. GDPR, however, requires consent to be "freely given, specific, informed and unambiguous" (Article 4(11)), which calls for purpose-level and vendor-level granularity that a single bit cannot express.
If the EU signal standard replicates a binary model, the result is a single toggle applied uniformly to every site and vendor. Publishers, e-commerce, and SaaS companies would have no way to distinguish between a user who objects to retargeting and one who is comfortable with functional analytics.
The opportunity is to build on GPC’s foundation. GPC establishes the opt-out floor; navigator.consent adds a structured, purpose-specific consent channel on top. The EU standardization process under Article 88b(4) can draw on both: a simple baseline signal and a granular coordination layer for informed consent.
For regulators Built-in auditability
Without a structured interoperability layer, the industry’s rational response to consent pressure is to go opaque: server-side tracking, fingerprinting, deterministic IDs, gated content. navigator.consent reverses that incentive: if you declare vendors and purposes through a structured channel, enforcement becomes possible.
| registrationId | reg_a1b2c3 |
| provenance | cmp |
| status | Active |
| purposes | 3 |
| vendors | 3 |
Purposes
| Purpose | Legal basis | Consent | Set by |
|---|---|---|---|
| Analytics | legitimate_interest | granted | privacy_assistant |
| Advertising | consent | denied | user |
| Functional | legitimate_interest | granted | cmp |
Vendors
| Name | Domain | Purposes | Consent | Set by |
|---|---|---|---|---|
| Analytics Co | analytics.example | analytics | granted | privacy_assistant |
| AdNetwork | ads.example | analytics, advertising | denied | user |
| Social Widget | social.example | functional | pending | — |
Timestamped audit trail
Every consent mutation is logged with provenance and timestamps. Regulators can see exactly what was set, by whom, and when, without relying on the CMP’s self-reporting alone.
Provenance attribution
The API tracks whether a preference was set by the user, a consent assistant, or the CMP. User choices always take precedence. No actor can silently override another.
Tracking goes dark without this
Server-side tracking, fingerprinting, and deterministic IDs are invisible to current enforcement tools. A structured API pulls data processing declarations back into the open where regulators can verify them.
Cybersecurity guardrails
Data protection authorities are responsible for ensuring that consent assistants comply with GDPR and ePrivacy, just as they already oversee CMPs. This is not a new regulatory mechanism: it is an extension of existing supervisory powers to a new category of actor.
For cyber risks such as data impersonation or user-space corruption, browser extension stores already enforce security reviews, code signing, and permission declarations before any extension reaches users. These controls are in force today and apply to consent assistants out of the box.
A specific provision in Article 88b could go further: requiring tighter vetting for extensions that handle consent data, beyond general extension store policies. This would give supervisory authorities an additional lever without creating a new oversight framework from scratch.
Signal standardization: interoperability, not uniformity
Article 88b(4) tasks European standardization organizations with drafting standards for machine-readable consent signals. This is the right direction, but the standard must preserve the specificity that makes consent meaningful under GDPR.
A consent signal must support granular, purpose-specific, and vendor-specific decisions. GPC’s binary model was designed for CCPA opt-out, not GDPR consent. The EU standard should go further, supporting context-aware signals that distinguish between purposes and vendors.
CMP providers must participate in the standardization process. They combine deep legal expertise with hands-on technical knowledge of consent collection and signaling. Caution is also warranted regarding the IAB Transparency and Consent Framework as a template: it covers publisher advertising but is unsuitable for e-commerce, SaaS, landing pages, and most other online services.
Consent fatigue has technical roots the regulation doesn’t address
The European Commission estimates EU citizens spend 334 million hours on cookie banners per year. But the root causes are technical, not inherent to consent itself, and the Digital Omnibus leaves them untouched.
Browser tracking protection
Safari’s ITP caps client-side cookies to 7 days. Firefox’s ETP applies similar restrictions. Since most CMPs store consent with document.cookie, your choices are silently erased, and the banner comes back as if you never decided.
In-app browsers
A growing share of mobile browsing happens inside apps (Instagram, LinkedIn, news apps). These sandboxed webviews can’t access consent stored in the main browser. Every visit looks like a new user. The Omnibus is silent on this.
Dark patterns
A 2025 study found 38% of GDPR-compliant banners still use aesthetic manipulation: highlighted "Accept" buttons, buried reject options. The fix is better CMP quality and enforcement, not eliminating CMPs.
The media exemption undermines the framework
Recital 46 exempts media service providers from respecting machine-readable consent signals. But media websites are where consent fatigue is most acute: news sites load dozens of advertising vendors, present the most complex consent interfaces, and deploy cookie walls followed by paywalls. Exempting them means the Digital Omnibus would reduce friction where it’s already low and preserve it where it’s highest.
What we ask of the Parliament
Open browser consent to third-party extensions
Amend Article 88b(6) to require that browser-level consent mechanisms be open to independent, third-party consent assistant extensions, not limited to browser vendors’ built-in functionality. Chrome and Safari are already designated core platform services under the DMA. Opening consent to competing extensions is consistent with the contestability obligations these gatekeepers already face. Consider mandating a choice screen for consent assistants, as was done for search engines.
Ensure CMP participation in signal standardization
Include CMP industry representatives in the standardization process under Article 88b(4). Specify that the standard must support granular, purpose-specific, and vendor-specific consent, not blanket signals.
Require granular signals, not blanket opt-out
Build on GPC’s success: adopt its opt-out baseline, and extend it with purpose-specific and vendor-specific consent signals that satisfy GDPR’s specificity requirement. The standard should support context-aware decisions that vary by site, vendor, and purpose.
Narrow the media exemption
Prevent Recital 46 from becoming a loophole that exempts the most consent-heavy sector from the framework’s core mechanism. Any exemption must be narrowly defined.
Address the root technical causes of consent fatigue
Investigate browser tracking protection (ITP, ETP) and webview sandboxing as structural drivers of repeated prompts. These technical factors, not the existence of CMPs, are the primary cause of the 334 million hours the Commission cites.
References
These references concern the Digital Omnibus proposal (COM(2025)0837) and should not be treated as final law.
- EU Digital Omnibus regulation proposal
- Official proposal text (CELEX 52025PC0837)
- European Parliament legislative tracking
- California Opt Me Out Act (AB 566), CPPA announcement
- Global Privacy Control, W3C Working Draft
- CMA investigation into Google Privacy Sandbox
- Autorité de la concurrence — Apple ATT fine
- Digital Markets Act (Regulation (EU) 2022/1925)
- European Commission — DMA designated gatekeepers