Fortschritte bei der Privacy Sandbox (Januar/Februar 2022)

Willkommen zur ersten Ausgabe des Jahres mit Neuigkeiten zur Privacy Sandbox. In diesem Artikel geht es um die Meilensteine auf dem Weg zur Einstellung von Drittanbieter-Cookies in Chrome und zu einem datenschutzfreundlicheren Web. In jeder Ausgabe geben wir einen Überblick über die Aktualisierungen des Zeitplans für die Privacy Sandbox sowie Neuigkeiten aus dem gesamten Projekt. Zu Beginn des Jahres 2022 gibt es viele Neuigkeiten.

Privacy Sandbox für Android

Wenn Sie die Privacy Sandbox-Website regelmäßig besucht haben, sind Ihnen vielleicht Änderungen an der Struktur aufgefallen, da wir die Privacy Sandbox für Android eingeführt haben.

„Wir kündigen eine mehrjährige Initiative an, um die Privacy Sandbox für Android zu entwickeln. Ziel ist es, neue, datenschutzfreundlichere Werbelösungen einzuführen. Diese Lösungen beschränken insbesondere die Weitergabe von Nutzerdaten an Dritte und funktionieren ohne App-übergreifende Kennungen, einschließlich der Werbe-ID. Außerdem beschäftigen wir uns mit Technologien, mit denen sich die Wahrscheinlichkeit unbemerkter Datenerhebung reduzieren lässt. Hierzu zählt unter anderem die sicherere Einbindung von Apps in Werbe-SDKs.“

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

Feedback

Feedback von einer vielfältigen Gruppe von Stakeholdern aus der Web-Community ist für die Privacy Sandbox-Initiative von entscheidender Bedeutung. Wir haben einen Feedbackbereich hinzugefügt, in dem Sie eine Übersicht über die vorhandenen öffentlichen Kanäle finden, denen Sie folgen oder an denen Sie teilnehmen können. Außerdem gibt es ein Feedbackformular, über das Sie das Chrome-Team jederzeit direkt erreichen können.

Websiteübergreifende Datenschutzgrenzen stärken

Drittanbieter-Cookies sind ein wichtiger Mechanismus, der websiteübergreifendes Tracking ermöglicht. Die Einstellung dieser Funktionen ist ein wichtiger Meilenstein. Wir müssen jedoch auch andere Formen des websiteübergreifenden Speicherns oder der websiteübergreifenden Kommunikation angehen.

Kekse

Während die cookiebezogenen Vorschläge voranschreiten, sollten Sie Ihre eigenen SameSite=None oder websiteübergreifenden Cookies prüfen und die Maßnahmen planen, die Sie auf Ihrer Website ergreifen müssen.

CHIPS

Wenn Sie Cookies setzen, die in websiteübergreifenden Kontexten, aber in 1:1-Beziehungen gesendet werden, z. B. iframe-Embeddings oder API-Aufrufe, haben wir eine neue Übersicht für CHIPS (Cookies with Independent Partitioned State) hinzugefügt. Mit CHIPS können Sie Cookies als „Partitioned“ markieren. Sie werden dann in einen separaten Cookie-Jar pro Website der obersten Ebene verschoben.

Wir haben auch die I2E (Intent to Experiment) für CHIPS gesendet. Der Ursprungstest soll in Chrome 100 beginnen und vom 31. März 2022 bis zum 30. Juni 2022 laufen. Die Registrierung für den Ursprungstest ist auf der Website für Chrome-Ursprungstests möglich.

Außerdem arbeiten wir weiter daran, Probleme bei der allgemeinen Cookie-Implementierung in Chrome zu beheben. Wir haben eine I2S (Intent to Ship) gesendet, um zuzulassen, dass Cookie-Domainattribute leere Strings sein dürfen. Sofern Sie nicht bereits wissen, dass Sie in Cookie-Attributen eine leere Domain verwenden, sind von Seiten der Entwickler wahrscheinlich keine Maßnahmen erforderlich. Dadurch entspricht das Verhalten von Chrome dem anderer Browser.

Federated Credential Management

Die Federated Credentials Management API baut auf bestehenden Anwendungsfällen von Identitätsanbietern auf, damit neue und bestehende Anwendungsfälle für föderierte Identitäten auch ohne Drittanbieter-Cookies fortgesetzt werden können. Wir haben die I2E für erste FedCM-Ursprungstests gesendet. Diese beginnen mit einem begrenzten Test in Chrome 101 für Android. Dieser erste Test richtet sich in erster Linie an Identitätsanbieter, die FedCM in ihre eigenen Bibliotheken einbinden werden.

Partitionierung des Netzwerkstatus

Bei der Netzwerkstatus-Partitionierung wird das in der HTTP-Cache-Partitionierung implementierte Muster fortgesetzt, indem detailliertere Container für Caches erstellt werden, um websiteübergreifende Datenlecks zu verhindern. Wir haben eine I2S zum Partitionieren des Netzwerkstatus gesendet, die sich unter anderem auf WebSocket-Verbindungen und den DNS-Cache auswirkt. Nach der Diskussion über die Liste werden wir jedoch weitere Leistungstests durchführen, bevor wir uns mit einer neuen Absicht wieder diesem Thema widmen.

Verdecktes Tracking verhindern

Da wir die Optionen für explizites websiteübergreifendes Tracking einschränken, müssen wir auch die Bereiche der Webplattform angehen, in denen identifizierende Informationen offengelegt werden, die das Fingerprinting oder verdecktes Tracking von Nutzern ermöglichen.

Verringerung der User-Agent-Strings und User-Agent-Client-Hints

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

Alt

Mozilla/5.0 (Linux; Android 12; Pixel 6) AppleWebKit/537.36 (KHTML, z. B. Gecko) Chrome/101.0.4638.16 Safari für Mobilgeräte/537.36

Neu

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

Ab Chrome 101 führen wir (über eine I2E) den Test zur Einstellung der Reduzierung der Informationen im User-Agent-String ein. So können Websites, die noch nicht zu User-Agent-Client-Hints migriert sind, weiterhin den vollständigen User-Agent-String erhalten.

Wir arbeiten kontinuierlich daran, die Funktion für Client-Hinweise in „User-Agent“-Headern zu verbessern. Es gibt eine neue I2S für die Markup-basierte Delegierung von Client Hints für Drittanbieterinhalte. So können Websites ein <meta>-Tag in ihrem HTML-Code anstelle eines Permissions-Policy-Headers verwenden, um erweiterte Client-Hinweise bei plattformübergreifenden Anfragen zu senden. Außerdem gibt es eine neue I2E, um die GREASE-Funktionen für UA-CH zu erweitern. Damit soll das korrekte Parsen von Sonderzeichen gefördert und die fehleranfällige Verarbeitung des User-Agent-Strings vermieden werden.

Relevante Inhalte und Werbung anzeigen

Wir arbeiten daran, Drittanbieter-Cookies nach und nach einzustellen. Deshalb führen wir APIs ein, die wichtige Anwendungsfälle unterstützen, mit denen Websites ihre Inhalte finanzieren konnten, ohne websiteübergreifendes Tracking zu ermöglichen.

Themen

Die Topics API ist ein neuer Vorschlag, der interessenbezogene Werbung ohne websiteübergreifendes Tracking ermöglicht. Topics wurde auf der Grundlage unserer Erkenntnisse und des umfangreichen Community-Feedbacks aus unseren früheren FLoC entwickelt und ersetzt unser FLoC-Angebot. Die Topics API verwendet eine ausgewählte Taxonomie von Themen, um einer Website ein zugehöriges Thema zuzuordnen und eine Methode zum Abrufen der Top-Themen eines Browsers bereitzustellen.

Diagramm mit den Phasen im Lebenszyklus der Topics API, vom Besuch von Websites durch einen Nutzer bis zur Auslieferung einer Anzeige
Phasen im Lebenszyklus der Topics API

Weitere Informationen finden Sie im Einführungsartikel zu Topics und im Erklärartikel zu Topics. Dieser Hinweis ist auch im zugehörigen Topics-Artikel zu I2P zu finden, in dem wir unsere Absicht angekündigt haben, mit der Programmierung der Funktion zu beginnen.

FLEDGE

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

FLEDGE bereitet sich auf einen ersten Test für die Herkunftsermittlung vor. Details dazu finden Sie im Repository. Außerdem haben wir einen detaillierten Entwicklerleitfaden veröffentlicht.

Digitale Anzeigen analysieren

Um Anzeigen ohne websiteübergreifendes Tracking zu präsentieren, benötigen wir datenschutzfreundliche Mechanismen, mit denen sich die Effektivität dieser Anzeigen messen lässt.

Attribution Reporting API

Mit der Attribution Reporting API können Sie Ereignisse auf einer Website erfassen, z. B. Klicks oder Anzeigenaufrufe, die zu einer Conversion auf einer anderen Website führen, ohne websiteübergreifendes Tracking zu aktivieren.

Der Vorschlag für die Attribution Reporting API wurde um eine Reihe neuer Änderungen ergänzt. Eine vollständige Liste finden Sie im Update der Attribution Reporting API vom Januar 2022. Dazu gehört eine Übersicht über Zusammenfassungsberichte (früher als Gesamtberichte bezeichnet). In Zusammenfassungsberichten erhalten Sie eine aggregierte Ansicht detaillierter Conversion-Daten. Dabei bleiben wichtige Informationen für die Berichterstellung erhalten, ohne dass einzelne Nutzer in diesen Daten identifiziert werden können. Berichte auf Ereignisebene wurden um neue Funktionen für Berichte von Drittanbietern, die Analyse von Conversions nach Aufruf und die Filterung von Berichten sowie um Funktionen zur Fehlerbehebung erweitert.

Feedback zum Artikel

Wir veröffentlichen diese Updates fortlaufend und arbeiten an der Privacy Sandbox insgesamt. Dabei möchten wir sicherstellen, dass Sie als Entwickler die Informationen und Unterstützung erhalten, die Sie benötigen. Wenn ihr Verbesserungsvorschläge habt, könnt ihr uns diese gern auf Twitter unter @ChromiumDev mitteilen. Wir verwenden dein Feedback, um das Format weiter zu verbessern.