Testanleitung für First-Party-Sets

Die neueste Version von First-Party-Sets kann ab Chrome 108 mit dem Funktions-Flag für Entwickler getestet werden. Wir arbeiten aktiv an Sets mit selbst erhobenen Daten, um sie bald einführen zu können. Daher berücksichtigen wir Feedback zu dieser Phase der Entwicklertests bis zur Veröffentlichung von Chrome 111 Anfang März (7. März 2023).

Das Feedback des Werbesystems hat Anwendungsfälle für websiteübergreifende Werbung aufgezeigt, die sich ändern werden, wenn Drittanbieter-Cookies in Chrome nicht mehr unterstützt werden. Im Vorschlag für First-Party-Sets werden Anwendungsfälle untersucht und behandelt, bei denen die voneinander abhängigen Websites eine Beziehung haben, die dem Browser mitgeteilt werden kann, damit der Browser im Namen des Nutzers die entsprechenden Maßnahmen ergreifen und/oder diese Informationen effektiv präsentieren kann.

Der aktualisierte Vorschlag verwendet zwei APIs (die Storage Access API und eine neue API mit dem vorläufigen Namen requestStorageAccessForOrigin), um Websites eine aktive Methode zum Anfordern von websiteübergreifendem Zugriff auf ihre Cookies innerhalb eines Sets selbst erhobener Daten zu bieten. Anhand der folgenden Anleitung können Sie testen und prüfen, welche Sets Sie für Ihre Websites erstellen möchten und an welchen Stellen die beiden APIs aufgerufen werden sollen.

First-Party-Sets – Übersicht

First-Party-Sets (FPS) ist ein Webplattformmechanismus, mit dem Entwickler Beziehungen zwischen Websites deklarieren können, damit Browser diese Informationen verwenden können, um für bestimmte nutzerorientierte Zwecke einen eingeschränkten websiteübergreifenden Cookie-Zugriff zu ermöglichen. Chrome verwendet diese erklärten Beziehungen, um zu entscheiden, ob einer Website der Zugriff auf ihre Cookies in einem Drittanbieterkontext erlaubt oder verweigert werden soll.

Ein First-Party-Set besteht aus einer Sammlung von Domains, für die es ein einzelnes „Set-Primärelement“ und potenziell mehrere „Set-Mitglieder“ gibt. Nur Websiteautoren können ihre Domains in eine Gruppe einreichen. Sie müssen die Beziehung zwischen jedem „Set-Mitglied“ und seinem „Set-Primärelement“ angeben. Die Mitglieder eines Sets können verschiedene Domaintypen mit auf Anwendungsfällen basierenden Untergruppen umfassen.

Um die Verarbeitung der einzelnen Teilmengen durch den Browser entsprechend den Datenschutzfolgen der einzelnen Teilmengen zu erleichtern, empfehlen wir die Verwendung der Storage Access API (SAA) und von „requestStorageAccessForOrigin“, um den Cookie-Zugriff innerhalb eines FPS zu ermöglichen.

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

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

Das kann die Implementierung von FPS für Websites der obersten Ebene erschweren, die websiteübergreifende Bilder oder Script-Tags verwenden, für die Cookies erforderlich sind. Um einige dieser Herausforderungen zu bewältigen, haben wir eine neue API vorgeschlagen, die requestStorageAccessForOrigin, die es Entwicklern erleichtern soll, diese Änderung umzusetzen. Diese API kann auch für Tests verwendet werden.

Einreichung festlegen

Die kanonische FPS-Liste ist eine öffentlich einsehbare Liste im JSON-Dateiformat, die in einem neuen FPS-GitHub-Repository gespeichert ist und als vertrauenswürdige Quelle für alle Sets dient. Chrome verwendet diese Datei, um sein Verhalten anzupassen.

Weitere Informationen zum vorgeschlagenen Verfahren und zu den Anforderungen für das Einreichen von Sets findest du in den Einreichungsrichtlinien. Sie können auch einen Satz einreichen, um die verschiedenen technischen Prüfungen zu testen, die die Einreichungen validieren. Hinweis: Alle Einreichungen werden gelöscht, bevor FPS in stabilen Versionen von Chrome verfügbar ist.

Da der Prozess zur Einreichung von Sets noch in der aktiven Entwicklungsphase ist, können Sie für lokale Tests Sets nur über die Befehlszeile erstellen und direkt an den Browser übergeben. Für lokale Tests ist es nicht erforderlich, ein Set an das GitHub-Repository einzureichen, um mit Feature-Flags zu testen.

Lokal testen

Vorbereitung

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

Wenn Sie sich neue Chrome-Funktionen schon vor der Veröffentlichung 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 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 kommagetrennten Liste von Flags verwenden, die in diesem Abschnitt erläutert werden. Außerdem müssen Sie eine Reihe von zugehörigen Websites als JSON-Objekt deklarieren, das an --use-first-party-set übergeben wird.

FPS aktivieren

FirstPartySets aktiviert FPS in Chrome.

FirstPartySets

Storage Access API aktivieren

StorageAccessAPI

Hiermit wird die Storage Access API (SAA) in Chrome aktiviert. Dadurch können eingebettete Iframes über requestStorageAccess() den Zugriff auf Cookies in einem websiteübergreifenden Kontext anfordern, auch wenn Drittanbieter-Cookies vom Browser blockiert werden.

Hinweis: Wenn requestStorageAccess() aufgerufen wird, ist eine Nutzergeste erforderlich, um die Auflösung zu erhalten. Für zukünftige Versionen von Chrome gelten möglicherweise andere Anforderungen, da die SAA-Spezifikation noch weiterentwickelt wird. Hier finden Sie eine Liste der geplanten Verbesserungen an der SAA-Implementierung in Chrome.

StorageAccessAPIForOriginExtension

Ermöglicht es Websites der obersten Ebene, über requestStorageAccessForOrigin() Speicherzugriff im Namen bestimmter Ursprünge anzufordern. Das ist nützlich für Websites der obersten Ebene, die websiteübergreifende Bilder oder Script-Tags verwenden, für die Cookies erforderlich sind. Außerdem werden einige der Herausforderungen bei der Einführung von SAA angegangen.

Satz lokal deklarieren

Ein First-Party-Set besteht aus einer Sammlung von Domains, für die es eine einzelne „set primary“- und möglicherweise mehrere „set members“-Elemente gibt. Die Mitglieder eines Sets können verschiedene Domaintypen mit auf Anwendungsfällen basierenden Untergruppen umfassen.

Erstellen Sie ein JSON-Objekt mit URLs, die Mitglieder eines Sets sind, und übergeben Sie es an --use-first-party-set.

Im folgenden Beispiel ist unter primary die primäre Domain und unter associatedSites eine Liste von Domains aufgeführt, die die Anforderungen der verknüpften 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\"]}"

Für lokale Tests können Sie Sets nur über die Befehlszeile erstellen und direkt an den Browser übergeben. Für lokale Tests gibt es keine Set-Validierung. Wenn FPS jedoch in stabilen Versionen bereitgestellt wird, müssen alle Sets an das FPS-GitHub-Repository gesendet und den Validierungskriterien unterliegen.

FPS-UI aktivieren

PageInfoCookiesSubpage

Hiermit wird die Anzeige der FPS im Bereich „Seiteninfo“ aktiviert, der über die URL-Leiste zugänglich ist.

PrivacySandboxFirstPartySetsUI

Aktiviert die 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 sind

  1. Klicken Sie in den Chrome-Einstellungen auf „Datenschutz und Sicherheit“ > „Cookies und andere Websitedaten“ oder auf chrome://settings/cookies.
  2. Achten Sie darauf, dass unter „Allgemeine Einstellungen“ die Option „Drittanbieter-Cookies blockieren“ aktiviert ist.
  3. Prüfen Sie, ob auch die Unteroption „Ähnliche Websites dürfen meine Aktivitäten in der Gruppe sehen“ aktiviert ist.

Sicherheitsaspekte

Da Websites mit der Storage Access API in bestimmten Fällen wieder Zugriff auf Drittanbieter-Cookies erhalten können, sind Webanwendungen anfällig für websiteübergreifende Angriffe und Datenlecks. Betreiber von Websites, die auf websiteübergreifende Cookies angewiesen sind, sollten sich der Risiken von CSRF und anderen Angriffen bewusst sein.

Geplante Verbesserungen

Um dies zu verbessern, werden in zukünftigen Chrome-Releases zusätzliche Sicherheitskontrollen erforderlich sein, um eine explizite Einwilligung des Einbettungspartners zu gewährleisten. Die vorgeschlagenen Verbesserungen würden Folgendes umfassen: Zugriff nur pro Frame gewähren, CORS für Anfragen mit Anmeldedaten erfordern und den Zugriff auf den Ursprung beschränken. Weitere Informationen finden Sie in der aktuellen Sicherheitsanalyse.

Hier finden Sie eine Liste der geplanten Verbesserungen an der SAA-Implementierung in Chrome.

Hinweis: Chrome sendet nur Cookies mit der Kennzeichnung „SameSite=None“ in websiteübergreifenden eingebetteten Kontexten. 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. Es ist nicht sicher anzunehmen, dass der Zugriff nur innerhalb eines FPS zulässig ist. Websites sollten weiterhin die standardmäßigen Sicherheitsbest Practices verwenden.

Feedback geben und erhalten

Lokale Tests sind eine gute Gelegenheit, den Mechanismus der Storage Access API zum Aktivieren von FPS auszuprobieren und Feedback zu geben oder Probleme zu melden, die auftreten. Außerdem können Sie beim Testen des Einreichungsprozesses auf GitHub Ihre Erfahrungen mit dem Prozess und den Validierungsschritten teilen. So können Sie mit dem Team interagieren und Feedback zum aktualisierten Vorschlag geben: