Testanleitung für First-Party-Sets

Die neueste Version der First-Party-Sets ist bereit für den Test mit Funktions-Flags von Entwicklern ab Chrome 108. Wir arbeiten aktiv an First-Party-Sets, um den Versand zu ermöglichen. Daher werden wir Feedback für diese Phase der Entwicklertests bis zur Veröffentlichung von Chrome 111 Anfang März (7. März 2023) berücksichtigen.

Das Feedback zur Plattform zeigt, dass websiteübergreifende Anwendungsfälle betroffen sein werden, wenn Drittanbieter-Cookies in Chrome nicht mehr unterstützt werden. Das „First-Party-Sets“-Angebot untersucht und befasst sich mit einer Reihe von websiteübergreifenden Anwendungsfällen, bei denen die voneinander abhängigen Websites eine Beziehung teilen, die dem Browser so ausgedrückt werden kann, dass der Browser im Namen des Nutzers die entsprechende Aktion ausführen und/oder dem Nutzer diese Informationen effektiv präsentieren kann.

Im aktualisierten Vorschlag werden zwei APIs verwendet (die Storage Access API und eine neue API mit dem Namen requestStorageAccessForOrigin), um Websites eine aktive Methode zur Anforderung des websiteübergreifenden Zugriffs auf ihre Cookies in einem First-Party-Set bereitzustellen. 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 geeignet sind.

First-Party-Sets – Übersicht

First-Party Sets (FPS) ist ein Webplattformmechanismus, mit dem Entwickler Beziehungen zwischen Websites deklarieren, damit Browser diese Informationen verwenden können, um den Zugriff auf websiteübergreifende Cookies für bestimmte, für den Nutzer sichtbare Zwecke zu beschränken. Chrome nutzt diese deklarierten Beziehungen, um zu entscheiden, wann einer Website im Zusammenhang mit Dritten der Zugriff auf ihre Cookies gewährt oder verweigert wird.

Grundsätzlich besteht ein First-Party-Set aus einer Sammlung von Domains, für die es ein einziges „Primäres Set“ gibt. und möglicherweise auch mehrere „Set-Mitglieder“. Nur Website-Autoren können ihre Domains für einen Satz einreichen und müssen die Beziehung zwischen den einzelnen Gruppenmitgliedern deklarieren. auf „Primär festlegen“. Satzmitglieder können eine Reihe verschiedener Domaintypen mit Untersätzen basierend auf Anwendungsfällen umfassen.

Wir schlagen vor, die Storage Access API (SAA) und requestStorageAccessForOrigin zu nutzen, um den Cookie-Zugriff innerhalb eines fps zu ermöglichen. So kann der Browser die einzelnen Teilmengen entsprechend den Datenschutzbestimmungen jeder Teilmenge besser verarbeiten.

Mit der SAA können Websites aktiv websiteübergreifenden Cookie-Zugriff anfordern. Chrome berücksichtigt die Anfrage automatisch, wenn sich die anfragende Website und die Website der obersten Ebene im selben fps befinden. Informationen dazu, wie Aufrufe an SAA von anderen Browsern verarbeitet werden, finden Sie in der Dokumentation zur Storage Access API (SAA).

SAA erfordert derzeit, dass das Dokument eine Nutzeraktivierung erhält, bevor die Methoden der API aufgerufen werden.

Dies kann die Einführung von FPS für Websites auf oberster Ebene erschweren, die websiteübergreifende Bilder oder Skript-Tags verwenden, die Cookies erfordern. Um einige dieser Herausforderungen zu bewältigen, haben wir die neue API requestStorageAccessForOrigin vorgeschlagen, die Entwicklern die Umsetzung 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 in einem neuen FPS-GitHub-Repository, das als „Source of Truth“ für alle Datasets dient. Chrome verwendet diese Datei, um auf ihr Verhalten anzuwenden.

Weitere Informationen zum vorgeschlagenen Verfahren und zu den Anforderungen beim Einreichen von Sets finden Sie in den Richtlinien zur Einreichung. Sie können auch eine Reihe einreichen, um die verschiedenen technischen Prüfungen zu testen, mit denen die Einreichungen validiert werden. Hinweis: Alle Einreichungen werden gelöscht, bevor der FPS in stabilen Chrome-Versionen verfügbar ist.

Da sich der Prozess zum Einreichen von Sätzen noch in der Entwicklung befindet, können Sie für lokale Tests Sätze nur über die Befehlszeile erstellen und direkt an den Browser übergeben. Bei lokalen Tests muss kein Set an das GitHub-Repository gesendet werden, um Funktions-Flags zu testen.

Lokale Tests durchführen

Vorbereitung

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 vor der Veröffentlichung in einer Vorschau ansehen möchten, laden Sie die Betaversion oder die 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 zur Ausführung von Chromium mit Flags

Schritte

Wenn Sie die Fingerabdruckerkennung 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, und eine Reihe ähnlicher Websites als JSON-Objekt deklarieren, das an --use-first-party-set übergeben werden soll.

fps aktivieren

FirstPartySets aktiviert die FPS in Chrome.

FirstPartySets

Storage Access API aktivieren

StorageAccessAPI

Aktiviert die Storage Access API (SAA) in Chrome. Damit können eingebettete iFrames mithilfe von requestStorageAccess() den Zugriff auf Cookies in einem websiteübergreifenden Kontext anfordern, auch wenn Drittanbieter-Cookies vom Browser blockiert werden.

Beim Aufrufen von requestStorageAccess() ist eine Nutzergeste erforderlich, um das Problem zu beheben. Da sich die SAA-Spezifikation noch in der Entwicklung befindet, können in zukünftigen Chrome-Versionen andere Anforderungen gelten. Hier finden Sie eine Liste mit geplanten Verbesserungen der Implementierung der SAA in Chrome.

StorageAccessAPIForOriginExtension

Ermöglicht Websites auf oberster Ebene die Verwendung von requestStorageAccessForOrigin(), um Speicherzugriff für bestimmte Ursprünge anzufordern. Dies ist nützlich für Top-Level-Websites, die websiteübergreifende Bilder oder Skript-Tags verwenden, die Cookies erfordern, und einige der Herausforderungen bei der Einführung von SAA gelöst werden.

Satz lokal deklarieren

Ein First-Party-Set besteht aus mehreren Domains, für die es ein einziges „Primäres Set“ gibt. und möglicherweise auch mehrere „Set-Mitglieder“. Satzmitglieder können eine Reihe verschiedener Domaintypen mit Untersätzen 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 listet primary die primäre Domain auf und associatedSites die Domains, die die Anforderungen der zugehörigen Teilmenge erfüllen.

{
     "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\"]}"

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

fps-Benutzeroberfläche aktivieren

PageInfoCookiesSubpage

Aktiviert die Anzeige von fps im Bereich „PageInfo“ (Seiteninfo), auf den über die URL-Leiste zugegriffen werden kann.

PrivacySandboxFirstPartySetsUI

Aktiviert die FPS-Benutzeroberfläche „Zulassen, dass ähnliche Websites 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 Cookies von Drittanbietern blockiert werden

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

Sicherheitsaspekte

Da die Storage Access API es Websites in ausgewählten Fällen ermöglicht, wieder Zugriff auf Drittanbieter-Cookies zu erhalten, kann sie Webanwendungen anfällig für websiteübergreifende Angriffe und Datenlecks machen. Websites, die websiteübergreifend auf Cookies angewiesen sind, sollten sich der Risiken von CSRF und anderen Angriffen bewusst sein.

Geplante Verbesserungen

Um dies zu verbessern, sind in zukünftigen Chrome-Versionen zusätzliche Sicherheitskontrollen erforderlich. So soll sichergestellt werden, dass die Einbettung explizit aktiviert wird. Die vorgeschlagenen Verbesserungen würden nur Zugriff pro Frame gewähren, CORS für berechtigte Anfragen verlangen und den Zugriffsbereich nur auf den Ursprung beschränken. Weitere Informationen finden Sie in der aktuellen Sicherheitsanalyse.

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

Beachten Sie, dass Chrome Cookies mit der Kennzeichnung „SameSite=None“ nur in websiteübergreifenden eingebetteten Kontexten sendet. Dort 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. Man darf nicht davon ausgehen, dass der Zugriff nur innerhalb einer FPS zulässig ist und Websites weiterhin die standardmäßigen Best Practices für die Sicherheit befolgen sollten.

Interagieren und Feedback geben

Lokale Tests bieten die Gelegenheit, den Mechanismus der Storage Access API zur Aktivierung von FPS zu testen und Feedback zu geben oder Probleme zu melden. Außerdem bietet das Testen des Prozesses zum Einreichen von Sätzen auf GitHub die Gelegenheit, Ihre Erfahrungen mit den Prozess- und Validierungsschritten zu teilen. So nehmen Sie Kontakt mit dem aktualisierten Angebot auf und geben Feedback: