Online Consent Is Broken,
But It Can Be Fixed

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.

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.

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.

The CMP retains full control over consent storage, compliance logic, and downstream signaling. The API is a read/write transport layer. It coordinates, it does not override.

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.

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.

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.

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.

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.

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.

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.

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.

Not yet. It is an open RFC-style proposal. The specification is publicly available and we welcome feedback from implementers, researchers, and policymakers.

The interactive demo runs the polyfill in your browser and walks through the CMP registration, metadata read, and consent update flow.