Online-Einwilligung funktioniert nicht,
aber das lässt sich ändern

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.

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.

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.

Die CMP behält die volle Kontrolle über die Einwilligungsspeicherung, die Compliance-Logik und die nachgelagerte Signalisierung. Die API ist eine Lese-/Schreib-Transportschicht. Sie koordiniert, sie überschreibt nicht.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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