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

  • Chrome: 114.
  • Edge: 114.
  • Firefox Technology Preview: unterstützt
  • Safari: wird nicht unterstützt.

Quelle

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.

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.

Diagramm, das zeigt, dass zwei verschiedene Websites, die einen gemeinsamen Drittanbieter einbetten, keine Cookies mehr für diesen Drittanbieter teilen
Mit 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 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.

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.

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, 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.

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.

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

Website A und Website B
Links: Drittanbieter-Cookies sind 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.

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.
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.
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 Partitionsschlüssel.
  • Das Cookie „__Host-partitioned-cookie“ hat den Partitionsschlüssel https://chips-site-b.glitch.me.
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 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.

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 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“.

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