Cookies mit unabhängig partitioniertem Status (CHIPS)

Ermöglicht Entwicklern, Cookies für „partitionierten“ Speicher mit einer separaten Cookie-JAR-Datei pro Website der obersten Ebene zu aktivieren.

Implementierungsstatus

Unterstützte Browser

  • 114
  • 114
  • x
  • x

Quelle

Was sind CHIPS?

Mit Cookies mit Independent Partitioned State (CHIPS) können Entwickler ein Cookie im partitionierten Speicher mit separaten Cookie-JAR-Dateien für jede Website der obersten Ebene speichern, wodurch der Datenschutz und die Sicherheit für Nutzer verbessert werden.

Ohne Partitionierung können Drittanbieter-Cookies Dienste nutzen, um Nutzer zu verfolgen und ihre Informationen von vielen nicht zusammengehörigen Top-Level-Websites zusammenzuführen. Dies wird als websiteübergreifendes Tracking bezeichnet.

In Browsern werden nicht partitionierte Drittanbieter-Cookies schrittweise eingestellt. Daher sind CHIPS, die Storage Access API und Gruppen ähnlicher Websites die einzige Möglichkeit, Cookies aus websiteübergreifenden Kontexten wie iFrames zu lesen und zu schreiben, wenn Drittanbieter-Cookies blockiert werden.

Diagramm, das zeigt, wie Rezepte von zwei verschiedenen Websites gemeinsam genutzt werden können.
Ohne Cookie-Partitionierung können Drittanbieterdienste ein Cookie setzen, wenn sie in eine Website der obersten Ebene eingebettet sind, und auf dasselbe Cookie zugreifen, wenn der Dienst in andere Websites auf oberster Ebene eingebettet ist.

CHIPS führt das neue Cookie-Attribut Partitioned ein, um websiteübergreifende Cookies zu unterstützen, die nach übergeordnetem Kontext 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 an die Website der obersten Ebene gebunden, auf der es ursprünglich gespeichert wurde, und kann von einer anderen Stelle aus nicht aufgerufen werden. So können Cookies, die von einem Drittanbieterdienst gesetzt wurden, nur in demselben eingebetteten Kontext der Website der obersten Ebene gelesen werden, in der sie ursprünglich gesetzt wurden.

Diagramm, das zeigt, dass zwei verschiedene Websites, die einen gemeinsamen Drittanbieter einbetten, keine Cookies mehr für diesen Drittanbieter teilen.
Mit der Cookie-Partitionierung können Drittanbieterdienste, die ein Cookie setzen, wenn sie in eine Website der obersten Ebene eingebettet sind, nicht auf dasselbe Cookie zugreifen, wenn der Dienst in andere Websites der obersten Ebene eingebettet ist.

Wenn ein Nutzer Website A besucht und eingebetteter Inhalt von Website C bei partitionierten Cookies 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 von Website C festgelegt werden, wenn sie in Website A eingebettet ist. Der Browser sendet dieses Cookie nur dann, wenn die Website der obersten Ebene A ist.

Wenn der Nutzer eine neue Website besucht, z. B. Website B, empfängt der eingebettete C-Frame das Cookie, das bei der Einbettung von C in Website A gesetzt wurde, nicht.

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.

Diagramm, das zeigt, dass Cookies nicht weitergegeben werden, wenn derselbe Drittanbieter auf zwei verschiedenen Websites eingebettet ist.
Mit der Cookie-Partitionierung kann ein Drittanbieterdienst, der ein Cookie setzt, wenn er in eine Website eingebettet ist, nicht auf dieses Cookie zugreifen, selbst wenn der Nutzer den Dienst als Website der obersten Ebene besucht.

Anwendungsfälle

Beispielsweise möchte die Website retail.example möglicherweise mit einem Drittanbieterdienst support.chat.example zusammenarbeiten, um ein Support-Chatfeld auf ihrer Website einzubetten. Viele integrierbare Chatdienste nutzen heutzutage Cookies, um den Status zu speichern.

Diagramm, das eine Website mit einem Chat-Widget zeigt
Website der obersten Ebene.Beispiel zum Einbetten eines Drittanbieterdienstes support.chat.example

Ohne die Möglichkeit, ein websiteübergreifendes Cookie zu setzen, müsste support.chat.example nach alternativen, oft komplexeren Methoden zum Speichern des Status suchen. Alternativ müsste sie in die Seite der obersten Ebene eingebettet werden, was Risiken birgt, da das support.chat.example-Skript so Berechtigungen für „retail.example“ haben kann, z. B. für den Zugriff auf Authentifizierungscookies.

CHIPS bietet eine einfachere Option, um weiterhin websiteübergreifende Cookies zu verwenden, ohne die Risiken in Zusammenhang mit nicht partitionierten Cookies.

Beispiele für Anwendungsfälle für CHIPS sind alle Szenarien, in denen websiteübergreifende Unterressourcen eine Vorstellung vom Sitzungs- oder dauerhaften Status erfordern, die sich auf die Aktivität eines Nutzers auf einer einzelnen Website der obersten Ebene bezieht, z. B.:

  • Chateinbettungen über Drittanbieter
  • Karteneinbettungen von Drittanbietern
  • Eingebettete Zahlungen von Drittanbietern
  • CDN-Load-Balancing der Unterressource
  • Anbieter von monitorlosen CMS
  • Sandbox-Domains zur Bereitstellung nicht vertrauenswürdiger Nutzerinhalte (z. B. googleusercontent.com und githubusercontent.com)
  • CDNs von Drittanbietern, die Cookies verwenden, um Inhalte bereitzustellen, deren Zugriff über den Authentifizierungsstatus auf der Erstanbieterwebsite gesteuert wird (z. B. Profilbilder auf Websites sozialer Medien, die auf Drittanbieter-CDNs gehostet werden)
  • Frontend-Frameworks, die auf Remote-APIs basieren, die Cookies für ihre Anfragen verwenden
  • Eingebettete Anzeigen, deren Status nach Publisher aufgeschlüsselt werden muss (z. B. Erfassung der Anzeigenvorgaben der Nutzer für die jeweilige Website)

Warum CHIPS ein Opt-in-Partitionierungsmodell verwendet

Da Browser nicht partitionierte Drittanbieter-Cookies nach und nach einstellen, wurden einige andere Partitionierungsansätze versucht.

Firefox kündigte an, dass alle Drittanbieter-Cookies standardmäßig partitioniert werden, und zwar im strikten ETP-Modus und im privaten Surfmodus, sodass alle websiteübergreifenden Cookies nach der Website der obersten Ebene partitioniert werden. Die Partitionierung von Cookies ohne Zustimmung durch Drittanbieter kann jedoch zu unerwarteten Fehlern führen, da einige Drittanbieterdienste Server eingerichtet haben, die nicht partitionierte Drittanbieter-Cookies erwarten.

Safari hat zuvor versucht, Cookies basierend auf Heuristik zu partitionieren, entschied sich dann aber dafür, sie vollständig zu blockieren, wobei als einer der Gründe die Verwirrung des Entwicklers genannt wurde. Vor Kurzem hat Safari Interesse an einem Opt-in-Modell gezeigt.

Der Unterschied zwischen CHIPS und vorhandenen Implementierungen partitionierter Cookies ist die Opt-in-Funktion von Drittanbietern. Cookies müssen mit einem neuen Attribut festgelegt werden, damit sie bei Anfragen von Drittanbietern gesendet werden können, sobald (nicht partitionierte) Drittanbieter-Cookies veraltet sind.

Zwar gibt es weiterhin Drittanbieter-Cookies, mit dem Attribut Partitioned können Sie jedoch ein restriktiveres und sichereres Cookie-Verhalten aktivieren. CHIPS ist ein wichtiger Schritt, um Diensten zu helfen, einen reibungslosen Übergang in eine Zukunft ohne Drittanbieter-Cookies zu ermöglichen.

Heutzutage basieren Cookies auf dem Hostnamen oder der Domain der Website, die sie festgelegt hat, also ihrem Hostschlüssel.

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

Unter CHIPS werden Cookies, die der Partitionierung zustimmen, mit ihrem Hostschlüssel und ihrem Partitionsschlüssel als Doppelschlüssel verwendet.

Der Partitionsschlü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 in https://retail.example eingebettet ist, lautet die Top-Level-URL https://retail.example.

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

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

So sieht der Cookie-Schlüssel im Beispiel von vor und nach CHIPS aus.

Website A und eingebettete Website C teilen sich ein partitioniertes Cookie. Wenn es nicht eingebettet ist, kann Website C nicht auf das partitionierte Cookie zugreifen.
Website A und die eingebettete Website C teilen sich ein partitioniertes Cookie. Wenn es nicht eingebettet ist, kann Website C nicht auf das partitionierte Cookie zugreifen.

Vor CHIPS

key=("support.chat.example")

Nach CHIPS

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

Sicherheitsdesign

Zur Förderung bewährter Sicherheitspraktiken werden Cookies bei CHIPS nur über sichere Protokolle gesetzt und darüber gesendet.

  • Partitionierte Cookies müssen mit Secure festgelegt werden.
  • Beim Festlegen von partitionierten Cookies wird empfohlen, das Präfix __Host zu verwenden, um sie an den Hostnamen und nicht an die registrierbare Domain zu gebunden zu machen.

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 nutzerseitige Zwecke ermöglichen.

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

Verwenden Sie die Storage Access API und Gruppen ähnlicher Websites, wenn Sie dasselbe Cookie für einen Dienst benötigen, der in mehrere verbundene Websites eingebettet ist.

Mit CHIPS kann ein Dienst als isolierte Komponente über mehrere Websites hinweg agieren, wobei dasselbe Cookie nicht über mehrere Websites hinweg verfügbar sein muss. Wenn der Dienst ein partitioniertes Cookie setzt, ist sein Partitionsschlüssel die Website der obersten Ebene und dieses Cookie ist nicht für andere Websites verfügbar, die den Dienst ebenfalls nutzen.

Das Design für Gruppen ähnlicher Websites basiert auf der Storage Access API und ist nicht in die CHIPS-Partitionierung integriert. Wenn Ihr Anwendungsfall auf einer gemeinsamen Cookie-Partition auf Websites innerhalb einer RWS-Website beruht, können Sie Beispiele und Feedback zum GitHub-Problem bereitstellen.

Demo

In dieser Demo erfahren Sie, wie partitionierte Cookies funktionieren und wie Sie sie in den Entwicklertools überprüfen können.

Website A bettet einen iFrame von Website B ein, der JavaScript verwendet, um zwei Cookies zu setzen: ein partitioniertes und ein nicht partitioniertes Cookie. Website B zeigt alle Cookies an, auf die von diesem Speicherort aus zugegriffen werden kann. Dazu wird document.cookie verwendet.

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

Wenn Drittanbieter-Cookies zulässig sind, kann Website B ebenfalls das nicht partitionierte Cookie setzen und darauf zugreifen.

Website A und Website B
Links: Drittanbieter-Cookies werden blockiert. Rechts: Drittanbieter-Cookies sind zulässig.

Voraussetzungen

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

Partitionierte Cookies mit den Entwicklertools prüfen

  1. Rufe https://chips-site-a.glitch.me auf.
  2. Drücke Control+Shift+J (oder Command+Option+J auf einem 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.

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

Cookies von Website B auf dem Tab „Entwicklertools“.

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

  • Es sollte __Host-partitioned-cookie mit dem Partitionsschlüssel des übergeordneten Standorts https://chips-site-a.glitch.me angezeigt werden.
Partitionsschlüssel für __Host-partition-cookie.
  1. Klicken Sie auf Zu Website B.
  2. Gehen Sie in den Entwicklertools zu Application > Storage > Cookies (Anwendung > Speicher > Cookies).
  3. Klicken Sie auf https://chips-site-b.glitch.me.
Website B
Auf oberster Ebene kann Website B alle Cookies sehen – partitioniert und nicht partitioniert

Da Sie sich in diesem Szenario auf oberster Ebene auf Website B befinden, kann sie beide Cookies setzen und darauf zugreifen:

  • Der Partitionsschlüssel unpartitioned-cookie ist leer.
  • Das Cookie __Host-partitioned-cookie hat den Partitionsschlüssel https://chips-site-b.glitch.me.
Cookies von Website B im Tab „Entwicklertools“, wenn Sie B als Website der obersten Ebene besuchen. „__Host-partition-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. Von Website A kann jedoch nicht darauf zugegriffen werden.

  1. Klicken Sie auf Zu Website A.
  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 https://chips-site-a.glitch.me der obersten Ebene angezeigt werden.

Tab „Netzwerk“ mit Cookies vom iFrame von Website B, auf die zugegriffen werden kann, wenn sie auf Website A eingebettet ist.

Wenn Sie das Kästchen Gefilterte Cookie-Anfragen anzeigen anklicken, zeigen die Entwicklertools an, dass das nicht partitionierte Cookie blockiert ist. Er wird gelb hervorgehoben und es erscheint die folgende Kurzinfo: Dieses Cookie wurde aufgrund von Nutzereinstellungen blockiert.

Tab „Network“ mit blockierten Cookies im iFrame von Website B.

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

  • unpartitioned-cookie durch den leeren Partitionsschlüssel.
  • __Host-partitioned-cookie-Cookie mit dem Partitionsschlüssel https://chips-site-a.glitch.me.
Cookies von Website B im 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 es auf Website A eingebettet ist.

Cookies löschen

Löschen Sie zum Zurücksetzen der Demo alle Cookies für die Website:

  • Drücke Control+Shift+J (oder Command+Option+J auf einem 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