Privacy Sandbox nach den Streichungen: Welche Techniken Chrome behält und was das für die Messung heißt

Inhalt
- CHIPS, Storage Access und FedCM bleiben wichtige Bausteine
- Die Gründe ergeben sich nicht allein aus einer technischen Trennlinie
- CHIPS trennt Cookies nach der übergeordneten Site
- Storage Access: Berechtigung und einzelne Aktivierung unterscheiden
- FedCM vermittelt Anmeldung, nicht pauschale Datenschutz-Einwilligung
- Folgen für bestehende Messungen und Einbettungen
- Fragen und Antworten
- Quellen
Die Privacy Sandbox ist kein einheitlicher Schalter für Datenschutz oder Werbung. Google führt einige Techniken weiter, kündigt andere ab und verfolgt weitere Vorschläge nicht mehr. Die am 24. Oktober 2026 geprüfte Statusseite trägt den Aktualisierungsstand 14. August 2026. Die frühere Kurzform „acht gestrichen, drei übrig“ beschreibt diese Übersicht nicht korrekt.
Die Zusammenfassung führt acht Einträge unter „Deprecate and remove“: Aggregation Service, Attribution Reporting, Fenced Frames, Private Aggregation, Protected Audience, Related Website Sets einschließlich requestStorageAccessFor(), Shared Storage einschließlich Select URL und Topics. IP Protection steht dagegen mit Partitioned Popins und Related Website Partition unter „Discontinue“. Weitere Vorschläge sind als „Do not launch“ eingeordnet. Eine solche Statusangabe ist keine Bestätigung, dass jede installierte Chrome-Version dieselbe Schnittstelle bereits entfernt hat.
CHIPS, Storage Access und FedCM bleiben wichtige Bausteine
CHIPS, Storage Access und FedCM gehören zu den weiter unterstützten Techniken, sind aber keine vollständige Restliste. Die Übersicht nennt außerdem unter anderem Private State Tokens, Storage and Network State Partitioning, User-Agent Client Hints und frame-ancestors. Die drei folgenden APIs lösen unterschiedliche Aufgaben; die Versionsnummern markieren die ursprüngliche Chrome-Verfügbarkeit, nicht den Umfang sämtlicher späterer Erweiterungen.
| Technik | Aufgabe | Wichtige Grenze | Erste Chrome-Version |
|---|---|---|---|
| CHIPS | Cookie-Zustand je Top-Level-Site | Keine automatische gemeinsame Cookie-Nutzung verschiedener Sites | 114 |
| Storage Access API | Unpartitionierten Speicherzugriff anfordern | Berechtigung und Browserbedingungen; nicht immer ein neuer Dialog | 119 |
| FedCM | Vom Browser vermittelte föderierte Anmeldung | Keine pauschale Einwilligung für zusätzliche Verarbeitung | 108 |
Die Gründe ergeben sich nicht allein aus einer technischen Trennlinie
Google nennt in der Ankündigung vom 17. Oktober 2025 Rückmeldungen aus dem Ökosystem, erwarteten Nutzen und geringe Nutzung als Gründe für die Einstellung mehrerer Angebote. Für Related Website Sets verweist die Chromium-Ankündigung zusätzlich auf die beibehaltene Cookie-Strategie und geringe beziehungsweise sinkende Nutzung. Eine allgemeine Regel „Partitionierung braucht kein Vertrauen, Listen dagegen zu viel“ ist damit nicht als Entscheidungsgrund belegt.
Related Website Sets sollte begrenzten Zugriff auf unpartitionierte Cookies zwischen zusammengehörigen Sites erleichtern. Dafür waren ein anerkanntes Set und API-Aufrufe erforderlich; eine beliebige selbst veröffentlichte Liste schaltete nicht automatisch freien Zugriff auf alle Domains frei. Die Entfernung von Related Website Sets betrifft auch document.requestStorageAccessFor(), ersetzt aber nicht die weiterhin unterstützte allgemeine Storage Access API.
Ebenso wichtig: Chrome hat Drittanbieter-Cookies nicht generell abgeschafft. Google bestätigte am 22. April 2025 die bestehende Wahlmöglichkeit in den Einstellungen und verzichtete auf einen neuen eigenständigen Abfragedialog. Im Inkognitomodus sind Drittanbieter-Cookies standardmäßig blockiert. Weitere Browser, Einstellungen und Richtlinien können andere Einschränkungen setzen.
CHIPS trennt Cookies nach der übergeordneten Site
Das Attribut Partitioned ergänzt die Cookie-Zuordnung um die übergeordnete Site. Gemeint ist die Kombination aus Schema und registrierbarer Domain, nicht jede einzelne URL und auch nicht zwangsläufig jede Subdomain. Zwei HTTPS-Seiten unter derselben registrierbaren Domain können deshalb derselben Site angehören.
Set-Cookie: __Host-widget=example-value; Path=/; Secure; HttpOnly; SameSite=None; Partitioned; Max-Age=2592000
Vereinfachte Partitionszuordnung (Name/Pfad ausgelassen):
(widget.example, https://shop.example)
(widget.example, https://blog.example)
Getrennte Cookie-Speicher für die beiden Top-Level-Sites.Das Beispiel zeigt einen einzelnen HTTP-Antwortheader und darunter eine vereinfachte Zuordnung. Der vollständige Cookie-Schlüssel umfasst weitere Merkmale, etwa Name und Pfad. Der Beispielwert ist kein einsatzfertiges Sitzungstoken. Secure ist für CHIPS erforderlich; das Präfix __Host- verlangt zusätzlich Path=/ und den Verzicht auf Domain. HttpOnly verhindert den Zugriff über document.cookie.
Max-Age=2592000 bedeutet 30 Tage und ist nur eine beispielhafte Laufzeit. CHIPS ist nicht auf eine Besuchssitzung beschränkt. Lebensdauer und gespeicherter Inhalt müssen zur Funktion passen. Ein Chat oder Zahlungsrahmen kann damit Zustand innerhalb einer Site erhalten; ein vorhandener Ablauf über mehrere Sites benötigt möglicherweise Anpassungen.
Partitionierung verhindert die automatische gemeinsame Nutzung dieses Cookies zwischen verschiedenen Top-Level-Sites. Daraus folgt weder garantierte Anonymität noch ein Verbot anderer zulässiger Kontoverknüpfungen. Der Browser erzeugt auch keine automatisch unterschiedlichen Cookie-Werte: Die Trennung betrifft die Speicherbereiche.
Storage Access: Berechtigung und einzelne Aktivierung unterscheiden
Eine Einbettung kann mit document.requestStorageAccess() Zugriff auf ansonsten blockierte unpartitionierte Cookies beziehungsweise unterstützte Speicherarten anfordern. Der Browser kann den Antrag erlauben oder ablehnen. Beim erstmaligen, zustimmungspflichtigen Zugriff ist häufig eine Interaktion im eingebetteten Inhalt nötig.
Eine neue Geste und ein neuer Dialog sind jedoch nicht bei jedem Aufruf zwingend. Chrome kann eine bereits erteilte Berechtigung wiederverwenden; die Dokumentation nennt 30 Tage und eine Verlängerung durch weitere Interaktion. Zusätzlich kann eine aktive FedCM-Anmeldung unter bestimmten Bedingungen als Vertrauenssignal dienen. Berechtigung und Aktivierung des Zugriffs im jeweiligen Dokument bleiben unterschiedliche Schritte. Details unterscheiden sich zwischen Browsern.
Beim Wegfall der RWS-Abkürzung braucht eine Integration einen passenden alternativen Ablauf, beispielsweise die direkte Anfrage aus dem eingebetteten Dokument. Fehlende Berechtigung oder eine abgelehnte Anfrage müssen als normale Fälle behandelt werden. Ein pauschales „ab jetzt immer wieder klicken“ beschreibt die API nicht richtig.
FedCM vermittelt Anmeldung, nicht pauschale Datenschutz-Einwilligung
FedCM vermittelt zwischen Website und Identitätsanbieter über den Browser und kann Anmeldeabläufe ohne Drittanbieter-Cookies ermöglichen. Herkömmliche föderierte Anmeldung ist dabei nicht generell von Drittanbieter-Cookies abhängig: Ein Weiterleitungsablauf kann Cookies im Erstanbieterkontext verwenden. FedCM erfordert passende Endpunkte beim Identitätsanbieter und Integration auf der Website.
Beim ersten Verknüpfen beziehungsweise Anmelden kann eine Kontoauswahl erscheinen. Für bereits verknüpfte Konten unterstützt FedCM unter bestimmten Voraussetzungen automatische erneute Anmeldung. Ein abgemeldeter Zustand kann je nach Ablauf eine Anmeldung beim Identitätsanbieter erfordern; die pauschale Aussage „ohne bestehende Anmeldung kommt nichts“ ist zu eng. Andere Anmeldewege bleiben für nicht unterstützte Browser und Fehlerfälle erforderlich.
Eine Browserfreigabe oder Kontoauswahl ist nicht automatisch die datenschutzrechtliche Einwilligung für zusätzliche Verarbeitung. Google weist ausdrücklich darauf hin, dass eine gegebenenfalls erforderliche Einwilligung für Zwecke außerhalb der Anmeldung gesondert eingeholt werden muss.
Folgen für bestehende Messungen und Einbettungen
Neue Abhängigkeiten von abgekündigten APIs erhöhen das Wartungsrisiko. Bestehende Integrationen benötigen eine Bestandsaufnahme: Welche Schnittstelle wird tatsächlich aufgerufen, welche Messwerte fallen weg und welcher geprüfte Ersatzablauf ist vorhanden? Entfernung und Rückbau sollten anhand der konkreten Chrome-Version, Anbieterhinweise und Anwendungstests erfolgen.
Nicht jede zustandsbehaftete Einbettung benötigt zwingend Partitioned. Je nach Funktion kommen partitionierte Cookies oder andere partitionierte Speicher, Storage Access, FedCM oder eine Integration im Erstanbieterkontext infrage. Eine serverseitige Verknüpfung eigener Kennungen ist ebenfalls kein universeller Ersatz und macht eine Verarbeitung nicht allein durch die Verlagerung auf einen Server zulässig.
Die weitere Arbeit an einem interoperablen Attribution-Standard wird von Google ausdrücklich erwähnt. Daraus folgt weder ein sofort verfügbarer Ersatz noch das Ende jeder browsergestützten Messung. Auch für weiter unterstützte APIs gibt es keine Garantie unveränderter langfristiger Verfügbarkeit.
Fragen und Antworten
Entfällt durch Partitioned die Einwilligungspflicht?
Nein, das Attribut begründet keine allgemeine Ausnahme. Artikel 5 Absatz 3 der ePrivacy-Richtlinie betrifft Speicherung und Zugriff auf dem Endgerät. Eine Ausnahme kann insbesondere für eine unbedingt erforderliche Funktion eines ausdrücklich angeforderten Dienstes gelten. Dass ein automatisch eingeblendetes Chatfenster technisch ein Cookie benötigt, genügt dafür allein nicht. Zweck, angeforderte Funktion und Laufzeit sind maßgeblich; zusätzliche Trackingzwecke brauchen eine eigene Bewertung nach den anwendbaren Regeln.
Welche Fundstellen zeigen mögliche Alt-Abhängigkeiten?
Eine Bestandsaufnahme umfasst eigenen Code, eingebundene Tags und Antworten der Server:
- Skripte:
document.browsingTopics(),navigator.joinAdInterestGroup(),navigator.runAdAuction(),window.sharedStorage,document.requestStorageAccessFor()sowiefencedframe-Elemente. - Markup und Antworten:
attributionsrc,Attribution-Reporting-Register-SourceundAttribution-Reporting-Register-Trigger. - Permissions Policy: Direktiven wie
browsing-topics,join-ad-interest-group,run-ad-auctionundattribution-reporting. Alte Deklarationen allein beweisen keine aktive Nutzung. - Historische RWS-Konfiguration:
/.well-known/related-website-set.json, Registrierungen und gegebenenfalls Unternehmensrichtlinien. Eine Datei allein belegt keine funktionierende Einbindung.
Ein Treffer belegt eine mögliche Verwendung, noch keinen tatsächlichen Ausfall. Ein Existenztest kann den Aufruf einer fehlenden Funktion verhindern. Für einen weiterhin funktionierenden Ablauf ist zusätzlich ein sinnvoller Ersatzpfad nötig. Asynchrone Fehler und abgelehnte Berechtigungen benötigen ebenfalls Behandlung. Bei fremden Tags gehören Herstelleränderungen und Auswirkungen auf die eigene Anwendung zusammen geprüft.
Quellen
- Google: Statusseite der Privacy Sandbox
- Google: Pläne vom Oktober 2025
- Google: Cookie-Wahl vom April 2025
- Google: CHIPS
- Google: Storage Access API
- Google: Related Website Sets
- Chromium: RWS-Abkündigung und Zeitplan
- Chrome: FedCM-Überblick
- Chrome: FedCM und erneute Anmeldung
- Chrome: Anmeldeabläufe beim Identitätsanbieter
- Artikel-29-Datenschutzgruppe: Stellungnahme 04/2012