[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 wie example.com, example.rs, example.co.uk usw.

Immer mehr Browser erstellen Drittanbieter-Cookies veraltet um den Datenschutz im Web zu verbessern. Websites wie diese nutzen jedoch häufig Cookies, Funktionen, die die domainübergreifende Verwaltung und den Zugriff auf den Status erfordern z. B. Einmalanmeldung (SSO) und Einwilligungsverwaltung.

„First-Party-Sets“ können zugehörige Domainnamen zulassen, die dem Unternehmen gehören und von diesem und dasselbe Rechtssubjekt als Erstanbieter behandelt werden, wenn Erstanbieter- und werden sonst anders behandelt. Die Domainnamen innerhalb einer Cookies von Erstanbietern gelten als gleichermaßen und können mit Labels versehen, die im selben Drittanbieterkontext festgelegt oder gesendet werden sollen. Ziel ist es, zwischen dem Verhindern von websiteübergreifendem Tracking durch Dritte, einen Pfad beibehalten, der gültige Anwendungsfälle nicht abbricht.

Das „First-Party-Sets“-Angebot befindet sich derzeit in der Testphase Phase, lesen Sie weiter, um zu erfahren, wie es funktioniert. und wie Sie es ausprobieren können.

Was ist der Unterschied zwischen Erstanbieter- und Drittanbieter-Cookies?

Cookies gehören nicht grundsätzlich zu Erst- oder Drittanbieter-Cookies, sondern hängen vom aktuellen Kontext, in dem das Cookie enthalten ist. Entweder auf eine Anfrage im cookie-Header oder über document.cookie in JavaScript.

Wenn zum Beispiel video.site ein theme=dark-Cookie hat, während du im Internet surfst video.site und eine Anfrage wird an video.site gesendet, das ist eine gleiche Website Kontext enthaltenes Cookie eigene.

Wenn du dich jedoch auf my-blog.site befindest, in dem ein iFrame-Player video.site, wenn die Anfrage von my-blog.site an video.site gestellt wird für websiteübergreifenden Kontext und das theme-Cookie ist ein Drittanbieter.

Diagramm, das ein Cookie von video.site in zwei Kontexten zeigt. Das Cookie ist auf derselben Website, wenn der Kontext auf oberster Ebene auch „video.site“ ist. Das Cookie ist websiteübergreifend, wenn der Kontext auf oberster Ebene „my-blog.site“ mit video.site in einem iFrame ist.

Die Aufnahme von Cookies wird über das Attribut SameSite des Cookies bestimmt:

  • Gleiche Website Kontext durch Durch SameSite=Lax, Strict oder None wird das Cookie selbst erhoben.
  • Der websiteübergreifende Kontext mit SameSite=None macht das Cookie zu einem Drittanbieter.

Das ist jedoch nicht immer so eindeutig. Stell dir vor, brandx.site ist eine Reise Buchungswebsite und nutzen fly-brandx.site und drive-brandx.site, um separate Flüge und Mietwagen. Im Laufe der Buchung einer Fahrt zwischen diesen Websites hin und her wechseln, um die verschiedenen Optionen auszuwählen – sie erwarten, dass ihre "Einkaufswagen" der Auswahl, die auf diesen Websites bestehen bleibt. brandx.site verwaltet die Sitzung des Nutzers mit einem SameSite=None-Cookie, um sie zuzulassen websiteübergreifenden Kontexten. Der Nachteil ist, dass das Cookie jetzt keine websiteübergreifende Fordern Sie Fälschungsschutz (CSRF) an. Wenn evil.site eine Anfrage für brandx.site würde er dieses Cookie mit einschließen!

Das Cookie ist websiteübergreifend, aber alle diese Websites gehören demselben Eigentümer und werden von demselben Unternehmen. Die Besucher wissen auch, dass es sich um dieselbe Organisation handelt und dass die Besucher also eine gemeinsame Identität.

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

Richtlinie zu First-Party-Sets

First-Party-Sets vorschlagen, Methode, um explizit diese Beziehung über mehrere Websites hinweg zu definieren, gehören derselben Partei und werden von ihr betrieben. Dadurch könnte brandx.site seine eigene Beziehung zu fly-brandx.site definieren, drive-brandx.site usw.

Unser Datenschutzmodell Die verschiedenen Privacy Sandbox-Vorschläge basieren auf dem Konzept der Partitionierung, um websiteübergreifendes Tracking zu verhindern, also um eine Grenze zwischen Websites zu ziehen, schränkt den Zugriff auf alle Informationen ein, die zur Identifizierung von Nutzern verwendet werden können.

Diagramm mit dem Status „Nicht partitioniert“, bei dem dasselbe Drittanbieter-Cookie in mehreren websiteübergreifenden Kontexten zugänglich ist, im Gegensatz zu einem partitionierten Modell, bei dem jeder Kontext auf oberster Ebene eine separate Instanz des websiteübergreifenden Cookies hat, was die Verknüpfungsaktivität zwischen diesen Websites verhindert.

Die Standardoption ist die Partitionierung nach Website, was viele Erstanbieter- Anwendungsfälle zeigt das Beispiel brandx.site, dass eigene Daten als nur eine Website.

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

Ein wichtiger Teil des „First-Party-Sets“-Angebots in allen Browsern verhindert Missbrauch. First-Party-Sets dürfen beispielsweise nicht den Austausch von User-Informationen über unabhängige Sites hinweg ermöglichen oder die Gruppierung von Websites, die nicht demselben Unternehmen gehören. Es geht darum, sicherzustellen, „First-Party-Set“ ist etwas zugeordnet, das ein Nutzer als Erstanbieter versteht und die nicht dazu verwendet werden, ihre Identität zwischen verschiedenen Parteien zu teilen.

Eine Möglichkeit zum Registrieren einer Erstanbieter-Gruppe könnte sein, die vorgeschlagene Domain-Gruppe an einen öffentlichen Tracker (z. B. dediziertes GitHub-Repository) zusammen mit Informationen, die für die Browseranforderungen erforderlich sind. .

Sobald die Assertion für selbst erhobene Daten gemäß der Richtlinie überprüft wurde, können Browser und ruft dann über einen Aktualisierungsprozess Listen von Sätzen ab.

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

  • Die Domains in einer Gruppe mit selbst erhobenen Daten müssen demselben Eigentümer und Betreiber gehören Unternehmen.
  • Die Domains sollten für die Nutzer als Gruppe erkennbar sein.
  • Für die Domains sollte eine gemeinsame Datenschutzerklärung gelten.

So definieren Sie ein Set mit selbst erhobenen Daten

Nachdem Sie die Mitglieder und Inhaber der Erstanbieter- festgelegt ist, besteht ein entscheidender Schritt darin, den vorgeschlagenen Satz zur Genehmigung einzureichen. Die genaue wird noch diskutiert.

Zum Deklarieren eines Erstanbieter-Satzes statische JSON-Ressourcen, die Mitglieder und Inhaber auflisten sollte unter /.well-known/first-party-set auf der obersten Ebene jedes eingeschlossene Domain.

Im Beispiel der brandx-eigenen Gruppe wird in der Inhaberdomain folgen bei 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 auch eine statische JSON-Ressource, die auf den Eigentümer des Satzes. Bei https://fly-brandx.site/.well-known/first-party-set haben wir:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

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

  • Ein Satz kann nur einen Inhaber haben.
  • Ein Mitglied kann nur zu einem Satz gehören. Überlappungen und Überschneidungen sind nicht zulässig.
  • Die Mitgliederliste soll relativ menschenlesbar bleiben und die zu groß sind.

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

Die passende Zutat für Cookies ist der vorgeschlagene SameParty . SameParty angeben weist den Browser an, das Cookie einzuschließen, wenn sein Kontext Teil desselben Cookies ist. eigenen Daten als Kontext auf oberster Ebene festgelegt.

Wenn brandx.site dieses Cookie setzt, bedeutet dies Folgendes:

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

Wenn sich der Besucher auf fly-brandx.site befindet und eine Anfrage an brandx.site eingeben, wird das Cookie session in diese Anfrage eingefügt. Wenn z. B. eine andere Website, die nicht zur Erstanbieter-Gruppe gehört, hotel.xyz eine Anfrage an brandx.site sendet, wird das Cookie nicht eingeschlossen.

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

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

  • SameSite=Lax; SameParty erweitert die Lax-Funktion auf Enthält Kontexte von gleichem Anbieter, sofern dies unterstützt wird, verwendet aber Lax wenn nicht.
  • SameSite=None; SameParty schränkt die None-Funktion ein auf: wenn dies unterstützt wird. None-Berechtigungen, wenn nicht.

Es gelten 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 und Sie diese abschwächen sollten durch sichere HTTPS-Verbindungen. Da dies ein websiteübergreifende Beziehung ist, ist SameSite=Strict ungültig, da noch Folgendes zulässig ist: CSRF-Schutz innerhalb eines Sets eng gefasst.

Welche Anwendungsfälle sind für First-Party-Sets geeignet?

First-Party-Sets eignen sich gut für Fälle, in denen eine Organisation einer gemeinsamen Identität auf verschiedenen Top-Level-Websites. Gemeinsame Identität in diesem Fall ist alles möglich – von einer vollständigen Einmalanmeldungs-Lösung bis hin zur Website-Präferenz.

Ihre Organisation kann verschiedene Top-Level-Domains haben 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 auf den Websites derselben Organisation: gstatic.com, githubassets.com, fbcdn.net
  • Sandbox-Domains, mit denen Nutzer nie direkt interagieren, die aber für Sicherheitsgründe: googleusercontent.com, githubusercontent.com

Wie können Sie sich einbringen?

Wenn eine Reihe von Websites die oben genannten Kriterien erfüllt, gibt es eine wie Sie sich einbringen können. Am leichtesten ist es, der Diskussion zu den beiden Vorschlägen an:

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

Sie können dies auf der Demowebsite unter https://fps-member1.glitch.me/ nach dem Start Chrome mit dem folgenden Flag:

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

Dies ist hilfreich, wenn Sie Tests in Ihrer Entwicklungsumgebung oder versuchen Sie, das Attribut SameParty in einer Live-Umgebung hinzuzufügen, um zu sehen, wie ein auf die Cookies auswirken.

Wenn Sie genügend Zeit für Experimente und Feedback haben, können Sie sich für den Ursprungstest für Erstanbieter-Sets und SameParty die in Chrome von Version 89 bis 93 verfügbar ist.

Cookies für den Ursprungstest aktualisieren

Wenn Sie am Ursprungstest teilnehmen und das Attribut SameParty testen auf verwenden möchten, sollten Sie die folgenden beiden Muster berücksichtigen.

Option 1

Erstens: Sie haben Cookies, die Sie als SameSite=None gekennzeichnet haben, Sie auf Kontexte mit selbst erhobenen Daten beschränken möchten, können Sie die SameParty hinzufügen. In Browsern, in denen der Ursprungstest aktiv ist, wird das Cookie dürfen nicht in websiteübergreifenden Kontexten außerhalb des Datasets gesendet werden.

Bei den meisten in Browsern außerhalb des Ursprungstests, wird das Cookie weiterhin wie gewohnt websiteübergreifend. Betrachten Sie dies als Progressive-Enhancement-Ansatz.

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 die vollständige Trennung des Ursprungs aus vorhandenen Funktionen getestet und ermöglicht insbesondere das Testen der SameSite=Lax; SameParty-Kombination.

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, das cname-fps-Cookie bei einer websiteübergreifenden Anfrage, wenn die beteiligten Websites am festgelegt ist und sich der Browser im Ursprungstest befindet. Betrachten Sie diesen Ansatz als gleichzeitige Einführung einer aktualisierten Funktion, bevor die vorherige Version.

Warum brauchen Sie möglicherweise kein Erstanbieter-Set?

Bei den meisten Standorten ist ihre Standortgrenze ein geeigneter Ort zum Zeichnen. die Partitions- oder Abgrenzung. Dies ist die vorgeschlagene Route mit CHIPS (Cookies mit unabhängiger Partitionierung) Bundesstaat), die Websites die Möglichkeit geben, über das Partitioned-Attribut konfigurieren, um diese wichtigen Einbettungen, Ressourcen, APIs und Dienste und verhindern gleichzeitig Datenlecks websiteübergreifend.

Ihre Website kann unter Umständen auch ohne eine Reihe:

  • Ihr Hosting findet über unterschiedliche Ursprünge statt, nicht über unterschiedliche Websites. Im obigen Beispiel Wenn brandx.site fly.brandx.site und drive.brandx.site hätte, dann diese Es handelt sich um verschiedene Sub-Domains auf derselben Website. Die Cookies können SameSite=Lax und es wird kein Set benötigt.
  • Du gibst auf anderen Websites Einbettungen von Drittanbietern an. In der Einleitung wird das Beispiel Bei einem auf my-blog.site eingebetteten Video von video.site handelt es sich um einen eindeutigen Drittanbieter. dividieren. Die Websites werden von verschiedenen Organisationen betrieben und die Nutzer sehen sie. als separate Entitäten. Diese beiden Websites sollten sich nicht in einer Gruppe befinden.
  • Sie bieten soziale Anmeldedienste von Drittanbietern an. Identitätsanbieter, die Dinge wie OAuth oder OpenId Connect benötigen oft Drittanbieter-Cookies, eine reibungslosere Anmeldung. Das ist ein gültiger Anwendungsfall, für First-Party-Sets geeignet, weil es bei den Organisationen einen klaren Unterschied gibt. Frühe Angebote wie WebID sind und suchen nach Möglichkeiten, diese Anwendungsfälle zu ermöglichen.