Getragen von der European CMP Association (ECMPA)

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.

Die CMP registriert sich beim Browser.

Worum es geht

Warum Interoperabilität entscheidend ist

Der Digital Omnibus in seiner derzeitigen Ausgestaltung weist strukturelle Probleme auf. Insbesondere Artikel 88b enthält Lücken, die eine ergänzende Interoperabilitätsschicht erfordern, damit er in der Praxis funktioniert.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Drei Lücken, die der Omnibus übersieht.

    Browser- und Betriebssystemanbieter unterlaufen schon heute gespeicherte Einwilligungen durch Mechanismen wie Safaris ITP, das Einwilligungseinträge nach 7 Tagen stillschweigend löscht. Die derzeitige Medienausnahme erzeugt ein Kohärenzproblem: Wenn große Inhalteplattformen maschinenlesbare Signale ignorieren dürfen, lernen Nutzer schnell, dass ihre Präferenzen nicht überall greifen. Und der 24-monatige Umsetzungshorizont setzt einen harmonisierten Standard voraus, der noch gar nicht entworfen ist.

Aktueller Stand

Work in Progress. Offen für Rückmeldungen.

Diese Spezifikation ist der aktive Beitrag der ECMPA zu einer besseren Koordination zwischen den Einwilligungsakteuren. Wir teilen sie jetzt, um Rückmeldungen von Implementierern, Gesetzgebern und Normungsgremien einzuholen, bevor sie sich verfestigt.

status
Entwurf. Offen für Prüfung und Kommentar.
trägerschaft
European CMP Association (ECMPA), Brüssel
standards
Im Austausch mit CEN, ETSI und W3C
aktualisiert
Mai 2026
// 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.

[ nutzer-kontrollebene ]

Nutzer

Hält die Präferenzen.

[ einwilligungsassistent ]optional

Einwilligungsassistent

Handelt im Auftrag des Nutzers.

[ browser-transport ]

Browsernavigator.consent

Implementieren navigator.consent.

[ compliance-ebene ]

CMP

Führendes System.

[ verantwortlicher ]

Website

Dort, wo der Nutzer tatsächlich ist. Stellt Inhalte bereit, bindet die CMP ein, fungiert als Verantwortlicher.

// 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.

Wir bringen sie zu CEN, ETSI und W3C als konkreten Vorschlag für den Standard nach Artikel 88b(4), nicht als fertiges Werk.

Browser-Anbieter, Einwilligungsassistenten, Verlage, andere Branchenorganisationen und die Zivilgesellschaft sind eingeladen, sich an der Spezifikation und am Governance-Prozess zu beteiligen.

Wir arbeiten außerdem an einem Verhaltenskodex nach Artikel 40 DSGVO. Er wird schriftlich festhalten, wie ein ehrlicher Einwilligungsagent aussieht, was eine CMP tun darf und welche Dark Patterns für uns alle tabu sind.

Mehr über die ECMPA erfahren →

Unterstützung

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.

Mitglieder der European CMP Association

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.

Consent-Plattformen

Einwilligungsassistenten

Unternehmen

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.

Müssen Browser-Anbieter dafür etwas ausliefern?

Ja. Wenn die Spezifikation angenommen wird, würden Browser-Anbieter die API nativ implementieren. Ein JavaScript-Polyfill existiert zu Demonstrations- und Prototyping-Zwecken, doch das Ziel ist ein Primitiv auf Browser-Ebene, kein Userland-Shim. Wir stehen im Austausch mit Browser-Anbietern und Normungsgremien als Teil des Verfahrens nach 88b(4).

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.

Welche Cybersicherheitsmaßnahmen gibt es für Einwilligungsassistenten?

Die Datenschutzbehörden sind dafür verantwortlich sicherzustellen, dass Einwilligungsassistenten die DSGVO und ePrivacy einhalten, genau wie sie heute CMPs beaufsichtigen. Bei Cyberrisiken (Datenidentitätsdiebstahl, Manipulation des Nutzerbereichs) schreiben die Browser-Erweiterungsstores bereits Sicherheitsprüfungen, Code-Signierung und Berechtigungsdeklarationen vor. Diese Kontrollen gelten schon heute. Eine spezifische Bestimmung in Artikel 88b könnte eine strengere Überprüfung für Erweiterungen vorschreiben, die Einwilligungsdaten verarbeiten und damit über die allgemeinen Store-Richtlinien hinausgehen.

Werden Browser-Plattformen nicht ihren eigenen Einwilligungsassistenten durchsetzen?

Das ist ein berechtigtes Souveränitäts- und Wettbewerbsanliegen. Dennoch bleibt es eine geringere Machtkonzentration, als wenn Browser die Einwilligung direkt verwalten würden, was die aktuelle Omnibus-Richtung vorsieht. Mit einer offenen API können unabhängige europäische Unternehmen über Qualität und Vertrauen konkurrieren. Die Verpflichtung zu einem Auswahlbildschirm für Einwilligungsassistenten (wie bei den Suchmaschinen unter dem DMA) würde sicherstellen, dass Nutzer Alternativen sehen. Wir setzen auf freien Wettbewerb und sind überzeugt, dass spezialisierte, unabhängige Assistenten einen besseren Service bieten können als eine in den Browser eingebaute Standardlösung.

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.

Wie kann ich es ausprobieren?

Die interaktive Demo führt den Polyfill in Ihrem Browser aus und führt Sie durch den CMP-Registrierungs-, Metadaten-Lese- und Einwilligungsaktualisierungsprozess.

To:Umsetzer des Einwilligungsmanagements
From:ECMPA Editorial Group
Re:navigator.consent · Bitte um Beteiligung

Widersprechen Sie. Oder treiben Sie es voran.

Über den Omnibus wird so oder so abgestimmt. Die Frage ist, was am Ende darin steht. Wenn Sie an einer CMP arbeiten, eine Einwilligungs-Erweiterung ausliefern, einen Browser betreiben oder im Parlament sitzen, sind die kommenden Monate jener Moment, in dem die Struktur festgelegt wird.