[ nutzer-kontrollebene ]
Nutzer
Hält die Präferenzen.
Eine offene Interoperabilitätsschicht für Einwilligungssignale im EU-Digitalökosystem
Heute wird jedes Banner bei jedem Besuch von Grund auf neu verhandelt. Jede Datenschutz-Erweiterung scrapt ihr eigenes DOM. Jeder Browser liefert sein eigenes Signal aus. navigator.consent ist der gemeinsame Kanal, der Browsern, CMPs und den Assistenten, die für die Nutzer handeln, endlich erlaubt, miteinander zu sprechen. Ohne die Kontrolle bei einem einzigen Akteur zu bündeln.
// navigator.consent
So funktioniert es
navigator.consent ist die Leitung zwischen Browsern, den Assistenten, die für die Nutzer handeln, und den CMPs, die die Aufzeichnungen führen. Der Browser transportiert die Nachrichten. Die CMP bewahrt die Belege.
Worum es geht
Warum Interoperabilität entscheidend ist
Einwilligungsmüdigkeit lässt sich lösen, ohne die Privatsphäre der Nutzer zu opfern oder die Kontrolle in Browsern zu zentralisieren. navigator.consent schlägt einen Standard vor, der die Erfahrung für Nutzer, CMPs und Websites gleichermaßen verbessert.
Einwilligung ist kontextabhängig. Ein einzelnes Signal kann sie nicht tragen.
Nutzer treffen je nach Gegenüber, Zweck und Kontext unterschiedliche Entscheidungen. Eine browserweite Voreinstellung, die vor jeder Interaktion mit einem konkreten Verantwortlichen gesetzt wird, kann die DSGVO-Anforderung an eine spezifische und informierte Einwilligung konstruktionsbedingt nicht erfüllen. Die Architektur muss die kontextbezogene Entscheidung neben globalen Voreinstellungen erhalten.
Kein Audit-Trail, keine Compliance.
Ein Einwilligungssignal ohne dokumentierten Pfad ist keine Compliance. Verantwortliche brauchen einen überprüfbaren Nachweis, wozu eingewilligt wurde, von wem, wann und für welche Zwecke. Diese Audit-Funktion kann nicht im Browser angesiedelt sein. Sie verlangt eine unabhängige Schicht, die jede Einwilligungsentscheidung aufzeichnet, durchsetzt und verantwortet.
Browser dürfen nicht zu den neuen Torwächtern werden.
Der Browsermarkt wird von einer Handvoll nicht-europäischer Unternehmen kontrolliert: Google, Apple, Microsoft. Jede Einwilligungsarchitektur, die Signale ausschließlich über Browser-Anbieter leitet, droht die Kontrolle über Europas Einwilligungsinfrastruktur ausgerechnet bei jenen Unternehmen zu bündeln, die der DMA in Schranken weisen sollte. Der Standard muss offen und technologieneutral sein.
Systemweite Dialoge zerstören die Einwilligungsraten.
Als Apple 2021 die App Tracking Transparency einführte, lehnten rund 80 % der Nutzer auf Systemebene ab. Das ist kein Problem der Schnittstellengestaltung. Es ist das, was geschieht, wenn Einwilligung von einem konkreten, vertrauten Dienst weg in einen generischen Systemdialog verschoben wird. Jeder browserweite Mechanismus läuft Gefahr, dieselbe Dynamik zu reproduzieren, mit direkten Folgen für europäische Verlage und Werbetreibende.
// navigator.consent.governance
Getragen von der European CMP Association
navigator.consent wird von der European CMP Association (ECMPA) getragen. Der Verband vertritt die CMP-Anbieter, die heute auf dem größten Teil des europäischen Webs die Einwilligung abwickeln: Axeptio, Didomi, iubenda, Usercentrics und andere. Wir haben die Spezifikation geschrieben, weil wir es sind, deren Produkte sie umsetzen müssten.
Die Spezifikation wird von der ECMPA im Rahmen ihres Auftrags entwickelt, CMP-Anbieter in EU-Politik und Standardisierung zu vertreten.
Browser-Anbieter, Einwilligungsassistenten, Verlage, andere Branchenorganisationen und die Zivilgesellschaft sind eingeladen, sich an der Spezifikation und am Governance-Prozess zu beteiligen.
Die Spezifikation ist ein offener RFC, veröffentlicht zur Überprüfung und Kommentierung. Rückmeldungen aus allen Teilen des Ökosystems sind willkommen.
UnterstützungSie unterstützen
Sie unterstützen navigator.consent
Die unten zitierten Personen liefern Cookie-Banner aus, bauen die Erweiterungen, die sie wegklicken, oder beides. Sie wissen, welche Teile dieser Spezifikation sie tatsächlich selbst schreiben müssten.
Consent-Plattformen
Einwilligungsassistenten
Unternehmen
“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.”
Häufig gestellte Fragen
Was ist navigator.consent?
Eine vorgeschlagene Browser-API, die als neutrale Koordinierungsschicht zwischen Consent Management Platforms (CMPs) und Browsererweiterungen für Einwilligungsassistenz fungiert. Sie bietet beiden Seiten eine gemeinsame, strukturierte Schnittstelle, anstatt Erweiterungen zu zwingen, das DOM jeder einzelnen CMP zu reverse-engineeren.
Wie unterscheidet sich das von Global Privacy Control?
GPC hat bewiesen, dass Datenschutzsignale auf Browser-Ebene im großen Maßstab funktionieren. Es sendet eine binäre Opt-out-Präferenz an jede Website, die der Nutzer besucht. navigator.consent fügt darauf eine strukturierte Schicht für anbieter- und zweckbezogene Einwilligung hinzu. Nutzerforschung zeigt durchgehend, dass Menschen kontextbezogene Entscheidungen treffen, kein pauschales Opt-out oder Opt-in. Die beiden ergänzen sich: GPC als Grundlinie, navigator.consent für Granularität.
Wie fügt sich das IAB Transparency and Consent Framework in dieses Modell ein?
Das TCF arbeitet bereits mit Zwecken, Anbietern, Rechtsgrundlagen und Regulierungen; mit GPP sogar noch umfassender. Seine technischen Komponenten (der __tcfapi-Stub und der TC String) sind für die Interoperabilität mit dem Werbe-Ökosystem konzipiert, nicht mit dem Browser. Einen TC String zu dekodieren und die Registrierungsmethoden von navigator.consent aufzurufen, ist unkompliziert. Die API ersetzt das TCF nicht: Sie gibt dem TCF eine für den Browser lesbare Schnittstelle. Sie deckt auch ab, was das TCF nicht leistet: imperative Befehle zum Setzen von Präferenzen. Das getTCData des TCF ist nur lesend; navigator.consent unterstützt Lesen und Schreiben.
Wer kontrolliert meine Einwilligungsdaten?
Die CMP behält die volle Kontrolle über die Einwilligungsspeicherung, die Compliance-Logik und die nachgelagerte Signalisierung. Die API verschiebt lediglich Bytes zwischen den Beteiligten. Sie kann niemanden überstimmen. Browser-Anbieter haben weder Einblick in noch Kontrolle über Einwilligungsentscheidungen.
Funktioniert das auf Mobilgeräten?
Die API ist auf Browser-Ebene angesiedelt und würde in jedem mobilen Browser funktionieren, der sie implementiert. Zwei Hürden bleiben: Einwilligungsassistenten sind derzeit Browser-Erweiterungen, und mobile Plattformen schränken Erweiterungen stark ein oder verbieten sie ganz. Hinzu kommen Webviews, die in Apps eingebetteten Sandbox-Browser, die ebenfalls Zugang zum Extension-Kontext bräuchten, damit Einwilligungsassistenten dort arbeiten können.
Fügt das nicht Komplexität hinzu, obwohl das Ziel Vereinfachung ist?
Der Integrationsaufwand liegt bei drei Browser-Anbietern (Google, Apple, Microsoft), die bereits täglich komplexe Web-Plattform-APIs verwalten. Für alle anderen bedeutet es Vereinfachung. Nutzer surfen wie gewohnt weiter, können aber optional einen Einwilligungsassistenten nutzen, um seltener mit Consent-Oberflächen konfrontiert zu werden. Unternehmen behalten ihre CMP; manche Besucher bringen einen Assistenten mit, der automatisch gültige Einwilligungsnachweise liefert. Für Gesetzgeber ist die Botschaft greifbar: Installieren Sie einen Assistenten, und die Cookie-Banner verschwinden. Das Modell fügt sich außerdem nahtlos in das Konzept der europäischen digitalen Identitätsbrieftasche ein: ein persönlicher Agent, der Ihre Präferenzen von Dienst zu Dienst mitträgt.
Welche Auswirkungen hat das auf die Performance?
Ein Einwilligungsassistent antwortet immer schneller als ein Mensch. Er reagiert nicht auf jeder Seite, sondern nur dann, wenn der Nutzer ohnehin gefragt worden wäre. Da Speicherung und Gültigkeitsdauer der Einwilligung in der Verantwortung der CMP verbleiben, springt der Assistent nur ein, wenn ein Mensch hätte entscheiden müssen. Unter dem Strich bedeutet das weniger UI-Roundtrips, nicht mehr.
Was passiert, wenn kein Einwilligungsassistent installiert ist?
Nichts ändert sich. Die CMP funktioniert genau wie bisher: Sie zeigt ihr Banner, erfasst die Entscheidungen und speichert die Einwilligung. Die API ist rein additiv. Sie bietet CMPs einen strukturierten Kanal zur Veröffentlichung von Metadaten und zum Empfang von Präferenzen, aber wenn kein Assistent zuhört, behält die CMP die volle Kontrolle. Keine Nutzererfahrung verschlechtert sich.
Kann ein Einwilligungsassistent meine Entscheidungen ohne mein Wissen ändern?
Die API setzt Herkunftskontrolle durch: Präferenzen, die der Nutzer direkt setzt, haben immer Vorrang vor denen eines Assistenten. Jede Änderung wird mit Quelle und Zeitstempel protokolliert, und technisch versierte Nutzer können den vollständigen Audit-Trail einsehen. Vertrauen ist allerdings keine Einbahnstraße. Schon heute hindert nichts eine CMP daran, das eine zu sagen und das andere zu tun. Und selbst wenn die CMP ehrlich arbeitet, ist das, was nachgelagert passiert, ein anderes Thema: Tag-Manager, CMS-Plugins und clientseitiger Code können Tracker unabhängig davon auslösen, was die Einwilligungsschicht entschieden hat. Die API löst dieses Problem nicht, aber sie macht die Einwilligungsschicht selbst transparent und prüfbar, was mehr ist, als der heutige Zustand bietet.
Ist das ein W3C-Standard?
Noch nicht. Es handelt sich um einen offenen Vorschlag im RFC-Stil. Die Spezifikation ist öffentlich verfügbar, und wir begrüßen Feedback von Implementierern, Forschern und Gesetzgebern.