So hat Chrome das Angebot für First-Party-Sets entwickelt

First-Party-Sets (FPS) unterstützen das Surfen im Web nach der Einstellung von Drittanbieter-Cookies in Chrome. Der Vorschlag hat sich während der FPS-Inkubation maßgeblich weiterentwickelt, zuerst in der Privacy Community Group des W3C und jetzt in der Web Incubator Community Group.

In diesem Blogpost fassen wir den Entwicklungsprozess zusammen, heben wichtige Änderungen hervor und erläutern, warum wir glauben, dass diese Änderungen den Datenschutz im Web verbessern und gleichzeitig das Ökosystem weiter unterstützen.

Hintergrund

Websites verlassen sich oft auf den Zugriff auf ihre Cookies in Drittanbieterkontexten, um eine nahtlose und maßgeschneiderte Nutzung zu ermöglichen. Zusätzlich zu den Privacy Preserving Ads APIs (Topics, Protected Audience API und Attribution) wollte das Chrome-Team herausfinden, in welchen Szenarien, in denen Drittanbieter-Cookies verwendet wurden, über die Personalisierung von Anzeigen oder zu Analysezwecken hinaus, um Nutzern ein besseres Browsererlebnis zu bieten.

Wir haben festgestellt, dass sich Organisationen auf Drittanbieter-Cookies verlassen können, da ihre Webarchitektur so konzipiert ist, dass mehrere Domains verwendet werden. Angenommen, eine Organisation hat eine Domain für ihren Wanderblog und eine andere für ihren Campingplatz und möchte Nutzerinteraktionen auf diesen Websites unterstützen. Eine Organisation kann auch mehrere länderspezifische Domains mit gemeinsam genutzter Infrastruktur für ihren Webdienst unterhalten. Für solche Fälle beschlossen wir, eine Lösung zu entwickeln, die den Anforderungen dieser Unternehmen entspricht und gleichzeitig die Erwartungen der Nutzer an den Schutz ihrer Daten im Web wahrt.

Wir haben angefangen

Da der Browser derzeit die Grenze auf Websiteebene verwendet, um „Erstanbieter“ im Vergleich zu „Drittanbieter“ zu interpretieren, um den Bereich der Domains zu berücksichtigen, die eine Organisation verwalten könnte, erschien es angebracht, diese technische Grenze durch eine differenziertere Definition zu ersetzen.

2021 wurde in Chrome ursprünglich das Cookie-Attribut SameParty für First-Party-Sets vorgeschlagen, mit dem Websites Cookies definieren können, die von Websites derselben Partei stammen. Wir haben in einer User-Agent-Richtlinie festgelegt, was eine "gleiche Partei" ausmacht. Mit dieser Richtliniendefinition wurde versucht, auf bestehenden „Partei“-Frameworks (z. B. aus der W3C-DNT-Spezifikation) aufzubauen und Empfehlungen aus dem einschlägigen Datenschutzdiskussion zu berücksichtigen (z. B. „Protecting Consumer Privacy in an Era of Rapid Change“ des Federal Trade Commission-Berichts von 2012).

Damals waren wir der Meinung, dass dieser Ansatz genügend Flexibilität für verschiedene Arten von Organisationen und Branchen bietet und gleichzeitig unser grundlegendes Ziel erfüllt, das Tracking durch Drittanbieter-Cookies möglichst gering zu halten.

Feedback zum ersten Vorschlag

In vielen Gesprächen mit Stakeholdern aus der Webumgebung haben wir herausgefunden, dass es bei diesem ursprünglichen Design Einschränkungen gab.

Datenschutzprobleme durch passiven Cookie-Zugriff über das SameParty-Attribut

Andere Browser-Anbieter bevorzugt einen aktiven Ansatz für den Zugriff auf Drittanbieter-Cookies, der einen expliziten API-Aufruf erfordert, anstatt eine Grenze festzulegen, innerhalb derer der passive Cookie-Zugriff möglich ist. Aktive Anfragen für den Cookie-Zugriff bieten Browsersichtbarkeit und Kontrolle, um das Risiko eines verdeckten Trackings über Drittanbieter-Cookies zu minimieren. Außerdem könnten Browser Nutzern durch diese Sichtbarkeit die Möglichkeit geben, den Zugriff auf Cookies zuzulassen oder zu blockieren.

Wir möchten die Web-Interoperabilität in verschiedenen Browsern anstreben und die Vorteile für den Datenschutz verbessern. Deshalb haben wir uns für diesen Weg entschieden.

Probleme bei der Implementierung der vorgeschlagenen Richtlinie

In der ursprünglichen Richtlinie wurden drei Anforderungen für Domains vorgeschlagen, die sich in einem Satz zusammenfassen lassen: „gemeinsame Inhaberschaft“, „Allgemeine Datenschutzerklärung“ und „Gemeinsame Gruppenidentität“.

Das Feedback zu den Richtlinien, das wir erhalten haben, beruht auf vier Hauptthemen.

Gemeinsame Eigentumsrechte sind zu stark eingeschränkt

In Bezug auf die Anforderung an die „gemeinsame Inhaberschaft“ haben wir Feedback erhalten, dass eine Definition von FPS, die sich ausschließlich auf die Unternehmenseigentumsrechte konzentriert, größeren Unternehmen im Vergleich zu kleineren Unternehmen eine bessere Möglichkeit zum Zusammenfassen von Daten über eine breite Palette von Domains und nutzerseitigen Diensten verschaffen würde. Da es unser Ziel ist, die Privacy Sandbox für die gesamte Plattform aufzubauen, haben wir dieses Feedback ernst genommen und eine inklusivere Lösung priorisiert.

Eine einzige Richtlinie schränkt die Erweiterbarkeit auf Anwendungsfälle ein

Die Idee einer ganzheitlichen Richtlinie zur Steuerung von Grenzen sollte zwar für verschiedene Arten von Domains, die im FPS einer Organisation erforderlich sein müssten, flexibel gestaltet werden. Wir sind jedoch zu dem Schluss gekommen, dass dieses Richtliniendesign bei einigen kritischen Anwendungsfällen nicht berücksichtigt werden konnte. Beispielsweise können Dienstdomains (z. B. solche, die von Nutzern erstellte Inhalte hosten) den Zugriff auf ihre Cookies in einem Drittanbieterkontext benötigen, um Nutzer zu authentifizieren oder zu identifizieren. Solche Domains haben nur selten eine für Nutzer zugängliche Startseite, sodass die Anforderungen der "gemeinsamen Gruppenidentität" oder der "gemeinsamen Datenschutzrichtlinie" mit anderen Domains im selben fps nicht erfüllt werden konnten.

Die Wahrnehmung und das Verständnis der Gruppenidentität durch die Nutzer

Ursprünglich haben wir Leitlinien zur Definition einer „gemeinsamen Gruppenidentität“ als Versuch vorgeschlagen, Domains innerhalb eines einzelnen Satzes in die Domains zu unterteilen, die leicht mit einer gemeinsamen Gruppenidentität verknüpft werden können. Wir konnten jedoch keine technische Methode definieren, um zu messen und zu bewerten, ob die gemeinsame Gruppenidentität „für Nutzer leicht auffindbar“ sein kann. Es gab also Chancen auf Missbrauch und Fragen zur Durchsetzung.

Außerdem haben wir Feedback erhalten, dass das Verständnis der Bedeutung von gemeinsamen Eigentumsrechten von Nutzer zu Nutzer unterschiedlich sein kann. Das macht es schwierig, Richtlinien zu erstellen, die auf alle Websites angewendet werden können.

Eine subjektive Richtlinie ist schwierig in großem Umfang durchzusetzen

Wir haben aufgrund der subjektiven Natur bestimmter Anforderungen (z. B. "gemeinsame Gruppenidentität") und der Notwendigkeit, Ausnahmen oder Grenzfälle für andere abzudecken (im Hinblick auf die "allgemeine Datenschutzerklärung"), viele Ersuchen um ausführlichere Richtlinien erhalten.

Damit die Richtlinie fair und einheitlich angewendet wird, hätte Chrome Websiteinhabern viel spezifischere Richtlinien zur Verfügung stellen müssen. Wir sind zu dem Schluss gekommen, dass der Versuch, strengere Richtlinien zu erlassen, dem Ökosystem schaden könnte.

Ursprünglich hatten wir vorgeschlagen, eine unabhängige Durchsetzungsbehörde für die Prüfung und Durchsetzung der Richtlinienkonformität zu übernehmen. Im derzeitigen System war es jedoch eine schwierige Aufgabe, eine unabhängige Durchsetzungsbehörde mit dem entsprechenden Fachwissen zu finden, um diese Aufgaben auf unparteiische Weise zu erfüllen. Stattdessen haben wir uns für eine Richtlinie entschieden, die technisch durchgesetzt werden kann, damit die Implementierung konsistent und objektiv umgesetzt werden kann.

Die Entwicklung

Als Reaktion auf das Feedback haben wir die fps überarbeitet. Wir sind auf die spezifischen Probleme zurückgekehrt, die wir angehen wollten, und beschlossen, den Vorschlag genauer auf die spezifischen Anwendungsfälle auszurichten, die wir lösen wollten.

Lösungen für wichtige Anwendungsfälle

Chrome hat drei verschiedene maßgeschneiderte „Untergruppen“ für wichtige Anwendungsfälle im Web entwickelt. Der Teilmengenansatz verbesserte den alten Ansatz besser, da er privater, spezifischer und einheitlicher durchsetzbar war.

• „ccTLDs“ (country-code top-level domains, länderspezifische Top-Level-Domains): Organisationen können Websites mit unterschiedlichen ccTLDs betreiben, um die Nutzererfahrung zu lokalisieren, und diese Websites benötigen möglicherweise weiterhin Zugriff auf gemeinsam genutzte Dienste und Infrastruktur.
• „Dienstdomains“: Websites können aus Sicherheits- oder Leistungszwecken eigenständige Domains verwenden. Diese Websites benötigen möglicherweise Zugriff auf die Identität eines Nutzers, um ihre Funktionen ausführen zu können.
• „Verknüpfte“ Domains: Organisationen können mehrere Websites für verschiedene, ähnliche Marken oder Produkte betreiben. Sie möchten beispielsweise den websiteübergreifenden Cookie-Zugriff für Anwendungsfälle wie die Analyse der User Journeys auf verschiedenen Websites benötigen, um besser zu verstehen, wie die Nutzer einer Organisation mit ihren Websites interagieren, oder um den Anmeldestatus eines Nutzers auf einer ähnlichen Website zu speichern, die dieselbe Anmeldeinfrastruktur verwendet.

Für jeden dieser Anwendungsfälle gibt es spezielle Richtlinienanforderungen, entsprechende technische Validierungsprüfungen und ein bestimmtes Browserverhalten. Weitere Informationen finden Sie in den Richtlinien zur Einreichung. Mit diesen Änderungen werden die Einschränkungen des ursprünglichen Vorschlags beseitigt, indem auf ein einheitliches Design verzichtet und ein abgegrenztes, anwendungsorientiertes Framework bevorzugt wird.

Möglichkeit der Interoperabilität durch aktive Anfragen für den Zugriff auf Drittanbieter-Cookies

Chrome ist bestrebt, die Interoperabilität mit anderen Browsern zu fördern, um die Integrität der Webplattform aufrechtzuerhalten. Da andere Browser wie Safari, Firefox und Edge derzeit die Storage Access API (SAA) zur Erleichterung aktiver Cookie-Anfragen verwenden, haben wir uns für den Einsatz von SAA in Chrome entschieden, um nicht nur wichtiges Feedback zu berücksichtigen, sondern auch die Interoperabilität im Web zu unterstützen.

Um Entwicklern mehr Flexibilität zu bieten und bekannte Einschränkungen der SAA zu umgehen, haben wir auch die requestStorageAccessForOrigin API vorgeschlagen.

Möglichkeit, die Storage Access API und FPS zusammen zu verwenden

Bei der Implementierung der Storage Access API (SAA) können Browser Nutzer direkt um die Berechtigung bitten. Andere Nutzer können eine begrenzte Anzahl von Anfragen ohne Berechtigungsaufforderung zulassen.

Chrome ist der Ansicht, dass FPS gegenüber SAA eine transparente Ebene darstellen kann, indem die Reibungspunkte der Nutzer minimiert und eine „Ermüdungsermüdung“ bei wichtigen, eingeschränkten Anwendungsfällen vermieden wird. FPS bietet Browsern außerdem die Flexibilität, Nutzern zusätzlichen Kontext zum Set-up zur Verfügung zu stellen, falls sie Nutzer um Erlaubnis bitten sollten.

Mit FPS haben Entwickler die Möglichkeit, ihre eigenen betroffenen Websites für wichtige Anwendungsfälle zu identifizieren. Dadurch können Entwickler vorhersehen, wie ihre Websites für die Nutzer funktionieren, und Maßnahmen ergreifen, um die Auswirkungen auf die Nutzererfahrung zu begrenzen, indem FPS oder eine Alternative für Drittanbieter-Cookies verwendet werden. Darüber hinaus bietet FPS Entwicklern Plattformpräzision im Gegensatz zu Heuristiken, die sich im Laufe der Zeit ändern oder zu unterschiedlichem Verhalten für verschiedene Nutzer führen können.

Entwickler, die SAA zur Zusammenarbeit mit fps in Chrome implementieren, können SAA auch für die Leistung ihrer Websites in anderen Browsern nutzen, selbst in denen, die keine fps anbieten.

Diskussion fortsetzen

Wir sind der Meinung, dass unser aktueller Vorschlag die richtige Balance in einem herausfordernden Kompromiss finden kann, in dem die Anforderungen von Nutzern und Entwicklern berücksichtigt werden. Wir schätzen das Feedback von Stakeholdern des Websystems, das uns bei der Weiterentwicklung des FPS-Vorschlags geholfen hat.

Uns ist bewusst, dass sich die Beteiligten im Web noch mit dem aktualisierten Vorschlag vertraut machen. Bitte nehmen Sie mit uns Kontakt auf, damit wir das Design weiter verbessern können, damit Entwickler nützlicher sind und um den Datenschutz im Web weiter zu verbessern. Google wird auch weiterhin mit der Wettbewerbsbehörde des Vereinigten Königreichs (Competition and Markets Authority, CMA) zusammenarbeiten, um die Einhaltung der Verpflichtungen sicherzustellen.

Die folgenden Ressourcen sind hilfreich:

• Inkubation in WICG
• Anleitung für FPS-Tests
• Integrationsanleitung für First-Party-Sets
• Richtlinien für die Einreichung von FPS

Mit der Plattform arbeiten

Es ist großartig, dass Unternehmen wie Salesforce und CafeMedia sich mit wichtigem Feedback austauschen und First-Party-Sets entwickeln. Sie haben entscheidend zur Weiterentwicklung der Technologie beigetragen. Einige andere haben auch ihre Meinung zu First-Party-Sets und den Bemühungen von Chrome zur Zusammenarbeit mit dem Web geäußert:

„Chrome entwickelt bereits eigene Datasets, die auf viele unserer Anwendungsfälle abgestimmt sind, z. B. die Bewahrung der Nutzerpfade. Das zeigt uns, dass das Google-Team ständig daran arbeitet, die unterschiedlichen Anforderungen von Websiteinhabern im Web zu verstehen.“ – Mercado Libre

„Wir bei VWO schätzen die Bemühungen von Google, die Datenschutzstandards zu erhöhen und gleichzeitig dafür zu sorgen, dass echte Anwendungsfälle gehandhabt werden. Es ist großartig, dass das Team mit der Entwicklerumgebung zusammenarbeitet und auf der Grundlage des Feedbacks von Web-Stakeholdern kontinuierlich die Implementierung der eigenen Vorschläge verbessert. Wir freuen uns darauf, bei der Testphase des Vorschlags zu sein und freuen uns darauf, ihn in den Browser zu integrieren.“ – Nitish Mittal, Director of Engineering, VWO