First-Party Sets (FPS) sollen das Surfen im Web für Nutzer nach der Einstellung von Drittanbieter-Cookies in Chrome unterstützen. Der Vorschlag hat sich während der FPS-Inkubationsphase in offenen Webforen erheblich weiterentwickelt, zuerst in der Privacy Community Group des W3C und jetzt in der Web Incubator Community Group.
In diesem Blogpost fassen wir die Entwicklung zusammen, gehen auf die wichtigsten Änderungen ein und erläutern, warum wir der Meinung sind, dass diese Änderungen den Datenschutz im Web verbessern und gleichzeitig das Werbesystem unterstützen.
Hintergrund
Websites benötigen häufig den Zugriff auf ihre Cookies im Kontext von Drittanbietern, um Nutzern eine nahtlose und personalisierte Nutzung zu ermöglichen. Neben den datenschutzfreundlichen APIs für Werbung (Topics, Protected Audience API und Attribution) wollte das Chrome-Team auch den Umfang der Szenarien ermitteln, in denen Drittanbieter-Cookies nicht nur zur Personalisierung von Werbung oder zu Analysezwecken verwendet wurden, sondern auch, um Nutzern ein besseres Surferlebnis zu bieten.
Wir haben festgestellt, dass Organisationen möglicherweise Drittanbieter-Cookies verwenden, weil ihre Webarchitektur für die Nutzung mehrerer Domains ausgelegt ist. Eine Organisation hat beispielsweise eine Domain für ihren Wanderblog und eine andere für ihren Campingshop und möchte den Kaufprozess auf diesen Websites unterstützen. Eine Organisation kann auch mehrere Ländercodedomains mit gemeinsamer Infrastruktur für ihren Webservice verwalten. Für solche Fälle haben wir eine Lösung entwickelt, die den Anforderungen solcher Organisationen entspricht und gleichzeitig die Erwartungen der Nutzer an den Datenschutz im Web erfüllt.
Der Anfang
Da der Browser derzeit die Grenze auf Websiteebene verwendet, um „eigene“ und „Drittanbieter“ zu unterscheiden, um die Bandbreite der Domains zu berücksichtigen, die eine Organisation verwalten kann, erschien es sinnvoll, diese technische Grenze durch eine differenziertere Definition zu ersetzen.
2021 wurde in Chrome das Cookie-Attribut SameParty für Sets mit selbst erhobenen Daten vorgeschlagen, damit Websites Cookies von Websites innerhalb desselben Rechtssubjekts definieren können. Wir haben eine User-Agent-Richtlinie verwendet, um zu definieren, was als „dieselbe Partei“ gilt. Bei dieser Richtliniendefinition wurde versucht, auf bestehenden „Partei“-Frameworks aufzubauen (z. B. aus der DNT-Spezifikation des W3C) und Empfehlungen aus relevanten Datenschutzdiskussionen zu berücksichtigen (z. B. aus dem Bericht der US-amerikanischen Federal Trade Commission von 2012 mit dem Titel Protecting Consumer Privacy in an Era of Rapid Change (Schutz des Verbraucherdatenschutzes in einer Zeit des schnellen Wandels)).
Wir waren der Meinung, dass dieser Ansatz für verschiedene Arten von Organisationen aus verschiedenen Branchen ausreichend flexibel ist und gleichzeitig unserem grundlegenden Ziel entspricht, das weit verbreitete Tracking über Drittanbieter-Cookies zu minimieren.
Feedback zum ursprünglichen Vorschlag
Bei vielen Gesprächen mit Stakeholdern im Web haben wir festgestellt, dass dieses ursprüngliche Design Einschränkungen aufweist.
Datenschutzprobleme beim passiven Cookie-Zugriff über das Attribut „SameParty“
Andere Browseranbieter bevorzugten einen aktiven Ansatz für den Zugriff auf Drittanbieter-Cookies, der eine explizite API-Aufruf erfordert, anstatt eine Grenze festzulegen, innerhalb derer der passive Cookie-Zugriff aufrechterhalten werden konnte. Aktive Anfragen für den Cookie-Zugriff bieten dem Browser Transparenz und Kontrolle, sodass das Risiko von verdecktem Tracking über Drittanbieter-Cookies verringert werden kann. Außerdem könnten Browser Nutzern die Möglichkeit bieten, diesen Cookie-Zugriff zuzulassen oder zu blockieren.
Wir haben uns für diese Lösung entschieden, um die Interoperabilität von Webinhalten über alle Browser hinweg zu verbessern und den Datenschutz zu stärken.
Implementierungsherausforderungen der vorgeschlagenen Richtlinie
Die ursprüngliche Richtlinie sah drei Anforderungen für Domains in einem einzelnen Set vor: „gemeinsame Inhaberschaft“, „gemeinsame Datenschutzerklärung“ und „gemeinsame Gruppenidentität“.
Wir haben festgestellt, dass das Feedback, das wir zu der Richtlinie erhalten haben, vier Hauptthemen umfasst.
Gemeinsame Inhaberschaft ist zu restriktiv
Bezüglich der Anforderung „gemeinsame Inhaberschaft“ haben wir Feedback erhalten, dass eine Definition von FPS, die sich ausschließlich auf die Unternehmenseigentümerschaft konzentriert, größeren Unternehmen im Vergleich zu kleineren Unternehmen mehr Möglichkeiten bietet, Daten aus einer Vielzahl von Bereichen und nutzerorientierten Diensten zusammenzuführen. Da wir die Privacy Sandbox für das gesamte Ökosystem entwickeln möchten, haben wir dieses Feedback ernst genommen und eine Lösung priorisiert, die inklusiver ist.
Eine einzelne Richtlinie schränkt die Erweiterbarkeit auf Anwendungsfälle ein
Die Idee einer ganzheitlichen Richtlinie zur Verwaltung einer Grenze sollte zwar Flexibilität für verschiedene Arten von Domains bieten, die sich im FPS einer Organisation befinden müssen, wir haben jedoch festgestellt, dass einige wichtige Anwendungsfälle nicht mit diesem Richtliniendesign erfüllt werden konnten. Beispielsweise benötigen Dienstdomains (z. B. solche, auf denen von Nutzern erstellte Inhalte gehostet werden) möglicherweise Zugriff auf ihre Cookies in einem Drittanbieterkontext, um Nutzer zu authentifizieren oder zu identifizieren. Solche Domains haben selten eine für Nutzer zugängliche Startseite. Daher konnten die Anforderungen an eine „gemeinsame Gruppenidentität“ oder eine „gemeinsame Datenschutzrichtlinie“ mit anderen Domains im selben FPS nicht erfüllt werden.
Die Wahrnehmung und das Verständnis der Gruppenidentität durch Nutzer können variieren
Wir haben ursprünglich Richtlinien vorgeschlagen, um eine „gemeinsame Gruppenidentität“ zu definieren, um Domains innerhalb einer Gruppe auf diejenigen einzugrenzen, die leicht mit einer gemeinsamen Gruppenidentität in Verbindung gebracht werden können. Wir konnten jedoch kein technisches Mittel definieren, mit dem sich messen und bewerten lässt, ob die gemeinsame Gruppenidentität „leicht von Nutzern gefunden werden kann“. Das führte zu Missbrauchsmöglichkeiten und Fragen zur Durchsetzung.
Wir haben außerdem Feedback und Erfahrungen erhalten, dass die Bedeutung der Grenzen für „gemeinsame Inhaberschaft“ von Nutzer zu Nutzer variieren kann. Das erschwert die Erstellung von Richtlinien, die auf alle Websites angewendet werden können.
Eine subjektive Richtlinie ist in großem Maßstab schwer durchzusetzen
Aufgrund der subjektiven Natur bestimmter Anforderungen (z. B. „gemeinsame Gruppenidentität“) und der Notwendigkeit, Ausnahmen oder Grenzfälle für andere zu berücksichtigen (bezüglich der „gemeinsamen Datenschutzerklärung“), haben wir viele Anfragen nach detaillierteren Richtlinien erhalten.
Damit die Richtlinie fair und einheitlich angewendet werden kann, müssten Website-Betreibern viel genauere Richtlinien zur Verfügung gestellt werden. Wir haben festgestellt, dass strengere Richtlinien dem gesamten System schaden könnten.
Wir hatten ursprünglich vorgeschlagen, dass eine unabhängige Durchsetzungsstelle die Aufgabe übernehmen sollte, Verstöße gegen die Richtlinien zu untersuchen und durchzusetzen. Im aktuellen Umfeld war es jedoch schwierig, eine unabhängige Durchsetzungsstelle mit der entsprechenden Fachkompetenz zu finden, um diese Aufgaben unparteiisch zu erfüllen. Stattdessen haben wir uns bemüht, zu einer Richtlinie überzugehen, die technisch durchgesetzt werden kann, damit die Implementierung einheitlich und objektiv angewendet werden kann.
Die Entwicklung
Aufgrund des Feedbacks haben wir die Funktion „Frequenz pro Sekunde“ neu gestaltet. Wir kehrten zu den spezifischen Problemen zurück, die wir angehen wollten, und entschieden uns, den Vorschlag direkter auf bestimmte Anwendungsfälle auszurichten, die wir lösen wollten.
Lösungen für wichtige Anwendungsfälle
Chrome hat drei verschiedene „Subsets“ entwickelt, die für wichtige Anwendungsfälle im Web konzipiert wurden. Der Ansatz mit Untergruppen hat den alten Ansatz verbessert, da er datenschutzfreundlicher, spezifischer und einfacher durchzusetzen ist.
- „ccTLDs“ (Country-Code Top-Level-Domains): Organisationen können Websites mit verschiedenen ccTLDs für lokalisierte Inhalte verwalten. Für diese Websites ist möglicherweise weiterhin Zugriff auf freigegebene Dienste und Infrastruktur erforderlich.
- Dienstdomains: Websites können separate Domains aus Sicherheits- oder Leistungsgründen 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, verwandte Marken oder Produkte verwalten. Sie benötigen möglicherweise websiteübergreifenden Cookie-Zugriff für Anwendungsfälle wie die Analyse von User Journeys auf ähnlichen Websites, 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 gelten spezifische Richtlinienanforderungen, entsprechende technische Validierungsüberprüfungen und bestimmte Verhaltensweisen bei der Browserbehandlung. Weitere Informationen finden Sie in den Richtlinien für die Einreichung. Mit diesen Änderungen werden die Einschränkungen des ursprünglichen Vorschlags behoben, indem ein „One-Size-Fits-All“-Design aufgegeben und ein gegliedertes, anwendungsfallorientiertes Framework bevorzugt wird.
Möglichkeit zur Interoperabilität durch aktive Anfragen für den Zugriff auf Drittanbieter-Cookies
Chrome fördert die Interoperabilität mit anderen Browsern, um die Webplattform gesund zu erhalten. Da andere Browser wie Safari, Firefox und Edge derzeit die Storage Access API (SAA) verwenden, um aktive Cookie-Anfragen zu ermöglichen, haben wir uns entschieden, die SAA in Chrome zu nutzen. Damit möchten wir nicht nur wichtiges Feedback berücksichtigen, sondern auch die Interoperabilität im Web unterstützen.
Um Entwicklern mehr Flexibilität zu bieten und bekannte Einschränkungen der SAA zu beheben, haben wir außerdem die requestStorageAccessForOrigin API vorgeschlagen.
Storage Access API und FPS gemeinsam verwenden
Bei der Implementierung der Storage Access API (SAA) können Browser Nutzer direkt um Erlaubnis bitten oder eine begrenzte Anzahl von Anfragen ohne Berechtigungsaufforderung zulassen.
Chrome ist der Ansicht, dass FPS eine transparente Schicht über SAA bieten kann, indem die Nutzerfreundlichkeit eingeschränkt und die schnelle Ermüdung bei wichtigen, begrenzten Anwendungsfällen verhindert wird. FPS bietet Browsern außerdem die Möglichkeit, Nutzern zusätzlichen Kontext zur Mitgliedschaft in einer Gruppe bereitzustellen, falls sie um Erlaubnis gebeten werden.
Mit FPS haben Entwickler die Möglichkeit, ihre eigenen betroffenen Websites zu identifizieren, die für wichtige Anwendungsfälle genutzt werden. So können Entwickler vorhersagen, wie ihre Websites für Nutzer funktionieren, und Maßnahmen ergreifen, um die Auswirkungen auf die Nutzerfreundlichkeit zu begrenzen, indem sie FPS oder eine Drittanbieter-Cookie-Alternative verwenden. Darüber hinaus bieten FPS Entwicklern Plattformvorhersagbarkeit, im Gegensatz zu Heuristiken, die sich im Laufe der Zeit ändern oder zu unterschiedlichem Verhalten bei verschiedenen Nutzern führen können.
Entwickler, die SAA für die Arbeit mit FPS in Chrome implementieren, können SAA auch für die Leistung ihrer Websites in anderen Browsern nutzen, auch in solchen, die FPS nicht unterstützen.
Fortsetzung der Diskussion
Wir sind der Meinung, dass unser aktueller Vorschlag in einem schwierigen Bereich, in dem es um Kompromisse geht, das richtige Gleichgewicht zwischen den Anforderungen von Nutzern und Entwicklern findet. Wir schätzen das Feedback der Web-Stakeholder, das uns geholfen hat, den FPS-Vorschlag weiterzuentwickeln.
Uns ist bewusst, dass sich die Stakeholder des Web-Ökosystems noch mit dem aktualisierten Vorschlag vertraut machen. Bitte geben Sie uns Feedback, damit wir das Design weiter so verbessern können, dass es für Entwickler nützlicher ist und der Datenschutz im Web weiter verbessert wird. Google arbeitet auch weiterhin mit der Wettbewerbs- und Marktaufsichtsbehörde des Vereinigten Königreichs (Competition and Markets Authority, CMA) zusammen, um die Einhaltung der Selbstverpflichtungen sicherzustellen.
Weitere Informationen finden Sie in den folgenden Ressourcen:
- Inkubation in WICG
- Anleitung für FPS-Tests
- First-Party-Sets: Integrationsleitfaden
- Richtlinien für die Einreichung von FPS-Dateien
Mit dem Google-System arbeiten
Es ist toll, dass Unternehmen wie Salesforce und CafeMedia sich an wichtigen Feedback- und Entwicklungsprojekten für Sets mit selbst erhobenen Daten beteiligen. Sie haben einen wichtigen Beitrag zur Weiterentwicklung der Technologie geleistet. Auch andere haben ihre Meinung zu First-Party-Sets und den Bemühungen von Chrome, mit dem Web-Ökosystem zusammenzuarbeiten, geteilt:
„In Chrome werden First-Party-Sets entwickelt, die zu vielen unserer Anwendungsfälle passen, z. B. zum Speichern von User Journeys. Das zeigt uns, dass das Google-Team daran arbeitet, die unterschiedlichen Anforderungen von Websiteinhabern im Web zu verstehen.“ – Mercado Libre
„Wir bei VWO begrüßen die Bemühungen von Google, die Datenschutzstandards zu erhöhen und gleichzeitig dafür zu sorgen, dass echte Anwendungsfälle berücksichtigt werden. Es ist toll, dass das Team mit der Entwickler-Community zusammenarbeitet und die Implementierung des Vorschlags für Sets mit selbst erhobenen Daten basierend auf dem Feedback von Web-Stakeholdern kontinuierlich verbessert. Wir freuen uns, an den Tests des Vorschlags teilzunehmen und auf die Einbindung in den Browser.“ – Nitish Mittal, Director of Engineering, VWO