Lebenszyklus von Vorschlägen in der Privacy Sandbox

Die Privacy Sandbox-Vorschläge sind der erste von vielen Schritten, die zum Erstellen von Webplattformfunktionen erforderlich sind.

Diese Webplattformfunktionen können zu Webstandards (auch als Spezifikationen oder Specs bezeichnet) werden. Das sind technische Dokumente, in denen genau beschrieben wird, wie Webtechnologien funktionieren sollen, und in denen definiert wird, wie Entwickler die Technologien in Webbrowsern implementieren sollen. Der WAI-ARIA-Standard (Accessible Rich Internet Applications) (allgemein als „ARIA“ bezeichnet) definiert beispielsweise technische Möglichkeiten, das Web für Menschen mit Behinderungen zugänglicher zu machen. Diese Spezifikationen werden für und vom World Wide Web Consortium (W3C) entwickelt, einer internationalen Community mit Vollzeitmitarbeitern, Mitgliedsorganisationen und Feedback aus der Öffentlichkeit.

Nach Diskussionen, Tests und skalierter Einführung werden einige Privacy Sandbox-Vorschläge und APIs zu Spezifikationen. Es ist wichtig, dass wir Feedback von Entwicklern und Branchenführern (mit und ohne Kenntnisse von Webtechnologien) erhalten, damit wir dauerhafte Webfunktionen mit breitem Nutzen und robusten Datenschutzmaßnahmen für Nutzer entwickeln können.

Funktionen durchlaufen einen Zeitplan für Entwicklung und Tests bis zur allgemeinen Verfügbarkeit.
Abbildung 1: Funktionen durchlaufen eine Zeitachse der Entwicklung und Tests bis zur allgemeinen Verfügbarkeit. Die Intents sind harte Grenzen, die erforderlich sind, bevor bestimmte Aktionen ausgeführt werden können. Tests können beispielsweise erst beginnen, wenn eine Absichtserklärung für den Test veröffentlicht wurde und Genehmigungen eingegangen sind. Weitere Informationen zu diesen Anforderungen

Chromium, das Open-Source-Projekt hinter vielen modernen Browsern, hat den Prozess zur Entwicklung von Funktionen für alle Technologien beschrieben, die ein Webstandard werden sollen. Da Datenschutz und Sicherheit im Web von entscheidender Bedeutung sind, erwarten und begrüßen wir umfangreiche Diskussionen und Feedback, bevor Tests beginnen.

Vom Vorschlag zum Webstandard

In jeder Entwicklungsphase gibt das Ökosystem wichtiges Feedback, das die Privacy Sandbox prägt. Webentwickler sind möglicherweise mit diesem Prozess vertraut, für andere Branchenakteure, die diese speziell entwickelten APIs verwenden und deren Fachwissen für diese Initiative von entscheidender Bedeutung ist, ist er jedoch möglicherweise neu.

Mit einer Diskussion beginnen

Ein Intent to Prototype startet die Unterhaltung.
Abbildung 2: Die Unterhaltung beginnt mit einer Absicht, einen Prototyp zu erstellen.

In den letzten Jahren wurden von Chrome und anderen Dutzende von Datenschutz bewahrenden Vorschlägen gemacht. Sie können sich diese Vorschläge ansehen, Fragen stellen, Ideen zur Verbesserung einbringen und sehen, was andere dazu sagen.

Je nach den Anwendungsfällen, die Sie interessieren, können Sie einer Reihe von W3C-Gruppen beitreten oder sie beobachten:

Die Diskussionsphase kann sehr aufwendig sein.

Protected Audience (früher FLEDGE) ist beispielsweise ein Vorschlag, um interessenbezogene Werbung ohne Website-übergreifendes Tracking zu ermöglichen. Die Protected Audience API ist aus zwei früheren Vorschlägen (PIGIN und TURTLEDOVE) hervorgegangen und wurde durch Beiträge von Datenschutzbefürwortern und vielen Branchenakteuren weiterentwickelt. Mehr als 100 Personen haben an W3C-Meetings teilgenommen, um die aktuelle Version zu optimieren, und es gab über 300 Online-Diskussionsthreads.

Es gab auch mehr als ein halbes Dutzend anderer Vorschläge von anderen Unternehmen im selben Lösungsbereich. Wir hoffen, dass wir durch die weitere Zusammenarbeit einen Weg nach vorn finden.

Tests für Protected Audience und andere APIs sind hinter einem Chrome-Flag verfügbar, sodass Entwickler frühzeitig darauf zugreifen können.

Nicht jedes Angebot durchläuft eine so intensive Inkubationsphase wie Protected Audience. Einige werden viel schneller umgesetzt, aber für jede API wird Feedback aus dem gesamten Ökosystem eingeholt. Das sind neue Ideen und es kann viel Arbeit erfordern, sie umzusetzen.

Entwickler testen und geben Feedback

„Intent to Experiments“ sind für funktionale und skalierte Tests vorgesehen.
Abbildung 3: Intentionen für Tests sind für funktionale und skalierte Tests vorgesehen.

Wir sind auf das Feedback von Entwicklern zu Verbesserungen dieser Technologien angewiesen und darauf, dass sie Probleme melden, die Änderungen am API-Design und an der API-Implementierung erfordern. Viele der Privacy Sandbox-Technologien sind mit verschiedenen Optionen zum Testen verfügbar. Wenn Sie beispielsweise die Topics API testen möchten, können Sie die Epochenlänge und andere Parameter mit Chrome-Flags festlegen.

Häufig implementieren Chrome-Entwickler Funktionen hinter Flags, um lokale Tests zu ermöglichen, ohne dass die Funktion standardmäßig in allen Browsern verfügbar ist. Entwickler müssen eine Funktion aktivieren, um sie auszuprobieren. Die Verfügbarkeit hängt von der Chrome-Version ab. Entwickler müssen damit rechnen, dass im weiteren Verlauf der Entwicklung Probleme auftreten.

Mit Chrome-Ursprungstests können Entwickler eine Funktion für eine begrenzte Anzahl von Chrome-Nutzern aktivieren. Um teilzunehmen, können sich Entwickler registrieren, um Ihre Website oder Ihren Dienst zu aktivieren. So können Sie die Funktion mit Produktions-Traffic testen und Feedback zu den Erfahrungen in der Praxis geben.

Für die Privacy Sandbox wurde ein einheitlicher Ursprungstest für die APIs für Relevanz und Messung durchgeführt, der jetzt abgeschlossen ist.

Wenn eine Funktion für Tests zur Verfügung gestellt wird, stehen in der Regel funktionale oder technische Tests im Vordergrund. Bei neuem Code wird erwartet, dass Mitwirkende Fehler entdecken und melden sowie Korrekturen für diese Fehler bereitstellen. Das bedeutet, dass sich die Stabilität und Gestaltung einer Funktion kurzfristig ändern können. Feedback zur Integration und zur Entwicklerfreundlichkeit ist entscheidend, damit Debugging- und Tooling-Support für die Funktion erstellt werden kann.

Wenn die Funktion im weiteren Entwicklungsverlauf stabiler wird, verlagert sich der Schwerpunkt auf breit angelegte Wirksamkeits- oder Nützlichkeitstests. Bei Nutzertests geht es darum, die Leistung der Funktion für die geplanten Anwendungsfälle im großen Maßstab zu testen. In dieser Phase wird die Anzahl der Chrome-Nutzer, die in den Test einbezogen werden, erhöht, um eine größere, repräsentativere Stichprobe zu erhalten. In dieser Phase hoffen wir, dass Websites längerfristige Tests für einen größeren Teil ihres eigenen Traffics durchführen, um die Funktion anhand ihrer geschäftlichen Anforderungen zu validieren.

Der Erfolg dieses Prozesses hängt davon ab, dass Entwickler diese Tests durchführen und dann ihre Erkenntnisse weitergeben. Wir führen auch gleichzeitig in jeder Phase Tests durch und teilen die Ergebnisse über die verschiedenen einzelnen Projektkanäle mit. Regelmäßige Zusammenfassungen des Projekts finden Sie in unseren API-Statusupdates und vierteljährlichen Feedbackberichten, die Teil unserer Verpflichtungen gegenüber der CMA sind.

Wir freuen uns auf Ihr Feedback, egal ob Sie Ihre Tests an öffentlichen Orten wie dem W3C, über Feedbackformulare oder über direkte Partnerkanäle teilen.

Das Testen im Browser über Feature-Flags oder Ursprungstests ist nicht die einzige Möglichkeit, um herauszufinden, wie neue Technologien funktionieren könnten. Einige Unternehmen entwickeln auch Simulationen auf Grundlage von Privacy Sandbox-Konzepten.

Einführung für eine breite Akzeptanz

Eine „Intent to Ship“-Anfrage bedeutet, dass eine API für die skalierte Einführung verfügbar gemacht werden soll.
Abbildung 4: Eine „Intent to Ship“-Anfrage weist darauf hin, dass eine API für die skalierte Einführung verfügbar gemacht werden soll.

Sobald eine API getestet wurde und für die allgemeine Verwendung in Chrome bereit ist, kündigen wir die Einführung an und sorgen dafür, dass die öffentliche Dokumentation für die breite Einführung im Ökosystem bereit ist.

Wir haben bereits eine Reihe wichtiger Meilensteine erreicht und viele weitere werden folgen. Die folgenden Technologien sind jetzt verfügbar:

  • Reduzierung des User-Agents: Die Menge der passiv weitergegebenen Browserdaten wird begrenzt, um die Menge an vertraulichen Informationen zu reduzieren, die zu Fingerprinting führen. Wir haben im Mai 2022 mit der Reduzierung dieser Werte begonnen und planen, sie bis Mai 2023 abzuschließen.
  • CHIPS: Entwickler können ein Cookie für partitionierten Speicher aktivieren. Dabei wird für jede Website der obersten Ebene ein separater Cookie-Bereich verwendet. CHIPS ist seit Februar 2023 in der stabilen Version verfügbar.
  • First-Party-Sets: Beziehungen zwischen Websites deklarieren, um mithilfe der Storage Access API einen eingeschränkten websiteübergreifenden Cookie-Zugriff zu ermöglichen. First-Party-Sets werden diese Woche langsam mit Chrome-Version 113 eingeführt.
  • Federated Credential Management (FedCM): Unterstützt die föderierte Identität, ohne die E-Mail-Adresse oder andere personenidentifizierbare Informationen des Nutzers an einen Drittanbieterdienst oder eine Website weiterzugeben, es sei denn, der Nutzer stimmt dem ausdrücklich zu. FedCM wurde im November 2022 eingeführt.

Im Juli 2023 wurden die APIs für Relevanz und Messung für die skalierte Einführung verfügbar. Das bedeutet, dass diese APIs standardmäßig in Chrome verfügbar sind. Entwickler können diese Technologien jetzt ohne Browser-Flags oder Teilnahme an Origin Trials verwenden.

Kurz gesagt: Diese APIs sind für 99 % der Nutzer in einer Produktionsumgebung bereit.

Gestaffelte Markteinführungen

Einige Technologien werden nach und nach eingeführt. So können unser Team und die Entwickler potenzielle Probleme beobachten und beheben. Die vollständige Verfügbarkeit bedeutet nicht, dass die APIs für 100% des Traffics aktiviert sind.

Die schrittweise Einführung von User-Agent Client Hints (UA-CH) in Chrome begann beispielsweise 2021. Die Reduzierung des User-Agents begann im April 2022 und wurde im März 2023 abgeschlossen. So hatten Entwickler ausreichend Zeit, die Nutzung des User-Agent-Strings auf ihren Websites umzustellen.

API-Steuerung

Einige APIs, z. B. die APIs für Relevanz und Analyse, bieten Konfigurationsoptionen für den Nutzer. Dazu gehört auch die Möglichkeit, diese APIs zu aktivieren und zu deaktivieren.

Es ist wichtig, die entsprechende Funktionserkennung zu erstellen. Mit der Funktionserkennung lässt sich feststellen, ob ein Browser bestimmten Code unterstützt. So können Sie alternativen Code bereitstellen. So wird überprüft, ob sich Ihre Website weiterhin wie erwartet verhält, auch wenn eine API von einem Nutzer deaktiviert wurde oder der Nutzer einen Browser verwendet, der eine bestimmte Technologie nicht unterstützt.

Erwägen Sie die Verwendung einer Berechtigungsrichtlinie, um den Zugriff von Erstanbietern und Drittanbietern auf Browserfunktionen zu steuern.

Feedback geben

Wir werden weiterhin erklären, was passiert, so viel Transparenz wie möglich schaffen, Sie zur Teilnahme ermutigen und auf Ihr Feedback eingehen.