Fortschritte bei der Privacy Sandbox (Januar/Februar 2022)

Willkommen bei der ersten Ausgabe des Jahres „Progress in the Privacy Sandbox“. Sie behandelt Januar und Februar 2022, in der wir die Meilensteine auf dem Weg zur schrittweisen Einstellung von Drittanbieter-Cookies in Chrome und zur Verbesserung des Datenschutzes im Web verfolgen. In jeder Ausgabe bieten wir einen Überblick über die Aktualisierungen des Zeitplans der Privacy Sandbox sowie Neuigkeiten aus dem gesamten Projekt. Anfang 2022 gibt es zahlreiche Aktualisierungen.

Privacy Sandbox für Android

Wenn Sie sich die Privacy Sandbox-Website angesehen haben, sind Sie vielleicht Änderungen an der Struktur bemerkt, als wir die Privacy Sandbox für Android eingeführt haben.

„Wir kündigen eine mehrjährige Initiative zur Entwicklung der Privacy Sandbox für Android an. Ziel ist es, neue, datenschutzorientiertere Werbelösungen einzuführen. Insbesondere wird durch diese Lösungen die Weitergabe von Nutzerdaten an Dritte eingeschränkt und es werden keine appübergreifenden Kennungen wie Werbe-IDs verwendet. Wir arbeiten außerdem an Technologien, die das Potenzial für verdeckte Datenerhebung reduzieren, einschließlich sicherer Methoden für die Integration von Apps in Werbe-SDKs.“

Weitere Informationen und Informationen zum Fortschritt finden Sie im Abschnitt „Android“ auf der Website „Privacy Sandbox“.

Feedback

Für die Privacy Sandbox-Initiative ist es von entscheidender Bedeutung, Feedback von verschiedenen Interessenvertretern aus der gesamten Webumgebung zu erhalten. Wir haben einen speziellen Feedback-Bereich hinzugefügt, der einen Überblick über die vorhandenen öffentlichen Kanäle bietet, in denen du Diskussionen folgen oder an Diskussionen teilnehmen kannst. Außerdem ist ein Feedbackformular vorhanden, damit du das Chrome-Team jederzeit direkt erreichen kannst.

Websiteübergreifende Datenschutzgrenzen stärken

Drittanbieter-Cookies sind ein wichtiger Mechanismus, der websiteübergreifendes Tracking ermöglicht. Die Möglichkeit, diese auslaufen zu lassen, ist ein wichtiger Meilenstein, aber wir müssen auch andere Formen der websiteübergreifenden Speicherung oder Kommunikation angehen.

Kekse

Im Verlauf der Vorschläge für Cookies sollten Sie Ihre eigenen SameSite=None oder websiteübergreifenden Cookies prüfen und die Maßnahme planen, die Sie auf Ihrer Website ausführen müssen.

CHIPS

Wenn Sie Cookies festlegen, die im websiteübergreifenden Kontext gesendet werden, aber in 1:1-Beziehungen – wie iFrame-Einbettungen oder API-Aufrufen –, haben wir eine neue Übersicht für CHIPS bzw. Cookies mit unabhängig partitioniertem Status hinzugefügt. Mit CHIPS können Sie Cookies als „Partitioned“ markieren. Dadurch werden sie pro Website der obersten Ebene in einer separaten Cookie-JAR-Datei abgelegt.

Außerdem haben wir die I2E (Intent to Experiment) for CHIPS mit dem Plan versendet, den Ursprungstest in Chrome 100 zu starten und vom 31. März 2022 bis zum 30. Juni 2022 laufen zu lassen. Der Ursprungstest kann auf der Website für Ursprungstests von Chrome registriert werden.

Außerdem werden wir weiterhin Probleme bei der allgemeinen Cookie-Implementierung in Chrome beheben und einen I2S (Intent to Ship) gesendet, damit Cookie-Domainattribute als leerer String verwendet werden können. Sofern Sie sich nicht bereits darüber im Klaren sind, dass Sie eine leere Domain in Cookie-Attributen verwenden, müssen wahrscheinlich keine Maßnahmen durch den Entwickler erforderlich sein. Dadurch wird das Verhalten von Chrome an die anderer Browser angepasst.

Verwaltung von föderierten Anmeldedaten

Die Federated Credentials Management API baut auf vorhandenen Anwendungsfällen für Identitätsanbieter auf, damit neue und bestehende Anwendungsfälle für föderierte Identitäten ohne Drittanbieter-Cookies weitergeführt werden können. Wir haben die I2E für erste FedCM-Ursprungstests gesendet, die mit einer eingeschränkten Testversion ab Chrome 101 für Android beginnen. Dieser erste Test richtet sich in erster Linie an Identitätsanbieter, die FedCM letztendlich in ihre eigenen Bibliotheken integrieren.

Partitionierung des Netzwerkstatus

Die Partitionierung des Netzwerkstatus setzt das in der HTTP-Cache-Partitionierung implementierte Muster fort und erstellt detailliertere Container für Caches, um websiteübergreifende Datenlecks zu verhindern. Wir haben einen I2S-zu-Partitions-Netzwerkstatus gesendet, der sich auf WebSocket-Verbindungen, den DNS-Cache und andere auswirkt. Nach der Erörterung der Liste führen wir jedoch zusätzliche Leistungstests durch, bevor wir zu diesem Thema mit einem neuen Intent zurückkehren.

Verdecktes Tracking verhindern

Wenn wir die Optionen für explizites websiteübergreifendes Tracking einschränken, müssen wir auch die Bereiche der Webplattform berücksichtigen, die identifizierende Informationen preisgeben, die Fingerprinting oder verdecktes Tracking von Nutzern ermöglichen.

Reduzierung des User-Agent-Strings und User-Agent-Client-Hints

Wir reduzieren schrittweise die passiv verfügbaren Informationen im User-Agent-String von Chrome und stellen alternative User-Agent-Client-Hints (UA-CH) für Websites bereit, die diese Informationen aktiv anfordern müssen. Wir haben die I2S für Phase 4 der Reduzierung gesendet, bei der wir ab Chrome 101 die Informationen zur Nebenversion durch Nullen ersetzen.

Alt

Mozilla/5.0 (Linux; Android 12; Pixel 6) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/101.0.4638.16 Mobile Safari/537.36

Neu

Mozilla/5.0 (Linux; Android 12; Pixel 6) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/100.0.0.0 Mobile Safari/537.36

In Chrome 101 führen wir außerdem den Test zur Einstellung der User-Agent-Reduzierung (über einen I2E) ein. Dadurch können Websites, die noch keine Zeit für die Migration zu User-Agent-Client-Hinweisen hatten, weiterhin den vollständigen User-Agent-String erhalten.

Wir arbeiten weiterhin daran, die Funktion „User-Agent-Client-Hints“ zu verbessern. Es gibt einen neuen I2S-Code für die Delegierung von clientseitigen Clienthinweisen zu Inhalten von Drittanbietern. Dadurch können Websites ein <meta>-Tag im HTML-Code anstelle eines Permissions-Policy-Headers verwenden, um erweiterte Clienthinweise zu ursprungsübergreifenden Anfragen zu senden. Es gibt auch einen neuen I2E zur Erweiterung der GREASE-Funktionalität für UA-CH, der das korrekte Parsen von Sonderzeichen fördern soll, um das instabile Parsing im Zusammenhang mit dem User-Agent-String zu vermeiden.

Relevante Inhalte und Werbung zeigen

Mit der schrittweisen Einstellung von Drittanbieter-Cookies führen wir APIs ein, die wichtige Anwendungsfälle ermöglichen, auf die sich Websites verlassen müssen, um ihre Inhalte zu finanzieren, ohne weiterhin websiteübergreifendes Tracking zu ermöglichen.

Themen

Die Topics API ist ein neuer Vorschlag für interessenbezogene Werbung ohne websiteübergreifendes Tracking. Topics basiert auf unseren Erkenntnissen und dem umfassenden Community-Feedback aus früheren FLoC-Tests und ersetzt unseren FLoC-Vorschlag. Die Topics API verwendet eine ausgewählte Thementaxonomie, um eine Website einem verknüpften Thema zuzuordnen und eine Methode zum Abrufen der Top-Themen eines Browsers bereitzustellen.

Diagramm mit den Phasen des Topics API-Lebenszyklus – vom Besuch eines Nutzers bis hin zur Auslieferung einer Anzeige
Phasen im Lebenszyklus der Topics API

Weitere Informationen finden Sie im Topics-Blogpost für Einsteiger sowie in der Erläuterung zu Topics. Dies ist auch über die zugehörige Topics I2P verlinkt. Damit wird bekannt gegeben, dass wir mit dem Programmieren der Funktion beginnen möchten.

FLEDGE

FLEDGE ermöglicht Anwendungsfälle für Remarketing und benutzerdefinierte Zielgruppen, z. B. bei der Werbung, bei der bereits besuchte Websites oder Produkte genutzt werden können, ohne dass eine einzelne Kennung erforderlich ist.

FLEDGE bereitet sich auf einen ersten Ursprungstest vor. Details finden Sie im Repository. Außerdem haben wir einen ausführlichen Entwicklerleitfaden veröffentlicht.

Digitale Werbung analysieren

Damit Anzeigen ohne websiteübergreifendes Tracking ausgeliefert werden können, benötigen wir datenschutzfreundliche Mechanismen, um die Effektivität dieser Anzeigen messen zu können.

Attribution Reporting API

Die Attribution Reporting API bietet eine Funktion zum Erfassen von Ereignissen auf einer Website, die zu einer Conversion auf einer anderen Website führen – z. B. das Klicken oder Aufrufen einer Anzeige –, ohne websiteübergreifendes Tracking zu aktivieren.

In den Vorschlag für die Attribution Reporting API wurden eine Reihe neuer Änderungen eingeführt. Eine vollständige Liste ist in der Attribution Reporting API vom Januar 2022 verfügbar. Dazu gehört auch eine Übersicht über zusammenfassende Berichte (früher „zusammengefasste Berichte“). Zusammenfassende Berichte bieten eine zusammengefasste Ansicht detaillierter Conversion-Daten. Dabei bleiben wichtige Informationen für die Berichterstellung erhalten, ohne dass einzelne Nutzer in diesen Daten identifiziert werden können. Bei Berichten auf Ereignisebene wurden neue Funktionen für Drittanbieterberichte, View-through-Analysen, Filterberichte und Fehlerbehebungsfunktionen hinzugefügt.

Feedback zum Artikel

Mit der Veröffentlichung dieser Updates und der Weiterentwicklung der Privacy Sandbox als Ganzes möchten wir sicherstellen, dass Sie als Entwickler die Informationen und den Support erhalten, den Sie benötigen. Wenn du etwas verbessern kannst, das wir in dieser Reihe verbessern könnten, teile uns dies über @ChromiumDev auf Twitter mit. Ihr Feedback hilft uns dabei, das Format weiter zu verbessern.