Angebotslebenszyklus 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 Spezifikationen bezeichnet) werden. Dabei handelt es sich um technische Dokumente, in denen genau beschrieben wird, wie Webtechnologien funktionieren sollten. Außerdem wird definiert, wie Entwickler die Technologien in Webbrowsern implementieren sollten. Der WAI-ARIA-Standard (Accessible Rich Internet Applications) (allgemein bekannt als "ARIA") 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 Allgemeinheit.

Nach Diskussion, Tests und der skalierten Einführung werden einige Privacy Sandbox-Angebote und -APIs zu Spezifikationen. Es ist entscheidend, dass wir Feedback von Entwicklern und Branchenführern (mit und ohne Kenntnisse der Webtechnologie) erhalten, um zu gewährleisten, dass wir zukunftsfähige Webfeatures mit großem Nutzen und zuverlässigem Datenschutz für Nutzer erstellen können.

Die Funktionen durchlaufen einen Zeitplan von der Entwicklung und Tests bis hin zur allgemeinen Verfügbarkeit.
Abbildung 1: Entwicklung und Tests der Features durchlaufen einen zeitlichen Verlauf der Entwicklung und Tests bis hin zur allgemeinen Verfügbarkeit. Intents sind feste Grenzen, die erforderlich sind, bevor bestimmte Aktionen ausgeführt werden können. Beispielsweise können Tests erst dann beginnen, wenn ein Test-Intent gepostet und genehmigt wurde. Weitere Informationen zu diesen Anforderungen

Chromium (das Open-Source-Projekt hinter vielen modernen Browsern) hat über den Prozess der Funktionsentwicklung für alle Technologien geschrieben, die zu einem Webstandard werden sollen. Da Datenschutz und Sicherheit im Web sehr wichtig sind, erwarten wir vor Beginn der Tests umfangreiche Diskussionen und Feedback.

Vom Angebot zum Webstandard

In jeder Entwicklungsphase gibt das System kritisches Feedback, das die Privacy Sandbox prägt. Dieser Prozess mag Webentwicklern vertraut sein, für andere Branchenvertreter, die diese zweckgebundenen APIs verwenden werden und deren Fachwissen für diese Initiative von entscheidender Bedeutung ist, jedoch möglicherweise neu.

Mit Diskussion beginnen

Ein Intent to Prototype beginnt das Gespräch.
Abbildung 2: Ein Intent-to-Prototype beginnt das Gespräch.

In den letzten Jahren wurden Dutzende datenschutzfreundliche Angebote von Chrome und anderen entwickelt. Sie können diese Vorschläge lesen, Fragen stellen, Verbesserungsvorschläge machen und sehen, was andere sagen.

Je nach den für Sie interessanten Anwendungsfällen können Sie einer Reihe von W3C-Gruppen beitreten oder diese überwachen:

Die Diskussionsphase kann sehr involviert sein.

Protected Audience (früher FLEDGE) ist beispielsweise ein Vorschlag zur Unterstützung von interessenbezogener Werbung ohne websiteübergreifendes Tracking. Die Protected Audience API hat sich anhand des Inputs von Datenschutzbeauftragten und vielen Branchenbeteiligten im Vergleich zu zwei früheren Vorschlägen (PIGIN und TURTLEDOVE) weiterentwickelt. Mehr als 100 Personen nehmen an W3C-Meetings teil, um die aktuelle Version weiter zu optimieren, sowie über 300 Online-Diskussionsthreads.

Es wurden auch mehr als ein halbes Dutzend weitere Vorschläge von anderen Unternehmen auf demselben Lösungsbereich angeboten. Durch kontinuierliche Zusammenarbeit hoffen wir, einen Weg nach vorn zu 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 Vorschläge werden viel schneller vorankommen, aber jede API erhält Input aus dem gesamten System. Das sind neue Ideen, und es kann viel Arbeit erfordern, sie richtig umzusetzen.

Entwickler testen und Feedback geben

Die Absicht von Tests ist für funktionale und skalierte Tests gedacht.
Abbildung 3: Absicht für Tests ist für funktionale und skalierte Tests vorgesehen.

Wir sind darauf angewiesen, dass Entwickler Feedback zu Verbesserungen dieser Technologien geben und Probleme teilen, die Änderungen am Design und der Implementierung der API erfordern können. Viele der Privacy Sandbox-Technologien stehen für Tests mit verschiedenen Optionen zur Verfügung. Wenn Sie beispielsweise die Topics API testen möchten, können Sie mit Chrome-Flags die Epochenlänge und andere Parameter festlegen.

Häufig implementieren Chrome-Entwickler Funktionen hinter Flags, um lokale Tests zu ermöglichen, ohne dass die Funktion standardmäßig in verschiedenen Browsern verfügbar ist. Entwickler müssen eine Funktion aktivieren, um sie auszuprobieren. Die Verfügbarkeit hängt von der Chrome-Version ab. Im Laufe der Entwicklung können Entwickler mit einigen Problemen rechnen.

Mit Chrome-Ursprungstests können Entwickler eine Funktion für eine begrenzte Anzahl von Chrome-Nutzern aktivieren. Entwickler können sich für Ihre Website oder Ihren Dienst registrieren, um teilzunehmen. So haben Sie die Möglichkeit, die Funktion im Produktionstraffic auszuprobieren und Feedback zur realen Umgebung zu geben.

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

Wenn eine Funktion erstmals für Tests zur Verfügung gestellt wird, liegt der Schwerpunkt in der Regel auf funktionalen oder technischen Tests. Bei neuem Code wird erwartet, dass Beitragende Fehler finden und melden sowie Korrekturen für diese Fehler bereitstellen. Das bedeutet, dass sich die Stabilität und Form eines Features in diesem Zeitraum schnell ändern können. Feedback zur Integration und zur Entwicklererfahrung ist von entscheidender Bedeutung, damit neben der Funktion auch Unterstützung für Fehlerbehebung und Tools bereitgestellt werden kann.

Im Laufe der Entwicklung und mit zunehmender Stabilität der Funktionen verlagert sich der Schwerpunkt auf Effektivitäts- oder Gebrauchstests. Das Ziel von Dienstprogrammtests besteht darin, die Leistung der Funktion im Hinblick auf die vorgesehenen Anwendungsfälle in großem Maßstab zu ermitteln. In dieser Phase wird die Anzahl der am Test teilnehmenden Chrome-Nutzer erhöht, um eine größere, repräsentativere Stichprobe zu erhalten. Wir hoffen, dass in dieser Phase längerfristige Tests für einen größeren Teil ihres eigenen Traffics ausgeführt werden, um die Funktion im Hinblick auf ihre geschäftlichen Anforderungen zu validieren.

Der Erfolg bei diesem Prozess hängt davon ab, dass Entwickler diese Tests durchführen und das Gelernte teilen. Außerdem führen wir während der einzelnen Phasen Tests durch und teilen die Ergebnisse über die verschiedenen Projektkanäle mit regelmäßigen Zusammenfassungen des Projekts in unserer Blogreihe „Fortschritte in der Privacy Sandbox“ und vierteljährlichen Feedbackberichten im Rahmen unserer Verpflichtungen gegenüber der CMA.

Unabhängig davon, ob du deine Tests an öffentlichen Orten wie dem W3C, über Feedbackformulare oder über direkte Partnerschaftskanäle teilst, wir würden uns freuen, von dir zu hören.

Tests im Browser – sei es über Funktions-Flags oder Ursprungstests – sind nicht die einzige Möglichkeit, herauszufinden, wie neue Technologien funktionieren könnten. Einige Unternehmen erstellen auch Simulationen, die auf Privacy Sandbox-Konzepten basieren.

Einführung für skalierte Akzeptanz

Ein Versand-Intent gibt eine Anfrage an, eine API für eine skalierte Einführung verfügbar zu machen.
Abbildung 4: Ein Intent to Ship gibt eine Anfrage an, eine API für eine skalierte Einführung verfügbar zu machen.

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 Einführung in ein skaliertes System bereit ist.

Wir haben bereits eine Reihe von wichtigen Meilensteinen erreicht und es werden noch viele weitere hinzukommen. Folgende Technologien sind jetzt verfügbar:

  • Reduzierung des User-Agents: Passiv freigegebene Browserdaten beschränken, 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, den Vorgang im Mai 2023 abzuschließen.
  • CHIPS: Ermöglicht Entwicklern, ein Cookie für den partitionierten Speicher mit einer separaten Cookie-JAR-Datei pro Top-Level-Website zu aktivieren. CHIPS wurde im Februar 2023 als stabile Version eingeführt.
  • First-Party-Sets: Deklarieren Sie Beziehungen zwischen Websites, um mit der Storage Access API einen begrenzten websiteübergreifenden Cookie-Zugriff zu ermöglichen. First-Party-Sets werden diese Woche nach und nach mit der stabilen Chrome-Version 113 eingeführt.
  • Federated Credential Management (FedCM): Unterstützen Sie die föderierte Identität, ohne die E-Mail-Adresse des Nutzers oder andere personenidentifizierbare Informationen an den Dienst oder die Website eines Drittanbieters weiterzugeben, es sei denn, der Nutzer stimmt dem ausdrücklich zu. FedCM wurde im November 2022 versendet.

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

Kurz gesagt, diese APIs sind für 99 % der Nutzer in großem Maßstab in einer Produktionsumgebung bereit.

Gestaffelte Markteinführungen

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

Die stufenweise Einführung der 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 konnten die Entwickler ihre Websites auf den User-Agent-String umstellen.

API-Steuerelemente

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

Es ist wichtig, eine geeignete Feature-Erkennung zu erstellen. Mit der Funktionserkennung können Sie feststellen, ob ein Browser bestimmten Code unterstützt, und alternativen Code bereitstellen. So wird sichergestellt, dass sich Ihre Website auch dann wie erwartet verhält, wenn eine API von einem Nutzer deaktiviert wurde oder der Nutzer sich in einem Browser befindet, der eine bestimmte Technologie nicht unterstützt.

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

Feedback geben

Wir werden weiterhin die Geschehnisse erklären, so viel Transparenz wie möglich bieten, Ihre Beteiligung fördern und Ihre Meinung hören.