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

Unterstützte Browser

  • 114
  • 114
  • x
  • x

Quelle

<ph type="x-smartling-placeholder">

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, was den Datenschutz und die Sicherheit für Nutzer verbessert.

Ohne Partitionierung können Drittanbieter-Cookies es Diensten ermöglichen, Nutzer zu verfolgen und deren 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.

<ph type="x-smartling-placeholder">
</ph> Diagramm, das zeigt, wie Köche von zwei verschiedenen Websites gemeinsam verwendet werden können.
Ohne Cookie-Partitionierung kann ein Drittanbieterdienst ein Cookie setzen, wenn er in eine Website auf oberster Ebene eingebettet ist, und auf dasselbe Cookie zugreifen, wenn der Dienst in andere Websites der obersten Ebene eingebettet ist.

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.

<ph type="x-smartling-placeholder">
</ph> Diagramm, das zeigt, dass zwei verschiedene Websites, auf denen ein gemeinsamer Drittanbieter eingebettet ist, keine Cookies mehr für diesen Drittanbieter teilen.
Bei der Cookie-Partitionierung kann ein Drittanbieterdienst, der ein Cookie setzt, wenn er in eine Website auf oberster Ebene eingebettet ist, nicht auf dasselbe Cookie zugreifen, wenn der Dienst in andere Websites der obersten Ebene eingebettet ist.

Wenn ein Nutzer mit partitionierten Cookies Website A besucht und eingebettete Inhalte von Website C ein Cookie mit dem Attribut „Partitioned“ (Partitioniert) setzt, wird das Cookie in einer partitionierten JAR-Datei gespeichert, die nur für Cookies bestimmt ist, die Website C beim Einbetten auf Website A setzt. 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.

<ph type="x-smartling-placeholder">
</ph> Diagramm, das zeigt, dass Cookies nicht gemeinsam genutzt werden, wenn derselbe Drittanbieter auf zwei verschiedenen Websites eingebettet ist.
Mit der Cookie-Partitionierung kann ein Drittanbieterdienst, der beim Einbetten in eine Website ein Cookie setzt, nicht auf dasselbe Cookie zugreifen, selbst wenn die Nutzer den Dienst als Top-Level-Website besuchen.

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.

<ph type="x-smartling-placeholder">
</ph> Diagramm, das eine Website mit einem Embeed-Chat-Widget zeigt
Top-Level-Website „retail.example“ zum Einbetten eines Drittanbieterdienstes support.chat.example.

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, weiterhin websiteübergreifende Cookies 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 standortübergreifende Unterressourcen ein gewisses Konzept des Sitzungs- oder persistenten Status erfordern, der sich auf die Aktivität eines Nutzers auf einer einzelnen Website auf oberster Ebene bezieht. Beispiele:

  • Eingebettete Chats von Drittanbietern
  • Karteneinbettungen von Drittanbietern
  • Zahlungseinbettungen von Drittanbietern
  • CDN-Load-Balancing der Unterressource
  • Monitorlose CMS-Anbieter
  • Sandbox-Domains für die Bereitstellung nicht vertrauenswürdiger Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com)
  • CDNs von Drittanbietern, die Cookies verwenden, um Inhalte bereitzustellen, deren Zugriff durch den Authentifizierungsstatus der eigenen Website gesteuert wird (z. B. Profilbilder auf Websites sozialer Medien, die auf Drittanbieter-CDNs 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 Cookies von Drittanbietern 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.

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").

Unter CHIPS werden Cookies, die die Partitionierung aktivieren, auf ihrem Hostschlüssel und 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 entspricht der Partitionierungsschlüssel einer Anfrage der Website der URL der obersten Ebene, die vom Browser am Anfang einer Anfrage aufgerufen wird. 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.

<ph type="x-smartling-placeholder">
</ph> Website A und eingebettete Website C teilen sich ein partitioniertes Cookie. Wenn Website C nicht eingebettet ist, kann sie nicht auf das partitionierte Cookie zugreifen.
Website A und eingebettete Website C teilen sich ein partitioniertes Cookie. Wenn Website C nicht eingebettet ist, kann sie nicht auf das partitionierte Cookie zugreifen.

Vor CHIPS

key=("support.chat.example")

Nach CHIPS

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

Sicherheitsdesign

Um gute Sicherheitspraktiken zu fördern, werden Cookies bei CHIPS nur von sicheren Protokollen gesetzt und über sichere Protokolle 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;
<ph type="x-smartling-placeholder">

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 benötigt wird.

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 Gruppen ähnlicher Websites basiert auf der Storage Access API und ist nicht in die CHIPS-Partitionierung integriert. 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 bettet einen iFrame von Website B ein, der mithilfe von JavaScript zwei Cookies setzt: 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 werden, kann Website B das Cookie nur mit dem Attribut Partitioned 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.

<ph type="x-smartling-placeholder">
</ph> Website A und Website B
Links: Drittanbieter-Cookies werden blockiert. Richtig: Drittanbieter-Cookies sind zulässig.

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.

<ph type="x-smartling-placeholder">
</ph>
Cookies von Website B auf dem Tab „Anwendung“ der Entwicklertools

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.
<ph type="x-smartling-placeholder">
</ph>
Partitionsschlüssel für __Host-partitioned-cookie.
  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.
<ph type="x-smartling-placeholder">
</ph> Website B
Auf der obersten Ebene kann Website B alle Cookies sehen – partitioniert und nicht partitioniert

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 Partitionierungsschlüssel.
  • Das Cookie __Host-partitioned-cookie hat den Partitionsschlüssel https://chips-site-b.glitch.me.
<ph type="x-smartling-placeholder">
</ph>
Cookies von Website B auf dem Tab der Entwicklertools-Anwendung beim Besuch von B als Website der obersten Ebene. __Host-partitioned-cookie hat den Partitionierungsschlü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 darauf zugreifen.

  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.

<ph type="x-smartling-placeholder">
</ph>
Tab „Network“ mit Cookies des iFrames von Website B, auf die bei der Einbettung auf Website A zugegriffen werden kann

Wenn Sie die Option Herausgefilterte Cookieanfragen 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“.

<ph type="x-smartling-placeholder">
</ph>
Tab „Network“ mit blockierten Cookies des iFrames von Website B

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.
<ph type="x-smartling-placeholder">
</ph>
Cookies von Website B auf dem Tab „Anwendung“ der Entwicklertools. Das Cookie „__Host-partitioned-cookie“ hat den Partitionsschlüssel https://chips-site-a.glitch.me. unpartitioned-cookie wird angezeigt, ist aber für den iFrame von Website B nicht zugänglich, wenn er auf Website A eingebettet ist.

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