Willkommen bei der Oktoberausgabe von „Fortschritte in der Privacy Sandbox“. Hier erfahren Sie, welche Meilensteine wir auf dem Weg zur Einstellung von Drittanbieter-Cookies in Chrome erreicht haben und wie wir ein datenschutzfreundlicheres Web schaffen. Jeden Monat veröffentlichen wir einen Überblick über die Updates zum Zeitplan der Privacy Sandbox sowie Neuigkeiten zum gesamten Projekt.
Ereignisse
Ab dem 3. November findet der Chrome Developer Summit statt. In der Keynote erhalten Sie aktuelle Informationen zur Privacy Sandbox. Außerdem haben Sie die Möglichkeit, dem Führungsteam im Rahmen des AMA Fragen zu stellen. Bei den Office Hours können Sie dann detailliertere Fragen an die Entwicklerteams richten. Melde dich noch heute an und wir sehen uns dort!
Außerdem fand im April die Jahreskonferenz des W3C (allgemein bekannt als TPAC) statt. Dort kommen alle W3C-Gruppen zusammen, um über verschiedene Themen rund um das Web zu diskutieren. Die Minuten und Videos für die Breakout-Sitzungen sowie bestimmte Sitzungen mit Themen zur Privacy Sandbox finden Sie unten.
Im Rahmen der anhaltenden Konferenzsaison veranstaltet die IETF (Internet Engineering Task Force) ihre regelmäßige 112. online-technische Plenarsitzung. Ähnlich wie bei der TPAC gibt es eine Reihe von Einzelsitzungen, in denen Themen zur Privacy Sandbox besprochen werden, z. B. die Arbeitsgruppen PRIV (Privacy Respecting Incorporation of Values), PEARG (Privacy Enhancements and Assessments Research Group) und MASQUE (Multiplexed Application Substrate over QUIC encryption). Es handelt sich dabei um ausführliche technische Diskussionen zu Protokolldesigns. Wenn Sie über die entsprechende Fachkompetenz verfügen und Interesse daran haben, an diesen Diskussionen teilzunehmen, sollten Sie sich bewerben.
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.
Federated Credentials Management API
Der FedCM-Vorschlag (Federated Credentials Management) ist der neue, aussagekräftigere Name für WebID. Die föderierte Identität ist ein wichtiger Dienst für das Web. Da es jedoch ausdrücklich darum geht, Aspekte der Identität mit anderen Websites zu teilen, gibt es Implementierungsdetails, die sich mit dem websiteübergreifenden Tracking überschneiden.
Im Vorschlag für die verwaltete Authentifizierung werden verschiedene Optionen untersucht, von einfachen Migrationspfaden für bestehende Lösungen bis hin zu privateren Methoden zur Verbindung mit Diensten, bei denen nur die minimal erforderlichen Informationen weitergegeben werden.
Dieser Vorschlag befindet sich noch in der Anfangsphase und die Diskussion kann in der Federated Identity Community Group des W3C verfolgt werden. Die Gruppe veranstaltete auch eine Breakout-Sitzung mit einer Vorstellung des Vorschlags im TPAC. Es gibt auch eine sehr frühe Prototypversion der API, die seit Chrome 89 über ein Flag verfügbar ist. Diese Version ist jedoch nur für Experimente gedacht und wird sich im Laufe der Diskussion ändern.
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, sollten Sie dem CHIPS-Vorschlag folgen, also Cookies mit unabhängigem partitioniertem Status. So können Sie Cookies als „Partitioniert“ markieren und sie in einen separaten Cookie-Jar pro Website der obersten Ebene legen.
Die Arbeit an CHIPS schreitet voran. Die Funktion ist zwar über chrome://flags/#partitioned-cookies und das --partitioned-cookies-Befehlszeilenflag verfügbar, kann aber noch nicht vollständig getestet werden. Sobald die Implementierung abgeschlossen ist, erhalten Sie aktuelle Informationen zu Tests und Fehlerbehebung.
First-Party-Sets
Wenn Sie Cookies für websiteübergreifende Kontexte festlegen, aber nur auf Websites, die Ihnen gehören, z. B. wenn Sie einen Dienst auf Ihrer .com-Website hosten, der von Ihrer .co.uk-Website verwendet wird, sollten Sie die Eigene Sets verwenden. In diesem Vorschlag wird eine Möglichkeit definiert, anzugeben, welche Websites Sie zu einem Set zusammenfassen möchten, und dann Cookies als „SameParty“ zu kennzeichnen, damit sie nur für Kontexte innerhalb dieses Sets gesendet werden.
Sets mit selbst erhobenen Daten sind für lokale Entwicklertests unter den Flags chrome://flags/#use-first-party-set und chrome://flags/#sameparty-cookies-considered-first-party verfügbar. So können Sie Ihre eigenen zugehörigen Websites angeben und das Cookie-Verhalten für diese testen.
Speicherpartitionierung
Die Webplattform umfasst auch andere Speicherformen, die websiteübergreifendes Tracking ermöglichen können. Die TPAC-Breakout-Sitzung zum Stand der Browserspeicherpartitionierung bietet einen Überblick über die Fortschritte bei Chrome sowie eine Diskussion mit anderen Browseranbietern.
Entwickler müssen derzeit nichts unternehmen. Wenn Sie jedoch SharedWorker, Web Storage, IndexedDB, CacheStorage, FileSystem API(s), BroadcastChannel, Web Locks API, Storage Buckets oder eine andere Form von Speicher- oder Kommunikations-API verwenden, bei der Sie auf diese Daten auf mehreren Websites zugreifen, sollten Sie dieses Thema im Blick behalten, um über zukünftige Updates informiert zu bleiben.
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 haben den Ursprungstest für die reduzierte User-Agent-Ansicht in Chrome auf eingebettete Inhalte von Drittanbietern ausgeweitet. Wenn Sie hauptsächlich websiteübergreifende Inhalte für andere Dienste bereitstellen, können Sie die Option für Drittanbieter aktivieren, wenn Sie sich für den Testzeitraum für den Ursprung registrieren, um das reduzierte Format bei Anfragen an Ihre Ressourcen zu erhalten.
Sie können die vollständige Zeitachse für die Reduzierung des User-Agents von Chrome mit weiteren Beispielen und Details zu den Einführungsphasen verfolgen. Außerdem müssen Sie zu User-Agent-Client-Hints (UA-CH) migrieren, wenn Sie die Informationen zur Plattformversion, zum Gerät oder zur vollständigen Buildversion im aktuellen User-Agent-Format verwenden.
Wir standardisieren weiterhin vorhandene Namen für Clienthinweise, indem wir dort, wo es fehlt, das Sec-CH--Headerpräfix hinzufügen. Sobald die Genehmigung vorliegt, hoffen wir, die Auswahl der GREASE-Zeichen für UA-CH erweitern zu können.
Relevante Inhalte und Werbung anzeigen
Da wir Drittanbieter-Cookies nach und nach einführen, müssen wir APIs einführen, die die Anwendungsfälle ermöglichen, die davon abhängig waren, ohne websiteübergreifendes Tracking zuzulassen.
FLoC
FLoC ist ein Vorschlag, der interessenbezogene Werbung ohne individuelles websiteübergreifendes Tracking ermöglichen soll. Wir haben das Feedback aus dem früheren Ursprungstest von FLoC ausgewertet, bevor wir mit weiteren Systemtests fortfahren. Während wir an den nächsten Schritten und Entscheidungen für FLoC arbeiten, sollten Sie bald explorativen Code zum Konzept von Topics (bereits erwähnt) in der Chromium-Codebasis sehen. Da die gesamte Entwicklung von Chrome offen stattfindet, sind diese Änderungen sichtbar. Für Entwicklertests gibt es jedoch nichts, was sofort umgesetzt werden kann. Das gilt auch für Nutzer. Wir hoffen, diese Diskussionen und Updates auch in der neuen PATCG (Private Advertising Technology Community Group) fortsetzen zu können.
Digitale Anzeigen analysieren
Um Anzeigen ohne websiteübergreifendes Tracking zu präsentieren, benötigen wir datenschutzfreundliche Mechanismen, um die Effektivität dieser Anzeigen zu messen.
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.
Wir möchten die Attribution Reporting API weiter testen und planen, den Ursprungstest bis Chrome 97 zu verlängern. Die aktuellen Testtokens für den Ursprung sind am 12. Oktober abgelaufen. Sie müssen also aktualisierte Tokens beantragen, um die Tests fortzusetzen.
Bekämpfung von Spam und Betrug im Internet
Die andere Herausforderung besteht darin, dass dieselben Fingerprinting-Techniken häufig zum Schutz vor Spam und Betrug eingesetzt werden. Auch hier sind datenschutzfreundliche Alternativen erforderlich.
Trust Tokens
Die Trust Token API ist ein Vorschlag, mit dem eine Website eine Behauptung über einen Besucher teilen kann, z. B. „Ich glaube, es ist ein Mensch“, und andere Websites diese Behauptung überprüfen können, ohne die Person zu identifizieren.
Trust Tokens sind Teil der Gesamtstrategie zur Bekämpfung von Spam und Betrug im Web. Im Workshop „Betrug im Web verhindern“ auf der TPAC haben Vertreter aus der gesamten Branche einige der aktuellen Herausforderungen und Ansätze besprochen.
Feedback
Wir veröffentlichen diese monatlichen Updates und arbeiten weiter an der Privacy Sandbox. 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.
Außerdem haben wir eine Liste mit häufig gestellten Fragen zur Privacy Sandbox hinzugefügt, die wir anhand der Probleme, die Sie im Repository für den Entwicklersupport melden, kontinuierlich erweitern werden. Wenn Sie Fragen zum Testen oder zur Implementierung eines der Vorschläge haben, können Sie sich jederzeit an uns wenden.