The problem banners don't solve
Eight years of GDPR. Over €7.1 billion in cumulative fines since 2018 ( GDPR Enforcement Tracker / ComplianceHub.Wiki, January 2026 ). Thousands of cookie banners deployed across just as many websites.
Yet anyone who browses the internet knows the scene well: every time you open a site, a banner appears. You make a choice. You close it. You open another site. You start again. The next day, on the same site, the browser has wiped your preferences and the banner is back.
This consent fatigue is real and well-documented. But its root cause is not the consent mechanism itself: it is the quality of implementations. Dark patterns. No "Reject" button at the first level. In-app browsers that don't share storage with the system browser. Low-quality cookie banners that fail to correctly implement regulatory requirements.
Consent is not the problem. Poor implementations are.
A correctly configured Consent Management Platform, in compliance with EDPB guidelines, can significantly reduce unnecessary interactions. Consent, when properly implemented, does not feed consent fatigue - it reduces it.
But there are real structural inefficiencies that no Consent Management Platform, on its own, can fully resolve. The ongoing regulatory debate at European level has made this clear - and that is where the navigator.consent proposal originates.
The Digital Omnibus and our position to the European Commission
navigator.consent sits within a broader regulatory debate that directly concerns the future of consent in Europe: the Digital Omnibus (COM(2025) 837), the European Commission's legislative proposal that, among other things, introduces Articles 88a and 88b into the GDPR, opening the door to browser-level configurable preference signals.
On 11 March 2026 we submitted the My Agile Privacy® Position Paper as part of the public consultation on the Digital Fitness Check. The document is available on the European Commission's Have Your Say platform .
Our position is nuanced: we share the objective of reducing consent fatigue and simplifying the regulatory framework, but we flag specific risks that, if not addressed during the revision phase, could produce effects contrary to those intended - particularly for European SMEs and the digital sovereignty of the Union.
The central risk of Article 88b is precise: if browser signals were to replace the Consent Management Platform, they would not meet the requirements for specific and informed consent under Art. 4(11) GDPR. A preference expressed in general terms does not incorporate the information necessary to constitute informed consent with respect to the specific processing of each data controller.
Delegating consent to the browser without a Consent Management Platform is not simplification. It is a transfer of responsibility to an actor that lacks the tools to handle it.
It is in this context that navigator.consent offers a different answer - and one more consistent with GDPR requirements.
What navigator.consent is and how it works
navigator.consent is a browser API proposal - currently in the status of a public RFC (Request for Comments), not yet a W3C standard (World Wide Web Consortium, the international body that defines web technical standards) - that creates a neutral interoperability layer between Consent Management Platforms and "Privacy Assistants": browser extensions that automatically apply the user's consent preferences.
Supporters already include Consent Management Platforms such as Axeptio and AdOpt, consent assistant tools such as SuperAgent and Taste, the Electronic Frontier Foundation with Privacy Badger, and companies like TWIPLA and Edgee. The full list of supporters is available at navigatorconsent.org.
The problem it aims to solve is concrete. Today, browser extensions that manage consent on behalf of the user operate through a fragile approach: they perform DOM scraping - analysing the banner's HTML code, trying to identify which buttons correspond to "accept" and "reject", and simulating clicks. Any update to the Consent Management Platform can break the extension. It is a continuous, costly, unreliable chase.
navigator.consent replaces this mechanism with a structured contract
: the Consent Management Platform declares its vendors, its purposes, and its consent state to the browser. The Privacy Assistant reads this information directly, without interpretation, without scraping.
navigator.consentdoes not eliminate consent. It eliminates the need to ask for it from scratch every time.
In practice, the flow works as follows. When a user arrives on a site:
- The Consent Management Platform registers with the browser, declaring its name, version, and applicable regulatory context.
- The Consent Management Platform publishes the vendor catalogue and processing purposes, each with its respective legal basis.
- The Consent Management Platform calls
requestConsent()- a signal telling the Privacy Assistant: "I'm about to show the banner, do you want to step in first?" - If the user has a Privacy Assistant installed with already-expressed preferences, the assistant applies them automatically. The banner is not shown.
- If no assistant is active, the Consent Management Platform proceeds normally with its own banner.
One fundamental point: the Consent Management Platform retains full control over storage, scope, and consent persistence. The API is a transport layer, not a substitute. Legal and compliance responsibilities remain where they belong. navigator.consent is designed as a complement to the Consent Management Platform, not its replacement - and it is precisely for this reason that it is compatible with GDPR requirements.
The conditions that remain open
The proposal has concrete technical value. But some conditions must be monitored.
Open and interoperable standards. For the ecosystem to work, the signal format must be published under an open licence, accessible to any Consent Management Platform provider or compliance tool, without dependence on proprietary APIs. The standard must not be delegated de facto to sector frameworks such as the IAB TCF, designed for programmatic advertising and inadequate as a general standard.
The concentration risk. One of the points we explicitly raised in the Position Paper concerns control over consent flows falling into the hands of a limited number of non-European operators. Apple with ATT, Google with Privacy Sandbox: the precedents exist. navigator.consent is designed with an open registration model, without allow-lists or centralised trust attestations. This characteristic is essential and must be preserved.
Browser vendors have not yet adopted it. This is a public RFC, not an adopted standard. Until Google, Apple, and Microsoft implement the API natively, the full ecosystem cannot function. A JavaScript polyfill exists for experimentation, but it is not the definitive solution.
The direction is right
Online consent has a structural problem. It cannot be solved with bigger banners, longer policies, or more fines. It is solved through interoperability: giving users tools to express their preferences in a portable and verifiable way, and giving Consent Management Platforms a structured channel to communicate with those tools without losing control of compliance.
More fines do not produce more Privacy. What produces more Privacy is a technical infrastructure in which consent actually works.
navigator.consent is the most concrete and technically sound proposal the industry has produced so far. It is compatible with the structure of the GDPR. It is compatible with the role that Consent Management Platforms must play in the consent ecosystem. And it is consistent with the direction we indicated to the European Commission in our consultation.
It is a proposal we are monitoring closely, and we are ready to integrate it when the technical and regulatory framework makes it operational.
In the meantime, GDPR and ePrivacy are fully in force. My Agile Privacy® is your tool to be compliant today, with a Consent Management Platform that correctly implements preventive script blocking, four compliant buttons, and consent documentation without unnecessary complexity.
