[VERALTET] First-Party-Sets und das Attribut „SameParty“

Viele Organisationen haben zugehörige Websites mit unterschiedlichen Domainnamen, z. B. brandx.site und fly-brandx.site, oder Domains für verschiedene Länder, z. B. example.com, example.rs und example.co.uk.

Browser streben an, Drittanbieter-Cookies abzuschaffen, um den Datenschutz im Web zu verbessern. Websites wie diese nutzen jedoch häufig Cookies für Funktionen, die den Zustand über Domains hinweg verwalten und darauf zugreifen müssen (z. B. Single Sign-On und Einwilligungsverwaltung).

Mit First-Party-Sets können zugehörige Domainnamen, die derselben Entität gehören und von ihr betrieben werden, in Situationen als selbst erhoben behandelt werden, in denen selbst erhobene Daten und Drittanbieterdaten andernfalls unterschiedlich behandelt werden. Die Domainnamen in einem Set mit selbst erhobenen Daten gelten als selbst erhoben und können kennzeichnen, welche Cookies im Kontext selbst erhobener Daten gesetzt oder gesendet werden sollen. Ziel ist es, ein Gleichgewicht zwischen dem Verhindern von websiteübergreifendem Tracking durch Dritte und der Aufrechterhaltung eines Pfads zu finden, der gültige Anwendungsfälle nicht beeinträchtigt.

Der Vorschlag für Sets mit selbst erhobenen Daten befindet sich derzeit in der Testphase. Lesen Sie weiter, um mehr über die Funktionsweise und die Möglichkeit zum Testen zu erfahren.

Was ist der Unterschied zwischen selbst erhobenen und Drittanbieter-Cookies?

Cookies sind nicht von Natur aus eigene oder Drittanbieter-Cookies. Das hängt vom aktuellen Kontext ab, in dem das Cookie enthalten ist. Das ist entweder in einer Anfrage im Header cookie oder über document.cookie in JavaScript möglich.

Wenn video.site beispielsweise ein theme=dark-Cookie hat und Sie video.site aufrufen und eine Anfrage an video.site gesendet wird, handelt es sich um einen SameSite-Kontext und das enthaltene Cookie ist ein Erstanbieter-Cookie.

Wenn Sie sich jedoch auf my-blog.site befinden, auf der ein Iframe-Player für video.site eingebettet ist, und die Anfrage von my-blog.site an video.site gesendet wird, handelt es sich um einen websiteübergreifenden Kontext und das theme-Cookie ist ein Drittanbieter-Cookie.

Diagramm mit einem Cookie von video.site in zwei Kontexten Das Cookie ist ein SameSite-Cookie, wenn der Kontext der obersten Ebene auch „video.site“ ist. Das Cookie ist websiteübergreifend, wenn der Kontext der obersten Ebene „my-blog.site“ mit „video.site“ in einem iFrame ist.

Ob ein Cookie eingeschlossen wird, wird durch das SameSite-Attribut des Cookies bestimmt:

  • Ein SameSite-Kontext mit SameSite=Lax, Strict oder None macht das Cookie zu einem eigenen Cookie.
  • Durch den websiteübergreifenden Kontext mit SameSite=None wird das Cookie zu einem Drittanbieter-Cookie.

Das ist jedoch nicht immer so eindeutig. Angenommen, brandx.site ist eine Reisebuchungswebsite und verwendet fly-brandx.site und drive-brandx.site, um Flüge und Mietwagen zu unterscheiden. Während der Buchung einer Fahrt wechseln Besucher zwischen diesen Websites, um ihre verschiedenen Optionen auszuwählen. Sie erwarten, dass ihr „Einkaufswagen“ mit den ausgewählten Optionen auf diesen Websites erhalten bleibt. brandx.siteverwaltet die Sitzung des Nutzers mit einem SameSite=None-Cookie, um sie websiteübergreifend zu ermöglichen. Der Nachteil ist jedoch, dass das Cookie jetzt keinen CSRF-Schutz (Cross-Site Request Forgery) bietet. Wenn evil.site eine Anfrage an brandx.site enthält, wird dieses Cookie ebenfalls enthalten sein.

Das Cookie ist websiteübergreifend, aber alle Websites gehören derselben Organisation und werden von ihr betrieben. Besucher wissen auch, dass es sich um dieselbe Organisation handelt, und möchten dieselbe Sitzung, also eine gemeinsame Identität.

Diagramm, das zeigt, dass ein Cookie weiterhin in einen websiteübergreifenden Kontext aufgenommen werden kann, wenn die Websites zum selben First-Party-Set gehören, aber für websiteübergreifende Kontexte außerhalb des Sets abgelehnt wird.

Richtlinie zu First-Party-Sets

First-Party-Sets bietet eine Methode, um diese Beziehung für mehrere Websites explizit zu definieren, die derselben Partei gehören und von ihr betrieben werden. So kann brandx.site seine selbst erhobenen Datenbeziehungen zu fly-brandx.site, drive-brandx.site usw. definieren.

Das Privacy Model, das die verschiedenen Privacy Sandbox-Vorschläge antreibt, basiert auf dem Konzept der Identitätspartitionierung, um websiteübergreifendes Tracking zu verhindern. Dabei wird eine Grenze zwischen Websites gezogen, die den Zugriff auf alle Informationen einschränkt, mit denen Nutzer identifiziert werden können.

Diagramm, das den nicht partitionierten Zustand zeigt, in dem auf dasselbe Drittanbieter-Cookie in mehreren websiteübergreifenden Kontexten zugegriffen werden kann, im Gegensatz zu einem partitionierten Modell, bei dem jeder Kontext der obersten Ebene eine separate Instanz des websiteübergreifenden Cookies hat, was Verknüpfungsaktivitäten zwischen diesen Websites verhindert.

Die Standardoption ist die Partitionierung nach Website. Das löst viele Anwendungsfälle für selbst erhobene Daten. Das Beispiel brandx.site zeigt jedoch, dass ein selbst erhobener Datensatz größer als eine einzelne Website sein kann.

Diagramm, das zeigt, wie dieselbe Instanz eines Cookies für einen Satz in websiteübergreifenden Kontexten enthalten sein kann, wenn alle diese Websites zum selben Satz gehören.

Ein wichtiger Teil des Vorschlags für First-Party-Sets besteht darin, zu verhindern, dass Browser richtlinienübergreifend missbraucht werden. Beispielsweise dürfen Sets mit selbst erhobenen Daten nicht den Austausch von Nutzerinformationen zwischen nicht zueinander gehörenden Websites oder die Gruppierung von Websites ermöglichen, die nicht derselben Entität gehören. Ziel ist es, dafür zu sorgen, dass ein First-Party-Set einem Element zugeordnet wird, das eine Person als selbst erhobene Daten versteht, und nicht dazu verwendet wird, die Identität für verschiedene Parteien freizugeben.

Eine Website kann beispielsweise einen Satz selbst erhobener Daten registrieren, indem sie die vorgeschlagene Gruppe von Domains zusammen mit den Informationen, die zur Einhaltung der Browserrichtlinien erforderlich sind, an einen öffentlichen Tracker (z. B. ein spezielles GitHub-Repository) sendet.

Sobald die Behauptung für das Set mit selbst erhobenen Daten gemäß der Richtlinie überprüft wurde, können Browser Listen mit Sets über einen Aktualisierungsprozess abrufen.

Für den Ursprungstest gibt es eine definierte Richtlinie, die noch nicht endgültig ist. Die Grundsätze werden jedoch wahrscheinlich gleich bleiben:

  • Die Domains in einem Set mit selbst erhobenen Daten müssen derselben Organisation gehören und von ihr betrieben werden.
  • Die Domains sollten für Nutzer als Gruppe erkennbar sein.
  • Die Domains sollten dieselbe Datenschutzerklärung haben.

Selbst erhobene Daten definieren

Nachdem Sie die Mitglieder und den Inhaber des selbst erhobenen Datensatzes Ihrer Organisation ermittelt haben, ist es wichtig, den vorgeschlagenen Datensatz zur Genehmigung einzureichen. Der genaue Ablauf wird noch diskutiert.

Wenn Sie ein Set mit selbst erhobenen Daten deklarieren möchten, müssen statische JSON-Ressourcen mit Mitgliedern und Inhabern auf /.well-known/first-party-set auf der obersten Ebene jeder enthaltenen Domain gehostet werden.

Im Beispiel für den selbst erhobenen Datensatz brandx wird das Folgende von der Eigentümerdomain unter https://brandx.site/.well-known/first-party-set gehostet:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Jedes Mitglied des Sets beherbergt außerdem eine statische JSON-Ressource, die auf den Eigentümer des Sets verweist. Bei https://fly-brandx.site/.well-known/first-party-set haben wir:

{ "owner": "brandx.site" }

Und um https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Für First-Party-Sets gelten einige Einschränkungen:

  • Ein Set kann nur einen Inhaber haben.
  • Ein Mitglied kann nur zu einem Satz gehören, es darf keine Überschneidungen oder Mischungen geben.
  • Die Mitgliederliste soll relativ menschenlesbar und nicht zu groß sein.

Wie wirken sich First-Party-Sets auf Cookies aus?

Die übereinstimmende Zutat für Kekse ist das vorgeschlagene SameParty-Attribut. Wenn Sie SameParty angeben, wird der Browser angewiesen, das Cookie einzubeziehen, wenn sein Kontext zum selben Set mit selbst erhobenen Daten wie der Kontext auf oberster Ebene gehört.

Das bedeutet, dass, wenn brandx.site dieses Cookie setzt:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Wenn sich der Besucher dann auf fly-brandx.site befindet und eine Anfrage an brandx.site gesendet wird, ist das session-Cookie in dieser Anfrage enthalten. Wenn eine andere Website, die nicht zum Set mit selbst erhobenen Daten gehört, z. B. hotel.xyz, eine Anfrage an brandx.site sendet, wird das Cookie nicht eingeschlossen.

Diagramm, in dem dargestellt ist, dass das Cookie „brandx.site“ wie beschrieben in websiteübergreifenden Kontexten zugelassen oder blockiert wird

Bis SameParty allgemein unterstützt wird, verwenden Sie das Attribut SameSite, um das Fallback-Verhalten für Cookies zu definieren. Sie können sich das SameParty-Attribut als Einstellung zwischen SameSite=Lax und SameSite=None vorstellen.

  • Mit SameSite=Lax; SameParty wird die Funktion Lax auf Kontexte desselben Anbieters ausgeweitet, sofern dies unterstützt wird. Andernfalls werden die Einschränkungen von Lax angewendet.
  • Mit SameSite=None; SameParty wird die Funktion None auf Kontexte desselben Anbieters beschränkt, sofern dies unterstützt wird. Andernfalls werden die umfassenderen None-Berechtigungen verwendet.

Es gelten einige zusätzliche Anforderungen:

  • SameParty-Cookies müssen Secure enthalten.
  • SameParty-Cookies dürfen SameSite=Strict nicht enthalten.

Secure ist erforderlich, da es sich weiterhin um websiteübergreifende Cookies handelt. Sie sollten diese Risiken durch sichere (HTTPS-)Verbindungen minimieren. Da es sich um eine websiteübergreifende Beziehung handelt, ist SameSite=Strict ebenfalls ungültig, da weiterhin ein strenger websitebasierter CSRF-Schutz innerhalb eines Sets zulässig ist.

Für welche Anwendungsfälle eignen sich Sets mit selbst erhobenen Daten?

First-Party-Sets eignen sich gut für Fälle, in denen eine Organisation eine gemeinsame Identität für verschiedene Websites der obersten Ebene benötigt. Eine gemeinsame Identität kann in diesem Fall alles umfassen, von einer vollständigen Lösung für die Einmalanmeldung bis hin zu einer gemeinsamen Einstellung für alle Websites.

Ihre Organisation kann unterschiedliche Top-Level-Domains für Folgendes haben:

  • App-Domains: office.com,live.com, microsoft.com
  • Markendomains: amazon.com, audible.com / disney.com, pixar.com
  • Länderspezifische Domains, um die Lokalisierung zu aktivieren: google.co.in, google.co.uk
  • Dienstdomains, mit denen Nutzer nie direkt interagieren, die aber Dienste auf den Websites derselben Organisation bereitstellen: gstatic.com, githubassets.com, fbcdn.net
  • Sandbox-Domains, mit denen Nutzer nie direkt interagieren, die aber aus Sicherheitsgründen vorhanden sind: googleusercontent.com, githubusercontent.com

Wie kann ich mitmachen?

Wenn Sie mehrere Websites haben, die den oben genannten Kriterien entsprechen, haben Sie verschiedene Möglichkeiten, sich zu beteiligen. Die geringste Investition ist es, die Diskussion zu den beiden Vorschlägen zu lesen und daran teilzunehmen:

Während der Testphase können Sie die Funktion mit dem Befehlszeilen-Flag --use-first-party-set und einer durch Kommas getrennten Liste von Websites testen.

Sie können dies auf der Demo-Website unter https://fps-member1.glitch.me/ ausprobieren, nachdem Sie Chrome mit dem folgenden Flag gestartet haben:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Das ist hilfreich, wenn Sie in Ihrer Entwicklungsumgebung testen oder das SameParty-Attribut in einer Live-Umgebung hinzufügen möchten, um zu sehen, wie sich ein selbst erhobenes Set auf die Cookies auswirkt.

Wenn Sie Zeit für Tests und Feedback haben, können Sie sich auch für den Ursprungstest für First-Party-Sets und SameParty registrieren, der in Chrome von Version 89 bis 93 verfügbar ist.

Cookies für den Test der Website-Quelle aktualisieren

Wenn Sie am Ursprungstest teilnehmen und das SameParty-Attribut in Ihren Cookies testen, sollten Sie zwei Muster berücksichtigen.

Option 1

Wenn Sie Cookies, die Sie als SameSite=None gekennzeichnet haben, auf Kontexte mit selbst erhobenen Daten beschränken möchten, können Sie ihnen das SameParty-Attribut hinzufügen. In Browsern, in denen der Test für den Ursprung aktiv ist, wird das Cookie nicht in websiteübergreifenden Kontexten außerhalb des Sets gesendet.

Bei den meisten Browsern, die nicht am Ursprungstest teilnehmen, wird das Cookie jedoch weiterhin wie gewohnt websiteübergreifend gesendet. Betrachten Sie dies als Ansatz für progressive Verbesserung.

Vorher:set-cookie: cname=cval; SameSite=None; Secure

Nachher:set-cookie: cname=cval; SameSite=None; Secure; SameParty

Option 2

Die zweite Option ist aufwendiger, ermöglicht es aber, den Ursprungstest vollständig von vorhandenen Funktionen zu trennen und speziell die Kombination SameSite=Lax; SameParty zu testen.

Vorher:set-cookie: cname=cval; SameSite=None; Secure

Nachher

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Wenn Sie bei eingehenden Anfragen nach dem Cookie suchen, sollten Sie das cname-fps-Cookie nur bei einer websiteübergreifenden Anfrage sehen, wenn sich die betreffenden Websites im Set befinden und der Browser sich im Ursprungstest befindet. Stellen Sie sich diesen Ansatz als gleichzeitige Einführung einer aktualisierten Funktion vor, bevor die vorherige Version eingestellt wird.

Warum benötigen Sie möglicherweise kein Set mit selbst erhobenen Daten?

Bei den meisten Standorten ist die Standortgrenze ein akzeptabler Ort, um die Trennlinie oder Datenschutzgrenze zu ziehen. Dieser Ansatz wird mit CHIPS (Cookies Having Independent Partitioned State) vorgeschlagen. Websites können dann über das Partitioned-Attribut die erforderlichen websiteübergreifenden Einbettungen, Ressourcen, APIs und Dienste weiterhin nutzen, während das Risiko von Datenlecks verringert wird.

Es gibt noch einige andere Aspekte, die dafür sprechen, dass Ihre Website möglicherweise ohne Satz funktioniert:

  • Sie hosten über verschiedene Ursprünge, nicht über verschiedene Websites. Wenn brandx.site im obigen Beispiel fly.brandx.site und drive.brandx.site hat, sind das unterschiedliche Subdomains auf derselben Website. Die Cookies können SameSite=Lax verwenden und es ist keine Einrichtung erforderlich.
  • Sie stellen anderen Websites eingebettete Inhalte von Drittanbietern zur Verfügung. Im Intro ist das Beispiel eines Videos von video.site, das auf my-blog.site eingebettet ist, ein klares Beispiel für Inhalte von Drittanbietern. Die Websites werden von verschiedenen Organisationen betrieben und Nutzer sehen sie als separate Entitäten. Diese beiden Standorte sollten nicht in einem Set zusammengefasst werden.
  • Sie stellen Dienste zur Anmeldung über soziale Netzwerke von Drittanbietern bereit. Identitätsanbieter, die OAuth oder OpenID Connect verwenden, setzen häufig Drittanbieter-Cookies ein, um die Anmeldung für Nutzer zu vereinfachen. Das ist ein gültiger Anwendungsfall, der sich aber nicht für First-Party-Sets eignet, da es einen deutlichen Unterschied zwischen den Organisationen gibt. Erste Vorschläge wie WebID untersuchen Möglichkeiten, diese Anwendungsfälle zu ermöglichen.