LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /Data Privacy / Privacy Sandbox nach den Streichungen: Welche Techniken...
Diesen Artikel in anderen Sprachen lesen:

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

Privacy Sandbox nach den Streichungen: Welche Techniken Chrome behält und was das für die Messung heißt
Inhalt
  1. CHIPS, Storage Access und FedCM bleiben wichtige Bausteine
  2. Die Gründe ergeben sich nicht allein aus einer technischen Trennlinie
  3. CHIPS trennt Cookies nach der übergeordneten Site
  4. Storage Access: Berechtigung und einzelne Aktivierung unterscheiden
  5. FedCM vermittelt Anmeldung, nicht pauschale Datenschutz-Einwilligung
  6. Folgen für bestehende Messungen und Einbettungen
  7. Fragen und Antworten
  8. 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.

Acht Einträge in der Entfernungskategorie, einschließlich Aggregation Service; drei Beispiele aus der größeren Unterstützungsgruppe. IP Protection hat einen gesonderten Status.
Acht Einträge in der Entfernungskategorie, einschließlich Aggregation Service; drei Beispiele aus der größeren Unterstützungsgruppe. IP Protection hat einen gesonderten Status.

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.

TechnikAufgabeWichtige GrenzeErste Chrome-Version
CHIPSCookie-Zustand je Top-Level-SiteKeine automatische gemeinsame Cookie-Nutzung verschiedener Sites114
Storage Access APIUnpartitionierten Speicherzugriff anfordernBerechtigung und Browserbedingungen; nicht immer ein neuer Dialog119
FedCMVom Browser vermittelte föderierte AnmeldungKeine pauschale Einwilligung für zusätzliche Verarbeitung108

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.

Text
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() sowie fencedframe-Elemente.
  • Markup und Antworten: attributionsrc, Attribution-Reporting-Register-Source und Attribution-Reporting-Register-Trigger.
  • Permissions Policy: Direktiven wie browsing-topics, join-ad-interest-group, run-ad-auction und attribution-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.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Beobachtungen aus anderen Umsetzungen, Einwände und Rückfragen sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.