[ user control plane ]
User
Holds preferences.
An open interoperability layer for consent signals across the EU digital ecosystem
Today, every banner is renegotiated from scratch every visit. Every privacy extension scrapes its own DOM. Every browser ships its own signal. navigator.consent is the shared channel that lets browsers, CMPs, and the assistants acting for users finally talk to each other. Without concentrating control in any single actor.
Why this matters
Why interoperability matters
The Digital Omnibus, as drafted, has structural problems. Article 88b in particular has gaps that require a complementary interoperability layer to work in practice.
Consent is contextual. One signal can’t carry it.
Users make different choices depending on who they are engaging with, for what purpose, and in what context. A browser-level preference set before any interaction with a specific controller cannot satisfy GDPR’s requirement for specific, informed consent by construction. The architecture must preserve contextual choice alongside global defaults.
No audit trail, no compliance.
A consent signal without a documented trail is not compliance. Controllers need a verifiable record of what was consented to, by whom, when, and for which purposes. That audit function cannot live in a browser. It requires an independent layer that records, enforces, and accounts for every consent decision.
Browsers can’t become the new gatekeepers.
The browser market is controlled by a handful of non-European companies: Google, Apple, Microsoft. Any consent architecture that routes signals exclusively through browser vendors risks concentrating control over Europe’s consent infrastructure in precisely the companies the DMA was designed to constrain. The standard must be open and technology-neutral.
System-level prompts kill consent rates.
When Apple introduced App Tracking Transparency in 2021, roughly 80% of users declined at the system level. This is not an interface design problem. It is what happens when consent moves away from a specific, trusted service into a generic system prompt. Any browser-level mechanism risks reproducing that dynamic, with direct consequences for European publishers and advertisers.
Three gaps the Omnibus doesn’t see.
Browser and OS vendors already undermine stored consent through mechanisms like Safari’s ITP, which silently deletes consent records after 7 days. The current media exemption creates a coherence problem: if major content platforms can ignore machine-readable signals, users will quickly learn their preferences do not work everywhere. And the 24-month implementation timeline assumes a harmonised standard that has not yet been drafted.
Current status
Work in progress. Open for input.
This specification is ECMPA’s active contribution to better coordination between consent actors. We share it now to invite input from implementers, policymakers, and standards bodies before it hardens.
- status
- Draft. Open for review and comment.
- steward
- European CMP Association (ECMPA), Brussels
- standards
- In conversation with CEN, ETSI, and W3C
- updated
- May 2026
// navigator.consent
How it works
navigator.consent is the wire between browsers, the assistants acting for users, the websites the user is visiting, and the CMPs that hold the records. The browser carries the messages. The CMP keeps the receipts.
// navigator.consent.governance
Governed by the European CMP Association
navigator.consent is stewarded by the European CMP Association (ECMPA). The association represents the CMP providers that run consent for most of the European web today: Axeptio, Didomi, iubenda, Usercentrics, and others. We wrote the spec because we are the ones whose products would have to implement it.
The specification is developed by ECMPA as part of its mandate to represent CMP providers in EU policy and standardisation.
We are taking it to CEN, ETSI, and W3C as a concrete proposal for the Article 88b(4) standard, not a finished one.
Browser vendors, consent assistants, publishers, other industry organisations, and civil society are all invited to engage with the specification and governance process.
We’re also drafting a code of conduct under Article 40 GDPR. It will spell out, in writing, what an honest consent agent looks like, what a CMP is allowed to do, and which dark patterns are off-limits for all of us.
SupportThey support
They support navigator.consent
The people quoted below ship cookie banners, build the extensions that dismiss them, or both. They know which parts of this spec they would actually have to write.
European CMP Association Members
“This specification, even if it looks somewhat technical, can profoundly change the daily lives of millions of people”
“This specification provides a very important clarification of what the EC's draft in Art. 88b Digital Omnibus means when it states that "browsers (...) shall provide the technical means to allow data subjects to give their consent".
This sentence does not mean that browser providers themselves provide consent management services. That would be like putting the fox in charge of the henhouse, as Apple's ATT impressively demonstrates.
Art. 88b Digital Omnibus rather means that browsers enable the technical interface for seamless communication between consent agents (of other providers than browsers) and the digital services that request consent.
This specification therefore clarifies what this technical interface of browsers must look like so that end users and digital services can finally establish user-friendly consent processes”
“Rewarded Interest believes the historical model of confronting consumers with cookie banners is broken – there doesn't need to be a tradeoff between usability and privacy. Consumers deserve both.”
“We always wanted to make consent very simple. This specification would help us simplify it even more.”
“This browser spec can be a game changer for Taste, and other assistants.”
“Super Agent has been applying user consent preferences at scale for years, through scraping, reverse-engineering, and constant maintenance as CMPs shift under our feet. navigator.consent is the substrate that makes this sustainable: a structured contract between assistants and platforms that eliminates fragility without centralizing control.”
“It's absolutely the right path.”
“A very promising initiative.
A standardized browser consent API could give users a much more effective way to manage their preferences, while dramatically reducing the endless stream of consent pop-ups across the web. A clear step toward a more user-centric and less frustrating privacy experience.”
“This initiative would help Privacy Badger empower users to more easily express their consent preferences.”
“navigator.consent does not eliminate consent. It eliminates the need to ask for it from scratch every time.”
“With evolving global regulations and users suffering consent fatigue, many site-specific banner controls are reaching their limits. Navigator Consent forms part of a new layer of coordinated solutions which handle how consent is controlled, audited and demonstrated across the web”
“As someone involved at the birth of the cookie banner, I soon realised its rise to ubiquity was due to it not breaking the system that created the need for consent control. Without reform, it’s now at risk of becoming part of the consent fatigue problem. I am delighted Navigator Consent has arrived to form part of an integrated, structured and responsible consent ecosystem that encourages collaboration between CMP’s, privacy assistants and other stakeholders and puts end users back in the driving seat.”
“Consent shouldn't be a wall between users and websites, it should be a bridge. Navigator.consent gives us the interoperability layer to make that bridge solid, and at Gimii, we're building on it to turn every consent into a positive impact.”
Consent Platforms
Consent Assistants
Companies
Frequently asked questions
What is navigator.consent?
A proposed browser API that acts as a neutral coordination layer between Consent Management Platforms (CMPs) and Consent Assistant browser extensions. It gives both sides a shared, structured interface instead of forcing extensions to reverse-engineer each CMP’s DOM.
How is this different from Global Privacy Control?
GPC proved that browser-level privacy signals work at scale. It sends a binary opt-out preference to every site the user visits. navigator.consent adds a structured layer for per-vendor, per-purpose consent on top. User research consistently shows that people make contextual decisions, not uniform opt-out or opt-in. The two are complementary: GPC as the baseline, navigator.consent for granularity.
How does IAB’s Transparency and Consent Framework fit with this?
TCF already works with purposes, vendors, legal basis, and regulations, even more so with GPP. Its technical components (the __tcfapi stub and the TC String) are designed for interoperability with the advertising ecosystem, not with the browser. Decoding a TC String and calling the navigator.consent registration methods is straightforward. The API does not replace TCF: it gives TCF a browser-legible interface. It also covers what TCF does not: imperative commands to set preferences. The TCF’s getTCData is read-only; navigator.consent supports both reading and writing.
Who controls my consent data?
The CMP retains full control over consent storage, compliance logic, and downstream signaling. The API just moves bytes between parties. It can’t override anyone. Browser vendors have no visibility into or control over consent decisions.
Does this require browser vendors to ship anything?
Yes. If the specification is adopted, browser vendors would implement the API natively. A JavaScript polyfill exists for demonstration and prototyping, but the goal is a browser-level primitive, not a userland shim. We are engaging with browser vendors and standards bodies as part of the 88b(4) process.
Does this work on mobile?
The API itself is browser-level, so it would work in any mobile browser that implements it. Two obstacles remain: consent assistants today are browser extensions, and mobile platforms restrict or prohibit extensions entirely. Then there are webviews, the sandboxed browsers embedded in apps, which would need access to extension context for consent assistants to operate inside them.
Doesn’t this add complexity when the goal is simplification?
The integration burden falls on three browser vendors (Google, Apple, Microsoft) who already manage complex web platform APIs. For everyone else, it simplifies. Users continue browsing as today but can optionally adopt a consent assistant to reduce their exposure to consent interfaces. Businesses keep using their CMP; some visitors will arrive with an assistant that delivers valid consent proofs automatically. For legislators, the narrative is concrete: install a consent assistant, and cookie banners disappear. This also aligns naturally with the EU digital identity wallet concept: a personal agent that carries your preferences across services.
What’s the impact on performance?
A consent assistant always responds faster than a human. It does not respond on every page, only when a user would have been prompted. Because consent storage and duration remain the CMP’s responsibility, the assistant only steps up when a human would have had to make a decision. The net effect is fewer UI round-trips, not more.
What cybersecurity safeguards exist for consent assistants?
Data protection authorities are responsible for ensuring that consent assistants comply with GDPR and ePrivacy, just as they oversee CMPs today. For cyber risks (data impersonation, user-space corruption), browser extension stores already enforce security reviews, code signing, and permission declarations. These controls are in force today. A specific provision in Article 88b could require tighter vetting for extensions that handle consent data, going beyond general extension store policies.
Won’t browser platforms push their own consent assistant?
This is a real sovereignty and competition concern. However, it is still a lesser concentration of power than letting browsers handle consent directly, which is the current Omnibus trajectory. With an open API, independent European companies can compete on quality and trust. Mandating a choice screen for consent assistants (as was done for search engines under the DMA) would ensure users are exposed to alternatives. We advocate for free competition and believe that purpose-built, independent assistants can offer a better service than a built-in browser default.
What happens if no consent assistant is installed?
Nothing changes. The CMP works exactly as it does today: it shows its banner, collects choices, and stores consent. The API is purely additive. It gives CMPs a structured channel to publish metadata and receive preferences, but if no assistant is listening, the CMP remains in full control. No user experience degrades.
Can a consent assistant override my choices without my knowledge?
The API enforces provenance: preferences set directly by the user always take precedence over those set by an assistant. Every mutation is logged with its source and timestamp, and savvy users can inspect the full audit trail. That said, trust cuts both ways. Already today, nothing prevents a CMP from saying one thing and doing another. And even when the CMP is honest, what happens downstream is a different story: tag managers, CMS plugins, and client-side code can all fire trackers regardless of what the consent layer decided. The API does not solve that, but it makes the consent layer itself transparent and auditable, which is more than the status quo offers.
Is this a W3C standard?
Not yet. It is an open RFC-style proposal. The specification is publicly available and we welcome feedback from implementers, researchers, and policymakers.
How can I try it?
The interactive demo runs the polyfill in your browser and walks through the CMP registration, metadata read, and consent update flow.
To:implementers of consent management
From:ECMPA Editorial Group
Re:
navigator.consent · request for engagementPush back, or push forward.
The Omnibus will be voted on either way. The question is what it ends up saying. If you work on a CMP, ship a consent extension, run a browser, or sit in a Parliament chair, the next few months are when the structure gets fixed.