Online toestemming werkt niet,
maar het kan worden hersteld

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.

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.

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.

Het CMP behoudt volledige controle over toestemmingsopslag, compliancelogica en downstream-signalering. De API is een lees-/schrijftransportlaag. Het coördineert, het overschrijft niet.

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.

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.

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.

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.

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.

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.

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.

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.

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

De interactieve demo draait de polyfill in uw browser en doorloopt het CMP-registratie-, metadata-uitlees- en toestemmingsupdateproces.