Cookies mit unabhängig partitioniertem Status (CHIPS)

Entwicklern erlauben, ein Cookie für „Partitioniert“ zu aktivieren mit einer separaten Keksdose pro Top-Level-Website.

Implementierungsstatus

• Diese Option wird in Chrome 114 und höher standardmäßig unterstützt.
• Ein Ursprungstest, der jetzt abgeschlossen war, war von Chrome 100 bis Chrome 116 verfügbar.
• Lesen Sie die Abschnitte Intent to Experiment und Intent to Ship.

Was sind CHIPS?

Cookies mit Independent Partitioned State (CHIPS) ermöglichen es Entwicklern, ein Cookie für den partitionierten Speicher mit separaten Cookie-JAR-Dateien pro Top-Level-Website zu aktivieren, wodurch der Datenschutz und die Sicherheit für Nutzer verbessert werden.

Ohne Partitionierung können Drittanbieter-Cookies es Diensten ermöglichen, Nutzer zu verfolgen und ihre Informationen über viele unabhängige Websites auf oberster Ebene hinweg zusammenzuführen. Dies wird als websiteübergreifendes Tracking bezeichnet.

In Browsern wird die schrittweise Einstellung von nicht partitionierten Drittanbieter-Cookies vorangetrieben. Daher werden CHIPS, die Storage Access API und die Gruppe ähnlicher Websites die einzige Möglichkeit sein, Cookies aus websiteübergreifenden Kontexten wie iFrames zu lesen und zu schreiben, wenn Drittanbieter-Cookies blockiert werden.

CHIPS führt das neue Cookie-Attribut Partitioned ein, um websiteübergreifende Cookies zu unterstützen, die nach Kontext der obersten Ebene partitioniert sind.

Set-Cookie-Header:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

Ein partitioniertes Drittanbieter-Cookie ist mit der Website auf oberster Ebene verknüpft, auf der es ursprünglich gesetzt wurde, und kann nicht von anderer Stelle aus aufgerufen werden. Auf diese Weise können von einem Drittanbieterdienst gesetzte Cookies nur im selben eingebetteten Kontext der Website auf oberster Ebene gelesen werden, in der sie ursprünglich gesetzt wurden.

Wenn ein Nutzer Website A besucht und eingebettete Inhalte von Website C ein Cookie mit dem Partitioned-Attribut setzen, wird das Cookie in einem partitionierten JAR-File gespeichert, das nur für Cookies bestimmt ist, die von Website C gesetzt werden, wenn sie in Website A eingebettet ist. Der Browser sendet dieses Cookie nur, wenn die Website der obersten Ebene A ist.

Wenn der Nutzer eine neue Website besucht, z. B. Website B, erhält ein eingebetteter C-Frame nicht das Cookie, das bei der Einbettung von C in Website C gesetzt wurde.

Wenn ein Nutzer Website C als Website der obersten Ebene besucht, wird das partitionierte Cookie, das C bei der Einbettung in A festgelegt hat, auch nicht in dieser Anfrage gesendet.

Anwendungsfälle

Die Website retail.example möchte beispielsweise mit dem Drittanbieter support.chat.example zusammenarbeiten, um ein Feld für den Supportchat in die Website einzubetten. Viele heute einbettbare Chatdienste nutzen Cookies, um den Status zu speichern.

Ohne die Möglichkeit, ein websiteübergreifendes Cookie zu setzen, müsste support.chat.example alternative, oft komplexere Methoden zum Speichern des Status finden. Alternativ muss es in die Seite der obersten Ebene eingebettet werden. Dies birgt Risiken, da das Skript support.chat.example dadurch erweiterte Berechtigungen für „retail.example“ hat, z. B. die Möglichkeit, auf Authentifizierungscookies zuzugreifen.

CHIPS bietet eine einfachere Möglichkeit, websiteübergreifende Cookies weiterhin zu verwenden, ohne die Risiken, die mit nicht partitionierten Cookies verbunden sind.

Beispiele für Anwendungsfälle für CHIPS sind Szenarien, in denen für websiteübergreifende Unterressourcen ein Sitzungs- oder persistenter Status erforderlich ist, der auf die Aktivitäten eines Nutzers auf einer einzelnen Website der obersten Ebene beschränkt ist, z. B.:

• Eingebettete Chats von Drittanbietern
• Karteneinbettungen von Drittanbietern
• Zahlungseinbettungen von Drittanbietern
• CDN-Load Balancing für untergeordnete Ressourcen
• Monitorlose CMS-Anbieter
• Sandbox-Domains für die Bereitstellung nicht vertrauenswürdiger Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com)
• Drittanbieter-CDNs, die Cookies zum Bereitstellen von Inhalten verwenden, deren Zugriff durch den Authentifizierungsstatus auf der Website des Unternehmens gesteuert wird (z. B. Profilbilder auf Websites sozialer Medien, die auf CDNs von Drittanbietern gehostet werden)
• Frontend-Frameworks, die auf Remote-APIs beruhen, die Cookies für ihre Anfragen verwenden
• Eingebettete Anzeigen, deren Status für jeden Publisher einzeln festgelegt werden muss (z. B. zum Erfassen der Anzeigenvorgaben von Nutzern für diese Website)

Warum CHIPS ein Opt-in-Partitionierungsmodell verwendet

Da Browser nicht partitionierte Cookies von Drittanbietern schrittweise einstellen, wurden einige andere Ansätze zur Partitionierung versucht.

Firefox gab bekannt, dass alle Drittanbieter-Cookies standardmäßig im ETP-Modus „Streng“ und im Modus „Privates Surfen“ partitioniert werden, sodass alle websiteübergreifenden Cookies nach der Top-Level-Website partitioniert werden. Die Partitionierung von Cookies ohne die Zustimmung von Dritten kann jedoch zu unerwarteten Fehlern führen, da einige Drittanbieterdienste Server aufgebaut haben, die nicht partitionierte Drittanbieter-Cookies erwarten.

Safari hat zuvor versucht, Cookies basierend auf Heuristiken zu partitionieren, entschied sich aber schließlich, sie vollständig zu blockieren. Als einer der Gründe nannte man Verwirrung bei den Entwicklern. Vor Kurzem hat Safari an einem Opt-in-Modell interessiert.

CHIPS unterscheidet sich von bestehenden Implementierungen partitionierter Cookies durch das Opt-in des Drittanbieters. Cookies müssen mit einem neuen Attribut gesetzt werden, um bei Anfragen von Drittanbietern gesendet zu werden, wenn (nicht partitionierte) Drittanbieter-Cookies veraltet sind.

Drittanbieter-Cookies sind zwar weiterhin vorhanden, das Attribut Partitioned ermöglicht aber eine restriktivere und sicherere Cookie-Funktionsweise. CHIPS ist ein wichtiger Schritt, um Dienste dabei zu unterstützen, einen reibungslosen Übergang in eine Zukunft ohne Drittanbieter-Cookies zu ermöglichen.

Technisches Design der Cookie-Partitionierung

Heutzutage werden Cookies anhand des Hostnamens oder der Domain der Website gespeichert, von der sie gesetzt wurden, d. h. ihrem Hostschlüssel.

Für Cookies von https://support.chat.example lautet der Hostschlüssel beispielsweise ("support.chat.example").

Bei CHIPS werden Cookies, für die die Partitionierung aktiviert ist, mit ihrem Hostschlüssel und dem Partitionsschlüssel doppelt verschlüsselt.

Der Partitionierungsschlüssel eines Cookies ist die Website (Schema und registrierfähige Domain) der Top-Level-URL, die der Browser zu Beginn der Anfrage an den Endpunkt besucht hat, der das Cookie gesetzt hat.

Im Beispiel oben, in dem https://support.chat.example in https://retail.example eingebettet ist, lautet die URL der obersten Ebene https://retail.example.

Der Partitionsschlüssel ist in diesem Fall ("https", "retail.example").

Ebenso ist der Partitionierungsschlüssel einer Anfrage die Website der URL der obersten Ebene, die der Browser am Anfang einer Anfrage aufruft. Browser dürfen ein Cookie mit dem Attribut Partitioned nur in Anfragen senden, die denselben Partitionierungsschlüssel wie dieses Cookie haben.

So sieht der Cookieschlüssel im obigen Beispiel vor und nach den CHIPS aus.

Vor CHIPS

key=("support.chat.example")

Nach CHIPS

key={("support.chat.example"),("https", "retail.example")}

Sicherheitsdesign

Um gute Sicherheitspraktiken zu fördern, werden bei CHIPS Cookies nur über sichere Protokolle festgelegt und gesendet.

• Partitionierte Cookies müssen mit Secure festgelegt werden.
• Es wird empfohlen, beim Festlegen partitionierter Cookies das Präfix __Host- zu verwenden, damit sie an den Hostnamen (und nicht an die registrierbare Domain) gebunden werden.

Beispiel:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Alternativen zu CHIPS

Die Storage Access API und die zugehörigen Related Website Sets (RWS) sind Webplattformmechanismen, mit denen der websiteübergreifende Cookie-Zugriff für bestimmte Zwecke für Nutzer eingeschränkt werden kann.

Dies sind Alternativen zur CHIPS-Partitionierung, bei der Zugriff auf websiteübergreifende, nicht partitionierte Köche erforderlich ist.

Verwenden Sie die Storage Access API und Gruppen ähnlicher Websites, wenn dasselbe Cookie für einen Dienst verfügbar sein soll, der in mehrere verwandte Websites eingebettet ist.

CHIPS bietet die Möglichkeit, dass ein Dienst als isolierte Komponente über mehrere Websites hinweg agiert, wobei dasselbe Cookie nicht für mehrere Websites verfügbar sein muss. Wenn der Dienst ein partitioniertes Cookie setzt, ist sein Partitionierungsschlüssel die Website der obersten Ebene und dieses Cookie ist nicht für andere Websites verfügbar, die den Dienst nutzen.

Das Design für Sets mit ähnlichen Websites basiert auf der Storage Access API und kann nicht mit der CHIPS-Partitionierung kombiniert werden. Wenn Sie in einem Anwendungsfall eine websiteübergreifende Cookie-Partition innerhalb einer RWS verwenden, können Sie Beispiele und Feedback zum GitHub-Problem bereitstellen.

Demo

In dieser demo erfährst du, wie partitionierte Cookies funktionieren und wie du sie in den Entwicklertools überprüfen kannst.

Website A fügt einen iFrame von Website B ein, auf dem mit JavaScript zwei Cookies gesetzt werden: ein partitioniertes und ein nicht partitioniertes Cookie. Website B zeigt alle Cookies an, auf die von diesem Speicherort aus mithilfe von document.cookie zugegriffen werden kann.

Wenn Drittanbieter-Cookies blockiert sind, kann Website B das Cookie mit dem Partitioned-Attribut nur im websiteübergreifenden Kontext setzen und darauf zugreifen.

Wenn Cookies von Drittanbietern zugelassen sind, kann Website B auch das nicht partitionierte Cookie setzen und darauf zugreifen.

Vorbereitung

1. Chrome 118 oder höher.
2. Aktivieren Sie diese Einstellung unter chrome://flags/#test-third-party-cookie-phaseout

Partitionierte Cookies mit Entwicklertools prüfen

1. Rufen Sie https://chips-site-a.glitch.me auf.
2. Drücken Sie Control+Shift+J (oder Command+Option+J auf einem Mac), um die Entwicklertools zu öffnen.
3. Klicken Sie auf den Tab Anwendung.
4. Wählen Sie Anwendung > Speicher > Cookies.
5. Klicken Sie auf https://chips-site-b.glitch.me.

Die Entwicklertools zeigen alle Cookies des ausgewählten Ursprungs an.

Website B kann das partitionierte Cookie nur im websiteübergreifenden Kontext setzen. Das nicht partitionierte Cookie wird blockiert:

• Sie sollten __Host-partitioned-cookie mit dem Partitionierungsschlüssel der Top-Level-Website https://chips-site-a.glitch.me sehen.

1. Klicken Sie auf Zu Website B.
2. Gehen Sie in den Entwicklertools zu Application > Speicher > Cookies.
3. Klicken Sie auf https://chips-site-b.glitch.me.

In diesem Szenario können Sie beide Cookies setzen und darauf zugreifen, da Sie sich auf Website B im Kontext der obersten Ebene befinden:

• unpartitioned-cookie hat einen leeren Partitionsschlüssel.
• Das Cookie „__Host-partitioned-cookie“ hat den Partitionsschlüssel https://chips-site-b.glitch.me.

Wenn Sie zu Website A zurückkehren, ist unpartitioned-cookie jetzt im Browser gespeichert, kann jedoch über Website A nicht aufgerufen werden.

1. Klicken Sie auf Zu Website A wechseln.
2. Klicken Sie auf den Tab Netzwerk.
3. Klicken Sie auf https://chips-site-b.glitch.me.
4. Klicken Sie auf den Tab Cookies.

Auf Website A sollten Sie __Host-partitioned-cookie mit dem Partitionsschlüssel der Top-Level-Website https://chips-site-a.glitch.me sehen.

Wenn Sie die Option Herausgefilterte Cookie-Anfragen anzeigen aktivieren, zeigt die Entwicklertools an, dass das nicht partitionierte Cookie blockiert ist. Dies ist gelb markiert und Sie sehen die folgende Kurzinfo: „Dieses Cookie wurde aufgrund von Nutzereinstellungen blockiert“.

Wählen Sie unter Anwendung > Speicher > Cookies, die auf https://chips-site-b.glitch.me klicken Folgendes wird angezeigt:

• unpartitioned-cookie durch den leeren Partitionsschlüssel.
• __Host-partitioned-cookie-Cookie mit dem Partitionsschlüssel https://chips-site-a.glitch.me.

Cookies löschen

Um die Demo zurückzusetzen, lösche alle Cookies für die Website:

• Drücken Sie Control+Shift+J (oder Command+Option+J auf einem Mac), um die Entwicklertools zu öffnen.
• Klicken Sie auf den Tab Anwendung.
• Wählen Sie Anwendung > Speicher > Cookies.
• Klicken Sie mit der rechten Maustaste auf https://chips-site-b.glitch.me.
• Klicken Sie auf Löschen.

Ressourcen

• GitHub: Lesen Sie die Erläuterung, stellen Sie Fragen und folgen Sie der Diskussion.
• Entwicklersupport: Im Privacy Sandbox-Repository für Entwicklersupport können Sie Fragen stellen und sich an Diskussionen beteiligen.