Testanleitung für First-Party-Sets

Die neueste Version von First-Party-Sets ist bereit für Entwickler-Funktions-Flag-Tests ab Chrome 108. Wir arbeiten aktiv an der Auslieferung von First-Party-Sets und berücksichtigen daher Feedback für diese Phase der Entwicklertests bis zur Veröffentlichung von Chrome 111 Anfang März (7. März 2023).

Die Rückmeldungen zur Plattform haben wir auf einige websiteübergreifende Anwendungsfälle hingewiesen, die sich darauf auswirken, wenn Drittanbieter-Cookies in Chrome nicht mehr unterstützt werden. Das Angebot für First-Party-Sets untersucht und untersucht eine Klasse von websiteübergreifenden Anwendungsfällen, bei denen die voneinander abhängigen Websites eine Beziehung haben, die dem Browser ausgedrückt werden kann, sodass der Browser im Namen des Nutzers die entsprechende Aktion ausführen und/oder dem Nutzer diese Informationen effektiv präsentieren kann.

Im aktualisierten Angebot werden zwei APIs (die Storage Access API und eine neue API mit dem vorläufigen Namen requestStorageAccessForOrigin) verwendet, um Websites eine aktive Methode zur Verfügung zu stellen, um den websiteübergreifenden Zugriff auf ihre Cookies in einem First-Party-Set anzufordern. Anhand der folgenden Anleitung können Sie testen und validieren, welche Gruppen Sie für Ihre Websites erstellen möchten und welche Punkte zum Aufrufen der beiden verschiedenen APIs am besten geeignet sind.

First-Party-Sets – Übersicht

First-Party-Sets (FPS) sind eine Webplattform, über die Entwickler Beziehungen zwischen Websites deklarieren können, damit Browser diese Informationen verwenden können, um einen eingeschränkten websiteübergreifenden Cookie-Zugriff für bestimmte nutzerseitige Zwecke zu ermöglichen. Anhand dieser erklärten Beziehungen entscheidet Chrome, wann einer Website im Kontext von Drittanbietern der Zugriff auf ihre Cookies gewährt oder verweigert wird.

Grundsätzlich ist ein First-Party-Set eine Sammlung von Domains, für die es ein einziges „primäres Set“ und möglicherweise mehrere „Set-Mitglieder“ gibt. Nur Website-Autoren können ihre Domains zu einem Satz einreichen und sie müssen die Beziehung zwischen jedem „Set-Mitglied“ zu seinem „Set-Primär“ deklarieren. Satzmitglieder können eine Reihe verschiedener Domaintypen mit Teilmengen basierend auf Anwendungsfällen umfassen.

Wir schlagen vor, die Storage Access API (SAA) und requestStorageAccessForOrigin zu verwenden, um den Cookie-Zugriff innerhalb eines FPS zu ermöglichen, um die Verarbeitung der einzelnen Teilmengen durch den Browser entsprechend dem Datenschutz jeder Teilmenge zu erleichtern.

Mit der SAA können Websites aktiv den websiteübergreifenden Cookie-Zugriff anfordern. Chrome gewährt die Anfrage automatisch, wenn die anfragende Website und die Website der obersten Ebene denselben fps haben. Informationen dazu, wie SAA-Aufrufe von anderen Browsern verarbeitet werden, finden Sie in der Dokumentation zur Storage Access API (SAA).

SAA verlangt derzeit, dass das Dokument die Nutzeraktivierung erhält, bevor die API-Methoden aufgerufen werden.

Dies kann die Implementierung der Framerate für Top-Level-Websites erschweren, die websiteübergreifende Bilder oder Skript-Tags verwenden, für die Cookies erforderlich sind. Um einige dieser Herausforderungen zu meistern, haben wir eine neue API namens requestStorageAccessForOrigin vorgeschlagen, die Entwicklern die Übernahme dieser Änderung erleichtert. Diese API ist auch zum Testen verfügbar.

Einreichung festlegen

Die kanonische FPS-Liste ist eine öffentlich sichtbare Liste im JSON-Dateiformat, die sich in einem neuen FPS-GitHub-Repository befindet und als Datenquelle für alle Sätze dient. Chrome verwendet diese Datei, damit sie auf ihr Verhalten angewendet werden kann.

Weitere Informationen zum vorgeschlagenen Prozess und zu den Anforderungen für die Einreichung von Sätzen finden Sie in den Einreichrichtlinien. Sie können auch ein Set einreichen, um die verschiedenen technischen Prüfungen zu testen, mit denen Ihre Einreichungen validiert werden. Hinweis: Alle Einreichungen werden gelöscht, bevor die Framerate in den stabilen Chrome-Versionen verfügbar ist.

Da sich das Senden von Sätzen noch in der aktiven Entwicklung befindet, können Sie für lokale Tests Sätze nur in der Befehlszeile erstellen und direkt an den Browser übergeben. Bei lokalen Tests ist es nicht erforderlich, einen Satz an das GitHub-Repository zu senden, um Tests mit Funktions-Flags durchzuführen.

Lokale Tests

Voraussetzungen

Wenn Sie die FPS lokal testen möchten, verwenden Sie Chrome 108 oder höher, das über die Befehlszeile gestartet wird.

Wenn Sie anstehende Chrome-Funktionen schon vor ihrer Veröffentlichung ausprobieren möchten, laden Sie die Beta- oder Canary-Version von Chrome herunter.

Beispiel

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Weitere Informationen zum Ausführen von Chromium mit Flags

Schritte

Wenn Sie FPS lokal aktivieren möchten, müssen Sie die Option --enable-features von Chrome mit einer durch Kommas getrennten Liste von Flags verwenden, die in diesem Abschnitt erläutert werden. Außerdem müssen Sie eine Reihe verwandter Websites als JSON-Objekt deklarieren, das an --use-first-party-set übergeben wird.

fps aktivieren

FirstPartySets aktiviert die fps (FPS) in Chrome.

FirstPartySets

Storage Access API aktivieren

StorageAccessAPI

Aktiviert die Storage Access API (SAA) in Chrome, die es eingebetteten iFrames ermöglicht, mithilfe von requestStorageAccess() den Zugriff auf Cookies in einem websiteübergreifenden Kontext anzufordern, auch wenn Drittanbieter-Cookies vom Browser blockiert werden.

Hinweis: Wenn requestStorageAccess() aufgerufen wird, ist zum Auflösen eine Nutzergeste erforderlich. Für zukünftige Versionen von Chrome gelten möglicherweise andere Anforderungen, da die SAA-Spezifikation sich noch in der Entwicklung befindet. Hier finden Sie eine Liste mit geplanten Verbesserungen der SAA in Chrome.

StorageAccessAPIForOriginExtension

Hiermit wird festgelegt, dass Websites der obersten Ebene über requestStorageAccessForOrigin() Speicherzugriff für bestimmte Ursprünge anfordern können. Das ist nützlich für Websites auf oberster Ebene, die websiteübergreifende Bilder oder Skript-Tags verwenden, die Cookies erfordern, und einige der Herausforderungen bei der Einführung von SAA beseitigen.

Gruppe lokal deklarieren

Ein First-Party-Set ist eine Sammlung von Domains, für die es ein einzelnes „Set primär“ und möglicherweise mehrere „Set Members“ gibt. Satzmitglieder können eine Reihe verschiedener Domaintypen mit Teilmengen basierend auf Anwendungsfällen umfassen.

Erstellen Sie ein JSON-Objekt, das URLs enthält, die Mitglieder eines Satzes sind, und übergeben Sie es an --use-first-party-set.

Im folgenden Beispiel sind unter primary die primäre Domain und unter associatedSites Domains aufgeführt, die den Anforderungen der zugeordneten Teilmenge entsprechen.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Beispiel:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Für lokale Tests können Sie Sätze nur in der Befehlszeile erstellen und direkt an den Browser übergeben. Für lokale Testzwecke gibt es keine Set-Validierung. Wenn FPS jedoch in stabilen Versionen ausgeliefert wird, müssen alle Sätze an das FPS-GitHub-Repository gesendet werden und den Validierungskriterien unterliegen.

FPS-UI aktivieren

PageInfoCookiesSubpage

Aktiviert die Anzeige von fps im Bereich „PageInfo“, der über die URL-Leiste aufgerufen werden kann.

PrivacySandboxFirstPartySetsUI

Aktiviert die FPS-Benutzeroberfläche mit der Option „Ähnliche Websites dürfen meine Aktivitäten in der Gruppe sehen“ in den Chrome-Einstellungen unter „Datenschutz und Sicherheit“ → „Cookies und andere Websitedaten“ (chrome://settings/cookies).

Prüfen, ob Drittanbieter-Cookies blockiert werden

  1. Gehe in den Chrome-Einstellungen zu „Datenschutz und Sicherheit“ → „Cookies und andere Websitedaten“ oder chrome://settings/cookies.
  2. Unter den allgemeinen Einstellungen muss die Option „Drittanbieter-Cookies blockieren“ aktiviert sein.
  3. Prüfen Sie, ob die Unteroption „Ähnliche Websites dürfen meine Aktivitäten in der Gruppe sehen“ ebenfalls aktiviert ist.

Sicherheitsaspekte

Da die Storage Access API es Websites ermöglicht, in ausgewählten Fällen wieder Zugriff auf Drittanbieter-Cookies zu erhalten, können Webanwendungen anfällig für websiteübergreifende Angriffe und Datenlecks bleiben. Bei Websites, die websiteübergreifende Cookies verwenden, sollten Sie sich der Risiken von CSRF- und anderen Angriffen bewusst sein.

Geplante Verbesserungen

Um dies zu verbessern, werden in zukünftigen Chrome-Versionen zusätzliche Sicherheitskontrollen erforderlich sein, um eine ausdrückliche Zustimmung zur Einbettung zu ermöglichen. Die vorgeschlagenen Verbesserungen würden: Zugriff nur für jeden Frame gewähren, CORS bei Anfragen mit Anmeldedaten verlangen und den Zugriffsbereich nur auf den Ursprung beschränken. Mehr dazu in der aktuellen Sicherheitsanalyse.

Sehen Sie sich die Liste der geplanten Verbesserungen an der Implementierung der SAA in Chrome an.

Beachten Sie, dass Chrome nur Cookies mit der Kennzeichnung „SameSite=None“ in websiteübergreifenden eingebetteten Kontexten sendet. Hier ist die Storage Access API relevant. Bis alle Browser den Standardzugriff auf diese Cookies eingestellt haben, können jedoch keine Annahmen darüber getroffen werden, wo das Cookie verwendet werden könnte. Es ist nicht sicher davon auszugehen, dass der Zugriff nur innerhalb eines fps erlaubt ist, und dass auf Websites weiterhin die standardmäßigen Best Practices für die Sicherheit angewendet werden sollten.

Reagieren und Feedback geben

Lokale Tests sind eine Gelegenheit, den Mechanismus der Storage Access API zur Aktivierung der FPS zu testen und Feedback oder auftretende Probleme zu teilen. Außerdem kannst du den festgelegten Einreichungsprozess auf GitHub testen, um deine Erfahrungen mit dem Prozess und den Validierungsschritten zu teilen. So interagieren Sie mit dem aktualisierten Angebot und geben Feedback dazu: