Viele Privacy Sandbox APIs werden im Rahmen der Vorbereitung auf die Einstellung von Drittanbieter-Cookies im Jahr 2024 in der stabilen Version von Chrome allgemein verfügbar gemacht. Mit einigen dieser APIs können wichtige websiteübergreifende Cookie-Anwendungsfälle beibehalten werden, z. B. CHIPS und die API, die derzeit als First-Party-Sets (FPS) bezeichnet wird. In diesem Beitrag stellen wir die Funktion „Related Website Sets“ (RWS) vor – unser neuer Name für FPS, der den Zweck besser widerspiegelt. Außerdem geben wir eine Auffrischung zu wichtigen Anwendungsfällen sowie eine Aktualisierung des Limits für zugehörige Teilmengen von Domains.
Kritische User Journeys erhalten
RWS wurde entwickelt, um Störungen bei bestimmten Funktionen für Nutzer zu minimieren, sobald Chrome damit beginnt, den Zugriff auf Drittanbieter-Cookies standardmäßig einzuschränken. Unser Ziel ist es, Nutzern möglichst schnelles Surfen im Web zu ermöglichen und gleichzeitig die Datenschutzziele der Privacy Sandbox einzuhalten. Um dieses Gleichgewicht zu finden, zielt RWS auf bestimmte Anwendungsfälle im Zusammenhang mit Websitefunktionen ab:
- Der ccTLD-Anwendungsfall befasst sich mit Fehlern wie dem Anmeldebeispiel, das in unserem öffentlichen Tracker abgelegt ist. Solche Fälle werden im System oft durch heuristische Ausnahmen berücksichtigt (siehe Ref. 1).
- Der Anwendungsfall „Dienstdomain“ befasst sich mit einer gängigen Vorgehensweise von Entwicklern, um sensible Funktionen (z. B. die Unterstützung eines Authentifizierungsvorgangs) von nutzerseitigen Domains zu isolieren. Solche Fälle können im System durch gezielte Ausnahmen behoben werden (siehe Referenz 2).
- Der Anwendungsfall „Verknüpfte Domain“ bietet mehr Flexibilität bei den Arten von Domains, bei denen der Zugriff auf Drittanbieter-Cookies für kritische Nutzerpfade erforderlich ist (siehe Referenz 3). Für die Anwendungsfälle der ccTLD und Dienstdomains gelten strenge technische Prüfungen, die auf Domaineigenschaften basieren, um Missbrauch zu minimieren. Für die zugehörige Domain gilt jedoch eine numerische Beschränkung. Weitere Informationen dazu finden Sie im nächsten Abschnitt.
Die Beschränkung für verknüpfte Domains wurde auf fünf Domains erhöht.
Chrome hat zuvor eine Beschränkung von drei Domains für die verknüpfte Untergruppe (plus eine primäre Domain) vorgeschlagen, um einen Missbrauch des weitverbreiteten Trackings zu verhindern. Einige Teilnehmer an Webstandards haben uns mitgeteilt, dass die Beschränkung für verschiedene Arten von Anwendungsfällen zu niedrig ist.
Wir haben uns entschieden, das Limit für verknüpfte Domains auf fünf Domains (plus eine primäre Domain) zu erhöhen, die am besten mit der Implementierung übereinstimmt, die von einem anderen großen Browser angeboten wird (siehe Ref. 4). Diese Änderung wird ab Chrome 117 wirksam.
Da RWS nicht als Werbelösung gedacht ist, berücksichtigen wir kein Feedback zur Verbesserung von RWS, um eine bessere Anzeigenbereitstellung zu ermöglichen. Für Anwendungsfälle mit Anzeigen sollten Entwickler die Topics, Protected Audience API und die Attribution Reporting API ausprobieren und entsprechendes Feedback geben.
Nutzer haben die Wahl für erweiterte Anwendungsfälle, aber über fünf verknüpfte Domains hinaus.
Für die Nutzererfahrung, die von dieser Beschränkung nicht unterstützt wird, arbeitet Chrome an einer Aufforderung zur Nutzeraufforderung, bei der auch die Storage Access API (SAA) zum Einsatz kommt, ein Standard, der auch von anderen Browsern genutzt wird. Bei Anwendungsfällen, in denen mehr als fünf verknüpfte Domains erforderlich sind, sollten Entwickler prüfen, wie SAA auch außerhalb von RWS unterstützt werden kann. Wir haben den Einführungsprozess von Blink für diese Funktion separat eingeführt, die ab Chrome 117 in Chrome Desktop eingeführt wird.
Nächste Schritte
Wir sind dankbar für das Feedback, das uns bisher an der Entwicklung der API geholfen hat. Wir haben in RWS investiert, um Entwicklern Vorhersehbarkeit, Kontrolle und Entscheidungsfreiheit zu bieten, um die Nutzererfahrung auf den von ihnen erstellten Websites zu wahren. Wir sind schon gespannt darauf, wie Entwickler RWS einführen und nutzen, während wir diese Entwicklung vorantreiben. Das Übermittlungsverfahren ist bereits in Kraft und das RWS-JSON-Generator-Tool ist ein guter Ausgangspunkt.
Folge dem Thread „Intent to Ship“, um den Fortschritt zu verfolgen. In diesen Materialien findest du Hinweise zur Implementierung.
Verweise
- Bei den Browsern ist man sich allgemein einig, dass diese websiteübergreifenden Cookie-Anwendungsfälle notwendig sind. Bei ihrer Aktivierung werden jedoch unterschiedliche Ansätze verfolgt. Firefox (Code) und Safari (Code) haben beide die Pop-up-Heuristik implementiert, die das Problem behebt, z. B. beim Nintendo-Anmeldevorgang.
- Es gibt auch mehrere Beispiele, in denen Ausnahmen für Browser hartcodiert werden, um Störungen für Nutzer so gering wie möglich zu halten. Firefox gewährt Speicherzugriff bei Weiterleitungsabläufen zwischen Microsoft Teams und login.microsoftonline.us.
- Firefox bietet einen „Shim“, der requestStorageAccessForOrigin im Namen von facebook.com aufruft, wenn sich der Nutzer auf instagram.com anmeldet. Ein Beispiel für die Websitegruppierung finden Sie auch in den hartcodierten Ausnahmen von Safari bei Aufforderungen zum Zugriff auf den Speicherzugriff für mehrere Domains.
- In Firefox werden die ersten 5 requestStorageAccess-Aufrufe einer Drittanbieter-Website automatisch gewährt (Code), die der Nutzer zuvor besucht hat. In Chrome wird den ersten fünf Domains, die in der zugehörigen Untergruppe aufgeführt sind, zusätzlich zur primären Domain derselben Gruppe automatisch der Zugriff auf Drittanbieter-Cookies über RWS gewährt.