Vier modellen voor toestemming in Europa
Alle vier de modellen plaatsen toestemming op browserniveau. Ze verschillen in wie de ervaring bepaalt en hoeveel granulariteit de gebruiker krijgt: het CMP van een website (vandaag), een gestandaardiseerde HTTP-header (GPC), browserleveranciers (Omnibus), of de door de gebruiker zelf gekozen assistent (open architectuur).
Vergelijkingsmatrix
| Vandaag | GPC (jan 2027) | Digital Omnibus | Open architectuur | |
|---|---|---|---|---|
| Wie ontwerpt de toestemmingservaring? Wie bepaalt de interface die de gebruiker ziet | Het CMP van elke website, geconfigureerd door de site-eigenaar. Enorme variatie in kwaliteit, van uitstekend tot manipulatief. | Volledig automatisch: een binaire HTTP-header die door de browser wordt verstuurd voordat de pagina laadt. Eenvoudig en wrijvingsloos, hoewel gebruikers geen beslissingen per site nemen. | Vier browserleveranciers: Google, Apple, Microsoft, Mozilla. Zij ontwerpen de UI voor alle EU-gebruikers. | De door de gebruiker gekozen toestemmingsassistent (bijv. Consent-o-matic, Taste, SuperAgent), die communiceert met het CMP van de site via een neutrale browser-API. |
| Hoe specifiek is de toestemming? AVG Art. 4(11): toestemming moet specifiek en geïnformeerd zijn | Hangt af van het CMP. Goede implementaties bieden keuzes per leverancier en per doel. Slechte presenteren een muur van tekst en één enkele “accepteren”-knop. | Binair: één enkel “verkoop of deel niet”-signaal dat uniform wordt toegepast. Ontworpen voor CCPA-opt-out; kan geen voorkeuren per doel of per leverancier uitdrukken. | Een generiek signaal (accepteren/weigeren) dat gelijk wordt toegepast op alle sites. Kan geen onderscheid maken tussen de analytics van een vertrouwde winkel en een onbekend advertentienetwerk. | Gedetailleerd, contextbewust. De assistent analyseert de leveranciers en doelen van elke site en past voorkeuren toe die per site kunnen variëren. |
| Is er concurrentie? Kan de gebruiker een andere oplossing kiezen? | Gebruikers hebben geen keuze: ze werken met het CMP dat de website gebruikt. Er bestaan browserextensies maar die zijn gebaseerd op reverse-engineering, wat regelmatig stuk gaat. | Het signaal is gestandaardiseerd door de W3C en ingebouwd in de browser. Gebruikers kunnen het aan- of uitzetten. Het signaal zelf is uniform; er is geen mechanisme voor alternatieve implementaties of toegevoegde granulariteit. | Nee. Elke browserleverancier implementeert zijn eigen aanpak. Gebruikers zitten vast aan de browser die ze gebruiken. Geen keuzescherm. | Ja. Een keuzescherm (gemodelleerd naar de DMA-zoekmachineselectie) laat gebruikers kiezen uit concurrerende toestemmingsassistenten. Marktprikkels stimuleren kwaliteit. |
| Belangenconflict? Profiteert de toestemmingsoperator van de uitkomst? | CMPs worden betaald door websites, wat kan aanzetten tot toestemmingsvriendelijke ontwerpen. Handhaving door toezichthouders (CNIL, enz.) fungeert als tegenwicht. | Indirect. Browserleveranciers bepalen de standaardstatus (aan/uit). De standaardkeuze heeft aanzienlijke marktimplicaties, aangezien platforms met first-party datarelaties minder worden geraakt dan partijen die afhankelijk zijn van toestemming. | Aanzienlijk. Browserleveranciers hebben hun eigen advertentie- en dataplatforms. Ze behouden first-party data ongeacht het signaal, terwijl concurrenten afhankelijk zijn van toestemming. | Verminderd. Onafhankelijke assistenten concurreren op het dienen van gebruikersbelangen. Als er een adverteerders bevoordeelt, stappen gebruikers over. Marktdiscipline vervangt structurele conflicten. |
| Wat gebeurt er op mobiel / in in-app browsers? Webviews in Instagram, LinkedIn, nieuws-apps, enz. | Toestemming gaat bij elk bezoek verloren. Webviews zijn geïsoleerd en hebben geen toegang tot opgeslagen toestemming. Dit is een belangrijke oorzaak van toestemmingsmoeheid vandaag. | Werkt in webviews: de HTTP-header wordt verstuurd ongeacht de context. Het signaal blijft binair en kan dus niet de per-site of per-doel voorkeuren van de gebruiker weerspiegelen. | Niet geadresseerd. De Omnibus zwijgt over webviews. Browserextensies draaien niet in in-app browsers. De grootste bron van toestemmingsmoeheid blijft onaangeroerd. | Gedeeltelijk geadresseerd. De neutrale API (navigator.consent) werkt op browserniveau, niet afhankelijk van extensies, waardoor het toekomstbestendig is voor mobiele oplossingen. Maar de webview-kloof vereist aparte wetgeving. |
| Welke rol spelen CMPs? Contextuele info, auditspoor, leveranciersbeheer, compliance | Centraal. CMPs verzamelen toestemming, verstrekken informatie, beheren leveranciersmachtigingen en onderhouden controleerbare registraties. | Beperkt. Het signaal wordt verstuurd voordat het CMP laadt. CMPs kunnen de header lezen en respecteren, maar er is geen gestructureerd kanaal voor het CMP om contextuele informatie te bieden of gedetailleerde keuze aan te bieden in reactie. | Verminderd. CMPs ontvangen het browsersignaal en onderhouden registraties, maar verliezen het vermogen om contextuele informatie en gedetailleerde keuze te bieden op het beslissingsmoment. | Behouden en versterkt. CMPs blijven contextuele info, gedetailleerde controles en audit trails bieden. De assistent communiceert met het CMP, niet eromheen. |
| Impact op toestemmingsmoeheid? Het verklaarde doel van de Digital Omnibus | Aanzienlijke moeheid. Hoofdzakelijk veroorzaakt door browsers die toestemmingscookies wissen (ITP, ETP), in-app browsers en slechte CMP-kwaliteit. Niet door het bestaan van CMPs zelf. | Elimineert bannermoeheid effectief: het signaal is automatisch en vereist geen gebruikersactie. De afweging is dat gebruikers die per-site of per-doel controle willen, geen mechanisme hebben om dit uit te drukken. | Beperkte verbetering. Banners verdwijnen op niet-mediasites, maar grondoorzaken (toestemmingswissing, webviews) worden niet geadresseerd. Mediasites — waar moeheid het ergst is — zijn vrijgesteld. | Betekenisvolle verbetering. Toestemmingsassistenten handelen beslissingen stilletjes af voor de meeste sites. CMP-banners verdwijnen tenzij de gebruiker handmatig wil beslissen. Grondoorzaken moeten nog apart worden geadresseerd. |
| Nettobeoordeling | Werkt, maar ongelijke kwaliteit en echte moeheidsproblemen. Het systeem heeft verbetering nodig, geen vervanging. | Bewezen op schaal en zeer effectief in het verminderen van toestemmingsfrictie. Het binaire model past goed bij de CCPA; voor de AVG zou een granulariteitslaag erboven de kloof overbruggen tussen de eenvoud van opt-out en de specificiteit die de regelgeving vereist. | Ruilt één probleem (moeheid) in voor een ander (machtsconcentratie), terwijl de hoofdoorzaken van moeheid onopgelost blijven. | Vermindert moeheid door door de gebruiker gekozen automatisering, behoudt betekenisvolle toestemming en creëert een concurrerende Europese markt voor privacytools. |