Browser-API
navigator.consent ist eine dünne, neutrale API — wie navigator.geolocation. CMPs deklarieren ihre Anbieter und Zwecke in strukturierten Daten. Kein undurchsichtiges Tracking mehr: Jeder Akteur legt offen, was er verarbeitet und warum.
Einwilligungsermüdung ist real, und Regulierung hat dazu beigetragen. Die Digitalrichtlinie (Omnibus) will das beheben — aber das vorgeschlagene Mittel birgt das Risiko, Macht bei einer Handvoll Browser-Anbieter zu konzentrieren, die sie lieber nicht hätten. Ein dritter Weg ist möglich: eine offene Interoperabilitätsschicht, in der jeder Akteur seine Karten offenlegt und Nutzer wählen, wer in ihrem Namen handelt.
334 Mio. Stunden/Jahr. ITP löscht Einwilligungs-Cookies, WebViews starten bei Null, und Banner tauchen ständig wieder auf. Unternehmen, die auf Cookie-Einwilligung angewiesen sind, drängen auf manipulative Designs (Dark Patterns, Gewöhnung, Schuldgefühle).
Hängt vollständig von der CMP ab. Gute bieten echte Wahlmöglichkeiten; schlechte nutzen Dark Patterns, um Nutzer zu „Alle akzeptieren“ zu lenken. Datenschutzorientierte Erweiterungen oder Techniken wie ATT oder ITP treiben Anbieter zu serverseitigem und nicht offengelegtem Tracking.
Publisher können mit informierter Einwilligung arbeiten. Das Modell funktioniert, auch wenn es ungleichmäßig ist.
Gute CMPs bieten Auswahl pro Anbieter und pro Zweck. Schlechte präsentieren eine Textwand und einen großen Button. Das Ausmaß des Trackings ist manchmal so groß, dass es überwältigend wird.
Regulierungsbehörden müssen die proprietären Aufzeichnungen jeder CMP einzeln prüfen.
Fragiles Gleichgewicht zwischen Datenschutzbehörden, CMPs, Berufsverbänden (IAB TCF) und Datenschutzaktivisten
Diese Architektur baut auf dem Fundament von GPC auf und fügt die Granularität hinzu, die die DSGVO verlangt: strukturierte, maschinenlesbare und prüfbare Einwilligungskoordination über drei Schichten.
Der Integrationsaufwand liegt bei drei Browser-Anbietern, die bereits täglich komplexe Web-Plattform-APIs verwalten. Für Nutzer ändert sich nichts; sie können lediglich optional einen Einwilligungsassistenten nutzen, um weniger Consent-Banner zu sehen. Für Unternehmen orchestriert die CMP weiterhin die Einwilligung; manche Besucher kommen einfach mit bereits hinterlegten Präferenzen. Für Gesetzgeber ist die Botschaft greifbar: Installieren Sie einen Assistenten, und die Cookie-Banner verschwinden. Das Modell fügt sich zudem nahtlos in das Konzept der europäischen digitalen Identitätsbrieftasche ein: ein persönlicher Agent, der verifizierte Präferenzen von Dienst zu Dienst mitträgt.
navigator.consent ist eine dünne, neutrale API — wie navigator.geolocation. CMPs deklarieren ihre Anbieter und Zwecke in strukturierten Daten. Kein undurchsichtiges Tracking mehr: Jeder Akteur legt offen, was er verarbeitet und warum.
Nutzer wählen einen Einwilligungsassistenten aus einem Auswahlbildschirm (wie bei der DMA-Suchmaschinenauswahl). Erweiterungen wie Consent-o-matic, SuperAgent und Taste nutzen die API, um Präferenzen granular anzuwenden. Dies schafft einen wettbewerbsfähigen europäischen Markt für Datenschutzinnovation.
CMPs bleiben verantwortlich für kontextbezogene Informationen, Audit-Trails, anbieterspezifische Anweisungen und regulatorische Compliance. Der Assistent kommuniziert mit der CMP, nicht an ihr vorbei. Ein Browsersignal allein kann diese Funktionen nicht erfüllen.
Der Digital Markets Act stuft Webbrowser als zentrale Plattformdienste ein (Erwägungsgrund 14). Im September 2023 hat die Europäische Kommission Google Chrome und Safari als zentrale Plattformdienste von Torwächtern benannt. Die Union erkennt damit bereits an, dass diese Browser wesentliche Zugangspunkte sind, über die gewerbliche Nutzer Endnutzer erreichen; ihre Regulierung im Sinne von Bestreitbarkeit und Fairness ist folgerichtig.
Die Einwilligungsschicht liegt unmittelbar auf diesen benannten zentralen Plattformdiensten. Würde ein Browser-Anbieter ein einzelnes Einwilligungsmodell zentralisieren oder aufzwingen, übte er damit direkte Kontrolle über eine Zugangsbedingung zum digitalen Markt aus. Einwilligung ist keine Nebenfunktion: Sie ist das Tor, durch das jede Datenverarbeitungsbeziehung beginnt.
navigator.consent als technische Verlängerung der im DMA verankerten Grundsätze der Interoperabilität und Bestreitbarkeit verstehen.Diese Einordnung ist für Artikel 88b von Bedeutung. Anstatt ein neues Einwilligungsregime zu schaffen, das die Macht bei den benannten Torwächtern konzentriert, sollte die Digitalrichtlinie (Omnibus) auf dem aufbauen, was der DMA bereits festlegt: dass Browser kritische Infrastruktur sind, die offene, pluralistische und nicht vereinnahmbare Schnittstellen erfordern. navigator.consent organisiert genau dies: eine neutrale Koordinationsschicht, die sicherstellt, dass die Einwilligungserfahrung auch auf Browser-Ebene bestreitbar bleibt.
Artikel 88b(6) fordert Browser-Anbieter auf, Einwilligungsmanagement in ihre Produkte einzubauen. Die Absicht ist richtig, aber die Architektur schafft Konzentrationsrisiken, die schwer rückgängig zu machen sind — und die die Browser-Anbieter selbst lieber vermeiden würden.
Wer die Einwilligungsoberfläche gestaltet, beeinflusst das Ergebnis. Wenn vier Browser-Anbieter die Erfahrung für alle EU-Nutzer gestalten, würden wenige Designentscheidungen die Einwilligungsraten im gesamten europäischen Internet bestimmen.
Ein browserweiter Schalter für „Tracking akzeptieren/ablehnen“ kann Artikel 4(11) nicht erfüllen, der verlangt, dass die Einwilligung spezifisch und informiert sein muss — bezogen auf bestimmte Zwecke und Verarbeiter. Ein Nutzer, der den Analytics seines Bankinstituts vertraut, hat keinen Grund, dieselbe Präferenz auf ein unbekanntes Werbenetzwerk anzuwenden.
Plattformen mit eingeloggten Nutzern behalten First-Party-Daten unabhängig von jedem Signal. Unabhängige Publisher, europäisches SaaS, E-Commerce und Analyseanbieter, die auf informierte, spezifische Einwilligung angewiesen sind, tragen die volle Last.
Den Bau einer Einwilligungs-UX bedeutet, Designentscheidungen zu treffen, die Compliance-Ergebnisse beeinflussen. Browser-Anbieter würden lieber neutrale Infrastruktur bereitstellen, als Einwilligungs-Gatekeeper mit regulatorischer Exponierung zu werden.
Der eigene Mechanismus der Omnibus-Richtlinie — Signale auf Browser-Ebene — versagt in In-App-Browsern, in denen Erweiterungen nicht laufen. Die größte Quelle der Einwilligungsermüdung bleibt von der vorgeschlagenen Lösung unberührt.
Global Privacy Control hat bewiesen, dass Datenschutzsignale auf Browser-Ebene im großen Maßstab funktionieren: über 150 Millionen Nutzer, rechtliche Absicherung in Kalifornien und eine W3C-Spezifikation. AB 566 (unterzeichnet Oktober 2025) verpflichtet alle großen Browser, bis zum 1. Januar 2027 integriertes GPC auszuliefern. Das ist ein großer Erfolg.
Wenn der EU-Signalstandard ein binäres Modell übernimmt, ist das Ergebnis ein einzelner Schalter, der einheitlich auf jede Website und jeden Anbieter angewendet wird. Publisher, E-Commerce- und SaaS-Unternehmen hätten keine Möglichkeit, zwischen einem Nutzer, der Retargeting ablehnt, und einem, der mit funktionaler Analyse einverstanden ist, zu unterscheiden.
Die Chance liegt darin, auf dem Fundament von GPC aufzubauen. GPC legt die Opt-out-Grundlinie fest; navigator.consent fügt darauf einen strukturierten, zweckspezifischen Einwilligungskanal hinzu. Der EU-Standardisierungsprozess gemäß Artikel 88b(4) kann auf beides zurückgreifen: ein einfaches Basissignal und eine granulare Koordinationsschicht für informierte Einwilligung.

Ohne eine strukturierte Interoperabilitätsschicht ist die rationale Antwort der Branche auf den Einwilligungsdruck, undurchsichtig zu werden: serverseitiges Tracking, Fingerprinting, deterministische IDs, Gated Content. navigator.consent kehrt diesen Anreiz um — wenn Sie Anbieter und Zwecke über einen strukturierten Kanal deklarieren, wird Durchsetzung möglich.
| registrationId | reg_a1b2c3 |
| provenance | cmp |
| status | Aktiv |
| zwecke | 3 |
| anbieter | 3 |
| Zweck | Rechtsgrundlage | Einwilligung | Gesetzt von |
|---|---|---|---|
| Analytics | legitimate_interest | granted | privacy_assistant |
| Advertising | consent | denied | user |
| Functional | legitimate_interest | granted | cmp |
| Name | Domain | Zwecke | Einwilligung | Gesetzt von |
|---|---|---|---|---|
| Analytics Co | analytics.example | analytics | granted | privacy_assistant |
| AdNetwork | ads.example | analytics, advertising | denied | user |
| Social Widget | social.example | functional | pending | — |
Jede Einwilligungsänderung wird mit Herkunft und Zeitstempeln protokolliert. Regulierungsbehörden können genau sehen, was gesetzt wurde, von wem und wann — ohne sich allein auf die Selbstauskunft der CMP zu verlassen.
Die API verfolgt, ob eine Präferenz vom Nutzer, einem Einwilligungsassistenten oder der CMP gesetzt wurde. Nutzerentscheidungen haben immer Vorrang. Kein Akteur kann einen anderen stillschweigend überschreiben.
Serverseitiges Tracking, Fingerprinting und deterministische IDs sind für aktuelle Durchsetzungswerkzeuge unsichtbar. Eine strukturierte API zieht Datenverarbeitungsdeklarationen zurück in die Öffentlichkeit, wo Regulierungsbehörden sie überprüfen können.
Die Datenschutzbehörden sind dafür verantwortlich sicherzustellen, dass Einwilligungsassistenten die DSGVO und ePrivacy einhalten: genau wie sie bereits CMPs beaufsichtigen. Das ist kein neuer Regulierungsmechanismus, sondern die Erweiterung bestehender Aufsichtsbefugnisse auf eine neue Akteurskategorie.
Bei Cyberrisiken wie Datenidentitätsdiebstahl oder Manipulation des Nutzerbereichs schreiben die Browser-Erweiterungsstores bereits Sicherheitsprüfungen, Code-Signierung und Berechtigungsdeklarationen vor, bevor eine Erweiterung die Nutzer erreicht. Diese Kontrollen gelten schon heute und greifen bei Einwilligungsassistenten unmittelbar.
Eine spezifische Bestimmung in Artikel 88b könnte weiter gehen: eine strengere Überprüfung für Erweiterungen vorschreiben, die Einwilligungsdaten verarbeiten und damit über die allgemeinen Store-Richtlinien hinausgehen. Das gäbe den Aufsichtsbehörden einen zusätzlichen Hebel, ohne einen völlig neuen Aufsichtsrahmen schaffen zu müssen.
Artikel 88b(4) beauftragt europäische Normungsorganisationen mit der Erarbeitung von Standards für maschinenlesbare Einwilligungssignale. Das ist die richtige Richtung — aber der Standard muss die Bestimmtheit bewahren, die Einwilligung unter der DSGVO bedeutsam macht.
Ein Einwilligungssignal muss granulare, zweckspezifische und anbieterspezifische Entscheidungen unterstützen. Das binäre Modell von GPC wurde für das Opt-out nach CCPA konzipiert, nicht für die DSGVO-Einwilligung. Der EU-Standard sollte weiter gehen und kontextbezogene Signale unterstützen, die zwischen Zwecken und Anbietern unterscheiden.
CMP-Anbieter müssen am Standardisierungsprozess teilnehmen. Sie vereinen fundierte juristische Expertise mit praktischem technischen Wissen über Einwilligungserfassung und -signalisierung. Vorsicht ist auch hinsichtlich des IAB Transparency and Consent Framework als Vorlage geboten — es deckt Publisher-Werbung ab, ist aber für E-Commerce, SaaS, Landing Pages und die meisten anderen Online-Dienste ungeeignet.
Die Europäische Kommission schätzt, dass EU-Bürger 334 Millionen Stunden pro Jahr für Cookie-Banner aufwenden. Aber die Ursachen sind technischer Natur, nicht der Einwilligung inhärent — und die Digitalrichtlinie (Omnibus) lässt sie unberührt.
Safaris ITP begrenzt clientseitige Cookies auf 7 Tage. Firefox’ ETP wendet ähnliche Einschränkungen an. Da die meisten CMPs die Einwilligung über document.cookie speichern, werden Ihre Entscheidungen stillschweigend gelöscht — und das Banner erscheint erneut, als hätten Sie nie entschieden.
Ein wachsender Anteil des mobilen Browsings findet innerhalb von Apps statt (Instagram, LinkedIn, Nachrichten-Apps). Diese isolierten WebViews können nicht auf die im Hauptbrowser gespeicherte Einwilligung zugreifen. Jeder Besuch sieht aus wie ein neuer Nutzer — und die Omnibus-Richtlinie schweigt dazu.
Eine Studie aus dem Jahr 2025 ergab, dass 38 % der DSGVO-konformen Banner noch immer ästhetische Manipulation einsetzen — hervorgehobene „Akzeptieren“-Buttons, versteckte Ablehnungsoptionen. Die Lösung ist bessere CMP-Qualität und Durchsetzung, nicht die Abschaffung von CMPs.
Recital 46 befreit Mediendienstleister von der Pflicht, maschinenlesbare Einwilligungssignale zu respektieren. Aber Medienwebsites sind der Ort, an dem die Einwilligungsermüdung am stärksten ist — Nachrichtenseiten laden Dutzende von Werbeanbietern, präsentieren die komplexesten Einwilligungsoberflächen und setzen Cookie-Walls gefolgt von Paywalls ein. Ihre Ausnahme bedeutet, dass die Digitalrichtlinie (Omnibus) die Reibung dort reduzieren würde, wo sie bereits gering ist, und sie dort bewahren würde, wo sie am höchsten ist.
Ändern Sie Artikel 88b(6), um zu verlangen, dass Einwilligungsmechanismen auf Browser-Ebene für unabhängige Einwilligungsassistent-Erweiterungen von Drittanbietern offen sind — nicht beschränkt auf die eingebaute Funktionalität der Browser-Anbieter. Chrome und Safari sind bereits unter dem DMA als zentrale Plattformdienste benannt. Die Öffnung der Einwilligung für konkurrierende Erweiterungen steht im Einklang mit den Bestreitbarkeitspflichten, denen diese Torwächter bereits unterliegen. Erwägen Sie einen verpflichtenden Auswahlbildschirm für Einwilligungsassistenten, wie er für Suchmaschinen eingeführt wurde.
Beziehen Sie CMP-Branchenvertreter in den Standardisierungsprozess gemäß Artikel 88b(4) ein. Legen Sie fest, dass der Standard granulare, zweckspezifische und anbieterspezifische Einwilligung unterstützen muss — keine pauschalen Signale.
Bauen Sie auf dem Erfolg von GPC auf: Übernehmen Sie dessen Opt-out-Grundlinie und erweitern Sie sie um zweck- und anbieterspezifische Einwilligungssignale, die der Bestimmtheitsanforderung der DSGVO genügen. Der Standard sollte kontextbezogene Entscheidungen unterstützen, die je nach Website, Anbieter und Zweck variieren.
Verhindern Sie, dass Recital 46 zu einem Schlupfloch wird, das den einwilligungsintensivsten Sektor vom Kernmechanismus des Rahmens ausnimmt. Jede Ausnahme muss eng definiert sein.
Untersuchen Sie den Browser-Tracking-Schutz (ITP, ETP) und WebView-Sandboxing als strukturelle Treiber wiederholter Aufforderungen. Diese technischen Faktoren — nicht die Existenz von CMPs — sind die Hauptursache der 334 Millionen Stunden, die die Kommission anführt.