Onder hoede van de European CMP Association (ECMPA)

Een open interoperabiliteitslaag voor toestemmingssignalen in het Europese digitale ecosysteem

Vandaag wordt elke banner bij elk bezoek opnieuw onderhandeld. Elke privacy-extensie scrapet zijn eigen DOM. Elke browser verstuurt zijn eigen signaal. navigator.consent is het gedeelde kanaal waarmee browsers, CMPs en de assistenten die voor gebruikers optreden eindelijk met elkaar kunnen praten. Zonder de controle bij één enkele speler te concentreren.

De CMP registreert zich bij de browser.

// navigator.consent

Hoe het werkt

navigator.consent is de draad tussen browsers, de assistenten die voor gebruikers optreden en de CMPs die de dossiers bijhouden. De browser draagt de berichten. Het CMP bewaart de bewijsstukken.

[ gebruikerscontrole-vlak ]

Gebruiker

Houdt voorkeuren aan.

[ toestemmingsassistent ]optioneel

Toestemmingsassistent

Treedt op namens de gebruiker.

[ browsertransport ]

Browsersnavigator.consent

Implementeren navigator.consent.

[ compliancevlak ]

CMP

Systeem van registratie.

[ verwerkingsverantwoordelijke ]

Website

Daar bevindt de gebruiker zich werkelijk. Host de inhoud, integreert het CMP, treedt op als verwerkingsverantwoordelijke.

Waarom dit ertoe doet

Waarom interoperabiliteit ertoe doet

Toestemmingsmoeheid kan worden opgelost zonder de privacy van gebruikers op te offeren of controle in browsers te centraliseren. navigator.consent stelt een standaard voor die de ervaring verbetert voor gebruikers, CMPs en websites.

  1. Toestemming is contextueel. Eén signaal kan dat niet dragen.

    Gebruikers maken verschillende keuzes afhankelijk van met wie ze in zee gaan, voor welk doel en in welke context. Een voorkeur op browserniveau, ingesteld vóór enige interactie met een specifieke verwerkingsverantwoordelijke, kan op constructieniveau niet voldoen aan de AVG-eis van specifieke, geïnformeerde toestemming. De architectuur moet contextuele keuze naast algemene standaardinstellingen behouden.

  2. Geen audit trail, geen naleving.

    Een toestemmingssignaal zonder gedocumenteerd spoor is geen naleving. Verwerkingsverantwoordelijken hebben een verifieerbaar dossier nodig van waarvoor toestemming is gegeven, door wie, wanneer en voor welke doelen. Die auditfunctie kan niet in een browser leven. Ze vereist een onafhankelijke laag die elke toestemmingsbeslissing registreert, handhaaft en verantwoordt.

  3. Browsers mogen geen nieuwe poortwachters worden.

    De browsermarkt wordt beheerst door een handvol niet-Europese bedrijven: Google, Apple, Microsoft. Elke toestemmingsarchitectuur die signalen uitsluitend via browserleveranciers stuurt, riskeert de controle over de Europese toestemmingsinfrastructuur te concentreren in precies die bedrijven die de DMA wilde beteugelen. De standaard moet open en technologie-neutraal zijn.

  4. Vragen op systeemniveau doden toestemmingspercentages.

    Toen Apple in 2021 App Tracking Transparency introduceerde, weigerde ongeveer 80% van de gebruikers op systeemniveau. Dit is geen probleem van interfaceontwerp. Dit is wat er gebeurt wanneer toestemming wordt verplaatst van een specifieke, vertrouwde dienst naar een generieke systeemvraag. Elk mechanisme op browserniveau riskeert dezelfde dynamiek te reproduceren, met directe gevolgen voor Europese uitgevers en adverteerders.

// navigator.consent.governance

Bestuurd door de European CMP Association

navigator.consent staat onder hoede van de European CMP Association (ECMPA). De vereniging vertegenwoordigt de CMP-aanbieders die vandaag de dag toestemming uitvoeren op het grootste deel van het Europese web: Axeptio, Didomi, iubenda, Usercentrics en anderen. Wij hebben de specificatie geschreven omdat wij degenen zijn wier producten ze zouden moeten implementeren.

De specificatie wordt ontwikkeld door ECMPA als onderdeel van haar mandaat om CMP-aanbieders te vertegenwoordigen in EU-beleid en standaardisatie.

Browserleveranciers, toestemmingsassistenten, uitgevers, andere brancheorganisaties en het maatschappelijk middenveld zijn allemaal uitgenodigd om deel te nemen aan de specificatie en het bestuursproces.

De specificatie is een open RFC, gepubliceerd voor beoordeling en commentaar. Reacties vanuit elk deel van het ecosysteem zijn welkom.

Meer over ECMPA →

Steun

Zij steunen navigator.consent

De mensen die hieronder geciteerd worden, bouwen cookiebanners, ontwikkelen de extensies die ze wegklikken, of doen beide. Zij weten welke delen van deze specificatie ze daadwerkelijk zouden moeten schrijven.

Steward of the specification

Leden van de European CMP Association

Toestemmingsplatforms

Toestemmingsassistenten

Bedrijven

Romain Bessuges-Meusy
CEO & Co-Founder, Axeptio

This specification, even if it looks somewhat technical, can profoundly change the daily lives of millions of people

Prof. Dr. Max von Grafenstein
CEO, Founder, and Lawyer, Consenter

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

Scott Spencer
CEO & Co-founder, Rewarded Interest

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.

Adonis Batista Beggi
CEO, AdOpt

We always wanted to make consent very simple. This specification would help us simplify it even more.

Antoine Martinez
Chief Product Officer, Taste

This browser spec can be a game changer for Taste, and other assistants.

Francisco Leite de Castro
Founder, SuperAgent

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.

Tim Hammermann
Co-Founder & CEO, TWIPLA

It's absolutely the right path.

Sacha Morard
Co-founder - formerly CTO at Le Monde, Edgee

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.

the Privacy Badger Team

This initiative would help Privacy Badger empower users to more easily express their consent preferences.

Daniele Bianco
Co-Founder, CEO & CTO, My Agile Privacy

navigator.consent does not eliminate consent. It eliminates the need to ask for it from scratch every time.

Richart Ruddie
CEO & Founder, Captain Compliance

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

Gilbert Hill
Founder of Optanon & MD, PrivTech

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.

Thomas Gicquel
CEO, Gimii

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.

Veelgestelde vragen

Wat is navigator.consent?

Een voorgestelde browser-API die fungeert als een neutrale coördinatielaag tussen Consent Management Platforms (CMPs) en toestemmingsassistent-browserextensies. Het biedt beide partijen een gedeelde, gestructureerde interface in plaats van extensies te dwingen de DOM van elk CMP te reverse-engineeren.

Wat is het verschil met Global Privacy Control?

GPC heeft bewezen dat privacysignalen op browserniveau op schaal werken. Het stuurt een binaire opt-outvoorkeur naar elke site die de gebruiker bezoekt. navigator.consent voegt daar een gestructureerde laag bovenop voor toestemming per leverancier en per doel. Gebruikersonderzoek toont consistent aan dat mensen contextuele beslissingen nemen, geen uniforme opt-out of opt-in. De twee zijn complementair: GPC als de basislijn, navigator.consent voor granulariteit.

Hoe past het IAB Transparency and Consent Framework in dit model?

Het TCF werkt al met doelen, leveranciers, rechtsgrondslagen en regelgeving; met GPP zelfs nog uitgebreider. De technische componenten (de __tcfapi-stub en de TC String) zijn ontworpen voor interoperabiliteit met het advertentie-ecosysteem, niet met de browser. Een TC String decoderen en de registratiemethoden van navigator.consent aanroepen is eenvoudig. De API vervangt het TCF niet: het geeft het TCF een voor de browser leesbare interface. Het dekt ook wat het TCF niet dekt: imperatieve opdrachten om voorkeuren in te stellen. Het getTCData van het TCF is alleen-lezen; navigator.consent ondersteunt zowel lezen als schrijven.

Wie beheert mijn toestemmingsgegevens?

Het CMP behoudt volledige controle over toestemmingsopslag, compliancelogica en downstream-signalering. De API verplaatst slechts bytes tussen partijen. Het kan niemand overschrijven. Browserleveranciers hebben geen inzicht in en geen controle over toestemmingsbeslissingen.

Werkt dit op mobiele apparaten?

De API werkt op browserniveau en zou functioneren in elke mobiele browser die hem implementeert. Twee obstakels blijven bestaan: toestemmingsassistenten zijn momenteel browserextensies, en mobiele platformen beperken of verbieden extensies volledig. Daarnaast zijn er webviews, de gesandboxte browsers in apps, die ook toegang tot de extensiecontext nodig zouden hebben om assistenten te laten werken.

Voegt dit geen complexiteit toe terwijl het doel vereenvoudiging is?

De integratie-inspanning rust op drie browserleveranciers (Google, Apple, Microsoft) die al dagelijks complexe webplatform-API’s beheren. Voor alle anderen vereenvoudigt het juist. Gebruikers surfen gewoon door zoals nu, met de mogelijkheid om een toestemmingsassistent te installeren die hun blootstelling aan cookiebanners vermindert. Bedrijven behouden hun CMP; sommige bezoekers arriveren met een assistent die automatisch geldige toestemmingsbewijzen aflevert. Voor wetgevers is de boodschap tastbaar: installeer een assistent en de cookiebanners verdwijnen. Dit model sluit bovendien naadloos aan bij het concept van de Europese digitale identiteitsportemonnee: een persoonlijke agent die uw geverifieerde voorkeuren van dienst naar dienst meedraagt.

Wat is de impact op de prestaties?

Een toestemmingsassistent reageert altijd sneller dan een mens. Hij reageert niet op elke pagina: alleen wanneer de gebruiker bevraagd zou zijn. Omdat opslag en geldigheid van de toestemming de verantwoordelijkheid van het CMP blijven, treedt de assistent alleen op wanneer een mens een beslissing had moeten nemen. Per saldo zijn het minder UI-roundtrips, niet meer.

Wat gebeurt er als er geen toestemmingsassistent is geïnstalleerd?

Er verandert niets. De CMP werkt precies zoals vandaag: toont de banner, verzamelt keuzes en slaat toestemming op. De API is puur additief. Het biedt CMP’s een gestructureerd kanaal om metadata te publiceren en voorkeuren te ontvangen, maar als er geen assistent luistert, behoudt de CMP volledige controle. Geen enkele gebruikerservaring gaat achteruit.

Kan een toestemmingsassistent mijn keuzes wijzigen zonder dat ik het weet?

De API dwingt herkomstcontrole af: voorkeuren die de gebruiker rechtstreeks instelt, winnen altijd van die van een assistent. Elke wijziging wordt vastgelegd met bron en tijdstempel, en technisch onderlegde gebruikers kunnen de volledige audit trail inspecteren. Dat gezegd hebbende: vertrouwen werkt twee kanten op. Al vandaag weerhoudt niets een CMP ervan het ene te zeggen en het andere te doen. En zelfs als de CMP eerlijk is, is wat er stroomafwaarts gebeurt een ander verhaal: tag managers, CMS-plugins en client-side code kunnen trackers activeren ongeacht wat de toestemmingslaag heeft besloten. De API lost dat niet op, maar maakt de toestemmingslaag zelf transparant en auditeerbaar, en dat is meer dan de huidige situatie biedt.

Is dit een W3C-standaard?

Nog niet. Het is een open voorstel in RFC-stijl. De specificatie is publiek beschikbaar en wij verwelkomen feedback van implementeerders, onderzoekers en beleidsmakers.