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

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

Browser werden immer mehr von Drittanbieter-Cookies überflüssig, um den Datenschutz im Web zu verbessern. Websites wie diese verwenden jedoch häufig Cookies für Funktionen, für die der Status über verschiedene Domains hinweg verwaltet und abgerufen werden muss (z. B. Einmalanmeldung und Einwilligungsverwaltung).

Mit First-Party-Sets können zusammengehörige Domainnamen, die derselben Entität gehören und von ihr betrieben werden, in Situationen, in denen Erstanbieter und Drittanbieter anders behandelt werden, als Erstanbieter behandelt werden. Die Domainnamen in einer Gruppe von Erstanbieter gelten als Sameparty und können mit Labels versehen werden, welche Cookies im selben Kontext festgelegt oder gesendet werden sollen. Ziel ist es, ein Gleichgewicht zwischen dem Verhindern von websiteübergreifendem Tracking durch Drittanbieter und einem Weg zu finden, der gültige Anwendungsfälle nicht bricht.

Das Angebot für First-Party-Sets befindet sich derzeit in der Testphase. Lesen Sie weiter, um zu erfahren, wie es funktioniert und wie Sie es ausprobieren können.

Was ist der Unterschied zwischen eigenen und Drittanbieter-Cookies?

Cookies gehören nicht grundsätzlich zu Erstanbieter- oder Drittanbieter-Cookies. Sie hängen vom aktuellen Kontext ab, in dem das Cookie enthalten ist. Das erfolgt entweder bei einer Anfrage im cookie-Header oder über document.cookie in JavaScript.

Wenn video.site beispielsweise ein theme=dark-Cookie hat und Sie beim Durchsuchen von video.site eine Anfrage an video.site senden, ist das ein SameSite-Kontext und das enthaltene Cookie ist ein eigenes Cookie.

Wenn Sie sich jedoch auf my-blog.site befinden, das einen iFrame-Player für video.site einbettet, gilt beim Senden der Anfrage von my-blog.site an video.site ein websiteübergreifender Kontext und das theme-Cookie ist ein Drittanbieter.

Diagramm, das ein Cookie von video.site in zwei Kontexten zeigt Das Cookie ist „Same-Site“, wenn der Kontext der obersten Ebene ebenfalls „video.site“ ist. Das Cookie ist websiteübergreifend, wenn der Kontext der obersten Ebene meine-blog.site mit video.site in einem iFrame lautet.

Das Einbeziehen von Cookies wird durch das SameSite-Attribut des Cookies bestimmt:

  • Durch Kontext auf derselben Website mit SameSite=Lax, Strict oder None wird das Cookie zu einem eigenen Cookie.
  • Websiteübergreifender Kontext mit SameSite=None macht das Cookie zu einem Drittanbieter.

Das ist jedoch nicht immer so eindeutig. Stellen Sie sich vor, brandx.site ist eine Reisebuchungswebsite, die auch fly-brandx.site und drive-brandx.site verwendet, um Flüge und Mietwagen zu trennen. Beim Buchen einer Reise wechseln Nutzer zwischen diesen Websites, um die verschiedenen Optionen auszuwählen. Sie erwarten, dass die Auswahl des Einkaufswagens auf diesen Websites beibehalten wird. brandx.site verwaltet die Nutzersitzung mit einem SameSite=None-Cookie, um sie websiteübergreifend zuzulassen. Der Nachteil ist, dass das Cookie jetzt nicht mehr durch Cross-Site-Request-Fälschungen (CSRF) geschützt ist. Wenn evil.site eine Anfrage an brandx.site enthält, wird auch dieses Cookie einbezogen.

Das Cookie ist zwar websiteübergreifend, doch alle diese Websites gehören derselben Organisation und werden von ihr betrieben. Die Besucher erkennen außerdem, dass es sich um dieselbe Organisation handelt, und möchten dieselbe Sitzung, also eine gemeinsame Identität.

Diagramm, das zeigt, wie ein Cookie weiterhin in einen websiteübergreifenden Kontext einbezogen werden kann, wenn die Websites Teil desselben First-Party-Sets sind, aber für websiteübergreifende Kontexte außerhalb des Datasets abgelehnt werden würden.

Richtlinie für First-Party-Sets

Bei First-Party-Sets wird eine Methode vorgeschlagen, um diese Beziehung für mehrere Websites, die derselben Partei gehören und von ihr betrieben werden, explizit zu definieren. Dadurch kann brandx.site seine eigene Beziehung zu fly-brandx.site, drive-brandx.site usw. definieren.

Das Datenschutzmodell, auf dem die verschiedenen Privacy Sandbox-Vorschläge basieren, basiert auf dem Konzept der Partitionierung der Identität, um websiteübergreifendes Tracking zu verhindern. Dabei wird eine Grenze zwischen Websites gezogen, die den Zugriff auf alle Informationen beschränkt, die zur Identifizierung von Nutzern verwendet werden können.

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

Die Standardoption ist zwar die Partitionierung nach Standort, wodurch viele eigene Anwendungsfälle gelöst werden können, aber das brandx.site-Beispiel zeigt, dass eine eigene Instanz größer als nur ein Standort sein kann.

Diagramm, das zeigt, wie dieselbe Instanz eines Cookies für eine Gruppe in websiteübergreifende Kontexte einbezogen werden kann, wenn alle diese Websites zur selben Gruppe gehören.

Ein wichtiger Teil des Vorschlags „First-Party-Sets“ besteht darin, dafür zu sorgen, dass durch Browserübergreifende Richtlinien Missbrauch oder Missbrauch verhindert werden. First-Party-Sets dürfen beispielsweise nicht den Austausch von Nutzerinformationen über irrelevante Websites hinweg oder die Gruppierung von Websites, die nicht derselben Entität gehören, ermöglichen. Wichtig ist, dass ein First-Party-Set einer Person zugeordnet wird, die als Erstanbieter gilt, und nicht dazu verwendet wird, die Identität zwischen verschiedenen Parteien zu teilen.

Eine Website zum Registrieren eines Erstanbietersatzes könnte darin bestehen, die vorgeschlagene Gruppe von Domains zusammen mit Informationen, die zur Einhaltung der Browserrichtlinie erforderlich sind, an einen öffentlichen Tracker (z. B. ein dediziertes GitHub-Repository) zu senden.

Sobald die Assertion von selbst erhobenen Sätzen gemäß der Richtlinie verifiziert wurde, können Browser über einen Aktualisierungsprozess Listen mit Sätzen abrufen.

Der Ursprungstest hat eine definierte Richtlinie, die nicht endgültig ist, aber die Prinzipien werden wahrscheinlich gleich bleiben:

  • Die Domains in einer Erstanbieter-Gruppe müssen derselben Organisation gehören und von ihr betrieben werden.
  • Die Domains sollten für Nutzer als Gruppe erkennbar sein.
  • Für die Domains muss eine gemeinsame Datenschutzerklärung verwendet werden.

Zielgruppe mit selbst erhobenen Daten definieren

Nachdem Sie die Mitglieder und den Inhaber des Erstanbietersatzes Ihrer Organisation identifiziert haben, besteht ein wichtiger Schritt darin, den vorgeschlagenen Satz zur Genehmigung einzureichen. Der genaue Prozess wird derzeit noch diskutiert.

Zum Deklarieren eines Erstanbietersatzes sollten statische JSON-Ressourcen, in denen Mitglieder und Inhaber aufgelistet werden, unter /.well-known/first-party-set auf der obersten Ebene jeder eingeschlossenen Domain gehostet werden.

Im Beispiel der eigenen Gruppe brandx hostet die Inhaberdomain Folgendes unter https://brandx.site/.well-known/first-party-set:

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

Jedes Mitglied des Satzes hostet außerdem eine statische JSON-Ressource, die auf den Inhaber des Satzes verweist. Hier bei https://fly-brandx.site/.well-known/first-party-set gibt es:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

Für Gruppen mit selbst erhobenen Daten gelten einige Einschränkungen:

  • Ein Satz kann nur einen Inhaber haben.
  • Ein Mitglied darf nur zu einem Satz gehören. Es darf sich nicht überlappen oder sich vermischen.
  • Die Mitgliederliste soll für Menschen lesbar bleiben und nicht übermäßig groß sein.

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

Die übereinstimmende Zutat für Cookies ist das vorgeschlagene Attribut SameParty. Wenn Sie SameParty angeben, wird der Browser angewiesen, das Cookie einzubeziehen, wenn sein Kontext Teil derselben Erstanbieter-Umgebung wie der Kontext der obersten Ebene ist.

Wenn brandx.site dieses Cookie also setzt, bedeutet das:

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

Wenn sich der Besucher dann im fly-brandx.site befindet und eine Anfrage an brandx.site gesendet wird, wird das session-Cookie in diese Anfrage eingefügt. Wenn eine andere Website, die nicht Teil des Erstanbieter-Datasets ist, z. B. hotel.xyz, eine Anfrage an brandx.site sendet, wird das Cookie nicht eingeschlossen.

Diagramm, das zeigt, wie das Cookie „brandx.site“ wie beschrieben im websiteübergreifenden Kontext zugelassen oder blockiert wird.

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

  • SameSite=Lax; SameParty erweitert die Lax-Funktion so, dass sie Kontexte derselben Partei enthält, sofern diese unterstützt werden. Falls nicht, gelten die Lax-Einschränkungen.
  • SameSite=None; SameParty schränkt die None Funktionalität auf Kontexte derselben Partei ein, sofern dies unterstützt wird. Falls nicht, wird auf die umfassenderen None Berechtigungen zurückgegriffen.

Es gibt einige zusätzliche Anforderungen:

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

Secure ist vorgeschrieben, da dies immer noch websiteübergreifend ist. Sie sollten diese Risiken durch sichere HTTPS-Verbindungen minimieren. Da es sich um eine websiteübergreifende Beziehung handelt, ist SameSite=Strict ungültig, da weiterhin ein strenger websitebasierter CSRF-Schutz innerhalb eines Satzes möglich ist.

Welche Anwendungsfälle eignen sich für First-Party-Sets?

First-Party-Sets eignen sich gut für den Fall, dass ein Unternehmen eine Form der gemeinsamen Identität für verschiedene Websites auf oberster Ebene benötigt. Eine gemeinsame Identität bedeutet in diesem Fall alles, von einer Lösung für die vollständige Einmalanmeldung (SSO) bis hin zu einer gemeinsamen Präferenz für mehrere Websites.

Ihre Organisation hat möglicherweise unterschiedliche Top-Level-Domains für:

  • App-Domains: office.com,live.com, microsoft.com
  • Markendomains: amazon.com, audible.com / disney.com, pixar.com
  • Länderspezifische Domains für die Lokalisierung: 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 existieren: googleusercontent.com, githubusercontent.com

Wie können Sie mitmachen?

Wenn Sie eine Reihe von Websites haben, die die oben genannten Kriterien erfüllen, gibt es verschiedene Möglichkeiten, sich darum zu kümmern. Am einfachsten ist es, die beiden Vorschläge zu lesen und sich an der Diskussion zu beteiligen:

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

Sie können dies auf der Demowebsite 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 Tests in Ihrer Entwicklungsumgebung durchführen oder das Attribut SameParty in einer Live-Umgebung hinzufügen möchten, um zu sehen, wie sich ein eigenes Set auf die Cookies auswirken würde.

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

Cookies für den Ursprungstest aktualisieren

Wenn Sie dem Ursprungstest beitreten und das Attribut SameParty für Ihre Cookies testen, sind zwei Muster zu berücksichtigen.

Option 1

Wenn Sie Cookies mit dem Label SameSite=None haben, aber auf eigene Kontexte beschränken möchten, können Sie ihnen das Attribut SameParty hinzufügen. In Browsern, in denen der Ursprungstest aktiv ist, wird das Cookie nicht in websiteübergreifenden Kontexten außerhalb der Gruppe gesendet.

Bei den meisten Browsern außerhalb des Ursprungstests wird das Cookie jedoch weiterhin wie gewohnt websiteübergreifend gesendet. Betrachten Sie dies als Ansatz der progressiven 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 aber, den Ursprungstest vollständig von der vorhandenen Funktionalität zu trennen, und ermöglicht insbesondere das Testen der Kombination SameSite=Lax; SameParty.

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 das Cookie bei eingehenden Anfragen suchen, sollten Sie nur dann davon ausgehen, dass das Cookie cname-fps bei einer websiteübergreifenden Anfrage zu sehen ist, wenn die beteiligten Websites in dem Satz enthalten sind und sich der Browser im Ursprungstest befindet. Betrachten Sie diesen Ansatz als eine gleichzeitige Einführung eines aktualisierten Features, bevor die vorherige Version heruntergefahren wird.

Warum brauchst du kein eigenes Set?

Bei den meisten Standorten ist die Standortgrenze ein akzeptabler Ort, um die Partitions- oder Datenschutzgrenze zu zeichnen. Dies ist die Route, die mit CHIPS (Cookies Having Independent Partitioned State) vorgeschlagen wird. Websites erhalten dadurch über das Attribut Partitioned eine Aktivierungsroute, über die sie weiterhin diese wichtigen websiteübergreifenden Einbettungen, Ressourcen, APIs und Dienste nutzen können. Gleichzeitig wird verhindert, dass personenidentifizierbare Informationen preisgegeben werden.

Es gibt noch ein paar weitere Dinge, die Sie beachten sollten, damit Ihre Website in Ordnung ist, auch wenn Sie keinen Satz benötigen:

  • Ihr Hostet über unterschiedliche Ursprünge, nicht über verschiedene Websites. Wenn im obigen Beispiel brandx.site fly.brandx.site und drive.brandx.site hatte, sind das unterschiedliche Subdomains derselben Website. Die Cookies können SameSite=Lax verwenden und sind nicht erforderlich.
  • Sie stellen Einbettungen von Drittanbietern auf anderen Websites bereit. Im Intro ist das Beispiel eines Videos von video.site, das auf my-blog.site eingebettet ist, eine deutliche Drittanbieter-Division. Die Websites werden von verschiedenen Organisationen betrieben und den Nutzern als separate Entitäten angezeigt. Diese beiden Websites sollten nicht in einem Set zusammengehören.
  • Sie bieten Drittanbieter-Dienste für soziale Anmeldung an. Identitätsanbieter, die OAuth oder OpenId verwenden, verlassen sich häufig auf Drittanbieter-Cookies, um Nutzern eine reibungslosere Anmeldung zu ermöglichen. Dies ist ein gültiger Anwendungsfall, eignet sich aber nicht für First-Party-Sets, da es einen klaren Unterschied zwischen Organisationen gibt. In ersten Angeboten wie WebID wird geprüft, wie sich diese Anwendungsfälle realisieren lassen.