Vierteljährlicher Bericht für das 2. Quartal 2022 mit einer Zusammenfassung des Feedbacks aus der Community zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.
Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google bereit erklärt, vierteljährliche Berichte über den Prozess der Einbeziehung der Stakeholder im Rahmen seiner Privacy Sandbox-Vorschläge zu veröffentlichen (siehe Abschnitte 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch eine Zusammenfassung des Feedbacks von Chrome aus den verschiedenen Quellen generiert, die in der Feedbackübersicht aufgeführt sind. Dazu gehören unter anderem: GitHub Issues, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Community und sucht aktiv nach Möglichkeiten, die gewonnenen Erkenntnisse in Designentscheidungen einfließen zu lassen.
Feedbackthemen sind nach Verbreitung pro API geordnet. Dazu wird eine Zusammenfassung des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, in absteigender Reihenfolge sortiert. Die gemeinsamen Feedbackthemen wurden ermittelt, indem Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen, die über interne Teams und öffentliche Formulare von Google gestellt wurden, überprüft wurden.
Genauer gesagt wurden die Gesprächsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, E-Mails, die von einzelnen Entwicklern eingegangen sind, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Anschließend koordinierte Google die Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, um die relative Verbreitung der Themen zu ermitteln, die in Bezug auf die einzelnen APIs entstehen.
Die Erklärungen zu den Reaktionen von Chrome auf Feedback basieren auf veröffentlichten häufig gestellten Fragen, aus tatsächlichen Antworten auf von Stakeholdern geäußerte Probleme und aus der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts von Entwicklung und Tests wurden Fragen und Feedback insbesondere zu Topics, Fledge und Attribution Reporting APIs erhalten.
Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingeht, hat möglicherweise noch keine Antwort von Chrome als Antwort erhalten.
Glossar der Akronyme
- CHIPS
- Cookies mit unabhängig partitioniertem 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
- ÜS
- Ursprungstest
- PatCG
- Private Advertising Technology Community Group
- RP
- Verlassende 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
- Vorsätzliche IP-Blindheit
Allgemeines Feedback, keine spezifische API/Technologie
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Präzisere Zeitpläne | Klarere und detailliertere Veröffentlichungspläne für die Privacy Sandbox-Technologien. | Wir haben unsere aktuellen Pläne für den Bereitstellungszeitplan unter privacysandbox.com festgelegt und monatlich aktualisiert. Dabei wird die Entwicklungszeit von Chrome- und Webentwicklern berücksichtigt sowie das Feedback, das wir von der gesamten Plattform erhalten haben, und berücksichtigen den zeitlichen Aufwand zum Testen und Einführen der neuen Technologien. Jede Technologie durchläuft mehrere Schritte vom Testen bis zur Veröffentlichung (Markteinführung). Das Timing jedes Schritts richtet sich nach dem, was wir im vorherigen Schritt gelernt und herausgefunden haben. Auch wenn wir derzeit noch keine verbindlichen Releases haben, werden wir unseren öffentlichen Zeitplan unter privacysandbox.com aktualisieren. |
| Nützlichkeit für verschiedene Arten von Stakeholdern | Bedenken, dass die Privacy Sandbox-Technologien größere Entwickler bevorzugen und dass Nischenwebsites (kleinere Websites) einen höheren Beitrag leisten als generische (größere) Websites. | Uns ist bewusst, dass einige Entwickler Bedenken bezüglich der Auswirkungen der Privacy Sandbox-Technologien haben. Google hat sich der CMA verpflichtet, die Privacy Sandbox-Angebote nicht so zu gestalten oder zu implementieren, dass der Wettbewerb dadurch verzerrt wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem werden die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende sowie deren Auswirkungen auf den Datenschutz und die Nutzererfahrung berücksichtigt. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird.
Im Zuge der Tests der Privacy Sandbox ist eine der wichtigsten Fragen, die wir bewerten, die Leistung der neuen Technologien für verschiedene Arten von Interessenvertretern. Feedback ist dabei von entscheidender Bedeutung, insbesondere spezifisches und umsetzbares Feedback, das uns helfen kann, die technischen Designs weiter zu verbessern. |
| Fristen für die Einstellung von Drittanbieter-Cookies | Anfragen zur Vermeidung weiterer Verzögerungen bei der Einstellung von Drittanbieter-Cookies | Einige Interessenvertreter haben uns mitgeteilt, dass Chrome mit der Einstellung von Drittanbieter-Cookies ohne Verzögerung fortfahren soll, und andere, die der Meinung sind, dass mehr Zeit zum Testen und Einführen der Privacy Sandbox-Technologien erforderlich ist. Angesichts der Komplexität der Technologien und der Bedeutung, die es für die Plattform so wichtig ist, alles richtig machen zu können, haben wir uns verpflichtet, verantwortungsvoll vorzugehen. Feedback aus der Branche und von Regulierungsbehörden war entscheidend für diesen Prozess. |
| Fristen für die Einstellung von Drittanbieter-Cookies | Anfragen, um die Einstellung von Drittanbieter-Cookies zu verzögern und mehr Zeit zum Testen der APIs zu haben. | Einige Interessenvertreter haben uns mitgeteilt, dass Chrome mit der Einstellung von Drittanbieter-Cookies ohne Verzögerung fortfahren soll, und andere, die der Meinung sind, dass mehr Zeit zum Testen und Einführen der Privacy Sandbox-Technologien erforderlich ist. Angesichts der Komplexität der Technologien und der Bedeutung, die es für die Plattform so wichtig ist, alles richtig machen zu können, haben wir uns verpflichtet, verantwortungsvoll vorzugehen. Feedback aus der Branche und von Regulierungsbehörden war entscheidend für diesen Prozess. |
| Dokumentationsanfragen | Anfragen nach weiteren Ressourcen zur Verwaltung von Tests, Analysen und Implementierungen. | Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden, und sind bestrebt, in den kommenden Wochen und Monaten weitere Informationen wie etwa Office Hours für Entwickler und technische Dokumentationen zur Verfügung zu stellen, damit Entwickler besser nachvollziehen können, wie sie von den neuen Technologien profitieren können.
Außerdem haben wir öffentliche Office Hours von externen Entwicklern abgehalten, um Best Practices und Demos zu teilen, sowie Fragerunden mit Fachleuten aus dem Produkt- und Entwicklungsteam, um Live-Diskussionen und -Fragen zu ermöglichen. |
| Branchenkenntnisse | Dem Chrome-Team, das mit Normungsgremien zusammenarbeitet, fehlt es an Fachwissen über das Anzeigensystem, das notwendig ist, um ein gutes Gleichgewicht zwischen Datenschutz und Nutzen herzustellen. | Wir sind uns bewusst, dass wir eine große Verantwortung tragen, und sind daher auf konkretes Feedback angewiesen, um diese Ziele zu erreichen. Außerdem betrachten wir sowohl Datenschutz als auch Effektivität als entscheidende und notwendige Designkriterien. Das Team, das an der Privacy Sandbox für das Web arbeitet, liegt insgesamt im Bereich der Hunderten Jahre, die im Werbesystem gearbeitet haben. |
Relevante Inhalte und Werbung zeigen
Themen
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Nützlichkeit für verschiedene Arten von Stakeholdern | Es gibt Bedenken hinsichtlich der Wertschaffung und Verteilung dieses Werts für Websites, abhängig von der Anzahl der Zugriffe oder der spezialisierten Inhalte der Websites. | Die Nützlichkeit der API wird durch Tests erforscht. Chrome geht davon aus, dass sich die Taxonomie und andere Parameter basierend auf den Testergebnissen weiterentwickeln werden. Für die Weiterentwicklung der Taxonomie oder der Parameter sind keine abwärtsinkompatiblen Änderungen erforderlich. Außerdem geht Chrome davon aus, dass sich das Feedback auch nach der Einstellung von Drittanbieter-Cookies auf die Weiterentwicklung der Topics API auswirken wird. |
| Taxonomie | Die Stakeholder der Branche möchten die Taxonomie mitbestimmen. | Chrome bleibt offen für Eingaben in der Taxonomie. Chrome ist sehr an Feedback zum Governance-Modell für die Änderung der Taxonomie interessiert. Außerdem wird diskutiert, wie andere Branchenverbände langfristig eine aktivere Rolle bei der Entwicklung und Verwaltung der Taxonomie spielen können. |
| Nicht genügend Browserverlauf vorhanden | Vorschlag zur Anzeige von Themen, die der Anrufer in den vergangenen Wochen angesehen hat, wenn der Browserverlauf nicht ausreicht, um fünf Themen für die letzte Woche zu erstellen | Für unser aktuelles Design werden sie nach dem Zufallsprinzip ausgewählt. Wir werden die Korrelation mit früheren Themen untersuchen und überlegen, ob es eine Möglichkeit gibt, dies zu berücksichtigen. Bei Korrelationen können jedoch nachteilige Datenschutzaspekte berücksichtigt werden. |
| Topics im Namen eines Publishers aufrufen | Kann ein Drittanbieter Themen für einen Publisher freigeben? | Ja, das ist eine Art und Weise, wie wir die Topics API verwenden werden. |
| Potenzielle Angriffsvektoren | Rauschende Themen identifizieren | Auf der Grundlage des Feedbacks vieler Nutzer aus der Plattform wurden Themen gefiltert und Störfaktoren hinzugefügt. Diese Entscheidungen wurden unter Berücksichtigung des Datenschutzes getroffen: Der Zugriff auf Informationen wurde auf diejenigen beschränkt, die sonst keinen Zugriff auf solche Informationen gehabt hätten, bzw. um eine plausible Leugnung für Nutzer einzuführen. Diese Entscheidungen haben Nachteile, wie z. B. der hier beschriebene Angriffsvektor. Wir sind jedoch der Ansicht, dass die Vorteile des Datenschutzes die potenziellen Risiken überwiegen. Wir freuen uns über eine öffentliche Diskussion zu dieser Entscheidung. |
| Voraussetzungen für einen Ursprungstest | Gibt es eine Möglichkeit herauszufinden, ob ein Nutzer die Voraussetzungen für einen Ursprungstest erfüllt? | Die Funktion eines Ursprungstests ist für Nutzer aufgrund von Browsereinstellungen oder anderen Faktoren möglicherweise nicht verfügbar, selbst wenn der Nutzer eine Webseite mit einem gültigen Testtoken besucht und sein Browser in der Gruppe enthalten ist, für die der Test aktiviert ist.
Daher sollte immer die Funktionserkennung verwendet werden, um zu prüfen, ob eine Funktion für einen Ursprungstest verfügbar ist, bevor Sie sie verwenden. |
| Auswirkungen auf die Leistung | Aufwand und Latenzprobleme bei Topics | Wir bitten Feedback zu Ansätzen, mit denen teure und langsame iFrames mit ursprungsübergreifender Nutzung vermieden werden können, und den Vorschlag, die Topics API zu entschlüsseln, damit die Themen den Browserstatus nicht ändern. |
| Funktionen der Split Topics API | Mehr Kontrolle über die drei verschiedenen Aspekte der API | Wir verstehen den Anwendungsfall und haben eine mögliche Lösung in GitHub vorgeschlagen. Wir warten derzeit noch auf weiteres Feedback vonseiten des Ökosystems zur Entwicklung dieser Funktion. Die laufende Diskussion finden Sie hier. |
| Zeitlicher Ablauf und Dokumentation des Klassifikators | Entwickler haben weitere Informationen zum Klassifikator angefordert. | Weitere Informationen zum Klassifikator
sowie hier und hier. |
| Steuerelemente und Sicherheit für Nutzer | Bestimmte Themen können als Anhaltspunkte für sensible Gruppen dienen und Nutzer benötigen mehr Kontrollen, um negative Ergebnisse zu verhindern. | Themen stellen einen bedeutenden Schritt nach vorn für mehr Kontrolle und Transparenz dar. Nutzer können Themen deaktivieren, die ihnen zugewiesenen Themen überprüfen, Themen entfernen und sehen, welche Unternehmen mit ihren Themen auf einer bestimmten Seite interagieren. Außerdem können Nutzer ihre Topics API anpassen, indem sie ihren Browserverlauf löschen. Wir begrüßen weitere Diskussionen über erweiterte Nutzersteuerungen, wie sie von Entwicklern vorgeschlagen werden. Wir müssen jedoch sicherstellen, dass die in diesem Fehler geäußerten Bedenken tatsächlich beseitigt werden. So wird beispielsweise nur das Thema "Fremdsprachenstudien" entfernt, aber nicht die Websites, die das Thema aus dem Browserverlauf generiert haben, den Nutzer nicht vollständig schützen. |
| Themen auf Websites mit prebid.js | Kann die Topics API auf Websites mit prebid.js verwendet werden? | Die kurze Antwort lautet „Ja“. Weitere Informationen |
| Topics API in einem Empfehlungs-Widget verwenden | Können wir die Topics API im Widget „Empfohlen“ verwenden (z.B. Outbrain) | Der Anwendungsfall von abgerufenen Themen nach dem Aufruf der API wird nicht eingeschränkt (dies hängt von der Datenrichtlinie des jeweiligen Entwicklers ab). |
| Datenschutzbestimmungen | Fragen zum Zweck des Filterns von Antworten nach Anrufer, wenn Dritte ihre Themen mit jedem Anrufer teilen | Basierend auf dem Feedback vieler Nutzer aus dem System hat Chrome dieses Design gewählt, um den Zugriff auf Informationen auf diejenigen zu beschränken, die sonst keinen Zugriff auf solche Informationen gehabt hätten. Natürlich können Publisher und Drittanbieter, die Topics erhalten, selbst entscheiden, welche Informationen sie mit den Parteien auf ihrer Website teilen möchten. Wenn sie diese Art der Freigabe nutzen, wird ihnen von Chrome dringend empfohlen, den Nutzern gegenüber transparent zu sein und ihnen Kontrolle über das Teilen zu geben. |
| Rauschende Signale | Die Übermittlung eines zufälligen Themas in 5% der Fälle kann zu viel Rauschen / falsches Signal erzeugen. | Rauschen ist eine wichtige Methode, um die Privatsphäre der Nutzer zu schützen, und die Rauschpegel im Vergleich zur Nützlichkeit der Themen werden in Tests untersucht. |
FLEDGE
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Testkoordination | Auswirkungen auf Leistung und Umsatz testen | Die Leistung von FLEDGE wird in den öffentlichen WICG-Meetings aktiv diskutiert. Außerdem wird erläutert, wie wir Umgebungstests bei Ursprungstests sowie die allgemeine Verfügbarkeit am besten unterstützen können. |
| Vertrauenswürdiger Server für FLEDGE | Wann wird der vertrauenswürdige Server zum Testen verfügbar sein? | Wir wissen dieses Feedback zu schätzen und arbeiten aktiv an einem detaillierteren Plan für die Verwendung vertrauenswürdiger Server in FLEDGE. |
| Protokollstandardisierung | Wird es ein gemeinsames Protokoll für die Weitergabe von Daten zwischen SSPs und DSPs geben, beispielsweise gemeinsame Labels für Interessengruppen? | Wir freuen uns über Feedback von DSPs, SSPs und dem gesamten Anzeigensystem zur möglichen Standardisierung der Spezifikation. Derzeit empfehlen wir Ihnen, zu ersten Tests direkt mit Ihren Testpartnern zusammenzuarbeiten, da sie gerade mit verschiedenen Ansätzen experimentieren. Wir ermutigen und planen auch, weiterhin mit Anzeigenhandelsorganisationen zusammenzuarbeiten, um Standardisierungen zu schaffen, falls dies für ihre Mitgliedsunternehmen nützlich ist. |
| Frequency Capping | Häufigkeitseinstellungen für einzelne Nutzer innerhalb einer Kampagne und Anzeigengruppe | FLEDGE unterstützt auch Frequency Capping für On-Device-Auktionen und Kontext-/Branding-Kampagnen. Gemeinsamer Speicher und websitespezifische Obergrenzen können auch für zusätzliche Steuerungsmöglichkeiten für das Frequency Capping verwendet werden. |
| Auswirkungen von FLEDGE auf die Leistung | Rechenintensive Bieter in der FLEDGE-Auktion | Chrome führt Gespräche mit Entwicklern über die möglichen Auswirkungen auf die Websiteleistung. Chrome freut sich über die Möglichkeit, während der Tests mehr darüber zu erfahren. |
| FLEDGE mit anderen Funktionen testen | Wie arbeiten die Berichte auf Ereignisebene aus der Attribution Reporting API und FLEDGE zusammen? | Dies wurde kürzlich in einem WICG-/conversion-measurement-api-Anruf besprochen. Hier finden Sie einen Link zu den detaillierten Minuten.
Zusammenfassung der Besprechung: Mit dem aktuellen Design für Fenced Frames Ad Reporting kann eine innerhalb des Fenced Frames generierte ID mit Kontextinformationen verknüpft werden. Berichte auf Ereignisebene, die innerhalb des Fenced Frame generiert werden, können daher mit denselben Kontextinformationen auf dem Server verknüpft werden. Dabei werden zwei serverseitige statt eines einzigen Joins verwendet. |
| Zählung von Impressionen | Welche Methode zur Impressionszählung zwischen Käufern und Verkäufern verwendet werden sollte und wird | Die FLEDGE API unterstützt bereits eine Abstimmung der Methodik zwischen Verkäufer und Käufer während der Auktion. Wir haben Vorschläge zu alternativen Implementierungen erhalten, ohne Feedback dazu erhalten zu haben, warum unser aktuelles Design nicht für die Plattform geeignet ist. |
| Mehrere Anzeigen schalten | Ob mehrere Anzeigen in einer Auktion in einem bestimmten Fenced Frame ausgeliefert werden können | Dies ist derzeit über Komponentenanzeigen möglich (nicht zu verwechseln mit Auktionen für Komponenten). Dazu müssen alle Anzeigen derselben Interessengruppe angehören. |
| Verkäuferdefinierte Zielgruppen (SDA) und FLEDGE | Kann FLEDGE zu einem Mechanismus werden, mit dem Käufer daran gehindert werden, Profile aus SDA für Anzeigenanfragen zu erstellen? | Mit FLEDGE sollen irrelevante Datenlecks vermieden werden, wenn der Publisher bereits weiß, in welchen SDAs sich seine Besucher befinden, und das Targeting auf dieselbe Website ausgerichtet ist. Wenn es wichtig ist, Käufe auf SDAs innerhalb aller in FLEDGE integrierten Schutzmaßnahmen zu unterstützen, kann eine Lösung darin bestehen, dass ein Verkäufer SDA-Labels an die On-Device-Auktion übergibt und eine AdTech auf Käuferseite, um eine eigene Interessengruppe zu erstellen, deren Gebotslogik „Ich möchte Zielgruppe X kaufen“ lautet. |
| Unterstützung für andere Währungen als US-Dollar | Unterstützung für das Testen von FLEDGE mit Währungen außerhalb US-Dollar | Wir wissen diese Zusatzinformation zu schätzen und haben die Entwicklung zur Unterstützung anderer Währungen innerhalb unseres Rückstands an Funktionsanfragen hinzugefügt. Wir hoffen, diese Funktion bald verfügbar zu machen. |
| Unterstützung für die Ausrichtung auf auszuschließende Interessengruppen | Eine API zur Unterstützung der negativen Ausrichtung auf Google-Plattformen: Anzeigen werden nur ausgeliefert, wenn ein Nutzer nicht zu einer Google-Suche gehört. | Laufende Diskussion, einschließlich einiger Vorschläge zur Unterstützung, finden Sie im GitHub-Problem. |
| Mehrere SSPs in FLEDGE | Risiko der Bevorzugung von Google bei der Implementierung von Auktionen mit mehreren Ebenen in FLEDGE | In FLEDGE werden jetzt mehrere SSPs unterstützt, um faire und gerechte Wettbewerbsbedingungen zu schaffen. Google hat im Rahmen dieser Selbstverpflichtungen versprochen, die Privacy Sandbox-Angebote nicht so zu gestalten, zu entwickeln oder umzusetzen, dass der Wettbewerb dadurch verfälscht wird, dass seine Werbeprodukte und -dienste selbst bevorzugt werden. Google nimmt das sehr ernst und ist offen dafür, sämtliche Bedenken zu besprechen, die Stakeholder in Bezug auf bestimmte Aspekte der Technologie haben könnten. Weitere Informationen zum Auktionsmechanismus von Komponenten finden Sie hier. |
Digitale Anzeigen analysieren
Attribution Reporting (und andere APIs)
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Multi-Touchpoint-Attribution | Publisher, die Unterstützung für die Multi-Touchpoint-Attribution anfordern | Aktuelle Methoden der Multi-Touchpoint-Attribution erfordern eine deterministische Verknüpfung der Impressionen (und damit der Identität) eines Nutzers über verschiedene Websites hinweg. 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 eine Annäherung der Zuordnung (z.B. durch gewichtete, randomisierte Prioritäten) möglich, ohne einzelne Nutzer zu erfassen. |
| Geräuscherzeugung | Fragen zum Rauschpegel in den Berichten | In unserem ersten Experiment können Entwickler einen eigenen Epsilon-Wert festlegen, um zu sehen, wie sich die Berichte je nach Rauschpegel ändern. Derzeit können Entwickler einen Epsilon-Wert bis zu Epsilon=64 auswählen. Damit möchten wir es Entwicklern leichter machen, die APIs zu testen und uns Feedback zu geeigneten Epsilon-Werten zu geben.
Wir haben auch öffentliches Ersuchen um solches Feedback eingereicht. |
| Testkoordination | Kann das lokale Testtool für den OT verwendet werden? | Ja, das lokale Testtool kann für die Dauer des OT verwendet werden. Das lokale Testtool kann mit Debug-Berichten verwendet werden, solange Drittanbieter-Cookies verfügbar sind. |
| Abfrageergonomie | Abfrage-Aggregat von Schlüsseln aktivieren | Wir sind der Meinung, dass dies zu einer Verbesserung der Ergonomie der API bei geringen oder gar keinen Kosten für den Datenschutz führt. Wir werden dann einen Vorschlag unterbreiten und prüfen, ob es einen allgemeinen Konsens gibt, dass er unterstützt werden sollte. |
| Weniger genaue Daten für kleine Websites | Kleinere Websites oder Kampagnen erhalten möglicherweise weniger genaue Daten. | Chrome erkennt, dass rauschenbasierte Datenschutzmaßnahmen sich stärker auf kleinere Datensegmente auswirken. Es ist jedoch möglich, dass dieses Problem mit Methoden wie der Zusammenfassung über einen längeren Zeitraum behoben wird. Es ist auch unklar, ob die Schlussfolgerungen, die auf sehr kleinen Datensegmenten (z. B. ein oder zwei Käufe) basieren, für Werbetreibende von Bedeutung sind. Während des Ursprungstests empfiehlt Chrome Testern, die Möglichkeit zu nutzen, mit einer Vielzahl von Datenschutz- und Rauschparametern zu experimentieren, um genaueres Feedback zu diesem Problem zu geben. |
Verdecktes Tracking begrenzen
Reduzierung des User-Agents
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Bot-Schutz | Auswirkungen von UA-R auf den Bot-Schutz | Wir schätzen dieses Feedback und sind gerade dabei, Informationen zu Ansätzen zum Bot-Schutz zu sammeln, um unsere zukünftigen Designs zu verbessern. |
| Bereitstellungsabhängigkeiten | Bereitstellungsabhängigkeiten des strukturierten User-Agents (SUA) beheben | Wir haben „Phase 4“, eine Reduzierung der Nebenversion, für alle Chrome-Nutzer ab Version 101 eingeführt. Aktuelle Informationen |
User-Agent-Client-Hints
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Alle unterstützten Hinweise auflisten | Interesse an einer programmatischen Methode, um alle unterstützten Hinweise für einen Browser zu kennen | Wir wissen dieses Feedback zu schätzen und sind gerade dabei, die Funktionsanfrage zu prüfen. Wir würden gerne erfahren, ob dies ein häufiger Anwendungsfall ist. |
| Flexibilität von UA-CH- und User-Agent-Headern | UA-CH ist im Vergleich zu der Flexibilität des User-Agent-Headers gemäß rfc7231-Definition zu allgemein. | Chrome betrachtet den präskriptiven Charakter von UA-CH-Headern als wichtige Verbesserung der Flexibilität des UA-Strings, sowohl im Hinblick auf die letztendliche browserübergreifende Interoperabilität und den Datenschutz für Nutzer, da das willkürliche Hinzufügen von Kennungen mit hoher Entropie verhindert wird.
Das Problem bleibt offen, für den Fall, dass auch andere Nutzer dasselbe Anliegen haben und Feedback geben möchten. |
| UA-CH: Betrugs- und Missbrauchsbekämpfung | Bestimmte Funktionen, die über UA-CH verloren gehen können: Klickweiterleitungs-Tracker und betrügerische Klicks. | Das Team untersucht diese potenziellen Probleme zusammen mit Stakeholdern, um Betrug zu verhindern und Analysen durchzuführen. |
| Leistung | Es gibt Bedenken hinsichtlich der Latenz beim Abrufen von Hinweisen über Critical-CH (beim ersten Seitenaufbau). | Chrome sucht nach Möglichkeiten, die Leistung zu verbessern. |
Gnatcatcher (WIP)
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Latenzprobleme | Das Hinzufügen zusätzlicher Hops könnte die Latenz beeinträchtigen | Wir erwägen einen Zwei-Hop-Proxy und suchen nach Möglichkeiten, das richtige Gleichgewicht zwischen Datenschutz und Latenz für Nutzer zu finden. Wir sind offen für Feedback und würden uns über weitere Diskussionen in W3C-Foren freuen. |
| Schutz vor Betrug und Bots | Auswirkungen auf Betrug und Bot-Schutz, auch in weniger entwickelten Ländern | Sicherheit ist eine zentrale Anforderung, da wir nach Möglichkeiten suchen, den Datenschutz für Nutzer auf sinnvolle Weise zu verbessern, z. B. Proxy-IP-Adressen. Ein Zwei-Hop-Proxy in Zusammenarbeit mit namhaften Unternehmen bietet überprüfbaren Datenschutz für Nutzer. Außerdem entwickeln wir neue Signale, um das Vertrauen der Nutzer zu stärken. |
| Einhaltung lokaler Datenschutzgesetze | Die Berichterstellung zu geografischen Daten auf Länderebene erschwert die Einhaltung detaillierterer Vorschriften vor Ort. | Wir haben unsere vorgeschlagenen Grundsätze veröffentlicht, einschließlich möglicher Ansätze, mit denen Websites die Einhaltung lokaler Anforderungen sicherstellen können. |
Websiteübergreifende Datenschutzgrenzen stärken
First-Party-Sets
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Nützlichkeit für verschiedene Arten von Stakeholdern | Auswirkungen der Framerate für kleine und große Publisher | Das Hauptziel der Privacy Sandbox besteht darin, den Datenschutz für Nutzer zu verbessern, indem aktuelle Verfahren durch Lösungen ersetzt werden, die nicht auf websiteübergreifende Tracking-Mechanismen basieren. Wir möchten, dass diese Lösungen für unterschiedliche Arten und Größen von Stakeholdern so weit wie möglich nützlich sind. Wir freuen uns über konkrete umsetzbare Vorschläge dazu, wie diese Lösungen verbessert werden können, und gehen davon aus, dass sie sich durch Diskussionen und Tests der Community weiterentwickeln werden. |
| Verbesserter Datenschutz | Zu viele Websites in derselben Gruppe können ähnliche Ergebnisse erzielen wie Drittanbieter-Cookies. | Wir wissen dieses Feedback zu schätzen und prüfen, ob oder welche Beschränkungen für sie gelten könnten. Gleichzeitig versuchen wir, sowohl Nutzern als auch Entwicklern Hinweise zur Verfügung zu stellen, damit sie nachvollziehen können, wann eine solche Beschränkung erreicht wird. Wir haben noch keinen konkreten Vorschlag, hoffen aber auf eine baldige Antwort. |
| FPS-Unterstützung | Sammlung von Support und Bedenken für die Weiterentwicklung der FPS außerhalb der Datenschutz-Community | Zwar hätten wir uns gewünscht, das Angebot für First-Party-Sets in der PrivacyCG zu belassen, freuen uns aber darauf, den Vorschlag in der WICG weiterzuführen. Die zahlreichen Unterstützungsbekundungen zum Thema First-Party-Sets und die damit verbundenen Anwendungsfälle haben uns ebenfalls überzeugt. Google arbeitet kontinuierlich daran, Lösungen zu entwickeln, mit denen das Web weiter wachsen und florieren kann – und zwar so, dass die Privatsphäre der Nutzer bestmöglich geschützt wird. |
| Browser-Interoperabilität | Implementierung durch andere Browser | Wir sind uns der Bedeutung der Browser-Interoperabilität für Entwickler bewusst und werden weiterhin mit anderen Browsern zusammenarbeiten, um eine Standardisierung der FPS zu erreichen. |
| Allgemeine Anforderung der Datenschutzerklärung | Es ist nicht möglich, für alle Produkte und Rechtsprechungen eine gemeinsame Datenschutzerklärung zu verwenden. | Chrome definiert noch unsere Richtlinienanforderungen und wird dieses Feedback berücksichtigen. |
Fenced Frames-API
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Dokumentationsanfrage | Unterschiede zu iFrames in einer Sandbox | Wir freuen uns über Ihr Feedback und Ihren Vorschlag. Auf GitHub wird dies derzeit diskutiert. Wir hoffen, die Anfrage abschließend zu klären, um sie dann vollständig prüfen zu können. Die öffentliche Diskussion finden Sie hier. |
| API-übergreifende Funktionen | Standardunterstützung für Attributionsberichte in Fenced Frames | Wir bitten Sie um Feedback zu einem Vorschlag, die Attribution Reporting API standardmäßig im "Modus für undurchsichtige Anzeigen" von umzäunten Frames zu verwenden. Wir empfehlen Entwicklern, die dies als nützlich empfinden würden, sich an der Diskussion zu beteiligen. |
Shared Storage API
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Datenlimits | Gibt es eine Beschränkung dafür, wie viele Daten pro Partition gespeichert werden können? | Ja, es wird Beschränkungen geben. Weitere Informationen finden Sie unter GitHub-Problem. Wir benötigen Speicherkontingente. Unser aktueller Vorschlag ist eine Größenbeschränkung von 4 KB pro Eintrag. Sowohl Schlüssel als auch Werte sind auf 1.024 Zeichen16_t pro Eintrag begrenzt. Eine Obergrenze für Einträge pro Ursprung ist auf 10.000 Einträge beschränkt. Durch einen Mechanismus wird verhindert, dass zusätzliche Einträge festgeschrieben werden, wenn die Kapazität eines Ursprungs voll ist. Wir freuen uns über Feedback zu den auf dieser Seite vorgeschlagenen Einschränkungen. |
| Transparenz für Nutzer | Nutzertransparenz für Datenquellen im Vergleich zur Datennutzung | Wir wissen dieses Feedback zu schätzen und sind der Ansicht, dass dieser Ansatz vielversprechend ist. Insbesondere prüfen wir, ob dies auf eine Art und Weise möglich ist, die den Nutzern ausreichend Transparenz bietet. |
CHIPS
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Hindernisse bei der Akzeptanz | Sollten CHIPS Hostname-gebunden sein? (die Nicht-Domain-Anforderung) | Wir haben diese Anforderung aufgrund des Feedbacks von Teilnehmern aus dem OT entfernt, dass diese Anforderung die Komplexität erhöht hat und die Einführung von CHIPS behindert.
Wir werden diese Anforderung im Rahmen der Einführung von Standards in der Privacy Community Group hier besprechen. |
| Anwendungsfälle für CHIPS-Werbung | Können 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, ist aber nicht der vorgesehene Anwendungsfall für CHIPS. Der Anwendungsfall für authentifizierte Einbettungen ist uns bekannt und wir arbeiten bereits an Lösungen. |
| Testkoordination | Sind weitere Nutzeraktionen erforderlich, 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 weitere Aktionen erforderlich sind. |
| Browserkompatibilität | Interesse daran, wie andere Browser mit partitionierten Cookieattributen umgehen. | Chrome arbeitet weiterhin in öffentlichen Standardgruppen wie dem W3C daran, Designs und Implementierungen zu identifizieren, die browserübergreifend funktionieren. |
FedCM
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Potenzielle Angriffsvektoren | Potenzielle Angriffsvektoren durch Linkdekoration und Timing-Angriffe | Wir sammeln aktiv Beiträge aus der Öffentlichkeit und suchen nach Möglichkeiten, dieses Problem anzugehen. |
| UX, um mehrere IdPs zu ermöglichen | Es kann jeweils nur ein IdP angezeigt werden | Wir möchten mehrere IdPs unterstützen und arbeiten aktiv an entsprechenden Ansätzen. |
| Ausdrucksstärke | Da der Browser einen Teil des Datenflusses für föderierte Identitäten rendert, ist es schwierig, alle Nuancen zu erfassen, die IdPs ihren Nutzern präsentieren möchten. | Chrome arbeitet an neuen Möglichkeiten, das Branding (z.B. Logos, Farben) und Strings anzupassen (z.B. „Auf diesen Artikel zugreifen“ statt „Anmelden mit“).
Chrome erkennt die Kompromisse und arbeitet weiterhin mit der Plattform zusammen, um möglichst viele Bereiche abzudecken und sie so ausdrucksstark wie möglich zu gestalten. |
| Anwendbarkeit und Interoperabilität | Bedenken, dass andere Browser FedCM nicht einführen oder implementieren werden | Chrome arbeitet außerdem mit anderen Browseranbietern zusammen, um in der FedID Community Group gängige Föderationslösungen zu finden. |
| Vorschlag, Anforderungen an personenbezogene Daten bei der Registrierung zu entfernen | (1) Eine UX, die dem Nutzer anzeigt, welchen IdP er auswählt, ohne zu signalisieren, dass seine E-Mail-Adresse, sein Bild und sein Name geteilt werden, wäre datenschutzfreundlicher
(2) Die Registrierung für Anwendungsfälle ist wenig nutzerfreundlich und die Auswahl von Ansprüchen vom IdP ist gering. |
Wir sind uns einig und überlegen, wie wir das Feedback nutzer- und datenschutzfreundlicher gestalten können. |
| Nutzerinteraktion mit IdP | Direkte Interaktion zwischen Nutzer und IdP erforderlich, wenn ein Risikogrenzwert überschritten wird | Wir prüfen dieses Feedback aktiv. |
Partitionierung des Netzwerkstatus
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Leistung | Die Partitionierung des Netzwerkstatus könnte zu einer Zunahme ressourcenintensiver Verbindungen zu CDNs führen | Wir untersuchen derzeit noch die Leistungsmerkmale der Partitionierung des Netzwerkstatus und messen auch verschiedene mögliche Schlüsselschemata. Wir haben noch keine Entscheidung zwischen den Kompromissen bei Leistung, Sicherheit und Datenschutz getroffen und müssen noch mehr Daten erheben. |
Spam und Betrug bekämpfen
Trust Tokens API
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Rechtliches Feedback | Bedenken, Zeit und Ressourcen in Trust Tokens zu investieren, ohne dass die Regulierungsbehörden ein klares Signal von der langfristigen Rentabilität erhalten | Unser Ziel ist es, eine Technologie zu entwickeln, die für das System funktioniert. Dabei ist das Feedback aus der Branche und den Regulierungsbehörden für den Prozess von entscheidender Bedeutung. Bei der Entwicklung der Privacy Sandbox und der Bereitstellung der Vorschläge für Entwickler, einschließlich Trust Tokens, werden wir uns weiterhin mit Aufsichtsbehörden auf der ganzen Welt beraten. Wie bei allen neuen Technologien sollten Unternehmen Entscheidungen auf der Grundlage ihrer eigenen Bewertung der regulatorischen Anforderungen treffen. |
| Startzeitpunkt | Wann werden Trust Tokens in Google Analytics eingeführt? | Wir geben unsere aktuellen Schätzungen für die Auslieferung in unserer öffentlichen Zeitachse auf privacysandbox.com an. Sobald wir eine endgültige Entscheidung über den Liefertermin in Google Analytics getroffen haben, werden wir die Angaben über die Veröffentlichungsprozesse von Chrome veröffentlichen und den Zeitplan auf der Website aktualisieren. |
| Trust Tokens im Vergleich zu anderen | Welche Rolle spielen Trust Tokens angesichts der anderen Tokens, die standardisiert werden, z. B. Private Zugriffstokens | Wir diskutieren über Standardisierungen. Unser Ziel ist es, sich so weit wie möglich mit anderen Bemühungen abzustimmen und gleichzeitig die unterschiedlichen Anwendungsfälle der einzelnen Technologien zu ermöglichen. Beispielsweise basieren sowohl Trust Tokens als auch Private Access Tokens auf dem Privacy Pass-Protokoll. |
| Datenlimits | Maximal 2 Aussteller für die Einlösung des Tokens pro Seite, die möglicherweise begrenzt ist | Wir suchen nach langfristigen Optionen, mit denen wir Unternehmen sicher das Einlösen von Tokens ermöglichen können, ohne mehr Nutzerentropie zu riskieren, etwa durch die Partitionierung des Zugriffs auf das Einlösen von Tokens. |
| Zugriffsbeschränkungen | Nur genehmigte (und bestätigte/nicht gefälschte Verweis-URLs) sollten das Vorhandensein eines Tokens prüfen und das Angebot einlösen können | Wir arbeiten daran, zu entscheiden, wer Tokens sehen und einlösen kann. |
| Gerätesupport | Die Nutzung von JavaScript-Laufzeitabhängigkeiten wird auf bestimmten Geräten eingeschränkt. Kann die TT-Unterstützung auf andere Gerätetypen ausgeweitet werden? | Das ist ein Thema, das wir für zukünftige Entwicklungen berücksichtigen könnten. Außerdem würden wir uns über Feedback von Entwicklern in W3C-Foren freuen. Es gibt auch ein offenes Problem bezüglich der Einlösung eines Tokens, das durch einen HTTP-Header ausgelöst wurde. Wir bitten Sie daher um Feedback. |
| Anwendungsfälle | Unklar, welche Anwendungsfälle für Trust Tokens richtig sind Unklare über die beabsichtigte Verwendung. | Unser Ziel ist es, Innovationen im Bereich der Betrugsbekämpfung zu fördern. Wir wissen, dass jedes Unternehmen eigene Techniken mit Trust Tokens einsetzen kann. Aus diesem Grund haben wir die vorgesehene(n) Verwendungszweck(e) nicht vorgegeben. Wir werden unsere Dokumentation jedoch wahrscheinlich um weitere Beispiele als Ausgangspunkt für Partner erweitern, die Tests oder eine Einführung in Betracht ziehen. |
| Abdeckung von Trust Tokens | Wenn Sie die Funktionsrichtlinie „Vertrauens-Token-Einlösung“ entfernen, sollte die Abdeckung von Trust Tokens deutlich erhöht werden. | Das wird berücksichtigt, wenn wir Feedback vom OT einholen und Entscheidungen über die nächsten Schritte treffen. |
| Vertrauensstellung des Ausstellers | Warum sollten wir Websites vertrauen, die Trust Tokens ausgestellt haben? | Es gibt keine Richtlinien dafür, wie man Aussteller werden kann - jeder kann das. Es wird davon ausgegangen, dass Publisher nur mit Ausstellern zusammenarbeiten, denen sie vertrauen. Darüber hinaus würden andere legitime Akteure im Werbesystem den Traffic von verdächtigen oder unbekannten Ausstellern möglicherweise billigen oder den Kauf einstellen. |
| Eingebettete Drittanbieterdienste | Können eingebettete Dienste von Drittanbietern Trust Tokens einlösen und/oder anfordern? | Ja, ein eingebetteter Drittanbieterdienst kann Trust Tokens ausstellen und einlösen. |
| Ausstellersystem | Ein größerer Nutzen kann erzielt werden, wenn Vertrauenssignale an andere Unternehmen weitergegeben werden können. | Trust Tokens sind eine einfache Methode und können von kooperierenden Ausstellern/Einlösern verwendet werden, um Vertrauens-/Rufsignale zu teilen. |
| Wartungsaufwand | Die kryptografischen Implementierungen, die den Trust Token-Vorgängen zugrunde liegen, befinden sich in BoringSSL. Google ist der alleinige Verwalter von BoringSSL. Wie wird die Pflege der Bibliothek verwaltet? | Trust Tokens basieren auf standardisierten kryptografischen Vorgängen (siehe Privacy Pass-Protokoll), die auch in anderen Bibliotheken implementiert werden können. Wir empfehlen Entwicklern, Support für diese Vorgänge in den Bibliotheken ihrer Wahl zu beantragen, zu entwickeln und aufrechtzuerhalten. |
| Wartungsaufwand | Unklar, wie lange Protokollversionen unterstützt werden | Wir arbeiten daran, die voraussichtlichen Unterstützungszeiträume für Protokollversionen genauer zu definieren und zu dokumentieren. |
| Ausstellerlimits | Wenn Sie weiter unten in der Kette sind, erhalten Sie möglicherweise keine Möglichkeit, Trust Tokens auszuführen. | Da immer mehr Organisationen Vertrauenstokens verwenden, könnten diese Art von Timing-Dynamik zunehmend in Spiel kommen und wir suchen nach potenziellen Lösungen. Wie bereits erwähnt, suchen wir nach langfristigen Optionen, mit denen wir Unternehmen das Einlösen von Tokens sicher ermöglichen können, ohne eine höhere Nutzerentropie zu riskieren. Die Platzierung auf der Seite oder in der Ladereihenfolge wäre dann nicht mehr so wichtig. |
Neue Lösungen gegen Betrug in der Inkubation
| Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Signale zur Attestierung der Geräteintegrität | Im Allgemeinen starke Unterstützung für die Verfolgung von Signalen zur Geräteintegrität, die von Plattformen bestätigt und im Web verfügbar gemacht wurden | Wir werden weiterhin Feedback sammeln und den Vorschlag durch eine öffentliche Gestaltung und Iteration weiter verfolgen. |
| Signale zur Attestierung der Geräteintegrität | Fragen dazu, wie viel Nutzerentropie durch neue Signale übertragen werden könnte und ob bestimmte Anwendungsfälle (z. B. die Anmeldung eines Nutzers bei seiner Bank) höhere Entropiesignale rechtfertigen könnten. | Wir versuchen, hochwertige Signale mit so wenig Nutzerentropie wie möglich bereitzustellen, um den Datenschutz für Nutzer zu wahren. |
| Signale zur Attestierung der Geräteintegrität | Würde dieses Signal den Zugriff für ältere Geräte oder Open-Source- bzw. modifizierte Plattformen einschränken? | Alle neuen Signale sollten den universellen Zugang als Grundprinzip in der Entwicklung betrachten. Diese Fragen sollten Sie sich im Vorfeld stellen, während wir die Entwicklung fortsetzen. |
| Signale zur Attestierung der Geräteintegrität | Es gab Bedenken, wenn neue Signale dazu führen könnten, dass sich Unternehmen im Bereich Sicherheit und Betrugsbekämpfung übermäßig auf den Browser und die Plattformen verlassen.
|
Jedes neue Signal sollte als ergänzende Daten betrachtet werden und nicht als Hinweis auf „Vertrauen“ vom Browser. Wir gehen davon aus, dass Sicherheitsunternehmen auch weiterhin auf ihre eigenen Daten, Modelle und Entscheidungs-Engines mit Geräteattestierung als zusätzlichen Input vertrauen werden. Hoffentlich trägt jedes neue Signal dazu bei, die Erkennung von Betrugsversuchen im gesamten System zu verbessern und Betrug zu erschweren. |
| Cookie-Alterssignal | Interessantes Konzept, erfordert aber wahrscheinlich eine genauere Untersuchung der anwendbaren Anwendungsfälle. | Je nach Interesse kann Chrome weitere Ideen zu diesem Konzept entwickeln und sie als Erklärung für zukünftiges Feedback aus der Community festhalten. |
| Vertrauenswürdige Server zum Schutz vor Betrug | Interessantes Konzept, erfordert aber wahrscheinlich eine genauere Untersuchung der anwendbaren Anwendungsfälle. | Je nach Interesse kann Chrome weitere Ideen zu diesem Konzept entwickeln und sie als Erklärung für zukünftiges Feedback aus der Community festhalten. |