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 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 Datenschutzfunktionen 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 von 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 die 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 beginnt die Unterhaltung.
Abbildung 2: Die Unterhaltung beginnt mit einer Absichtserklärung für einen Prototyp.

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 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-Diskussions-Threads.

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 vorangetrieben, aber für jede API werden Beiträge aus dem gesamten Ökosystem berücksichtigt. 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 bitten sie, Probleme zu 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 wir neben der Funktion auch Debugging- und Tooling-Support anbieten können.

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 Funktions-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 gibt an, 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: Passiv weitergegebene Browserdaten werden eingeschränkt, um die Menge an sensiblen 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, mit einem separaten Cookie-Bereich pro Website der obersten Ebene. CHIPS ist seit Februar 2023 in der stabilen Version verfügbar.
  • First-Party-Sets: Beziehungen zwischen Websites deklarieren, um mit 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 identifizierende 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 Analyse 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 im Blick behalten 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 entwickeln. Mithilfe 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.