Fortschritte bei der Privacy Sandbox (August 2021)

Im Juli 2021 haben wir einen detaillierten Zeitplan für unsere Privacy Sandbox-Arbeit veröffentlicht. Mit der Privacy Sandbox möchten wir ein Web schaffen, das standardmäßig datenschutzfreundlich ist. Dazu werden Drittanbieter-Cookies eingestellt und Umgehungsmöglichkeiten für verdecktes Tracking verhindert. Der Zeitplan wird monatlich aktualisiert und Sie können damit alle Phasen und Meilensteine im Blick behalten. Außerdem veröffentlichen wir begleitende Artikel und Videos mit weiteren Informationen.

Es gibt jedoch viel zu beachten. Die Fortschritte bei der Privacy Sandbox sollen Ihnen alle nötigen Informationen liefern, damit Sie sich zum richtigen Zeitpunkt mit den Vorschlägen auseinandersetzen können. Betrachten Sie dieses und das nächste Video als Pilotfolge. Wir benötigen dein Feedback, damit wir diese Beiträge jeden Monat so gestalten können, dass sie für dich interessant sind.

Sie können Feedback an das Team senden, indem Sie @ChromiumDev auf Twitter kontaktieren oder ein Problem unter GoogleChromeLabs/privacy-sandbox-dev-support auf GitHub melden.

Sehen wir uns nun die Updates des letzten Monats an.

Websiteübergreifende Datenschutzgrenzen stärken

Kekse

Auf der Google I/O haben wir ein Flussdiagramm mit den Vorschlägen und Aktionen geteilt, die für die verschiedenen Cookie-Anwendungsfälle geeignet sind.

Wird mein Cookie websiteübergreifend verwendet? Nein: Verwenden Sie das Rezept für gute eigene Cookies.
Ja: 1:1 partitioniert – CHIPS-Vorschlag prüfen, Statusfreigabe über Domains derselben Partei – Sets mit selbst erhobenen Daten verwenden, Statusfreigabe über Websites (unterschiedliche Parteien) – neue APIs ausprobieren

Im Rahmen unserer Reihe zum Tag der Muttersprache hat Maud ein Video auf Französisch veröffentlicht, in dem sie Verbesserungen an eigenen Cookies vorstellt, die Sie jetzt vornehmen können.

Wir haben die Intent to Prototype (I2P) for CHIPS (Intent to Prototype (I2P) für Cookies mit unabhängigem Partitionsstatus) veröffentlicht. Jetzt können wir mit dem Schreiben des Codes für die Funktion beginnen. CHIPS ermöglicht Anwendungsfälle, für die websiteübergreifende Cookies erforderlich sind, deren Verwendung jedoch auf einen einzigen Kontext der obersten Ebene beschränkt oder partitioniert ist. Dazu gehören beispielsweise websiteübergreifende Einbettungen oder API-Aufrufe, bei denen Sie möglicherweise ein Cookie für eine Art Sitzung oder zum Speichern des Status verwenden. Wenn die I2P-Funktion veröffentlicht wird, wird sie in einer kommenden Version mit einem Flag versehen. Wenn Sie der Meinung sind, dass CHIPS für Ihre Cookies nützlich wäre, sollten Sie den I2P-Thread oder den Chrome-Statuseintrag im Blick behalten. Außerdem werden wir weitere Artikel und Demos veröffentlichen, in denen Sie die Funktion in Aktion sehen können.

In der Reihe „Was ist die Privacy Sandbox?“ haben wir ein neues Video von Sam zu Sets mit selbst erhobenen Daten veröffentlicht.

Es gibt noch eine weitere I2P-Version, mit der die Cookie-Größenbeschränkungen von Chrome an den HTTP-Standard angepasst und dem Verhalten von Firefox angenähert werden sollen. Dies ist eine geringfügige Änderung, da Chrome bereits Cookies ablehnt, die über die Zeichenbeschränkung von 4.096 Zeichen hinausgehen. Wenn auf Ihrer Website regelmäßig Cookies in der Nähe dieses Werts gesetzt werden, sollten Sie diesen Wert idealerweise reduzieren. Sehen Sie sich aber auch die Details der I2P an, um die genauen Änderungen zu erfahren. In den DevTools werden bereits abgelehnte Cookies angezeigt. Diese werden entsprechend den neuen Limits aktualisiert.

Zusätzliche Bereinigungsarbeiten

Die Einstellung und Entfernung (I2D / I2R) der bereits veralteten Web SQL API in Drittanbieterkontexten und eine weitere I2D für den Kontingenttyp „persistent“ der bereits eingestellten webkitRequestFileSystem API ist geplant. Die Chrome-Nutzungsmesswerte sind niedrig. Wenn auf Ihrer Website jedoch weiterhin window.openDatabase() in einem iframe oder window.webkitRequestFileSystem(window.PERSISTENT, […]) verwendet wird, sehen Sie sich die Links an, um die möglichen Auswirkungen zu ermitteln.

Verdecktes Tracking verhindern

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

Der vollständige User-Agent-String ist eine wichtige Quelle für Informationen zur Identifizierung des Browsers und des Geräts. Im Mai haben wir unsere Pläne vorgestellt, wie Chrome die Details im User-Agent-String reduzieren wird. Im Rahmen von Phase 1 werden Probleme bereits in den DevTools angezeigt, damit Websiteinhaber prüfen können, wo sie auf navigator.userAgent zugreifen.

Im Bereich „DevTools-Probleme“ wird ein Verbesserungsproblem angezeigt, bei dem der Entwickler aufgefordert wird, die Verwendung von „navigator.userAgent“, „navigator.appVersion“ und „navigator.platform“ zu prüfen.

Für Phase 2 haben wir die Intent to Experiment (I2E) geteilt. Das bedeutet, dass wir einen Ursprungstest durchführen möchten, bei dem Websites frühzeitig die Option zum Empfangen eines reduzierten User-Agent-Strings aktivieren können. Wenn Sie den User-Agent auf Ihrer Website auf irgendeine Weise verarbeiten – über den HTTP-Header oder in JavaScript – sollten Sie an der Teilnahme teilnehmen, um frühzeitig über Änderungen informiert zu werden, die Sie möglicherweise vornehmen müssen. Der Ursprungstest soll ab Chrome 95 beginnen. Wir geben bekannt, sobald er zur Registrierung verfügbar ist.

Wenn Sie die erweiterten Informationen vom User-Agent benötigen, bietet User-Agent Client Hints (UA-CH) diese Funktion sowohl für HTTP-Header als auch für JavaScript. Weitere Informationen zur Einbindung in Ihre Website finden Sie im Leitfaden zur Migration.

UA-CH ist standardmäßig in Chrome Stable verfügbar. Wir arbeiten kontinuierlich daran, die Funktion mithilfe von Feedback aus dem System zu verbessern. Das Microsoft Edge-Team trägt mit einem I2P zur Verbesserung der für Windows bereitgestellten Plattformversion-Daten bei.

Relevante Inhalte und Werbung anzeigen

FLoC

FLoC ist ein Vorschlag, mit dem interessenbezogene Werbung ohne individuelles websiteübergreifendes Tracking ermöglicht werden soll. Der Ursprungstest für die erste Version von FLoC endete Mitte Juli. Wir prüfen derzeit Verbesserungen für die nächste Version von FLoC, bevor wir mit weiteren Systemtests fortfahren. Wenn Sie Ihr Testtoken für FLoC oder anderen experimentellen Code noch bereitstellen, sollten Sie dies jetzt ändern.

Shared Storage API

Wir haben eine I2P für die Shared Storage API veröffentlicht. Dies ist eine relativ niedrige Speicherkomponente, die aggregierte Berichte und die Inhaltsfilterung von websiteübergreifenden Daten unterstützen soll. Der Ursprung kann dann über mehrere eingebettete Kontexte in den Speicher schreiben und die Daten nur über eine sehr eingeschränkte Schnittstelle wieder lesen. Beispielsweise können Sie einen einzelnen Wert für einen einheitlichen A/B-Test oder eine einheitliche Reichweiten-/Frequenzbeschränkung für mehrere Kontexte angeben, ohne direkten Zugriff auf diese Kennung zu gewähren.

Das Thema wird derzeit intensiv diskutiert. Wenn Sie an der Designphase interessiert sind, können Sie Probleme im Repository melden. Weitere Tests und Herkunftstests stehen aber noch bevor.

Digitale Anzeigen analysieren

Attributionsberichte

Die Attribution Reporting API ist seit Ende 2020 unter dem Namen Conversion Measurement API auf Ereignisebene in Ursprungstests.

Seit Chrome 92 gab es eine Reihe von API-Änderungen. Wir haben einen Leitfaden zur Migration von der Conversion Measurement API zur Attribution Reporting API veröffentlicht. Außerdem verlängern wir den Testzeitraum bis zur stabilen Version von Chrome 93. Außerdem haben wir die Phase „Diskussion“ in der Zeitleiste verlängert, um die laufenden Arbeiten an Aspekten wie aggregierten und geräteübergreifenden Berichten widerzuspiegeln.

Berichte auf Ereignisebene werden so erstellt: Der Browser gleicht Klicks oder Aufrufe (Attributionsquellereignisse) mit Conversion-Daten (Attributionsauslöserdaten) ab, die durch AdTech definiert wurden. Mit einer gewissen Verzögerung sendet der Browser dann die resultierenden Berichte an einen vordefinierten Endpunkt, wobei manchmal auch zufällige Daten anstelle echter Berichte gesendet werden.

Wir haben eine Einführung in die Attributionsberichte und eine Videoübersicht veröffentlicht, in denen die Funktionsweise der API, die wichtigsten Anwendungsfälle, der API-Implementierungsstatus und der Vergleich mit Drittanbieter-Cookies erläutert werden.

Bekämpfung von Spam und Betrug im Internet

Trust Tokens

Trust Tokens sind ein Vorschlag, mit dem eine Website eine Behauptung über einen Nutzer teilen kann, z. B. „Ich glaube, es ist ein Mensch“, und andere Websites diese Behauptung überprüfen können, aber so, dass der Nutzer nicht über diese Websites hinweg verknüpft werden kann.

Im Rahmen der Reihe „Was ist die Privacy Sandbox?“ hat Sam ein kurzes Video mit einer Übersicht über die Trust Tokens API erstellt.

Der Ursprungstest für Trust Tokens ist seit Chrome 84 verfügbar und soll bis Chrome 94 laufen. Es gibt also noch Zeit, die Funktion auf Ihren Websites zu testen.

Außerdem haben wir einen I2E zu von der Android-Plattform bereitgestellte Trust Tokens veröffentlicht, in dem das Potenzial zur Ausstellung von Tokens aus einer größeren Bandbreite von Quellen als nur anderen Websites untersucht wird. Dies ist ein sehr begrenzter erster Test, um die serverseitige Implementierung zu testen und auf der Grundlage der hier gewonnenen Erkenntnisse weitere Tests durchzuführen.

Feedback

Das Pilotvideo erscheint demnächst und im nächsten Monat gibt es eine weitere Folge dieser Reihe. Unser Ziel ist es, dass dieser Rückblick für Sie nützlich und umsetzbar ist. Bitte lassen Sie uns wissen, was wir verbessern können.