navigator.geolocation
Der Browser stellt den Gerätestandort bereit. Websites fragen ihn an, Nutzer genehmigen ihn. Der Browser entscheidet nie, wann der Standort benötigt wird.
Eine dünne Transportschicht, kein Einwilligungsprodukt
Die Regulierung fordert Browser auf, Einwilligung zu verarbeiten. navigator.consent ermöglicht es Ihnen, diese Pflicht zu erfüllen, ohne Einwilligungs-Gatekeeper zu werden. Sie stellen die Infrastruktur bereit. CMPs und Einwilligungsassistenten erledigen den Rest.
Konvergierender regulatorischer Druck
Einwilligungspflichten für Browser kommen von beiden Seiten des Atlantiks. Die Frage ist nicht ob, sondern wie.
GPC gibt Ihnen navigator.globalPrivacyControl, ein binäres Opt-out-Signal. navigator.consent erweitert dasselbe navigator.*-Muster von einem binären Signal zu granularer, zweckspezifischer Einwilligungskoordination, die den Bestimmtheitsanforderungen der DSGVO genügt.
California Opt Me Out Act
AB 566 (unterzeichnet Oktober 2025) verpflichtet alle großen Browser, bis zum 1. Januar 2027 eine integrierte Global Privacy Control-Funktionalität bereitzustellen.
EU Digital Omnibus
Artikel 88b(6) verpflichtet Nicht-KMU-Browser-Anbieter, technische Mittel bereitzustellen, mit denen Nutzer ihre Einwilligung über maschinenlesbare Signale erteilen oder verweigern können.
Vorschlag DevTools: ein Consent-Panel
Ein dedizierter Consent-Tab in den DevTools, analog zu Application oder Network, würde Entwicklern und Regulierungsbehörden Echtzeit-Einblick in den Einwilligungsstatus geben. Eine Chance zur Browser-Differenzierung, keine Verpflichtung.
| registrationId | reg_a1b2c3 |
| provenance | cmp |
| status | Aktiv |
| zwecke | 3 |
| anbieter | 3 |
Zwecke
| Zweck | Rechtsgrundlage | Einwilligung | Gesetzt von |
|---|---|---|---|
| Analytics | legitimate_interest | granted | privacy_assistant |
| Advertising | consent | denied | user |
| Functional | legitimate_interest | granted | cmp |
Anbieter
| 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 | — |
Für Entwickler
Inspizieren Sie aktive Registrierungen, Anbieterkataloge, Zweckdeklarationen und den Echtzeit-Präferenzstatus mit Herkunftszuordnung. Debuggen Sie Event-Flüsse und erkennen Sie häufige Fehler, wie den Aufruf von Extension-only-Methoden aus dem DOM-Kontext.
Für Regulierungsbehörden
Die Audit-Zeitleiste bietet ein chronologisches Protokoll jeder Einwilligungsänderung: wer sie gesetzt hat, wann und was geändert wurde. Ein Werkzeug zur Compliance-Verifizierung, das dem gesamten Ökosystem zugutekommt.
Ein vertrautes Muster
navigator.consent folgt demselben Design wie Web-APIs, die Sie bereits ausliefern:
navigator.permissions
Der Browser verfolgt, welche Berechtigungen erteilt wurden, und setzt die Grenze zwischen gewährt und verweigert durch. Er wählt nicht für den Nutzer.
CSP / CORS
Websites deklarieren, welche Origins und Ressourcen erlaubt sind. Der Browser setzt diese Deklarationen durch. Keine Interpretation, nur Richtliniendurchsetzung.
navigator.consent ist die gleiche Art von Ding: Der Browser stellt den Namespace bereit, setzt Berechtigungsgrenzen zwischen DOM- und Extension-Kontexten durch, leitet die Herkunft aus dem Laufzeitkontext ab und dispatcht Events. Er trifft keine Einwilligungsentscheidungen.
Berechtigungsgrenzen
Der Browser setzt eine saubere Trennung zwischen DOM-Kontext (Seitenskripte) und Extension-Kontext (Einwilligungsassistenten) durch. Die Herkunft wird aus dem Laufzeitkontext abgeleitet. Aufrufer können sie nicht fälschen.
| Fähigkeit | DOM-Kontext | Extension-Kontext |
|---|---|---|
| Interfaces, Anbieter, Zwecke registrieren | Erlaubt | Abgelehnt |
| Anbieter-/Zweck-Metadaten lesen, ein-/ausblenden, prüfen | Abgelehnt | Erlaubt |
| Präferenzen aktualisieren, widerrufen, Events abhören | Erlaubt | Erlaubt |
| Regulierungskontext lesen | Erlaubt | Erlaubt |
| Regulierungskontext überschreiben | Abgelehnt | Erlaubt |
Aktualisierungen mit Nutzer-Herkunft gewinnen immer. Zwischen CMP und Assistent (wenn kein Wert mit Nutzer-Herkunft existiert) gilt das Last-Write-Wins-Prinzip. Der Browser leitet die Herkunft automatisch aus dem Ausführungskontext des Aufrufers ab.
Über die Einwilligung hinaus: kooperative Cookie-Durchsetzung
Wenn CMP-Registrierungen deklarieren, welche Anbieter-Domains eine Einwilligung haben, verfügt der Browser über genügend Informationen, um Cookie-Richtlinien auf Netzwerkebene durchzusetzen. Drittanbieter-Cookies von Domains ohne passendes Einwilligungssignal könnten bei Set-Cookie blockiert oder bei der Navigation gelöscht werden, ähnlich wie CSP nicht autorisierte Skriptquellen blockiert. Eingewilligte Anbieter funktionieren weiter. Nicht eingewilligtes Tracking stoppt an der Grenze.
Wofür Sie nicht verantwortlich wären
navigator.consent ist eine Transportschicht. Der Browser trägt Nachrichten, er interpretiert sie nicht. Das bedeutet, die Verantwortung des Browsers endet an der API-Grenze.
Keine Einwilligungs-UI
Die CMP präsentiert die Einwilligungsoberfläche, nicht der Browser. Keine Designentscheidungen, keine Haftung für Dark Patterns.
Keine Einwilligungsentscheidungen
Die API ist Transport. Sie trägt Signale zwischen CMPs und Einwilligungsassistenten, ohne sie zu interpretieren oder zu überschreiben.
Keine Compliance-Last
Die CMP besitzt Audit-Trails, Rechtsgrundlagen und regulatorische Nachweise. Der Browser ist nicht das führende System.
Keine Anbieterkuratierung
Offenes Registrierungsmodell. Keine Positivlisten, keine Attestierungsbarrieren, keine Gatekeeping-Verantwortung.
Spezifikation erkunden
RFC-Quelle
Die vollständige Spezifikation.
JSON Schemas
Maschinenlesbare Payload-Definitionen für alle API-Typen.
Shim-Demo
Ein funktionierender Polyfill zum Experimentieren.