Cookies mit unabhängig partitioniertem Status (CHIPS)

Entwicklern ermöglichen, ein Cookie für die „partitionierte“ Speicherung zu aktivieren, mit einem separaten Cookie-Speicher pro Website der obersten Ebene.

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 ist CHIPS?

Mit Cookies Having Independent Partitioned State (CHIPS) können Entwickler ein Cookie für die partitionierte Speicherung aktivieren. Dabei werden separate Cookie-Bereiche pro Top-Level-Website verwendet, was den Datenschutz und die Sicherheit der Nutzer verbessert.

Ohne Partitionierung können Drittanbieter-Cookies es Diensten ermöglichen, Nutzer zu tracken und ihre Informationen von vielen unabhängigen Top-Level-Websites zusammenzuführen. Das wird als websiteübergreifendes Tracking bezeichnet.

CHIPS, die Storage Access API und Gruppen ähnlicher Websites sind die einzigen Möglichkeiten, Cookies aus websiteübergreifenden Kontexten wie iFrames zu lesen und zu schreiben, wenn Drittanbieter-Cookies blockiert sind.

Mit CHIPS wird ein neues Cookie-Attribut, Partitioned, eingeführt, um websiteübergreifende Cookies zu unterstützen, die nach Kontext der obersten Ebene partitioniert werden.

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 an die Website der obersten Ebene gebunden, auf der es ursprünglich gesetzt wurde, und kann nicht von anderen Websites aus aufgerufen werden. So können von einem Drittanbieterdienst gesetzte Cookies nur im selben eingebetteten Kontext der Website der obersten Ebene gelesen werden, auf der sie ursprünglich gesetzt wurden.

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

Wenn der Nutzer eine neue Website aufruft, z. B. Website B, wird das Cookie, das beim Einbetten von C in Website A gesetzt wurde, nicht an einen eingebetteten C-Frame gesendet.

Wenn ein Nutzer Website C als Top-Level-Website besucht, wird das partitionierte Cookie, das von C gesetzt wurde, als es in A eingebettet war, ebenfalls nicht mit dieser Anfrage gesendet.

Anwendungsfälle

Die Website retail.example möchte beispielsweise mit dem Drittanbieterdienst support.chat.example zusammenarbeiten, um ein Support-Chatfeld auf ihrer Website einzubetten. Viele einbettbare Chatdienste speichern den Status heute mithilfe von Cookies.

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 müsste es in die Seite der obersten Ebene eingebettet werden, was Risiken birgt, da das support.chat.example-Script dann erweiterte Berechtigungen für retail.example erhält, z. B. die Möglichkeit, auf Authentifizierungs-Cookies 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 alle Szenarien, in denen für untergeordnete Ressourcen, die auf mehreren Websites verwendet werden, eine Art Sitzung oder ein persistenter Status erforderlich ist, der auf die Aktivität eines Nutzers auf einer einzelnen Website der obersten Ebene beschränkt ist, z. B.:

• Eingebettete Chats von Drittanbietern
• Eingebettete Karten von Drittanbietern
• Einbettungen von Drittanbieter-Zahlungen
• Load-Balancing für Subressourcen-CDNs
• Anbieter von monitorlosen CMS
• Sandbox-Domains für die Bereitstellung nicht vertrauenswürdiger Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com)
• Drittanbieter-CDNs, die Cookies verwenden, um Inhalte bereitzustellen, auf die aufgrund des Authentifizierungsstatus auf der eigenen Website nur eingeschränkt zugegriffen werden kann (z. B. Profilbilder auf Social-Media-Websites, die auf Drittanbieter-CDNs gehostet werden)
• Frontend-Frameworks, die auf Remote-APIs angewiesen sind, die Cookies in ihren Anfragen verwenden
• Eingebettete Anzeigen, für die der Status pro Publisher festgelegt werden muss, z. B. um die Anzeigenpräferenzen der Nutzer für die jeweilige Website zu erfassen

Warum CHIPS ein Opt-in-Partitionierungsmodell verwendet

Wenn der Zugriff auf nicht partitionierte Drittanbieter-Cookies blockiert ist, wurden einige andere Ansätze zur Partitionierung versucht.

Firefox hat angekündigt, dass alle Drittanbieter-Cookies standardmäßig partitioniert werden, wenn der ETP-Modus „Streng“ oder der Modus für privates Surfen verwendet wird. Alle websiteübergreifenden Cookies werden also nach der Website auf oberster Ebene partitioniert. Das Partitionieren von Cookies ohne Einwilligung des Drittanbieters kann jedoch zu unerwarteten Fehlern führen, da einige Drittanbieterdienste Server erstellt haben, die ein nicht partitioniertes Drittanbieter-Cookie erwarten.

Safari hat zuvor versucht, Cookies heuristisch zu partitionieren, sich aber schließlich dafür entschieden, sie ganz zu blockieren. Als einen der Gründe wurde die Verwirrung der Entwickler angeführt. Vor Kurzem hat Safari Interesse an einem Opt-in-basierten Modell gezeigt.

Der Unterschied zwischen CHIPS und bestehenden Implementierungen partitionierter Cookies besteht darin, dass Drittanbieter die Verwendung von CHIPS explizit aktivieren müssen. Cookies müssen mit einem neuen Attribut festgelegt werden, damit sie bei anbieterübergreifenden Anfragen einmal gesendet werden, wenn (nicht partitionierte) Drittanbieter-Cookies nicht mehr unterstützt werden.

Drittanbieter-Cookies sind zwar weiterhin vorhanden, aber mit dem Attribut Partitioned können Sie sich für ein restriktiveres, sichereres Cookie-Verhalten entscheiden. CHIPS ist ein wichtiger Schritt, um Diensten einen reibungslosen Übergang in eine Zukunft ohne Drittanbieter-Cookies zu ermöglichen.

Technisches Design der Cookie-Partitionierung

Heute werden Cookies anhand des Hostnamens oder der Domain der Website, auf der sie gesetzt wurden, also anhand ihres Hosts-Schlüssels, identifiziert.

Für Cookies von https://support.chat.example ist 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 registrierbare 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 auf https://retail.example eingebettet ist, ist https://retail.example die URL der obersten Ebene.

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

Der Partitionierungsschlüssel einer Anfrage ist die Website der Top-Level-URL, die der Browser zu Beginn einer Anfrage aufruft. Browser dürfen ein Cookie mit dem Attribut Partitioned nur in Anfragen mit demselben Partitionsschlüssel wie das Cookie senden.

So sieht der Cookie-Schlüssel im obigen Beispiel vor und nach 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 Cookies mit CHIPS nur über sichere Protokolle festgelegt und gesendet.

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

Beispiel:

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

Alternativen zu CHIPS

Die Storage Access API und die zugehörigen Gruppen ähnlicher Websites sind Webplattformmechanismen, die einen eingeschränkten websiteübergreifenden Cookie-Zugriff für bestimmte, nutzerorientierte Zwecke ermöglichen.

Dies sind Alternativen zur CHIPS-Partitionierung, wenn der Zugriff auf websiteübergreifende, nicht partitionierte Cookies erforderlich ist.

Die Storage Access API und Related Website Sets sind eine gute Option, wenn Sie dasselbe Cookie für einen Dienst benötigen, der in mehrere zugehörige Websites eingebettet ist.

CHIPS ermöglicht es einem Dienst, als isolierte Komponente auf mehreren Websites zu fungieren, wobei dasselbe Cookie nicht auf mehreren Websites verfügbar sein muss. Wenn der Dienst ein partitioniertes Cookie festlegt, ist der Partitionsschlüssel die Top-Level-Website. Dieses Cookie ist dann nicht für andere Websites verfügbar, die den Dienst ebenfalls verwenden.

Das Design von Gruppen ähnlicher Websites basiert auf der Storage Access API und ist nicht in die CHIPS-Partitionierung integriert. Wenn Sie einen Anwendungsfall haben, der auf einer gemeinsamen Cookie-Partition über Websites innerhalb eines RWS basiert, können Sie Beispiele und Feedback im GitHub-Problemfall bereitstellen.

Demo

In dieser Demo wird gezeigt, wie partitionierte Cookies funktionieren und wie Sie sie in den Entwicklertools untersuchen können.

Auf Website A ist ein iFrame von Website B eingebettet, in dem mit JavaScript zwei Cookies gesetzt werden: ein partitioniertes und ein nicht partitioniertes Cookie. Auf Website B werden alle Cookies angezeigt, auf die von diesem Ort aus mit document.cookie zugegriffen werden kann.

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

Wenn Drittanbieter-Cookies zugelassen sind, kann auf Website B auch das nicht partitionierte Cookie festgelegt und darauf zugegriffen werden.

Vorbereitung

1. Chrome 118 oder höher.
2. Rufen Sie chrome://flags/#test-third-party-cookie-phaseout auf und aktivieren Sie diese Einstellung.

Partitionierte Cookies mit DevTools untersuchen

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

In den DevTools werden alle Cookies des ausgewählten Ursprungs angezeigt.

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

• Sie sollten __Host-partitioned-cookie mit dem Partitionsschlüssel der Website der obersten Ebene https://chips-site-a.glitch.me sehen.

1. Klicken Sie auf Go to Site B (Zu Website B wechseln).
2. Rufen Sie in den DevTools Anwendung > Speicher > Cookies auf.
3. Klicken Sie auf https://chips-site-b.glitch.me.

In diesem Szenario kann Website B, da Sie sich im Kontext der obersten Ebene befinden, beide Cookies festlegen und darauf zugreifen:

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

Wenn Sie zu Website A zurückkehren, wird unpartitioned-cookie jetzt im Browser gespeichert, ist aber nicht über Website A zugänglich.

1. Klicken Sie auf Go to Site A (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 sollte __Host-partitioned-cookie mit dem Partitionsschlüssel der Website der obersten Ebene https://chips-site-a.glitch.me angezeigt werden.

Wenn Sie Herausgefilterte Cookie-Anfragen anzeigen aktivieren, wird in den Entwicklertools angezeigt, dass das nicht partitionierte Cookie blockiert wurde. Es wird gelb hervorgehoben und es wird die Kurzinfo Dieses Cookie wurde aufgrund von Nutzereinstellungen blockiert angezeigt.

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

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

Cookies löschen

So setzen Sie die Demo zurück:

• Drücken Sie Control+Shift+J oder Command+Option+J (Mac), um die Entwicklertools zu öffnen.
• Klicken Sie auf den Tab Anwendung.
• Gehen Sie zu 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: Stellen Sie Fragen und beteiligen Sie sich an Diskussionen im Privacy Sandbox Developer Support-Repository.