[ gebruikerscontrole-vlak ]
Gebruiker
Houdt voorkeuren aan.
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.
Waarom dit ertoe doet
Waarom interoperabiliteit ertoe doet
De Digital Omnibus, zoals nu opgesteld, kent structurele problemen. Met name Artikel 88b vertoont leemtes die om een aanvullende interoperabiliteitslaag vragen om in de praktijk te werken.
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.
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.
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.
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.
Drie leemtes die de Omnibus niet ziet.
Browser- en OS-leveranciers ondermijnen reeds opgeslagen toestemming via mechanismen als Safari’s ITP, dat na 7 dagen toestemmingsregistraties stilletjes verwijdert. De huidige media-uitzondering creëert een coherentieprobleem: als grote contentplatforms machineleesbare signalen mogen negeren, leren gebruikers snel dat hun voorkeuren niet overal werken. En de implementatietermijn van 24 maanden veronderstelt een geharmoniseerde standaard.
Huidige status
Werk in uitvoering. Open voor input.
Deze specificatie is de actieve bijdrage van ECMPA aan een betere coördinatie tussen toestemmingsactoren. Wij delen ze nu om input uit te nodigen van implementeerders, beleidsmakers en standaardisatieorganisaties, voordat ze uitkristalliseert.
- status
- Concept. Open voor beoordeling en commentaar.
- onder hoede van
- European CMP Association (ECMPA), Brussel
- standaarden
- In gesprek met CEN, ETSI en W3C
- bijgewerkt
- Mei 2026
// 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.
// 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.
Wij brengen ze naar CEN, ETSI en W3C als een concreet voorstel voor de standaard onder Artikel 88b(4), niet als een voltooide.
Browserleveranciers, toestemmingsassistenten, uitgevers, andere brancheorganisaties en het maatschappelijk middenveld zijn allemaal uitgenodigd om deel te nemen aan de specificatie en het bestuursproces.
We werken ook aan een gedragscode onder Artikel 40 AVG. Die zal zwart op wit vastleggen hoe een eerlijke toestemmingsagent eruitziet, wat een CMP mag doen en welke dark patterns voor ons allemaal verboden terrein zijn.
SteunZij steunen
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.
Leden van de European CMP Association
“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.”
Toestemmingsplatforms
Toestemmingsassistenten
Bedrijven
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.
Moeten browserleveranciers hiervoor iets implementeren?
Ja. Als de specificatie wordt aangenomen, zouden browserleveranciers de API native implementeren. Er bestaat een JavaScript-polyfill voor demonstratie en prototyping, maar het doel is een primitief op browserniveau, geen userland-shim. Wij werken samen met browserleveranciers en standaardisatieorganisaties in het kader van het 88b(4)-proces.
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.
Welke cyberveiligheidsmaatregelen bestaan er voor toestemmingsassistenten?
Gegevensbeschermingsautoriteiten zijn verantwoordelijk voor het waarborgen dat toestemmingsassistenten de AVG en ePrivacy naleven, precies zoals zij vandaag al toezicht houden op CMPs. Voor cyberrisico’s (gegevensvervalsing, corruptie van de gebruikersomgeving) stellen browser-extensiestores al beveiligingsbeoordelingen, code-ondertekening en machtigingsverklaringen verplicht. Deze controles zijn nu al van kracht. Een specifieke bepaling in Artikel 88b zou een strengere verificatie kunnen vereisen voor extensies die toestemmingsgegevens verwerken, verder dan de algemene store-beleidsregels.
Zullen browserplatforms niet hun eigen toestemmingsassistent opleggen?
Dit is een reële zorg op het vlak van soevereiniteit en mededinging. Het is echter nog steeds een geringere machtsconcentratie dan wanneer browsers de toestemming rechtstreeks zouden beheren, wat de huidige koers van de Omnibus is. Met een open API kunnen onafhankelijke Europese bedrijven concurreren op kwaliteit en vertrouwen. Het verplicht stellen van een keuzescherm voor toestemmingsassistenten (zoals gedaan voor zoekmachines onder de DMA) zou garanderen dat gebruikers alternatieven te zien krijgen. Wij pleiten voor vrije mededinging en geloven dat onafhankelijke, doelgerichte assistenten een betere dienst kunnen bieden dan een ingebouwde browserstandaard.
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.
Hoe kan ik het uitproberen?
De interactieve demo draait de polyfill in uw browser en doorloopt het CMP-registratie-, metadata-uitlees- en toestemmingsupdateproces.
To:implementeerders van toestemmingsbeheer
From:ECMPA Editorial Group
Re:
navigator.consent · verzoek tot engagementDuw tegen, of duw door.
De Omnibus wordt sowieso gestemd. De vraag is wat er uiteindelijk in komt te staan. Werkt u aan een CMP, levert u een toestemmingsextensie, beheert u een browser of zit u in een parlementaire zetel, dan zijn de komende maanden het moment waarop de structuur wordt vastgelegd.