Partitioned ist nicht cookie-frei: Was CHIPS bei eingebetteten Diensten wirklich ändert

Ein eingebetteter Chat merkt sich eine Unterhaltung, ein Zahlungs-Widget den Checkout-Schritt, eine Karte eine Einstellung. Genau dafür brauchen manche Drittanbieter Zustand. Problematisch wird es, wenn derselbe Cookie quer über viele fremde Websites wiederverwendet werden kann.

CHIPS – Cookies Having Independent Partitioned State – gibt Browsern dafür eine engere Grenze. Ein Cookie mit Partitioned wird nicht nur nach seinem Cookie-Host, sondern zusätzlich nach der Top-Level-Site getrennt gespeichert. Derselbe eingebettete Dienst kann auf zwei Websites also zwei unabhängige Cookie-Zustände erhalten.

Das ist nützlich. Es bedeutet aber weder „cookie-frei“ noch automatisch „datenschutzkonform“.

Was Partitioned praktisch ändert

Google und PrivacyCG beschreiben CHIPS als Double-Keying: Cookie-Host plus Partition-Key der Top-Level-Site. Für typische Cross-Site-Embeds wird der Cookie mit Partitioned, Secure und meist SameSite=None gesetzt. Google empfiehlt bei hostgebundenen Cookies außerdem das __Host--Präfix.

Der entscheidende Effekt: Ein Cookie, den widget.example innerhalb von shop-a.example setzt, steht derselben Einbettung auf shop-b.example nicht automatisch als derselbe Zustand zur Verfügung.

Damit eignet sich CHIPS besonders für Chat, Karten, Payment-Embeds oder SaaS-Widgets, die lokalen Zustand brauchen, aber keine globale Browser-Identität über unabhängige Websites hinweg.

Drei Audit-Fragen, die schnell Klarheit schaffen

1. Braucht der Dienst lokalen Zustand oder globale Wiedererkennung?

Wenn ein Widget nur innerhalb Ihrer Website Einstellungen oder eine Session halten muss, ist ein global wiederverwendbarer Third-Party-Identifier technisch schwer zu begründen. Prüfen Sie deshalb den Zweck jedes Cookies und nicht nur seinen Namen.

Ein session-Cookie kann lokaler UI-Zustand sein – oder ein globaler Account-Identifier. Der Header allein erklärt das nicht.

2. Was passiert in Browsern ohne wirksames CHIPS?

MDN führt CHIPS inzwischen als Baseline-Feature, weist aber weiterhin auf Unterschiede bei älteren Browsern hin. WebKit hat CHIPS in Safari 26.2 wieder ausgeliefert, nachdem es zwischenzeitlich entfernt worden war. Browser-Speicherverhalten bleibt also ein Kompatibilitätsthema.

Besonders wichtig: Google dokumentiert, dass ein Cookie mit SameSite=None in einem Client ohne Unterstützung für Partitioned als unpartitionierter Third-Party-Cookie verwendet werden kann, sofern Third-Party-Cookies dort grundsätzlich erlaubt sind.

Damit kann ein modernes Setup in aktuellen Browsern eng partitioniert sein und in älteren Clients auf einen breiteren Zustand zurückfallen. Genau dieser Fallback gehört in den Test.

3. Versteht das Backend die neue Identität?

CHIPS ist nicht nur ein Browser-Flag. Wenn ein Backend denselben Cookie-Wert bisher als globale Browser-Identität interpretiert hat, kann Partitionierung Funktionen verändern: Login, Logout, Support-Historie, Rate Limits oder Warenkorbzustand können plötzlich pro Top-Level-Site getrennt sein.

Das kann gewünscht sein. Es muss aber bewusst sein.

Der praktische Zwei-Site-Test

Ein guter Test braucht zwei unterschiedliche Top-Level-Sites mit derselben Einbettung:

1. Öffnen Sie Seite A in einem frischen Browserprofil und erzeugen Sie einen erkennbaren Zustand.
2. Öffnen Sie Seite B mit demselben Drittanbieter.
3. Prüfen Sie, ob B den Zustand aus A sieht.
4. Kehren Sie zu A zurück und prüfen Sie, ob A seinen eigenen Zustand behalten hat.
5. Wiederholen Sie den Test mit einem Client oder Modus, in dem Partitioned nicht unterstützt oder nicht wirksam ist.

Bei korrekt partitioniertem Zustand sollte A seinen eigenen Zustand behalten, während B eine getrennte Partition erhält.

Red Flags

Achten Sie besonders auf diese Muster:

• Derselbe Cookie-Name existiert gleichzeitig partitioniert und unpartitioniert.
• Logout löscht nur eine Variante und alte Sessions bleiben bestehen.
• Das Widget funktioniert nur, weil ein alter globaler Third-Party-Cookie bereits vorhanden ist.
• Partitioned wird in Dokumentation mit „anonym“ oder „kein Tracking möglich“ gleichgesetzt.
• Ein Anbieter kombiniert den partitionierten Cookie serverseitig mit globalen Account- oder Gerätekennungen.
• Niemand hat geprüft, was bei Ablehnung, Zustimmung und späterem Widerruf passiert.

Partitionierung reduziert die Reichweite eines Cookie-Zustands. Sie verhindert nicht automatisch andere Formen der Wiedererkennung oder serverseitigen Korrelation.

CHIPS oder Storage Access API?

CHIPS passt dann gut, wenn Zustand pro Top-Level-Site getrennt bleiben soll. Wenn ein Dienst dagegen bewusst denselben unpartitionierten Account-Zustand über mehrere Sites benötigt, ist CHIPS gerade nicht dafür gedacht. Google verweist für solche Fälle auf die Storage Access API und verwandte Mechanismen.

Die Architekturfrage kommt zuerst: Soll Zustand geteilt werden – oder soll er getrennt bleiben?

Was Website-Pflichtencheck prüfen würde

Ein technischer Cookie- und Embed-Check kann unter anderem erfassen:

• welche Drittanbieter tatsächlich eingebettet werden,
• welche Cookies sie in Produktion setzen,
• ob Partitioned, Secure, SameSite und Host-Scope zusammenpassen,
• ob Zustand zwischen zwei unabhängigen Websites wirklich getrennt bleibt,
• wie ältere Browser oder Fallbacks reagieren,
• ob Session-, Logout- und Löschlogik Partitionen korrekt behandelt,
• wie sich Consent-Änderungen auf Requests und gespeicherten Zustand auswirken,
• ob die technische Dokumentation das reale Browserverhalten beschreibt.

Das Ziel ist nicht, überall ein neues Attribut anzuhängen. Das Ziel ist eine klare Aussage: Welcher Zustand muss existieren, wo darf er wiederverwendet werden und was passiert außerhalb des idealen Browserpfads?

Hinweis: Dieser Beitrag ist eine technische Übersicht und keine Rechtsberatung. Ob für einen konkreten Cookie oder Datenfluss eine Einwilligung oder andere rechtliche Anforderungen gelten, hängt vom tatsächlichen Zweck, den verarbeiteten Informationen und dem jeweiligen Einsatzfall ab.