Feedbackbericht – 2. Quartal 2022

Quartalsbericht für das 2. Quartal 2022 mit einer Zusammenfassung des Feedbacks zum Privacy Sandbox-Vorschlag und zur Antwort von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google zugestimmt, öffentlich vierteljährliche Berichte zum Prozess der Stakeholder-Beteiligung an seinen Privacy Sandbox-Vorschlägen zu veröffentlichen (siehe Paragraf 12 und Paragraf 17(c)(ii) der Verpflichtungen). Für die Feedbackberichte werden die Rückmeldungen aggregiert, die das Chrome-Team aus den verschiedenen Quellen erhält, die in der Feedbackübersicht aufgeführt sind, darunter: GitHub-Probleme, das Feedbackformular, das unter privacysandbox.com verfügbar ist, Besprechungen mit Branchenvertretern und Foren für Webstandards. Wir freuen uns über das Feedback, das wir aus der Community erhalten haben, und suchen aktiv nach Möglichkeiten, die Erkenntnisse in Designentscheidungen einfließen zu lassen.

Feedbackthemen werden nach Häufigkeit pro API sortiert. Dazu wird die Menge des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, zusammengefasst und in absteigender Reihenfolge nach Menge sortiert. Die häufigsten Feedbackthemen wurden anhand von Diskussionsthemen aus öffentlichen Treffen (W3C, PatCG, IETF), direktem Feedback, GitHub und häufig gestellten Fragen identifiziert, die über die internen Teams von Google und öffentliche Formulare aufkamen.

Insbesondere wurden die Protokolle der Sitzungen von Webstandards-Organisationen überprüft. Für direktes Feedback wurden die Aufzeichnungen von persönlichen Stakeholder-Sitzungen von Google, E-Mails, die von einzelnen Entwicklern empfangen wurden, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Google koordinierte dann die an diesen verschiedenen Outreach-Aktivitäten beteiligten Teams, um die relative Verbreitung der Themen in Bezug auf die einzelnen APIs zu ermitteln.

Die Erläuterungen zu den Antworten von Chrome auf Feedback wurden anhand veröffentlichter FAQs, tatsächlicher Antworten auf von Stakeholdern angesprochene Probleme und einer speziell für diese öffentliche Berichterstattung festgelegten Position entwickelt. Entsprechend dem aktuellen Schwerpunkt der Entwicklung und Tests haben wir vor allem Fragen und Feedback zu den Topics-, FLEDGE- und Attribution Reporting APIs erhalten.

Für Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingegangen ist, wurde möglicherweise noch keine Chrome-Antwort berücksichtigt.

CHIPS
Cookies mit unabhängigem partitionierten Status
DSP
Demand-Side-Plattform
FedCM
Federated Credential Management
FPS
First-Party-Sets
IAB
Interactive Advertising Bureau
IDP
Identitätsanbieter
IETF
Internet Engineering Task Force
IP-Adresse
Internet Protocol-Adresse
openRTB
Echtzeitgebote
NSZ
Origin-Testversion
PatCG
Private Advertising Technology Community Group
RP
Vertrauende Partei
SSP
Supply-Side-Plattform
TEE
Vertrauenswürdige Ausführungsumgebung
UA
User-Agent-String
UA-CH
User-Agent-Client-Hints
W3C
World Wide Web Consortium
WIPB
Willful IP Blindness

Allgemeines Feedback, keine bestimmte API/Technologie

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Klarere Zeitpläne Klarere und detailliertere Zeitpläne für die Einführung der Privacy Sandbox-Technologien. Unsere aktuellen Pläne für den Zeitplan der Einführung stellen wir auf privacysandbox.com bereit und aktualisieren sie monatlich. Dabei wird sowohl die Entwicklungszeit für Chrome- als auch für Webentwickler berücksichtigt. Außerdem haben wir Feedback aus der gesamten Branche zum Zeitaufwand für das Testen und Einführen der neuen Technologien erhalten. Jede Technologie durchläuft mehrere Schritte vom Testen bis zur Veröffentlichung (Launch). Der Zeitpunkt jedes Schritts richtet sich nach den Erkenntnissen aus dem vorherigen Schritt. Wir haben derzeit keine Veröffentlichungstermine festgelegt. Sobald wir diese kennen, aktualisieren wir unseren öffentlichen Zeitplan auf privacysandbox.com.
Nützlichkeit für verschiedene Arten von Stakeholdern Bedenken, dass die Privacy Sandbox-Technologien größere Entwickler begünstigen und dass Nischen-Websites (kleinere Websites) mehr beitragen als allgemeine (größere) Websites. Uns ist bewusst, dass einige Entwickler Bedenken hinsichtlich der Auswirkungen der Privacy Sandbox-Technologien haben. Google hat sich gegenüber der CMA verpflichtet, die Privacy Sandbox-Vorschläge nicht so zu entwerfen oder umzusetzen, dass der Wettbewerb durch Bevorzugung des eigenen Geschäfts von Google verzerrt wird. Außerdem wird Google die Auswirkungen auf den Wettbewerb in der digitalen Werbung, auf Publisher und Werbetreibende sowie auf den Datenschutz und die Nutzerfreundlichkeit berücksichtigen. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen entspricht.

Im Laufe der Tests der Privacy Sandbox werden wir unter anderem prüfen, wie sich die neuen Technologien für verschiedene Arten von Stakeholdern schlagen. Feedback ist in dieser Hinsicht entscheidend, insbesondere spezifisches und umsetzbares Feedback, das uns dabei helfen kann, die technischen Designs weiter zu verbessern.

Zeitplan für die Einstellung von Drittanbieter-Cookies Anfragen zur Vermeidung weiterer Verzögerungen bei der Einstellung von Drittanbieter-Cookies Einige Stakeholder haben uns mitgeteilt, dass sie möchten, dass Drittanbieter-Cookies in Chrome sofort eingestellt werden. Andere sind der Meinung, dass mehr Zeit für die Tests und die Einführung der Privacy Sandbox-Technologien erforderlich ist. Angesichts der Komplexität der Technologien und der Bedeutung, die eine korrekte Umsetzung für das Ökosystem hat, sind wir bestrebt, verantwortungsbewusst vorzugehen. Das Feedback aus der Branche und von Regulierungsbehörden war für diesen Prozess entscheidend.
Zeitplan für die Einstellung von Drittanbieter-Cookies Anfragen zur Verzögerung der Einstellung von Drittanbieter-Cookies und zur Bereitstellung mehr Zeit für das Testen der APIs. Einige Stakeholder haben uns mitgeteilt, dass sie möchten, dass Drittanbieter-Cookies in Chrome sofort eingestellt werden. Andere sind der Meinung, dass mehr Zeit für die Tests und die Einführung der Privacy Sandbox-Technologien erforderlich ist. Angesichts der Komplexität der Technologien und der Bedeutung, die eine korrekte Umsetzung für das Ökosystem hat, sind wir bestrebt, verantwortungsbewusst vorzugehen. Das Feedback aus der Branche und von Regulierungsbehörden war für diesen Prozess entscheidend.
Anträge auf Dokumentation Anfragen nach weiteren Ressourcen zum Verwalten von Tests, Analysen und Implementierungen. Wir freuen uns, dass Entwickler unsere aktuellen Materialien hilfreich finden. In den kommenden Wochen und Monaten werden wir weitere Materialien wie Entwicklersprechstunden und technische Dokumentationen veröffentlichen, damit Entwickler weiterhin verstehen können, wie die neuen Technologien für sie funktionieren können.

Außerdem haben wir öffentliche Sprechstunden für externe Entwickler abgehalten, um Best Practices und Demos zu teilen. Außerdem gab es Fragerunden mit Produkt- und Engineering-Leitern, um Live-Diskussionen und Fragen zu ermöglichen.

Branchenkompetenz Das Chrome-Team, das mit Standardsorganisationen zusammenarbeitet, verfügt nicht über das erforderliche Fachwissen im Anzeigensystem, um Datenschutz und Nutzen in Einklang zu bringen. Wir sind uns bewusst, dass wir eine große Verantwortung haben, und wir sind auf konkretes Feedback angewiesen, um das Produkt so zu gestalten, dass es allen Anforderungen gerecht wird. Außerdem sind Datenschutz und Wirksamkeit für uns wichtige und notwendige Designkriterien. Die Gesamtzahl der Jahre, die die Mitglieder des Teams für die Privacy Sandbox für das Web im Anzeigensystem gearbeitet haben, geht in die Hunderte.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Nützlichkeit für verschiedene Arten von Stakeholdern Es wurden Bedenken hinsichtlich des generierten Werts und der Verteilung dieses Werts für Websites geäußert, je nach Traffic oder Spezialisierung der Inhalte. Der Nutzen der API wird anhand von Tests untersucht. Das Chrome-Team geht davon aus, dass sich die Taxonomie und andere Parameter auf Grundlage der Testergebnisse weiterentwickeln werden. Dabei sollten keine abwärtsinkompatiblen Änderungen erforderlich sein. Außerdem wird erwartet, dass das Feedback auch nach der Einstellung von Drittanbieter-Cookies Einfluss auf die Weiterentwicklung der Topics API haben wird.
Taxonomie Branchenvertreter möchten sich an der Weiterentwicklung der Taxonomie beteiligen. Das Chrome-Team berücksichtigt auch weiter entsprechende Eingaben. Das Chrome-Team ist sehr an Feedback zum Governance-Modell für die Anpassung der Taxonomie oder zur Frage interessiert, wie andere Branchenorganisationen langfristig eine aktivere Rolle bei der Entwicklung und Verwaltung der Taxonomie spielen können.
Nicht genügend Browserverlauf Vorschlag, Themen anzuzeigen, die der Anrufer in den letzten Wochen gesehen hat, wenn der Nutzer nicht genügend Browserverlauf hat, um fünf Themen für die letzte Woche zu erstellen Bei unserem aktuellen Design werden sie zufällig ausgewählt. Wir werden die Korrelation mit früheren Themen untersuchen und prüfen, ob es eine Möglichkeit gibt, sie zu berücksichtigen. Korrelationen können jedoch negative Auswirkungen auf den Datenschutz haben, die berücksichtigt werden müssen.
Topics im Namen eines Publishers aufrufen Kann ein Drittanbieter Topics mit einem Publisher teilen? Ja, das ist eine mögliche Verwendung von Topics.
Potenzielle Angriffsvektoren Störende Themen identifizieren Aufgrund des Feedbacks vieler Nutzer hat sich Chrome dazu entschieden, Themen zu filtern und Rauschen einzuführen. Diese Entscheidungen wurden im Hinblick auf den Datenschutz getroffen, um den Zugriff auf Informationen auf Personen zu beschränken, die sonst keinen Zugriff auf solche Informationen hätten, und um Nutzern die Möglichkeit zu geben, plausibles Nichtwissen zu beteuern. Uns ist bewusst, dass diese Entscheidungen Nachteile haben, wie z. B. den hier beschriebenen Angriffsvektor. Wir sind jedoch der Ansicht, dass die Vorteile für den Datenschutz die potenziellen Risiken überwiegen. Wir begrüßen eine öffentliche Diskussion über diese Entscheidung.
Voraussetzungen für den Ursprungstest Gibt es eine Möglichkeit, zu erkennen, ob ein Nutzer Anspruch auf einen Origin-Probezeitraum hat? Eine Testfunktion für den Ursprung ist für einen Nutzer möglicherweise aufgrund von Browsereinstellungen oder anderen Faktoren nicht verfügbar, auch wenn er eine Webseite besucht, die ein gültiges Testtoken enthält und sein Browser in der Gruppe enthalten ist, für die das Testabo aktiviert ist.

Aus diesem Grund sollte immer die Funktionserkennung verwendet werden, um zu prüfen, ob eine Testfunktion für den Ursprung verfügbar ist, bevor Sie versuchen, sie zu verwenden.

Auswirkungen auf die Leistung Probleme mit Overhead und Latenz bei Topics Wir bitten um Feedback zu Ansätzen zur Vermeidung teurer und langsamer iframes mit unterschiedlichen Ursprüngen und zum Vorschlag, die Topics API so zu entflechten, dass das Abrufen von Themen den Browserstatus nicht ändert.
Aufteilung der Topics API-Funktionen Mehr Kontrolle über die drei verschiedenen Aspekte der API Wir haben den Anwendungsfall verstanden und eine mögliche Lösung auf GitHub vorgeschlagen. Wir warten derzeit auf weiteres Feedback aus der Community, um zu entscheiden, ob wir die Funktion entwickeln sollen. Hier finden Sie die aktuelle Diskussion.
Zeitleiste und Dokumentation des Klassifikators Entwickler haben weitere Informationen zum Klassifikator angefordert. Hier finden Sie weitere Informationen zum Klassifikator.

sowie hier

Und hier.

Nutzereinstellungen und Sicherheit Bestimmte Themen können für sensible Gruppen stehen und Nutzer benötigen mehr Einstellungen, um negative Folgen zu vermeiden. Themen sind ein wichtiger Schritt in Richtung mehr Nutzerkontrolle und Transparenz. Nutzer können Themen deaktivieren, sich die ihnen zugewiesenen Themen ansehen, Themen entfernen und sehen, welche Unternehmen auf einer bestimmten Seite mit ihren Themen interagieren. Außerdem können Nutzer ihre Themen beeinflussen, indem sie ihren Browserverlauf löschen. Wir begrüßen weitere Diskussionen zu erweiterten Nutzereinstellungen, wie sie von Entwicklern vorgeschlagen wurden. Wir müssen jedoch sicherstellen, dass die Risiken in Bezug auf die in diesem Fehler gemeldeten Bedenken tatsächlich beseitigt werden. Wenn beispielsweise nur das Thema „Studium der Fremdsprache“ entfernt wird, aber nicht die Websites, die das Thema aus dem Browserverlauf generiert haben, ist der Nutzer nicht vollständig geschützt.
Verwendung von Themen auf Websites mit prebid.js Kann die Topics API auf Websites mit prebid.js verwendet werden? Die kurze Antwort lautet: Ja. Weitere Informationen
Verwendung der Topics API in einem Empfehlungs-Widget Kann die Topics API im empfohlenen Widget (z.B. Outbrain) verwendet werden? Wir beschränken den Anwendungsfall der abgerufenen Themen nicht nach dem Aufruf der API. Das hängt von der Datenrichtlinie des jeweiligen Entwicklers ab.
Datenschutz / Richtlinien Fragen zum Zweck der Filterung von Antworten nach Anrufer, ob einige Drittanbieter ihre Themen mit jedem Anrufer teilen. Aufgrund des Feedbacks vieler Nutzer hat Chrome dieses Design ausgewählt, um den Zugriff auf Informationen auf diejenigen zu beschränken, die sonst keinen Zugriff auf solche Informationen hätten. Publisher und Drittanbieter, die Topics erhalten, können natürlich selbst entscheiden, welche Informationen sie mit Dritten auf ihrer Website teilen. Wenn sie diese Art der Freigabe nutzen, werden sie von Chrome dringend aufgefordert, ihren Nutzern gegenüber transparent zu sein und ihnen Einstellungen zur Verfügung zu stellen.
Störsignale Die Auslieferung eines zufälligen Themas in 5% der Fälle kann zu viel Rauschen / falschen Signalen führen. Genau das ist jedoch wichtig zum Schutz der Nutzerdaten. Der Störpegel und der Nutzen der Themen werden in Tests einander gegenübergestellt.

FLEDGE

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Koordination testen Auswirkungen auf Leistung und Umsatz testen Die FLEDGE-Leistung und die Frage, wie wir die Ökosystemtests während der Origin Trials und der allgemeinen Verfügbarkeit am besten unterstützen können, werden in den öffentlichen WICG-Treffen aktiv diskutiert.
Trusted Server für FLEDGE Wann ist der Trusted Server für Tests verfügbar? Wir freuen uns über dieses Feedback und arbeiten aktiv an einem detaillierteren Plan, den wir zur Verwendung vertrauenswürdiger Server in FLEDGE veröffentlichen können.
Protokollstandardisierung Wird es ein gemeinsames Protokoll für die Weitergabe von Daten zwischen SSPs und DSPs geben, z. B. gemeinsame Labels für Interessengruppen? Wir freuen uns über Feedback von DSPs, SSPs und dem gesamten Anzeigensystem zur möglichen Standardisierung der Spezifikation. Für erste Tests empfehlen wir derzeit, direkt mit Ihren Testpartnern zusammenzuarbeiten, da diese gerade mit verschiedenen Ansätzen experimentieren. Wir möchten auch die Werbewirtschaftsverbände dazu ermutigen, sich für eine Standardisierung einzusetzen, falls dies für ihre Mitgliedsunternehmen sinnvoll ist. Wir werden auch weiterhin mit ihnen zusammenarbeiten.
Frequency Capping Einstellungen für die Häufigkeit pro Nutzer innerhalb einer Kampagne und Anzeigengruppe. FLEDGE unterstützt auch das Frequency Capping für On-Device-Auktionen und kontextbezogene / Markenkampagnen. Gemeinsam genutzter Speicherplatz und websitespezifische Limits können auch für zusätzliche Einstellungen für das Frequency Capping verwendet werden.
Auswirkungen von FLEDGE auf die Leistung Rechenintensive Bieter in der FLEDGE-Auktion Das Chrome-Team befindet sich in aktiven Gesprächen mit Entwicklern über die möglichen Auswirkungen auf die Websiteleistung. Das Chrome-Team freut sich über die Möglichkeit, während der Tests mehr zu erfahren.
FLEDGE mit anderen Funktionen testen Wie fügen sich die Berichte auf Ereignisebene der Attribution Reporting API und FLEDGE zusammen? Dieses Thema wurde in einem kürzlichen WICG-/Conversion-Measurement-API-Anruf besprochen. Hier finden Sie einen Link zu den detaillierten Protokollen.

Das aktuelle Design für Berichte zu Anzeigen in abgegrenzten Frames ermöglicht es, eine im abgegrenzten Frame generierte ID mit Kontextinformationen zu verknüpfen. Berichte auf Ereignisebene, die innerhalb des eingegrenzten Frames generiert werden, können daher mit denselben kontextbezogenen Informationen auf dem Server zusammengeführt werden (mit zwei serverseitigen Zusammenführungen anstelle von einer).

Impressionszählung Welche Methode zur Impressionszählung sollte oder könnte zwischen Käufern und Verkäufern verwendet werden Die FLEDGE API unterstützt bereits die Abstimmung der Methodik zwischen Verkäufer und Käufer während der Auktion. Wir haben Vorschläge für alternative Implementierungen erhalten, aber kein Feedback dazu, warum unser aktuelles Design für das System nicht funktioniert.
Mehrere Anzeigen ausliefern Gibt an, ob in einem bestimmten abgegrenzten Frame mehrere Anzeigen in einer Auktion ausgeliefert werden können. Das ist derzeit über Komponentenanzeigen möglich (nicht zu verwechseln mit Komponentenauktionen). Dazu müssen alle Anzeigen in derselben Interessengruppe enthalten sein.
Spezifikation „Seller Defined Audiences (SDA)“ und FLEDGE Könnte FLEDGE ein Mechanismus werden, um zu verhindern, dass Käufer anhand von SDA-Daten aus Anzeigenanfragen Profile erstellen? FLEDGE soll Datenlecks vermeiden, die nicht relevant sind, wenn der Publisher bereits weiß, in welchen SDAs sich seine Besucher befinden und die Ausrichtung auf dieselbe Website erfolgt. Wenn es wichtig ist, Käufe über datengetriebene Anzeigen unter Einhaltung aller in FLEDGE integrierten Schutzmaßnahmen zu unterstützen, kann eine Lösung darin bestehen, dass ein Verkäufer datengetriebene Anzeigenlabels in die On-Device-Auktion weitergibt und eine Käuferseite-Werbetechnologie eine eigene Interessengruppe erstellt, deren Gebotslogik lautet: „Ich möchte Zielgruppe X kaufen“.
Unterstützung anderer Währungen als US-Dollar Unterstützung für FLEDGE-Tests mit anderen Währungen als dem US-Dollar Vielen Dank für diesen Hinweis. Wir haben die Unterstützung für andere Währungen in unseren Backlog mit Featureanfragen aufgenommen. Wir hoffen, dass dies bald möglich sein wird.
Unterstützung für die ausschließende Ausrichtung auf Interessengruppen Eine API zur Unterstützung des ausschließenden Targetings auf Interessengruppen: Anzeigen werden nur ausgeliefert, wenn ein Nutzer keiner Interessengruppe angehört. Laufende Diskussion, einschließlich einiger vorgeschlagener Supportoptionen, im GitHub-Problem.
Mehrere SSPs in FLEDGE Risiko, dass Google bei der Implementierung mehrstufiger Auktionen in FLEDGE begünstigt wird Die Unterstützung mehrerer SSPs in FLEDGE wurde hinzugefügt, um für faire und gerechte Wettbewerbsbedingungen zu sorgen. Google hat sich im Rahmen der Verpflichtungen verpflichtet, die Privacy Sandbox-Vorschläge nicht so zu entwerfen, zu entwickeln oder zu implementieren, dass der Wettbewerb durch eine Bevorzugung der eigenen Werbeprodukte und ‑dienste verzerrt wird. Google nimmt diese Bedenken ernst und ist sehr offen für Gespräche über mögliche Bedenken von Stakeholdern in Bezug auf bestimmte Aspekte der Technologie. Der Auktionsmechanismus für Komponenten ist in Chrome öffentlich dokumentiert.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Multi-Touchpoint-Attribution Publisher, die Unterstützung für die Multi-Touch-Attribution anfordern Bei den aktuellen Methoden der Multi-Touch-Attribution müssen die Impressionen (und damit die Identität) eines Nutzers auf verschiedenen Websites deterministisch verknüpft werden. Daher entspricht diese Funktion in ihrer aktuellen Form nicht den Zielen der Privacy Sandbox, die wichtige Anwendungsfälle für Werbung ohne websiteübergreifendes Tracking unterstützen soll. In einigen Fällen ist es möglich, die Zuordnung von Gutschriften zu approximieren (z.B. durch gewichtete, zufällige Prioritäten), ohne einzelne Nutzer zu erfassen.
Rauscherzeugung Fragen zu den Geräuschpegeln in den Berichten In unserem ersten Test können Entwickler ihren eigenen Epsilonwert festlegen, um zu sehen, wie sich die Berichte je nach Rauschen ändern. Derzeit können Entwickler einen Epsilonwert bis zu epsilon=64 auswählen. Wir haben dies speziell getan, um es Entwicklern zu erleichtern, die APIs zu testen und uns Feedback zu geeigneten Epsilonwerten zu geben.

Wir haben auch öffentlich um Feedback gebeten.

Koordination testen Kann das Tool für lokale Tests für die OT verwendet werden? Ja, das Tool für lokale Tests kann während der gesamten OT verwendet werden. Das Tool für lokale Tests kann mit Debugberichten verwendet werden, solange Drittanbieter-Cookies verfügbar sind.
Ergonomie von Abfragen Abfrage von Schlüsselaggregaten aktivieren Wir stimmen zu, dass dies die API-Ergonomie mit wenig bis gar keinen offensichtlichen Datenschutzkosten zu verbessern scheint. Wir werden einen Vorschlag machen und prüfen, ob es einen breiten Konsens darüber gibt, dass er unterstützt werden sollte.
Weniger genaue Daten für kleine Websites Bei kleineren Websites oder Kampagnen sind die Daten möglicherweise weniger genau. Chrome erkennt, dass datenschutzfreundliche Maßnahmen, die auf Rauschen basieren, bei kleineren Datenmengen stärkere Auswirkungen haben. Es ist jedoch möglich, dass Methoden wie die Aggregation über einen längeren Zeitraum dieses Problem lösen würden. Außerdem ist unklar, ob die Schlussfolgerungen, die auf sehr kleinen Datenmengen (z. B. ein oder zwei Käufe) basieren, für Werbetreibende aussagekräftig sind. Während des Ursprungstests können Chrome-Tester mit einer Vielzahl von Datenschutz- und Rauschparametern experimentieren, um genaueres Feedback zu diesem Problem zu geben.

Verdecktes Tracking einschränken

Reduzierung des User-Agents

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Bot-Schutz Auswirkungen von UA-R auf den Botschutz Wir freuen uns über dieses Feedback und sammeln derzeit Informationen zu Ansätzen für den Botschutz, die wir in unsere zukünftigen Designs einfließen lassen.
Bereitstellungsabhängigkeiten Bereitstellungsabhängigkeiten für strukturierte User-Agents (SUA) beheben Wir haben Phase 4 eingeführt, d. h. die Reduzierung der Nebenversion auf 100% der Chrome-Nutzer in den Versionen 101 und höher. Weitere Informationen

User-Agent-Client-Hints

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Alle unterstützten Hinweise auflisten Interesse an einer programmatischen Möglichkeit, alle unterstützten Hinweise für einen Browser zu ermitteln. Vielen Dank für dein Feedback. Wir prüfen derzeit die Funktion. Wir möchten wissen, ob dies ein häufiger Anwendungsfall ist.
Flexibilität von UA-CH im Vergleich zum User-Agent-Header UA-CH ist im Vergleich zur Flexibilität des User-Agent-Headers, wie in RFC 7231 definiert, zu normativ. Chrome betrachtet die präskriptive Natur von UA-CH-Headern als wichtige Verbesserung gegenüber der Flexibilität des UA-Strings, sowohl im Hinblick auf die geräteübergreifende Interoperabilität als auch auf den Datenschutz der Nutzer (durch Verhinderung von willkürlichen Zusätzen von High-Entropy-IDs).

Das Problem bleibt offen, falls andere Nutzer diese Bedenken teilen und Feedback geben möchten.

UA-CH: Bedenken hinsichtlich Betrugs-/Missbrauchsprävention Bestimmte Funktionen, die bei UA-CH möglicherweise nicht mehr verfügbar sind: Klickweiterleitungs-Tracker und betrügerische Klicks. Das Team untersucht diese potenziellen Probleme gemeinsam mit den zuständigen Mitarbeitern für Betrugsprävention und Analysen.
Leistung Es gibt Bedenken hinsichtlich der Latenz beim Empfangen von Hinweisen über Critical-CH (beim ersten Laden der Seite). Wir arbeiten an Möglichkeiten, die Leistung von Chrome zu verbessern.

Mückenfänger (WIP)

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Bedenken hinsichtlich der Latenz Das Hinzufügen zusätzlicher Hops kann sich auf die Latenz auswirken Wir prüfen einen Proxy mit zwei Hops und suchen nach Möglichkeiten, das richtige Gleichgewicht zwischen Datenschutz und Latenz zu finden. Wir freuen uns über Feedback und würden uns über weitere Diskussionen in den W3C-Foren freuen.
Schutz vor Betrug und Bots Auswirkungen auf den Betrugs- und Botschutz, auch in weniger entwickelten Ländern Sicherheit ist eine zentrale Anforderung, wenn wir nach Möglichkeiten suchen, den Datenschutz für Nutzer auf sinnvolle Weise zu verbessern, z. B. durch Proxy-IP-Adressen. Ein Two-Hop-Proxy in Zusammenarbeit mit seriösen Unternehmen bietet nachweisbaren Datenschutz für Nutzer. Außerdem arbeiten wir an neuen Signalen, die das Vertrauen der Nutzer stärken sollen.
Einhaltung lokaler Datenschutzgesetze Die Berichterstellung zu geografischen Daten auf Länderebene erschwert die Einhaltung detaillierterer lokaler Bestimmungen Wir haben unsere vorgeschlagenen Grundsätze veröffentlicht. Darin finden Sie auch mögliche Ansätze, mit denen Websites die lokalen Anforderungen weiterhin erfüllen können.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Nützlichkeit für verschiedene Arten von Stakeholdern Auswirkungen von FPS für kleine und große Publisher Das primäre Ziel der Privacy Sandbox besteht darin, den Datenschutz für Nutzer zu verbessern, indem aktuelle Praktiken durch Lösungen ersetzt werden, die nicht auf websiteübergreifenden Tracking-Mechanismen basieren. Wir möchten, dass diese Lösungen für verschiedene Arten und Größen von Stakeholdern möglichst breit nutzbar sind. Wir freuen uns über konkrete, umsetzbare Vorschläge, wie diese Lösungen verbessert werden können. Wir gehen davon aus, dass sie sich durch Diskussionen und Tests in der Community weiterentwickeln werden.
Besseres Datenschutzniveau Zu viele Websites in einem Set können zu ähnlichen Ergebnissen wie Drittanbieter-Cookies führen. Wir freuen uns über dieses Feedback und prüfen, ob und welche Limits sinnvoll wären. Außerdem möchten wir sowohl Nutzern als auch Entwicklern Hinweise geben, damit sie erkennen können, wenn ein solches Limit erreicht wird. Wir haben noch keinen konkreten Vorschlag, hoffen aber, bald einen machen zu können.
Unterstützung von FPS-Systemen Unterstützung und Bedenken zur weiteren Entwicklung von FPS außerhalb des Datenschutz-Centers Wir hätten es zwar vorgezogen, wenn der Vorschlag für Sets mit selbst erhobenen Daten in der PrivacyCG geblieben wäre, freuen uns aber, ihn im WICG weiterverfolgen zu können. Wir haben uns auch über die zahlreichen positiven Reaktionen auf die weitere Diskussion über Sets mit selbst erhobenen Daten und die Anwendungsfälle gefreut, für die sie gedacht sind. Google ist bestrebt, Lösungen zu finden, mit denen das Web weiter wachsen und gedeihen kann, wobei der Datenschutz der Nutzer geschützt und respektiert wird.
Browser-Interoperabilität Implementierung durch andere Browser Uns ist bewusst, wie wichtig die Interoperabilität von Browsern für Entwickler ist. Wir werden daher auch weiterhin mit anderen Browsern zusammenarbeiten, um die FPS zu standardisieren.
Gemeinsame Anforderung an die Datenschutzerklärung Es ist nicht möglich, eine gemeinsame Datenschutzerklärung für alle Produkte und Gerichtsbarkeiten zu pflegen, die Teil desselben Sets sein müssen. Wir arbeiten derzeit noch an unseren Richtlinienanforderungen für Chrome und werden dieses Feedback berücksichtigen.

Fenced Frames API

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Anforderung an die Dokumentation Unterschiede zu iFrames in Sandboxes Vielen Dank für dein Feedback und deine Vorschläge. Derzeit wird das Thema auf GitHub diskutiert. Wir hoffen, dass wir dort endgültige Klarheit über die Anfrage erhalten, um sie dann vollständig bewerten zu können. Die öffentliche Diskussion finden Sie hier.
API-übergreifende Funktionen Standardmäßige Unterstützung für Attributionsberichte in abgegrenzten Frames Wir bitten um Feedback zu einem Vorschlag, die Attribution Reporting API standardmäßig im Modus „Opaque-Anzeigen“ für abgegrenzte Frames zuzulassen. Wir möchten Entwickler, die diese Funktion für nützlich halten, dazu ermutigen, sich an der Diskussion zu beteiligen.

Shared Storage API

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Datenlimits Gibt es eine Beschränkung für die Menge der Daten, die pro Partition gespeichert werden können? Ja, es gibt Einschränkungen. Weitere Informationen finden Sie im GitHub-Problem. Wir benötigen Speicherkontingente. Derzeit schlagen wir eine Obergrenze von 4 KB pro Eintrag vor. Sowohl Schlüssel als auch Werte sind auf jeweils 1.024 char16_t-Zeichen beschränkt. Außerdem wird die Anzahl der Einträge pro Ursprung auf 10.000 Einträge begrenzt. Ein Mechanismus verhindert, dass zusätzliche Einträge verbindlich festgelegt werden, wenn die Kapazität eines Ursprungs voll ist. Wir sind auf Feedback zu den hier vorgeschlagenen Limits angewiesen.
Transparenz für Nutzer Transparenz für Nutzer in Bezug auf Datenquellen und Datennutzung Vielen Dank für dein Feedback. Wir sind der Meinung, dass dies ein vielversprechender Ansatz ist, den es zu untersuchen gilt. Insbesondere prüfen wir, ob dies auf eine Weise möglich ist, die Nutzern ausreichend Transparenz bietet.

CHIPS

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Hindernisse für die Akzeptanz Sollten CHIPS an einen Hostnamen gebunden sein? (Anforderungen ohne Domain) Wir entfernen diese Anforderung aus dem OT, da Teilnehmer des OT uns mitgeteilt haben, dass sie die Implementierung von CHIPS erschwert und behindert.

Wir werden diese Anforderung in der Privacy Community Group im Rahmen der Standardsentwicklung hier besprechen.

Anwendungsfälle für Google Ads mit CHIPS Kann CHIPS für Google Ads-Anwendungsfälle auf einer einzelnen Website verwendet werden? Das Nutzer-Tracking innerhalb einer Website ist ein zulässiger Anwendungsfall. Wir haben unseren Entwicklerartikel aktualisiert, um diesen Anwendungsfall hervorzuheben.
Authentifizierte Einbettungen Wird der Anmeldestatus mit CHIPS beibehalten? Der Anmeldestatus wird derzeit nicht beibehalten. Dies ist jedoch nicht der beabsichtigte Anwendungsfall für CHIPS. Uns ist der Anwendungsfall für authentifizierte Einbettungen bekannt und wir arbeiten an Lösungen.
Koordination testen Müssen Nutzer zusätzliche Aktionen ausführen, um die Partitionierung zu testen? Solange das OT-Token gültig ist und in den Headern der besuchten Seiten vorhanden ist, sollte die Funktion für Nutzer verfügbar sein, ohne dass zusätzliche Nutzeraktionen erforderlich sind.
Browserkompatibilität Interesse daran, wie andere Browser mit partitionierten Cookie-Attributen umgegangen sind. Chrome arbeitet weiterhin mit öffentlichen Standardsgruppen wie dem W3C zusammen, um Designs und Implementierungen zu identifizieren, die plattformübergreifend funktionieren.

FedCM

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Potenzielle Angriffsvektoren Potenzielle Angriffsvektoren über Link-Dekoration und Timing-Angriffe Wir sammeln aktiv Feedback von Nutzern und prüfen mögliche Lösungen für dieses Problem.
UX, die mehrere IDPs zulässt Es kann jeweils nur eine IDP-Anfrage gesendet werden. Wir sind der Meinung, dass mehrere Identitätsanbieter unterstützt werden sollten, und arbeiten aktiv an Lösungen,
Ausdruckskraft Bedenken, dass es aufgrund der Tatsache, dass der Browser einen Teil des Ablaufs der föderierten Identität rendert, schwierig ist, alle Nuancen zu erfassen, die Identitätsanbieter ihren Nutzern präsentieren möchten. In Chrome wird derzeit geprüft, ob Branding-Anpassungen (z.B. Logos, Farben) und String-Anpassungen (z.B. „auf diesen Artikel zugreifen“ anstelle von „mit anmelden“) möglich sein sollen.

Chrome ist sich des Trade-offs bewusst und wird weiterhin mit dem Ökosystem zusammenarbeiten, um sowohl möglichst viele Bereiche abzudecken als auch möglichst ausdrucksstark zu sein.

Anwendbarkeit und Interoperabilität Bedenken, dass andere Browser FedCM nicht übernehmen oder implementieren werden Chrome arbeitet auch mit anderen Browseranbietern zusammen, um gemeinsame Lösungen für die Föderierung in der FedID Community Group zu finden.
Vorschlag, Anforderungen an personenbezogene Daten bei der Registrierung zu entfernen (1) Eine UX, die dem Nutzer mitteilt, welchen Identitätsanbieter er auswählt, ohne ihm zu signalisieren, dass seine E-Mail-Adresse, sein Bild und sein Name weitergegeben werden, wäre datenschutzfreundlicher.

(2) Die Nutzerfreundlichkeit und die Auswahl der Ansprüche des Identitätsanbieters bei der Registrierung sind dürftig.

Wir sind uns einig und prüfen, wie wir das Feedback nutzerfreundlicher und datenschutzfreundlicher umsetzen können.
Nutzerinteraktion mit dem Identitätsanbieter Direkte Interaktion zwischen Nutzer und Identitätsanbieter erforderlich, wenn ein Risikogrenzwert überschritten wird Wir prüfen dieses Feedback derzeit.

Partitionierung des Netzwerkstatus

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Leistung Die Partitionierung des Netzwerkstatus kann zu einer Erhöhung der ressourcenintensiven Verbindungen zu CDNs führen Wir untersuchen noch die Leistungsmerkmale der Partitionierung des Netzwerkstatus, einschließlich der Messung verschiedener möglicher Verschlüsselungsschemata. Wir haben noch keine Entscheidung zwischen den Abwägungen von Leistung, Sicherheit und Datenschutz getroffen und müssen noch mehr Daten erheben.

Spam und Betrug bekämpfen

Trust Tokens API

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Feedback zu rechtlichen Bestimmungen Bedenken, Zeit und Ressourcen in Trust Tokens zu investieren, ohne klare Signale von Regulierungsbehörden zur langfristigen Rentabilität Unser Ziel ist es, eine Technologie zu entwickeln, die für das gesamte System funktioniert. Daher ist Feedback von der Branche und von Regulierungsbehörden für uns von entscheidender Bedeutung. Wir werden uns bei der Entwicklung der Privacy Sandbox weiterhin mit Regulierungsbehörden auf der ganzen Welt beraten und die Vorschläge, einschließlich Trust Tokens, für Entwickler verfügbar machen. Wie bei allen neuen Technologien sollten Unternehmen Entscheidungen auf der Grundlage ihrer eigenen Bewertung der rechtlichen Anforderungen treffen.
Einführungszeitpunkt Wann werden Trust Tokens in GA eingeführt? Aktuelle Schätzungen zur Bereitstellung finden Sie in unserer öffentlichen Zeitleiste auf privacysandbox.com. Sobald wir eine endgültige Entscheidung über das Bereitstellungsdatum für die allgemeine Verfügbarkeit getroffen haben, veröffentlichen wir es über die Release-Prozesse von Chrome und aktualisieren die Zeitleiste auf der Website.
Trust Tokens im Vergleich zu anderen Welche Rolle spielen Trust Tokens im Vergleich zu anderen Token, die derzeit standardisiert werden, z. B. Private Access Tokens? Wir nehmen an Standardisierungsgesprächen teil und unser Ziel ist es, uns so weit wie möglich an anderen Bemühungen auszurichten und gleichzeitig die verschiedenen Anwendungsfälle zu ermöglichen, die jede Technologie bietet. So basieren beispielsweise Trust Tokens und Private Access Tokens auf dem Privacy Pass-Protokoll.
Datenlimits Maximal zwei Aussteller für die Tokeneinlösung pro Seite, was potenziell eine Einschränkung darstellt Wir suchen nach langfristigen Optionen, mit denen Unternehmen sicher Tokens einlösen können, ohne die Entropie der Nutzer zu erhöhen, z. B. durch eine Partitionierung des Zugriffs auf die Tokeneinlösung.
Zugriffsbeschränkungen Nur genehmigte (und bestätigte/nicht gefälschte Verweisquellen) sollten das Vorhandensein eines Tokens prüfen und es einlösen können. Wir prüfen derzeit, wer Tokens sehen und einlösen kann.
Geräteunterstützung JavaScript-Laufzeitabhängigkeiten beschränken die Nutzung auf bestimmten Geräten. Kann der TT-Support auf andere Gerätetypen ausgeweitet werden? Das ist etwas, das wir für die zukünftige Entwicklung in Betracht ziehen könnten. Wir würden uns sehr über Feedback von Entwicklern in den W3C-Foren zu diesem Thema freuen. Außerdem haben wir ein offenes Problem zur Diskussion einer über einen HTTP-Header ausgelösten Tokeneinlösung. Wir freuen uns über Feedback.
Anwendungsfälle Unklar, was die richtigen Anwendungsfälle für Trust Tokens sind. Unklarheit über die beabsichtigten Verwendungen. Unser Ziel ist es, Innovationen im Bereich der Betrugsprävention zu fördern. Wir sind uns bewusst, dass jedes Unternehmen eigene Verfahren mit Trust Tokens verwenden kann. Deshalb haben wir keine Vorgaben hinsichtlich der beabsichtigten Verwendung gemacht. Wir werden unsere Dokumentation jedoch wahrscheinlich um weitere Beispiele ergänzen, die Partnern als Ausgangspunkt dienen können, die Tests oder die Einführung von Conversions in Betracht ziehen.
Abdeckung durch Trust Tokens Durch das Entfernen dieser Feature-Richtlinie für das Vertrauenstoken sollte die Abdeckung des Vertrauenstokens deutlich erhöht werden. Wir berücksichtigen dies, wenn wir Feedback von der OT einholen und Entscheidungen über die nächsten Schritte treffen.
Aussteller-Trust Warum sollten wir Websites vertrauen, die Trust-Tokens ausgestellt haben? Es gibt keine Richtlinien für die Zulassung als Aussteller – jeder kann es werden. Es wird davon ausgegangen, dass die Publisher nur mit vertrauenswürdigen Ausstellern zusammenarbeiten. Außerdem würden andere legitime Akteure im Anzeigensystem mit der Zeit den Traffic von verdächtigen oder unbekannten Ausstellern diskreditieren oder nicht mehr kaufen.
Eingebettete Dienste von Drittanbietern Können von Drittanbietern eingebettete Dienste Trust Tokens einlösen und/oder anfordern? Ja, ein eingebetteter Drittanbieterdienst kann Trust Tokens ausstellen und einlösen.
Ausstellernetzwerk Wenn Vertrauenssignale mit anderen Unternehmen geteilt werden können, ist die Nutzung noch effektiver. Trust Tokens sind als Low-Level-Primitive konzipiert und können von kooperierenden Ausstellern/Inhabern verwendet werden, um Vertrauens-/Reputationssignale zu teilen.
Wartungsaufwand Die kryptografische Implementierung, die Trust Token-Vorgängen zugrunde liegt, befindet sich in BoringSSL, das von Google allein verwaltet wird. Wie wird die Wartung der Bibliothek verwaltet? Trust Tokens basieren auf standardisierten kryptografischen Operationen (siehe Privacy Pass-Protokoll), die auch in anderen Bibliotheken implementiert werden können. Wir empfehlen Entwicklern, Unterstützung für diese Vorgänge in den Bibliotheken ihrer Wahl anzufordern, zu entwickeln und zu pflegen.
Wartungsaufwand Es ist nicht klar, wie lange Protokollversionen unterstützt werden Wir arbeiten daran, genauere Informationen zu den voraussichtlichen Zeiträumen für die Unterstützung von Protokollversionen zu entwickeln und zu dokumentieren.
Limits des Kartenausstellers Wenn Sie weiter unten in der Kette stehen, haben Sie möglicherweise keine Möglichkeit, Trust Tokens auszuführen. Da immer mehr Organisationen Trust-Tokens verwenden, werden wir diese Art von Zeitabweichungen möglicherweise häufiger sehen. Wir prüfen derzeit mögliche Lösungen. Wie bereits erwähnt, suchen wir nach langfristigen Optionen, mit denen Unternehmen Tokens sicher einlösen können, ohne die Entropie der Nutzer zu erhöhen. Dadurch wird die Bedeutung der Position auf der Seite oder der Ladereihenfolge minimiert.

Neue Lösungen zur Betrugsprävention in der Entwicklungsphase

Feedbackthema

(Rangfolge nach Prävalenz)

Zusammenfassung der Fragen und Bedenken Chrome-Antwort
Signale zur Attestierung der Geräteintegrität Allgemeine Unterstützung für die Suche nach Geräteintegritätssignalen, die von Plattformen bestätigt und für das Web verfügbar gemacht werden Wir werden weiterhin Feedback einholen und den Vorschlag durch öffentliches Design und Iteration vorantreiben.
Signale zur Attestierung der Geräteintegrität Es wurden Fragen gestellt, wie viel Nutzerentropie durch neue Signale vermittelt werden kann und ob bestimmte Anwendungsfälle (z. B. wenn sich ein Nutzer bei seiner Bank anmeldet) höhere Entropiesignale rechtfertigen könnten. Wir neigen dazu, wertvolle Signale mit möglichst wenig Nutzerentropie bereitzustellen, um den Datenschutz der Nutzer zu wahren.
Signale zur Attestierung der Geräteintegrität Würde dieses Signal den Zugriff für ältere Geräte oder Open-Source-/modifizierte Plattformen einschränken? Bei allen neuen Signalen sollte der universelle Zugang ein wichtiges Prinzip bei der Entwicklung sein. Diese Fragen sollten wir uns vorab stellen, während wir die Entwicklung fortsetzen.
Signale zur Attestierung der Geräteintegrität Es gab einige Bedenken, dass neue Signale dazu führen könnten, dass Sicherheits- und Betrugspräventionsunternehmen zu sehr auf den Browser und die Plattformen angewiesen sind.

Alle neuen Signale sollten als ergänzende Daten betrachtet werden und nicht als Hinweis auf das „Vertrauen“ des Browsers. Wir gehen davon aus, dass Sicherheitsunternehmen weiterhin auf ihre eigenen Daten, Modelle und Entscheidungsmechanismen mit Geräteattestierung als zusätzlichem Eingabewert setzen werden. Wir hoffen, dass jedes neue Signal die Erkennungsbemühungen im gesamten System verbessern und Betrug erschweren wird.
Signal zum Alter des Cookies Interessantes Konzept, erfordert aber wahrscheinlich weitere Untersuchungen zu anwendbaren Anwendungsfällen. Je nach Interesse kann das Chrome-Team weitere Ideen zu diesem Konzept entwickeln und es in eine Erläuterung für zukünftiges Feedback zum ChromeOS-System einbinden.
Trusted Servers für Betrugsprävention Interessantes Konzept, erfordert aber wahrscheinlich weitere Untersuchungen zu anwendbaren Anwendungsfällen. Je nach Interesse kann das Chrome-Team weitere Ideen zu diesem Konzept entwickeln und es in eine Erläuterung für zukünftiges Feedback zum ChromeOS-System einbinden.