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 Funktionen der Webplattform können zu Webstandards (auch als Spezifikationen bezeichnet) werden. Dies sind technische Dokumente, in denen genau beschrieben wird, wie die Webtechnologie funktionieren soll und wie Entwickler die Technologien in Webbrowsern implementieren sollten. Der Accessible Rich Internet Applications (WAI-ARIA)-Standard (allgemein als „ARIA“ bezeichnet) definiert beispielsweise technische Möglichkeiten, das Web für Menschen mit Behinderung barrierefreier zu gestalten. Diese Spezifikationen werden vom und für das World Wide Web Consortium (W3C) entwickelt, einer internationalen Community mit Vollzeitmitarbeitern, Mitgliedsorganisationen und Feedback von der Allgemeinheit.

Nach Diskussionen, Tests und einiger Zeit in der Praxis werden einige Privacy Sandbox-Vorschläge und ‑APIs zu Spezifikationen. Es ist wichtig, dass wir Feedback von Entwicklern und Branchenführern (mit und ohne Webtechnologie-Kenntnisse) erhalten, damit wir langlebige Webfunktionen mit breiter Nützlichkeit und robustem Datenschutz für Nutzer entwickeln können.

Funktionen durchlaufen einen Zeitplan für Entwicklung und Tests bis zur allgemeinen Verfügbarkeit.
Abbildung 1: Funktionen durchlaufen einen Zeitplan für 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 die Absicht, einen Test durchzuführen, gepostet und genehmigt wurde. Weitere Informationen zu diesen Anforderungen

Chromium (das Open-Source-Projekt, das vielen modernen Browsern zugrunde liegt) hat den Prozess der Funktionsentwicklung für alle Technologien beschrieben, die zu einem Webstandard werden sollen. Da Datenschutz und Sicherheit im Web von entscheidender Bedeutung sind, erwarten wir vor Beginn der Tests eine intensive Diskussion und viel Feedback.

Vom Vorschlag zum Webstandard

In jeder Entwicklungsphase erhalten wir wichtiges Feedback, das die Privacy Sandbox beeinflusst. Dieser Prozess ist Webentwicklern möglicherweise vertraut, aber möglicherweise neu für andere Branchenakteure, die diese speziell entwickelten APIs verwenden und deren Fachwissen für diese Initiative entscheidend ist.

Mit einer Diskussion beginnen

Ein Intent to Prototype startet die Unterhaltung.
Abbildung 2: Mit einer Intent-to-Prototype-Anfrage wird die Unterhaltung gestartet.

In den letzten Jahren wurden von Chrome und anderen Anbietern Dutzende von datenschutzfreundlichen Vorschlägen gemacht. Sie können sich diese Vorschläge ansehen, Fragen stellen, Verbesserungsvorschläge machen und sehen, was andere dazu sagen.

Je nach Anwendungsfall können Sie einer Reihe von W3C-Gruppen beitreten oder sie beobachten:

Die Diskussionsphase kann sehr arbeitsintensiv sein.

Protected Audience (früher FLEDGE) ist beispielsweise ein Vorschlag für interessenbezogene Werbung ohne websiteübergreifendes Tracking. Die Protected Audience API wurde mithilfe von Input von Datenschutzexperten und vielen Branchenakteuren aus zwei früheren Vorschlägen (PIGIN und TURTLEDOVE) entwickelt. Mehr als 100 Personen haben an W3C-Meetings teilgenommen, um die aktuelle Version zu optimieren, und es gab über 300 Onlinediskussionsforen.

Außerdem wurden von anderen Unternehmen mehr als ein halbes Dutzend weiterer Vorschläge für die gleiche Lösung gemacht. Wir hoffen, dass wir durch die weitere Zusammenarbeit einen Weg in die Zukunft finden.

Tests für die Protected Audience API und andere APIs sind über ein Chrome-Flag verfügbar, damit Entwickler frühzeitig darauf zugreifen können.

Nicht jeder Vorschlag durchläuft eine so intensive Inkubationsphase wie Protected Audience. Einige werden viel schneller umgesetzt, aber jede API erhält Feedback aus dem gesamten System. Das sind neue Ideen und es kann viel Arbeit kosten, sie richtig umzusetzen.

Entwickler testen und geben Feedback

Intent-to-Tests sind für funktionale und skalierte Tests gedacht.
Abbildung 3: „Intent to“-Tests sind für funktionale und skalierte Tests gedacht.

Wir sind auf das Feedback von Entwicklern angewiesen, um diese Technologien zu verbessern und Probleme zu identifizieren, die Änderungen am API-Design und an der Implementierung erfordern. Viele der Privacy Sandbox-Technologien sind mit verschiedenen Optionen 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 zu testen. Die Verfügbarkeit hängt von der Chrome-Version ab. Im Laufe der Entwicklung können Entwickler auf einige Probleme stoßen.

Mit Chrome-Ursprungstests können Entwickler eine Funktion für eine begrenzte Anzahl von Chrome-Nutzern aktivieren. Entwickler können sich registrieren, um Ihre Website oder Ihren Dienst zu aktivieren. So haben Sie die Möglichkeit, die Funktion mit Produktionstraffic zu testen und Feedback zu Ihrer praktischen Erfahrung zu geben.

In der Privacy Sandbox wurde ein einheitlicher Test 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 davon ausgegangen, dass Mitwirkende Fehler finden und melden sowie Fehlerkorrekturen bereitstellen. Das bedeutet, dass sich die Stabilität und Gestaltung einer Funktion kurzfristig ändern können. Feedback zur Integration und zur Nutzerfreundlichkeit für Entwickler ist wichtig, damit neben der Funktion auch Support für die Fehlerbehebung und die Tools erstellt werden kann.

Im weiteren Verlauf der Entwicklung und wenn die Funktionen stabiler werden, verlagert sich der Schwerpunkt auf Effektivitäts- oder Nutzwerttests im größeren Maßstab. Das Ziel von Nutzwerttests besteht darin, die Leistung der Funktion im Hinblick auf die vorgesehenen Anwendungsfälle im großen Maßstab zu ermitteln. In dieser Phase wird die Anzahl der im Test enthaltenen Chrome-Nutzer erhöht, um eine größere, repräsentativere Stichprobe zu erhalten. Wir hoffen, dass in dieser Phase Websites längerfristige Tests mit einem größeren Teil ihres eigenen Traffics durchführen, um die Funktion auf ihre Geschäftsanforderungen hin zu validieren.

Der Erfolg dieses Prozesses hängt davon ab, dass Entwickler diese Tests durchführen und dann ihre Erkenntnisse teilen. Außerdem führen wir in jeder Phase gleichzeitig Tests durch und teilen die Ergebnisse über die verschiedenen Projektkanäle mit regelmäßigen Zusammenfassungen im Rahmen unserer Verpflichtungen gegenüber der CMA in unseren API-Statusaktualisierungen und vierteljährlichen Feedbackberichten.

Ganz gleich, ob Sie Ihre Tests an öffentlichen Stellen wie dem W3C, über Feedbackformulare oder über direkte Partnerschaftskanäle teilen: Wir freuen uns auf Ihre Nachricht.

Tests im Browser, entweder über Feature-Flags oder Ursprungstests, sind nicht die einzige Möglichkeit, die Funktionsweise neuer Technologien zu untersuchen. Einige Unternehmen entwickeln auch Simulationen auf der Grundlage von Privacy Sandbox-Konzepten.

Einführung für eine breitere Nutzung

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

Sobald eine API getestet wurde und für die allgemeine Nutzung in Chrome bereit ist, geben wir die Einführung bekannt und sorgen dafür, dass die öffentliche Dokumentation für die breite Nutzung im gesamten System bereit ist.

Wir haben bereits eine Reihe wichtiger Meilensteine erreicht und es stehen noch viele weitere an. Die folgenden Technologien sind jetzt verfügbar:

  • Reduzierung des User-Agents: Begrenzen Sie passiv freigegebene Browserdaten, um die Menge an sensiblen Informationen zu reduzieren, die zu Fingerprinting führen. Wir haben die Reduzierung dieser Werte im Mai 2022 begonnen und planen, sie im Mai 2023 abzuschließen.
  • CHIPS: Entwickler können ein Cookie für den partitionierten Speicher aktivieren, wobei es für jede Website der obersten Ebene einen separaten Cookie-Bereich gibt. CHIPS wurde im Februar 2023 in der stabilen Version eingeführt.
  • First-Party-Sets: Hiermit können Sie Beziehungen zwischen Websites deklarieren, um mithilfe der Storage Access API einen eingeschränkten websiteübergreifenden Cookie-Zugriff zu ermöglichen. First-Party-Sets wird diese Woche mit der stabilen Version 113 von Chrome langsam eingeführt.
  • Federated Credential Management (FedCM): Unterstützung der föderierten Identität, ohne die E-Mail-Adresse oder andere identifizierende Informationen des Nutzers an einen Drittanbieterdienst oder eine Drittanbieterwebsite 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 breite Nutzung freigegeben. Das bedeutet, dass diese APIs standardmäßig in Chrome verfügbar sind. Entwickler können diese Technologien jetzt ohne Browser-Flags oder Teilnahme an Ursprungstests 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. Vollständige Verfügbarkeit bedeutet nicht, dass die APIs für 100% des Traffics aktiviert sind.

So wurde beispielsweise 2021 die schrittweise Einführung von User-Agent-Client-Hints (UA-CH) in Chrome gestartet. Die Reduzierung der 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 Relevanz- und Mess-APIs, haben Konfigurationsoptionen für den Nutzer. Dazu gehört auch die Möglichkeit, diese APIs zu aktivieren und zu deaktivieren.

Es ist wichtig, die richtige Feature-Erkennung zu implementieren. Mithilfe der Funktionserkennung können Sie feststellen, ob ein Browser bestimmten Code unterstützt, und alternativen Code bereitstellen. So wird sichergestellt, dass Ihre Website wie erwartet funktioniert, auch wenn eine API von einem Nutzer deaktiviert wurde oder der Nutzer einen Browser verwendet, der eine bestimmte Technologie nicht unterstützt.

Sie können eine Berechtigungsrichtlinie verwenden, um den Zugriff von selbst erhobenen Daten und von Drittanbietern auf Browserfunktionen zu steuern.

Feedback geben

Wir werden Sie weiterhin über die aktuellen Entwicklungen informieren, so weit wie möglich in die Zukunft blicken, Sie um Ihr Feedback bitten und uns an Ihren Ideen beteiligen.