Feedbackbericht – 4. Quartal 2022

Quartalsbericht für das 4. Quartal 2022 mit einer Zusammenfassung des Feedbacks zum Privacy Sandbox-Vorschlag und zur Reaktion 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 Zusammenfassung Chrome-Antwort
(Auch im 3. Quartal erfasst)

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 Unsere Antwort bleibt unverändert:

„Google hat sich gegenüber der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu entwerfen und umzusetzen, dass der Wettbewerb nicht durch Bevorzugung des eigenen Geschäfts von Google verzerrt wird. Außerdem werden die Auswirkungen auf den Wettbewerb in der digitalen Werbung sowie auf Publisher und Werbetreibende unabhängig von ihrer Größe berücksichtigt. 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.

Wir haben mit der CMA zusammengearbeitet, um unseren Ansatz für quantitative Tests zu entwickeln. Wir unterstützen die CMA bei der Veröffentlichung einer Mitteilung zum Testdesign, um Marktteilnehmern mehr Informationen zur Verfügung zu stellen und ihnen die Möglichkeit zu geben, sich zu den vorgeschlagenen Ansätzen zu äußern.“
(Auch im 3. Quartal gemeldet)
Anfragen zur Dokumentation		 Anfragen nach weiteren Ressourcen zum Verwalten von Tests, Analysen und Implementierung Update für das 4. Quartal:

Wir freuen uns, dass Entwickler unsere aktuellen Materialien hilfreich finden. Wir werden auch weiterhin weitere Materialien bereitstellen, damit Entwickler verstehen, wie sie die neuen Technologien für sich nutzen können. Im letzten Quartal haben wir privacysandbox.com den Bereich „Neuigkeiten und Updates“ hinzugefügt und einen ausführlichen Artikel darüber veröffentlicht, wie die Privacy Sandbox in Zukunft die Anzeigenrelevanz verbessern kann.

Außerdem haben wir öffentliche Sprechstunden für Entwickler veranstaltet, um Best Practices und Demos zu teilen, sowie Fragerunden mit Produkt- und Entwicklungsleitern, um Live-Diskussionen und Fragen zu ermöglichen.
Core Web Vitals Wie wirkt sich die Latenz der Privacy Sandbox API auf die Core Web Vitals aus? Die Latenz so gering wie möglich zu halten, ist ein wichtiges Designziel der Privacy Sandbox APIs. Wir gehen davon aus, dass sich die API-Latenz nur minimal auf die Core Web Vitals einer Website auswirken sollte, da die meisten APIs nach dem ersten Rendering der Website aufgerufen werden. Wir beobachten die Latenz der einzelnen APIs kontinuierlich und nehmen Verbesserungen vor, um sie weiter zu reduzieren. Wir freuen uns über weitere Tests und Feedback.

Die Latenz beim Echtzeitgebotsverfahren wird im Abschnitt zu FLEDGE unter „Leistung von FLEDGE-Auktionen“ behandelt.
Interoperabilität Bedenken hinsichtlich der Interoperabilität mit anderen potenziellen Lösungen Ziel der Privacy Sandbox ist es, Nutzer vor websiteübergreifendem Tracking zu schützen und gleichzeitig die Anforderungen des Web-Ökosystems zu erfüllen. Wir möchten dies erreichen, indem wir uns von älteren Browsertechnologien entfernen, die ein solches websiteübergreifendes Tracking ermöglichen, z. B. Drittanbieter-Cookies, und stattdessen neue Technologien einführen, die speziell für bestimmte Anwendungsfälle entwickelt wurden.

Die Privacy Sandbox-Vorschläge verbessern den Datenschutz, indem die Daten, die das Gerät eines Nutzers verlassen, eingeschränkt werden. Die Vorschläge beschränken nicht technisch die Möglichkeit einer Website, Daten, die im Browser erhoben wurden, weiterzugeben oder anderweitig zu verarbeiten. Die Technologien verhindern daher nicht, dass Unternehmen Vereinbarungen zur Datenverwaltung oder andere ähnliche vertragliche Beziehungen eingehen. Ebenso wird die Möglichkeit der Nutzer nicht eingeschränkt, der Weitergabe ihrer Daten auf andere Weise zuzustimmen.

Zur Klarstellung: Google hat sich verpflichtet, die Privacy Sandbox-Technologien auf alle Websites anzuwenden, einschließlich Google-Produkten und ‑Diensten. Nach der Einstellung der Unterstützung von Drittanbieter-Cookies in Chrome wird in den Verpflichtungen auch klargestellt, dass Google keine anderen personenbezogenen Daten wie den synchronisierten Chrome-Browserverlauf von Nutzern verwendet, um Nutzer für die Ausrichtung oder Analyse digitaler Werbung zu erfassen.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema Zusammenfassung Chrome-Antwort
Auswirkungen auf das Ranking in der Google Suche Anfrage, ob die Topics API-Unterstützung einer Website als potenzielles Signal für das Ranking in den Google-Suchergebnissen verwendet wird Einige Websites können die Topics API deaktivieren. Das Privacy Sandbox-Team hat die Suchorganisation nicht gebeten, den Seitenrang als Anreiz für Websites zu verwenden, die Topics API zu verwenden. Google hat der CMA bestätigt, dass die Entscheidung einer Website, die Topics API zu deaktivieren, in der Google Suche nicht als Rankingsignal verwendet wird.
Themenklassifikator Fügen Sie zusätzlich zum Hostnamen die URL und den Seiteninhalt hinzu, um das Thema einer Webseite zu bestimmen und die Nutzung für verschiedene Stakeholder zu verbessern. Der Browserverlauf eines Nutzers wird derzeit anhand der Hostnamen einer Website klassifiziert. In Chrome werden weiterhin Optionen geprüft, um Metadaten auf Seitenebene (z. B. alle oder einige Komponenten der Seiten-URL und/oder des Inhalts) bei der Themenklassifizierung zu berücksichtigen. Alle Verbesserungen der Nützlichkeit müssen gegen die Datenschutz- und Missbrauchsrisiken abgewogen werden.

Im Hinblick auf Metadaten sind beispielsweise folgende Risiken zu nennen:
– Websites, die Metadaten auf Seitenebene ändern, um verschiedene (und potenziell sensible) Bedeutungen in Themen einzubetten;
– Websites, die Metadaten auf Seitenebene ändern, um ihre Themen aus finanziellen Gründen falsch darzustellen;
– Websites, die Metadaten auf Seitenebene dynamisch ändern, um websiteübergreifend zu erfassen.
(Auch im 3. Quartal gemeldet)
Auswirkungen auf selbst erhobene Signale		 Das Themensignal kann sehr wertvoll sein und andere interessenbezogene Signale aus selbst erhobenen Daten dadurch abwerten. Unsere Antwort bleibt unverändert:

„Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist. Topics wurde entwickelt, um diesen Anwendungsfall zu unterstützen. Wie in unserem Bericht zu [Q3] beschrieben, haben andere Stakeholder des Google-Werbenetzwerks Bedenken geäußert, dass Topics möglicherweise nicht nützlich genug sind, um einen Mehrwert zu bieten. Verbesserungen an der Taxonomie sind in jedem Fall ein fortlaufender Prozess. Wir gehen davon aus, dass sich die Taxonomie mithilfe von Tests und Feedback aus dem Werbesystem weiterentwickelt.“
Taxonomie aktualisieren Wie wird die Taxonomieliste aktualisiert? Wir sind auf der Suche nach Feedback zur Taxonomie, die für das Ökosystem am nützlichsten wäre. Die im ursprünglichen Vorschlag für die Topics API enthaltene Taxonomie wurde entwickelt, um Funktionstests zu ermöglichen. Für Chrome werden derzeit mehrere Ansätze zur Aktualisierung der Taxonomie geprüft. Chrome kann beispielsweise den kommerziellen Wert für jedes Thema verwenden, um zu bestimmen, welche Kategorie in zukünftigen Iterationen enthalten sein soll.
Leistung des regionalen Klassifikators für Themen Themenklassifikator funktioniert in regionalen Domains nicht gut Die Verbesserung des Klassifikators ist ein fortlaufender Prozess. Auf Grundlage des Feedbacks, das wir erhalten haben, wird derzeit erwogen, die Liste der Topics-Überschreibungen zu erweitern. Unsere Analysen haben gezeigt, dass sich dadurch die globale Abdeckung und die Genauigkeit verbessern lassen.

Die Topics API-Klassifizierung besteht aus zwei relevanten Komponenten: (1) einer Überschreibungsliste mit den 10.000 wichtigsten Websites und ihren Themen und (2) einem On-Device-ML-Modell, das Hostnamen in Themen klassifiziert. Durch die Erweiterung der Überschreibungsliste (1) können wir die Klassifizierungsleistung in Regionen verbessern, in denen die Leistung des Klassifikators möglicherweise gering ist.
Eine Woche Die Zeitspanne von einer Woche ist zu lang für Nutzer, die kurzfristige Entscheidungen treffen möchten. Wir prüfen derzeit, wie lang eine Epoche sein sollte, und freuen uns über weitere Rückmeldungen dazu, welche Epoche für das System am besten geeignet wäre.
Abrufen von HTTP-Headern Bedenken, dass nicht genügend Informationen zum Abrufen von Themen über den HTTP-Header vorliegen Wir arbeiten derzeit an Headern und fetch(). Weitere Informationen Außerdem haben wir der Erläuterung Informationen zu „skipObservation“ hinzugefügt.
Topics soll nur Werbetreibenden helfen, nicht Nutzern. Topics/Privacy Sandbox ist offenbar ein branchenspezifischer Ansatz. Der Vorteil für Nutzer ist nicht so klar wie der Vorteil für die Branche. Wir sind der Ansicht, dass Topics für Nutzer von Vorteil ist, da es interessenbezogene Werbung unterstützt, die das Web kostenlos und offen hält. Außerdem verbessert es den Datenschutz im Vergleich zu Drittanbieter-Cookies deutlich. Wenn Drittanbieter-Cookies ohne praktikable Alternativen entfernt werden, kann sich das negativ auf Publisher auswirken und zu schlechteren Ansätzen führen,
die weniger datenschutzfreundlich, nicht transparent und nicht realistisch von Nutzern zurückgesetzt oder gesteuert werden können. Viele Unternehmen testen Topics und Sandbox APIs aktiv. Wir möchten Unternehmen die Tools zur Verfügung stellen, mit denen sie den Datenschutz verbessern und das Web unterstützen können.


Die W3C Technical Architecture Group hat vor Kurzem ihre erste Einschätzung zur Topics API veröffentlicht. Wir werden öffentlich darauf reagieren. Da Google in dieser Phase Fragen aus der Branche dazu erhalten hat, was diese Überprüfung für die Entwicklung und Einführung der Topics API bedeuten könnte, möchten wir unseren Plan bekräftigen, sie noch in diesem Jahr in Chrome Stable verfügbar zu machen. Google schätzt den Input der W3C Technical Architecture Group, hält es aber für äußerst wichtig, die Bemühungen zur Entwicklung und Prüfung von Topics in Absprache mit der CMA und dem gesamten System fortzusetzen.
Datenleck Bedenken, dass Topics ohne Erlaubnis an andere Websites weitergegeben werden können Aufgrund der Funktionsweise der Topics API ist es sehr unwahrscheinlich, dass Daten eines einzelnen Publishers (oder einer kleineren Gruppe von Publishern) auf irgendeine Weise gehackt werden. Inhaber von Publisher-Websites haben außerdem die volle Kontrolle über die Topics API und können den Zugriff auf diese API über die Berechtigungsrichtlinie unterbinden.
Zu wenige Werbetreibende für Tests Publisher sind besorgt, dass sie Werbetreibenden derzeit nicht den Wert von Themen verdeutlichen können. Im zweiten Halbjahr 2023 sollen alle APIs für Anzeigen für Integrationstests verfügbar sein und es soll eine Analyse des Werts von Topics für Werbetreibende geben. Die Tests und die Veröffentlichung der Ergebnisse werden von der CMA überwacht, die die Daten, die Analyse und die Methodik überprüft. Wir möchten Sie bitten, Feedback an Google und die CMA zu senden.
Topics und FLEDGE Weitere Informationen zur Verwendung von Topics in der Gebotslogik von FLEDGE anfordern Sie können Themen in der Gebotslogik von FLEDGE verwenden. Wir arbeiten auch an einem Integrationsleitfaden, der weitere Details zur Implementierung enthält.
Benutzerdefinierte Rangfolge für Themenaufruf Rankings vom Anrufer anpassen lassen Das Problem bei benutzerdefinierten Themenrangfolgen oder -werten für jede Anzeigentechnologie besteht darin, dass dies zu einem Mechanismus werden könnte, mit dem eine Anzeigentechnologie die zurückgegebenen Themen beeinflussen kann, also zu einem Fingerprinting-Vektor.
Themenliste für Anruferpriorität Es wird ermöglicht, dass Aufrufer eine nach Priorität sortierte Liste von Themen angeben, die die Topics API basierend auf der Eignung zurückgibt. Wir besprechen diese Idee derzeit weiter und freuen uns über weitere Vorschläge.

FLEDGE

Feedbackthema Zusammenfassung Chrome-Antwort
Google Ad Manager Bedenken, dass Google Ad Manager die endgültige Entscheidung für FLEDGE-Auktionen trifft und Google Publisher-Tags und Google Ad Manager bevorzugt Mit FLEDGE kann jeder Publisher die Struktur der Auktion auswählen, einschließlich der Auswahl von Verkäufern der obersten Ebene und Komponentenverkäufern. Jeder Käufer und Verkäufer in einer Komponentenauktion weiß, wer der Verkäufer der obersten Ebene ist, und kann entscheiden, ob er ein Gebot abgeben möchte.
Nicht genügend Teilnehmer für FLEDGE-Tests Bitte, mehr Unternehmen dazu anzuregen, FLEDGE zu testen, z. B. durch Verbesserung der API-Funktionen und Entmutigung zu datenschutzverletzenden Alternativen wie Fingerprinting Die Privacy Sandbox wird in enger Zusammenarbeit mit der CMA und der ICO in mehreren Phasen eingeführt. Die funktionalen FLEDGE-Tests haben die erforderliche Stabilität und Leistung nachgewiesen. Google ermutigt die Branche weiterhin, die Sandbox-APIs zu testen. Vor Kurzem haben wir die Dokumentation Maximale Anzeigenrelevanz veröffentlicht, in der gezeigt wird, wie FLEDGE und andere APIs nach der Einstellung von Drittanbieter-Cookies wichtige Anwendungsfälle für die Werbebranche unterstützen können.

Andere Teile der Privacy Sandbox unterstützen bereits Maßnahmen zur Abschwächung von Tracking (siehe UA-CH, IP-Schutz und Maßnahmen zur Abschwächung des Bounce-Trackings). Sie werden im Laufe der Zeit weiter verbessert. Google möchte FLEDGE nicht zur einzigen praktikablen Lösung für das Targeting machen. Stattdessen arbeiten wir weiterhin mit der Branche und Regulierungsbehörden zusammen, um die besten datenschutzfreundlichen Werbetechnologien im Chrome-Browser zu entwickeln.
Anwendungsfälle für maschinelles Lernen Weitere Informationen dazu, wie Anwendungsfälle für maschinelles Lernen zum Trainieren von Algorithmen für Auktionsgebote in FLEDGE und Attribution Reporting unterstützt werden Wir sind uns bewusst, dass wir Testern dabei helfen müssen, die Privacy Sandbox-Technologien am besten anzuwenden. Wir haben damit begonnen, Richtlinien speziell zur Verwendung der verschiedenen Aspekte der Privacy Sandbox APIs als Eingaben für maschinelles Lernen zu veröffentlichen. In unserem neuesten Artikel Maximale Anzeigenrelevanz wird beschrieben, wie die Werbebranche diese Signale für maschinelles Lernen nutzen kann. Wir werden auch in Zukunft solche Leitfäden veröffentlichen.
FLEDGE-Schlüssel/Wert-Server abfragen Warum ist der K/V-Server öffentlich abfragbar? Der K/V-Server soll FLEDGE-Auktionen Echtzeitsignale zur Verfügung stellen. Daher muss der K/V-Server von den Geräten der Nutzer aus zugänglich sein, auf denen diese FLEDGE-Auktionen ausgeführt werden. Er muss also öffentlich zugänglich sein. Ein auf dem K/V-Server gespeicherter Wert kann nur von einer Partei abgerufen werden, die bereits den entsprechenden Schlüssel hat. Wenn eine Anzeigentechnologie also die Schlüssel nur an Browser weitergibt, die sich in der Interessengruppe befinden, und keine Schlüssel verwendet, die zufällig erraten werden können, können nur Browser, die den Wert für die Durchführung ihrer Auktion benötigen, ihn abrufen.
Wie funktioniert das Datums-/Uhrzeit-Targeting? Unterstützung für Datumsobjekte in der Gebotslogikfunktion Dazu haben Sie verschiedene Möglichkeiten. Käufer können ihren Verkäufer bitten, das aktuelle Datum und die aktuelle Uhrzeit anzugeben. Für Verkäufer sollte es einfach sein, diese Informationen allen Käufern zur Verfügung zu stellen. Käufer können Datum und Uhrzeit auch in ihrer Echtzeit-Schlüssel/Wert-Antwort angeben. Käufer können Datum und Uhrzeit auch als Teil ihrer kontextbezogenen Antwort in den pro-Käufer-Signalen angeben, die ein Verkäufer an das generateBid-Script des Käufers weitergeben kann.
Nutzereinstellungen Nutzer können Creatives nach Werbetreibenden blockieren, wenn sie über FLEDGE oder alternative Lösungen ausgeliefert werden. Nutzer können die Verwendung von Anzeigen-APIs in Chrome deaktivieren. Bei bestimmten Anzeigen ist der entsprechende Anzeigentechnologie-Anbieter am besten in der Lage, Einstellungen dafür vorzunehmen, welche Creatives ausgeliefert werden oder wie sie ausgewählt werden.
Klarere Zeitpläne Weitere Informationen zur Verfügbarkeit von Datenschutzmaßnahmen in FLEDGE anfordern, z. B. die Anforderung von abgegrenzten Frames Im ersten Quartal werden wir detailliertere Zeitpläne veröffentlichen.
Verwirrung melden Erläuterung dazu, wie FLEDGE-Berichte mit anderen APIs wie der Fenced Frames API und der Private Aggregation API funktionieren. In den kommenden Wochen werden wir eine Erläuterung zur Interaktion zwischen der Private Aggregation API, FLEDGE und Fenced Frames veröffentlichen.
Echtzeitgebote und FLEDGE Informationen zur Integration von FLEDGE in standardmäßige Echtzeitgebote. Die beiden Hauptfaktoren, die die Echtzeitgebote von Anbietern von Anzeigentechnologien erschweren, sind der Zugriff auf Daten auf Ereignisebene und eine einfachere Einbindung in die ARA. Im 1. Quartal werden wir Updates und Erläuterungen zu diesen beiden Themen senden.
Leistung von FLEDGE-Auktionen Tester berichten von hoher Latenz bei FLEDGE-Auktionen Wir freuen uns über Berichte von Testern, in denen sie ihre Ergebnisse und Anwendungsfälle teilen. Außerdem haben wir einige Vorschläge zur Verbesserung der Leistung von FLEDGE geteilt.

Parallel dazu haben wir dem Browser Tools hinzugefügt, mit denen Entwickler die Ursachen für langsame Auktionen besser diagnostizieren können. Außerdem haben wir die Hauptursachen für die beobachteten Latenzen systematisch behoben. Zu den jüngsten Verbesserungen gehören Zeitüberschreitungen für langsame Auktionen, eine Schnellfiltermethode für Bieter, eine Möglichkeit, FLEDGE-Worklets wiederzuverwenden, um Startkosten zu vermeiden, und laufende Arbeiten, um die kontextbezogene Anzeigenanfrage parallel zum FLEDGE-Start und zu Netzwerkabrufen auszuführen. Wir gehen davon aus, dass die Latenzoptimierung ein fortlaufender Dialog zwischen Chrome-Entwicklern und FLEDGE-Testern sein wird, der auf ihren praktischen Erfahrungen mit der API basiert.
Speicherlimit für die Größe von Interessengruppen Erhöhung der Größe einer einzelnen Interessengruppe von 50 KB Wir prüfen die Anfrage derzeit und suchen nach Feedback dazu, welcher Grenzwert am besten geeignet ist.
Von FLEDGE bereitgestellte Daten mit selbst erhobenen Cookies kombinieren Unterstützt FLEDGE die Integration in die selbst erhobenen Daten eines Werbetreibenden? FLEDGE wurde entwickelt, um Werbung mit den selbst erhobenen Daten eines Werbetreibenden zu unterstützen. FLEDGE soll Werbetreibenden jedoch nicht dabei helfen, das Browserverhalten einer Person auf anderen Websites als der eigenen Website des Werbetreibenden zu ermitteln. Das Verknüpfen von Browserverhalten außerhalb Ihrer Website mit selbst erhobenen Daten verstößt gegen die Ziele der Privacy Sandbox.

In den kommenden Wochen werden wir Integrationsleitfäden mit weiteren Details dazu veröffentlichen, wie FLEDGE die Einbindung von selbst erhobenen Daten unterstützt.
Wert für die k-Anonymität Wie wird der Wert „K“ zu „k-anon“ festgelegt und wird er veröffentlicht? Der Wert „K“ wird noch finalisiert. Wir werden Sie über die Entwicklung unserer Pläne auf dem Laufenden halten. Wir möchten mehr darüber erfahren, wie ein unbekannter K-Wert die FLEDGE-Vorbereitung und die Definition des Umfangs des ML-Modelltrainings beeinträchtigen kann. Wir freuen uns über zusätzliches Feedback zu diesem Thema.
Unterstützung mehrerer SSPs Wie werden mehrere SSPs in FLEDGE unterstützt? FLEDGE unterstützt Auktionen mit mehreren Verkäufern, wie in diesem Vorschlag beschrieben.
Sichtbarkeit der Gebotslogik Bedenken, dass die DSP-Gebotslogik in JavaScript freigegeben wird Bei der aktuellen Gebotslogik kann JavaScript von anderen abgerufen werden. Wir würden uns aber über weitere Rückmeldungen freuen, warum dies für DSPs ein Problem sein könnte.
prebid.js Wann wird prebid.js in FLEDGE unterstützt? Nur Prebid.js-Versionen 7.14 und höher unterstützen das FLEDGE-Modul. Publisher, die FLEDGE testen möchten, müssen das FLEDGE-Modul hinzufügen und ihre Prebid-Instanz aktualisieren.
Benutzerdefinierte Funktionen in FLEDGE Wie werden benutzerdefinierte Funktionen (UDFs) in FLEDGE unterstützt? Dies sind Funktionen, die von Endnutzern programmiert werden können, um die Funktionalität der API zu erweitern. Erläuterung Diese Funktion wird noch weiterentwickelt. Wir freuen uns daher über zusätzliches Feedback zu Anwendungsfällen.
Lockerung der Same-Origin-Einschränkung für Ressourcen von Interessengruppen Lockerung der Einschränkung für Ressourcen von Interessengruppen mit demselben Ursprung, um bestimmte Anwendungsfälle für Anzeigentechnologien zu ermöglichen Bei der aktuellen Implementierung von FLEDGE müssen biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl und trustedBiddingSignalsUrl denselben Ursprung wie der Inhaber der Interessengruppe haben.

Die Einschränkung soll bestimmte Ausnutzungen durch Angreifer verhindern, wie hier erläutert.
interestGroup Ownership Anfrage, die Verwendung von „joinInterestGroup“ für dieselbe Interessengruppe auf Websites durch Anzeigentechnologien einzuschränken Unser Fokus liegt darauf, wie Zielgruppen verwendet werden, nicht darauf, wie sie erstellt werden. Wir besprechen derzeit mögliche Ansätze und freuen uns über weitere Vorschläge.
Ablauf des Serverschlüssels für den Dienst für Schlüssel/Wert-Paare Diskussion zum Entfernen von Serverschlüsseln, sobald die entsprechenden Interessengruppen abgelaufen sind Wir arbeiten an Lösungen für das Ablaufen von Schlüsseln und freuen uns über Feedback.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Zugriffe aus Ursprungstests Der aktuelle Traffic für den Test des Ursprungs reicht nicht aus, um Nutzwerttests durchzuführen. Die aktuellen Origin Trials sollen es Akteuren des Ökosystems ermöglichen, Funktionstests durchzuführen, um sicherzustellen, dass die API wie vorgesehen funktioniert. Wir sind uns bewusst, dass für die Durchführung von Nutzwerttests größere Mengen an Traffic erforderlich sind, sobald die Entwicklung der verschiedenen Privacy Sandbox APIs fortgeschritten ist. Gemäß dem aktuellen Testzeitplan wird dies bis zur allgemeinen Verfügbarkeit (d. h. bis die Technologien für die Anwendungsfälle eingeführt und für 100% des Chrome-Traffics verfügbar sind) im 3. Quartal 2023 der Fall sein (siehe aktuellen Zeitplan auf privacysandbox.com). Wir freuen uns über zusätzliches Feedback zu Anwendungsfalltests, für die zusätzliche Zugriffe erforderlich sind.
Überschneidung der Funktionen verschiedener Privacy Sandbox-Mess-APIs Bedenken hinsichtlich der Überschneidung mehrerer Analysemethoden durch die Privacy Sandbox erhöhen die Komplexität, z. B. die Attribution Reporting API und die Private Aggregation API. Wir arbeiten an einer besseren Dokumentation, um die verschiedenen Anwendungsfälle für die APIs zu verdeutlichen. Wir freuen uns über zusätzliches Feedback dazu, in welchen Bereichen noch Erklärungen erforderlich sind. Die Attribution Reporting API ist beispielsweise speziell für die Conversion-Analyse gedacht, während die Private Aggregation API und die Shared Storage API APIs für allgemeine Zwecke sind, die eine breitere Palette von standortübergreifenden Analyseanwendungsfällen unterstützen sollen.
Fehlgeschlagene Berichtsanfrage noch einmal versuchen Es wird erläutert, wie oft ein Berichtsanfrage wiederholt wird, wenn sie fehlschlägt. Hier finden Sie weitere Informationen dazu. Zusammenfassend lässt sich sagen, dass Berichte nur gesendet werden, wenn der Browser aktiv ist bzw. online ist. Nach dem ersten Sendefehler wird der Bericht nach 5 Minuten noch einmal gesendet. Nach dem zweiten Fehler wird der Bericht nach 15 Minuten noch einmal versucht. Danach wird die Meldung nicht gesendet.
Verzögerung der Auswertung Wie lange dauert es, bis die Berichte verfügbar sind? Wir möchten Feedback von Nutzern erhalten, wenn es zu Berichtsverzögerungen kommt. Parallel dazu erheben wir Daten, um diese Verzögerungen weiter zu untersuchen.
Seiten vorab rendern Funktioniert die ARA-Attribution auf Seiten, die vorab gerendert werden? Die Attributionsregistrierung wird auf Seiten mit Pre-Rendering bis zur Aktivierung (tatsächlicher Klick oder Aufruf) verschoben. Das bedeutet, dass wir den Ping für die Anfrage „attributionsrc“ verschieben.
Conversion-Steigerung messen Conversion-Steigerung mit A/B-Tests in derselben Domain messen Für Websites lässt sich die Conversion-Steigerung mit A/B-Tests in derselben Domain anhand von Attributionsberichten messen. Sie können ihre A/B-Parameter mit der Aggregate API als Schlüssel codieren und dann Zusammenfassungsberichte für die Conversion-Werte nach diesen Schlüssel-Buckets erhalten.
(Auch in Q3 erfasst) Domainübergreifende Conversions Domainübergreifende Conversions erfassen, z. B. mit zwei oder mehr Zielen Update für das 4. Quartal:

Wir haben einen Vorschlag veröffentlicht, die Einschränkung für Landingpage-Ziele aufzuheben, damit domainübergreifende Unterhaltungen erfasst werden können. Dieser Vorschlag wurde umgesetzt.
(wurde auch im 3. Quartal gemeldet)
Ablaufeinstellung im Conversion-Bericht 		Unterstützung für Berichtsfilter / Ablaufzeit von weniger als 24 Stunden anfordern Update für das 4. Quartal:

Wir haben diesen Pull-Request veröffentlicht, mit dem Ablaufzeiträume und Berichtszeitraum voneinander getrennt werden, um den Trade-off zwischen Berichtsverzögerung und Ablauf der Conversion zu verringern. Diese Funktion ist jetzt in M110 verfügbar.
Betrug und Missbrauch Anfragen von Werbetreibenden und Marketingfachleuten, Daten nach Publisher-Websites zu segmentieren und zusammenzuführen, auf denen ihre Anzeigen ausgeliefert werden. Dies würde auch mehr Aufschluss über potenziell betrügerische Werbepraktiken geben. Dieses Feedback wird hier aktiv diskutiert und wir freuen uns über weitere Beiträge.
(Auch im 3. Quartal gemeldet) Verzögerung bei Berichten auf Ereignisebene Die Verzögerung von 2 bis 30 Tagen bei Berichten auf Ereignisebene ist für bestimmte Anwendungsfälle möglicherweise zu lang. Für Berichte auf Ereignisebene sind standardmäßig Berichtszeitraume von 2, 7 und 30 Tagen verfügbar. Das kann mit dem Parameter „expiry“ geändert werden. Anbieter von Anzeigentechnologien können die Gültigkeitsdauer mit mindestens einem Tag konfigurieren, um Berichte in weniger als zwei Tagen zu erhalten. Aus Datenschutzgründen beschränken wir die Gültigkeitsdauer auf einen Tag. Eine detailliertere Berichterstellung könnte zu Timing-Angriffen führen. Außerdem können Sie unabhängige „expiry“-Parameter für Ereignisebene und aggregierte Berichte festlegen. Weitere Informationen finden Sie hier. Außerdem erhält Google Ads keine speziellen Berichtsfenster, die andere Anbieter von Anzeigentechnologien nicht über die Attribution Reporting API erhalten.
Dieselbe Quelle für die Meldung Antrag auf Aufhebung der Anforderung, dass der Ursprung der Quellenregistrierung mit dem Ursprung der Conversion-Registrierung identisch sein muss Wir empfehlen, HTTP-Weiterleitungen zu verwenden, um die Registrierung zu delegieren und diesen Anwendungsfall zu lösen. Wir freuen uns über weiteres Feedback zu den neuen Richtlinien.
Conversion-Tracking Es muss unterschieden werden, ob die Conversion vor oder nach bestimmten vom Werbetreibenden festgelegten Uhrzeiten erfolgt ist. Die Attribution Reporting API unterstützt das Festlegen eines Ablaufzeitraums und einer Priorität für die Quellenverfolgung. Wenn Sie beide verwenden, ist es technisch möglich, eine Conversion, die innerhalb eines Zeitraums von X Tagen erfolgt ist, separat von einer Conversion zu zuordnen, die nach X Tagen erfolgt ist.
Rauschsimulation Anforderung, das unterschiedliche Conversion-Volumen pro Bucket simulieren zu können, um die Auswirkungen auf Werbetreibende mit weniger Conversions zu verstehen In zukünftigen Versionen von Noise Lab werden wir Möglichkeiten zur Simulation dieser Effekte hinzufügen. Wir freuen uns über zusätzliches Feedback.
Berichte zu Mobilgeräten Wird der Bericht auch gesendet, wenn Chrome auf einem Mobilgerät im Hintergrund ausgeführt wird? Momentan wird der Bericht auch auf Mobilgeräten nicht gesendet, wenn Chrome im Hintergrund läuft. Das wird sich wahrscheinlich ändern, wenn die API in die Android Privacy Sandbox eingebunden wird. Weitere Informationen finden Sie hier. Die Android Privacy Sandbox ist nicht Teil der von der CMA akzeptierten Verpflichtungen.
Datenverfügbarkeit Bedenken, dass Google über Privacy Sandbox APIs zusätzlichen Zugriff auf Daten hat Erstens: Google Ads erhält keinen bevorzugten Zugriff auf Daten aus der Attribution Reporting API oder anderen Privacy Sandbox APIs. Dieses Problem wird auch im Abschnitt „Allgemeines Feedback“ unter „Interoperabilität“ behandelt. Dort finden Sie weitere Informationen zu den Verpflichtungen von Google.

Zweitens: Google erkennt an, dass der datenschutzfreundlichere Ansatz mit Rauschen bei kleineren Datenmengen einen größeren Einfluss haben kann. Es gibt jedoch einige Möglichkeiten, die Auswirkungen zu verringern. So kann dieses Problem beispielsweise durch Methoden wie die Aggregation über einen längeren Zeitraum behoben werden. Es bleibt jedoch unklar, ob Schlussfolgerungen, die auf sehr kleinen Datenmengen beruhen (z. B. ein oder zwei Käufe), für Werbetreibende überhaupt aussagekräftig sind. Während des Ursprungstests haben wir Tester dazu ermutigt, mit einer Vielzahl von Datenschutz- und Rauschparametern zu experimentieren, damit sie detaillierteres Feedback zu diesem Problem geben können.

Verdecktes Tracking einschränken

Reduzierung des User-Agents

Feedbackthema Zusammenfassung Chrome-Antwort
Reduzierung des User-Agents bis zur vollständigen Bereitschaft des Web-Ökosystems verzögern Es bleibt nicht genügend Zeit, sich auf die bevorstehenden Änderungen bei der User-Agent-Reduzierung vorzubereiten. Wir gehen auf dieses Feedback im vollständigen Bericht unter „Bedenken der Stakeholder“ im Abschnitt „Die Interaktion von Google mit der CMA“ ein.
Reduzierung des User-Agents bis zur vollständigen Bereitschaft des Web-Ökosystems verzögern Anfrage zur Verzögerung der Einführung der User-Agent-Reduzierung bis zur Bereitstellung von strukturierten User-Agents (SUA) Das Google Ads-Team hat im Oktober 2021 die Erweiterung „Structured User-Agent“ (siehe Spezifikation) für OpenRTB vorgeschlagen. Diese Erweiterung wurde in die Spezifikationsaktualisierung 2.6 aufgenommen, die im April 2022 veröffentlicht wurde.

Es gibt einige Hinweise darauf, dass SUA bereits bereitgestellt und verfügbar ist. Das zeigt der Blogpost von Scientia Mobile, in dem beschrieben wird, wie mit UA-CH und der WURFL API eine SUA erstellt wird.

###

User-Agent-Client-Hints

Feedbackthema Zusammenfassung Chrome-Antwort
UA-CH mit anderen Methoden zum Schutz vor verschleiertem Tracking testen Anleitung zum Testen aller Privacy Sandbox APIs und Fingerprinting-Techniken in einem ganzheitlichen Ansatz Unser Testplan wurde so konzipiert, dass er die asynchronen Zeitpläne für die Entwicklung einiger der Anti-Fingerprinting-Maßnahmen widerspiegelt, im Gegensatz zum Rest der Sandbox-Vorschläge. Es wird darauf hingewiesen, dass einige Maßnahmen zur Verhinderung von Fingerprinting (z.B. Datenschutzbudget, IP-Schutz und Minderung von Bounce-Tracking) erst nach der Einstellung von Drittanbieter-Cookies vollständig entwickelt und für die allgemeine Verfügbarkeit bereit sind.

Diese Maßnahmen zur Verhinderung von Fingerprinting werden nicht in quantitative Tests einbezogen, sondern einer qualitativen Bewertung unterzogen, die auf den zum Zeitpunkt des Stillstands verfügbaren Fakten basiert.
(wurde auch im 2. Quartal gemeldet)
Leistung		 Bedenken hinsichtlich der Latenz beim Empfangen von Hinweisen über Critical-CH (beim ersten Laden der Seite) Siehe unten im Abschnitt zu UA-CH
Unzureichendes Feedback Das Feedback der Community zur Änderung von UA zu CH ist möglicherweise nicht ausreichend, was zu Bedenken hinsichtlich der mangelnden Kenntnis der Community führt. Wir haben unsere Pläne proaktiv geteilt, um ein sorgfältiges Roll-out zu ermöglichen, das Unterbrechungen minimiert.

Die Pläne zur Reduzierung von User-Agents und zur UA-CH API wurden am 18. März 2022 der W3C Anti-Fraud Community Group und am 20. Januar 2022 der Web Payments Working Group und der Web Payments Security Interest Group vorgestellt. Während oder nach den Präsentationen wurden keine wesentlichen Bedenken geäußert.

Google hat proaktiv mit mehr als 100 Website-Betreibern Kontakt aufgenommen, um Feedback zu erhalten. Außerdem hat Google über Blink-Dev-Kanäle das Roll-out der User-Agent-Einschränkung auf Grundlage von Feedback von Stakeholdern des Ökosystems öffentlich kommuniziert.
Timing Bedenken hinsichtlich des Zeitplans für die Einführung und der Bereitschaft der Branche Siehe unten im Abschnitt zu UA-CH
Status der Chrome-Plattform Aktualisierung der Chrome-Statusseite für UA-CH angefordert Der Eintrag in chromestatus wurde am 19. Dezember auf „Gemischte Signale“ aktualisiert.

IP-Schutz (früher Gnatcatcher)

Feedbackthema Zusammenfassung Chrome-Antwort
Funktion aktivieren oder deaktivieren Ist die Datenleihe von IP-Adressen standardmäßig aktiviert oder deaktiviert? Unser Ziel ist es, allen Nutzern einen IP-Schutz zu bieten. Aus diesem Grund prüfen wir derzeit Optionen für die Nutzerauswahl für den IP-Schutz.
Anwendungsfall für IP-Adressen bei selbst erhobenen Daten Ist es möglich, nach der IP-Schutzfunktion IP-Adressen zu verwenden, um User Journeys über Domains von selbst erhobenen Daten zusammenzuführen? Wie bereits veröffentlicht, liegt der Schwerpunkt des IP-Schutzes zunächst auf dem Tracking im Drittanbieterkontext. Domains von selbst verwalteten Websites sind also nicht betroffen.
Anwendungsfälle für Werbetechnologie Wie können Unternehmen mit dem IP-Schutz Maßnahmen zur Betrugsprävention einrichten? Wir sind uns der Bedeutung der IP-Adresse als Signal für die Betrugsbekämpfung im heutigen Web bewusst. Im Rahmen unserer Verpflichtungen gegenüber der CMA (Absatz 20) haben wir erklärt, dass wir den IP-Schutz nicht implementieren, ohne angemessene Maßnahmen zu ergreifen, um Websites bei der Durchführung von Anti-Spam- und Anti-Betrugsmaßnahmen zu unterstützen. Eine unserer wichtigsten Prioritäten besteht darin, zu verstehen, wie sich der IP-Schutz auf Anwendungsfälle und Erkennungsfunktionen zur Betrugsprävention auswirkt, damit wir weiter in datenschutzfreundliche Technologien investieren können, die Unternehmen dabei helfen, die Sicherheit im Web zu gewährleisten. Wir freuen uns über Feedback und Vorschläge, die auf die Anforderungen von Sicherheits- und Betrugspräventionsunternehmen ausgerichtet sind, auch wenn sich die Signale im Laufe der Zeit ändern.
Betrug und Missbrauch Ist der Schutz vor Denial-of-Service-Angriffen (DoS) im IP-Schutz enthalten? Wir möchten den Datenschutz verbessern und gleichzeitig das Web sicherer machen. Der Schutz vor Denial-of-Service-Angriffen ist ein wichtiger Anwendungsfall für den Missbrauch, der bei der Entwicklung berücksichtigt werden sollte. Wir hoffen, dass wir die Auswirkungen auf den DoS-Schutz sowohl durch die Gestaltung des IP-Schutzes selbst als auch durch neue Lösungen zur Missbrauchsprävention minimieren können. Da der IP-Schutz anfangs auf eingebettete Dienste von Drittanbietern ausgerichtet ist, haben einige Stakeholder angegeben, dass er nur begrenzte Auswirkungen auf den DoS-Schutz für Websites von Webpublishern haben sollte. Wir bitten jedoch weiterhin um öffentliches Feedback, um das Risiko für DoS-Anwendungsfälle, insbesondere für eingebettete Dienste von Drittanbietern, zu bewerten.

Parallel dazu prüfen wir Feedbackmechanismen zu Missbrauch und Client-Blockierungsmechanismen, mit denen eine Website oder ein Dienst einen Spammer blockieren kann, ohne ihn zu identifizieren.
Inhaltsfilter Inhaltsfilterung mit IP-Schutz Unterschiedliche Unternehmen haben unterschiedliche Anforderungen in Bezug auf das Filtern von Inhalten und die Anpassung der Nutzererfahrung. Viele dieser Anwendungsfälle basieren derzeit nicht auf IP-Adressen und sollten daher vom IP-Schutz nicht betroffen sein. Ein Verlag oder Webpublisher, der seine Inhalte anpassen und die Interaktionen steigern möchte, kann beispielsweise eigene Cookies oder partitionierte Drittanbieter-Cookies (CHIPs) verwenden, um die Interessen eines Nutzers und seine bisherigen Interaktionen mit dem Verlag oder Webpublisher zu ermitteln. Oder ein Anzeigentechnologie-Partner, der sich darauf konzentriert, die richtige Anzeige für den richtigen Nutzer auszuliefern, kann FLEDGE und Topics einbinden, um beispielsweise ähnliche Anzeigenergebnisse zu erzielen wie heute mit Drittanbieter-Cookies oder anderen websiteübergreifenden Tracking-Technologien.

Wir prüfen auch, ob wir dem IP-Schutz neue datenschutzfreundliche Funktionen hinzufügen können, z. B. eine grobe Standortbestimmung, um die Inhaltsfilterung zu unterstützen, wenn die vorhandenen Mechanismen möglicherweise nicht ausreichen. Wir freuen uns über zusätzliches Feedback zu Anwendungsfällen für die Inhaltsfilterung, die vom IP-Schutz betroffen sein könnten.
(Auch im 3. Quartal gemeldet)
Anwendungsfälle für die Standortermittlung		 Der IP-Schutz kann dazu führen, dass legitime Anwendungsfälle der Standortbestimmung in Zukunft nicht mehr funktionieren, z. B. die personalisierte Bereitstellung von Inhalten auf Grundlage der Standortbestimmung. Update für das 4. Quartal:

Wir arbeiten mit Stakeholdern zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Hier können Sie uns Feedback zur Detailgenauigkeit der IP-Standortbestimmung geben.

Datenschutzbudget

Feedbackthema Zusammenfassung Chrome-Antwort
Klarere Dokumentation Weitere Beispiele, damit Stakeholder einschätzen können, was nach der Implementierung von Privacy Budget eingeschränkt werden könnte Der Vorschlag für ein Datenschutzbudget wird derzeit noch diskutiert und wurde von keinem Browser implementiert. Das früheste Datum der skalierten Verfügbarkeit ist das früheste Datum, an dem das Privacy-Budget erzwungen werden kann. Das wird erst nach der Entfernung von Drittanbieter-Cookies im Jahr 2024 der Fall sein. Derzeit haben wir keine weiteren Dokumente für Sie.

Wir teilen dir weitere Details zum Vorschlag mit, sobald er fertig ist. In der Zwischenzeit können Stakeholder Feedback geben, das bei der Entwicklung des Vorschlags hilfreich sein könnte.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 3. Quartal gemeldet) Domainlimit Mehr verknüpfte Domains beantragen Update für das 4. Quartal:

Wir haben FPS für lokale Tests veröffentlicht, einschließlich eines Mock-Set-Einreichungsprozesses auf GitHub und einer Flagge zum lokalen Testen von rSA und rSAFor. Außerdem haben wir zwei offene Treffen für Entwickler zu FPS veranstaltet, um weitere Fragen zu Anwendungsfällen für die zugehörige Untergruppe zu beantworten. Wir empfehlen Entwicklern, die FPS-Funktion zu testen, um Feedback dazu zu geben, wie sich die Domainbeschränkung für die zugehörige Teilmenge auf die Nutzerfreundlichkeit von FPS für ihre Anwendungsfälle auswirken würde.

Wir haben in WICG-Anrufen klargestellt, dass wir uns bei Chrome für eine praktikable Lösung einsetzen, die auch die Datenschutzinteressen der Nutzer berücksichtigt. In diesem Zusammenhang würden wir uns Feedback von der Community zu bestimmten Anwendungsfällen freuen, die von der Domainbeschränkung betroffen sein könnten. So kann das Team nach Möglichkeiten suchen, diese Anwendungsfälle zu berücksichtigen und gleichzeitig den Datenschutz für Nutzer zu schützen.
Weitere Informationen zu den Maßnahmen zur Missbrauchsprävention anfordern Was passiert, wenn einer Gruppe eine Domain hinzugefügt wird, für die keine Einwilligung erteilt wurde? Am 2. Dezember 2022 haben wir hier Richtlinien für die Einreichung von Sets mit selbst erhobenen Daten veröffentlicht.

Wie in den Einreichungsrichtlinien erläutert, wird jede festgelegte Änderungsverwaltung einem Validierungsprozess auf GitHub folgen und diesen einhalten, einschließlich der Validierung der Inhaberschaft, was dieses Risiko minimieren sollte.
Minderung des Missbrauchsrisikos Bedenken, dass First-Party-Sets ausgenutzt werden können Wir prüfen derzeit, wie wir die technischen Prüfungen für Untergruppentypen ausweiten können, und suchen hier aktiv nach weiteren Vorschlägen von der Community.
Anwendungsfälle für Google Ads Fragen dazu, ob Sets mit selbst erhobenen Daten für das Anzeigen-Targeting verwendet werden sollten Wir unterstützen keine Anwendungsfälle für das Anzeigen-Targeting für selbst erhobene Datensätze. Wir empfehlen, die für solche Anwendungsfälle verfügbaren Google Ads APIs zu verwenden.
(Auch im 3. Quartal gemeldet) Richtlinie Bedenken, dass die FPS nicht mit den Verpflichtungen der CMA in Bezug auf anwendbare Datenschutzgesetze übereinstimmt, da die DSGVO keine Beschränkung der Anzahl der Websites in einem Set vorsieht, während die FPS eine Beschränkung auf drei vorsieht Unsere Antwort bleibt unverändert:

„Google verpflichtet sich weiterhin gegenüber der CMA, die Privacy Sandbox-Vorschläge so zu entwerfen und umzusetzen, dass der Wettbewerb nicht durch Bevorzugung des eigenen Geschäfts von Google verzerrt wird. Außerdem werden die Auswirkungen auf den Wettbewerb in der digitalen Werbung, auf Publisher und Werbetreibende sowie die Auswirkungen auf den Datenschutz und die Einhaltung der Datenschutzgrundsätze gemäß den anwendbaren Datenschutzgesetzen berücksichtigt. Die geäußerte Bedenken ergeben keine Inkompatibilität mit der DSGVO. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen entspricht.“
Alternativer Vorschlag DSGVO-konforme Sets Zusätzlich zum Feedback des Ökosystems zum Vorschlag zur Einführung von „GDPR-geprüften Sets“ hat Chrome Bedenken hinsichtlich der folgenden Einschränkungen dieses alternativen Vorschlags:

  • „GDPR Validated Sets“ (DSGVO-konforme Sets) sollen der DSGVO entsprechen, was jedoch nicht wirklich klar ist. Im Gegensatz dazu muss Google gemäß seinen Verpflichtungen die „Auswirkungen auf den Datenschutz“ allgemeiner berücksichtigen. In ihrer Entscheidung, die Verpflichtungen zu akzeptieren, weist die CMA darauf hin, dass dies von der Verpflichtung von Google abweicht, die „Einhaltung der Datenschutzgrundsätze gemäß den anwendbaren Datenschutzgesetzen“ zu berücksichtigen. Dies spiegelt laut CMA die Tatsache wider, dass Google an die anwendbaren Datenschutzgesetze gebunden ist, sowohl im Hinblick auf die Verpflichtungen als auch allgemein.
  • Wir haben Bedenken im Hinblick auf den Datenschutz hinsichtlich des Vorschlags, dass Domains in mehreren Sets erscheinen dürfen. Sets mit selbst erhobenen Daten sollen bestimmte Anwendungsfälle unterstützen, die derzeit auf Drittanbieter-Cookies angewiesen sind, ohne ein umfassendes websiteübergreifendes Tracking zu ermöglichen. Wenn Domains mehreren Sets hinzugefügt werden könnten, würde ein wichtiger Datenschutzmechanismus des Vorschlags für Sets mit selbst erhobenen Daten aufgehoben, ohne dass andere sinnvolle Einschränkungen eingeführt würden.
  • Für DSGVO-konforme Sets wird außerdem vorgeschlagen, „einen Satz als Gruppe von Datenverantwortlichen und -verarbeitern zu definieren, die eine gemeinsame Nutzungsrichtlinie teilen“. Das ähnelt der Anforderung in unserem ursprünglichen Vorschlag für First-Party-Sets, dass alle Parteien in einem Set dieselbe Datenschutzerklärung haben müssen. Aufgrund des starken Feedbacks aus der Community, in dem Bedenken hinsichtlich der datenschutzerklärungsbasierten Anforderungen geäußert wurden, haben wir diese Anforderung inzwischen entfernt. So haben wir beispielsweise von Website-Publishern gehört, dass die Einhaltung einer gemeinsamen Datenschutzerklärung aufgrund von Produkt- und geografischen Unterschieden nicht möglich ist. Dies ist eine der Herausforderungen, die von Mitgliedern der W3C-Community genannt wurden (1, 2, 3). Wir sind der Meinung, dass für diesen Vorschlag dieselben Herausforderungen gelten würden.

Seit dieser Alternative wurde in Chrome der Vorschlag für Sets mit selbst erhobenen Daten aktualisiert und Richtlinien für die Einreichung zum Erstellen neuer Sets veröffentlicht.

Fenced Frames API

Feedbackthema Zusammenfassung Chrome-Antwort
Einschränkungen für eingezäunte Frames während der Betriebszeit Welche Einschränkungen gelten derzeit für Fenced Frames während des Ursprungstests? Wir arbeiten an einer Dokumentation zu den Einschränkungen und zum Implementierungsstatus, die wir im ersten Quartal 2023 veröffentlichen werden.
Mehrere Anzeigen in einem einzigen eingegrenzten Frame Anzeigen mehrerer Werbetreibender in einem eingegrenzten Frame in einer Auktion ausliefern lassen Derzeit wird diese Anfrage nicht aktiv entwickelt. Wir freuen uns aber über zusätzliches Feedback, wenn Akteure des Ökosystems diese Funktion für wichtig halten.
Web Bundles Welche Anforderungen und welcher Support sind für Web-Bundles mit eingezäunten Frames geplant? Wir können derzeit nicht sagen, ob dies in Zukunft erforderlich sein wird. Alle Änderungen werden im Voraus angekündigt und erst nach der Einstellung von Drittanbieter-Cookies erzwungen. In dieser Erklärung finden Sie den aktuellen Status.

Shared Storage API

Feedbackthema Zusammenfassung Chrome-Antwort
Gemeinsamer Speicherplatz für Werbetechnologien Unklarheiten bei der Verwendung von freigegebenen Speichern für Anwendungsfälle von Ad Tech Die Shared Storage API und die Private Aggregation API können für verschiedene Arten von Messungen verwendet werden, bei denen eine websiteübergreifende Speichermessung erforderlich ist. Hier finden Sie einige Beispiele.

Wir gehen davon aus, dass Anbieter von DSPs und Analyselösungen die Hauptintegratoren für Anwendungsfälle im Bereich Werbung sein werden.

CHIPs

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 3. Quartal gemeldet) Anforderung an Partitionen Fügen Sie eine explizite Verhaltensanforderung für das Attribut „Partitioniert“ für selbst erhobene Cookies hinzu. Update für das 4. Quartal:

Nach Diskussionen auf GitHub und PrivacyCG-Anrufen haben wir uns darauf geeinigt, dass partitionierte Cookies, die auf selbst erhobenen Daten basieren, den Partitionsschlüssel (A,A) verwenden, wobei „A“ die Top-Level-Website ist. Wir werden dieses Verhalten in der Erläuterung und in der Spezifikation dokumentieren.
Cookie-Verwaltung Gibt es Tools zum Verwalten oder Verwalten von selbst erhobenen oder Drittanbieter-Cookies? Mit den Chrome-Entwicklertools und NetLog können Sie Websites testen, bei denen Drittanbieter-Cookies blockiert sind. Beide Tools melden, wenn Cookies aufgrund der Nutzerkonfiguration blockiert werden. Wir freuen uns über Feedback dazu, welche zusätzlichen Prüfungen Sie sich für Websites wünschen.

FedCM

Feedbackthema Zusammenfassung Chrome-Antwort
Der IdP benötigt Informationen zum RP, um eine Sitzung zuzulassen Problem, wenn ein Nutzer versucht, sich über zwei verschiedene RPs beim Feide-IdP anzumelden Wir besprechen derzeit mögliche Lösungen für dieses Problem.
Interoperabilität Bedenken hinsichtlich der Auswirkungen von FedCM auf die Beziehung zwischen Nutzern und den Websites, auf denen sie sich mit FedCM anmelden, sowie hinsichtlich der „Interoperabilität“ zwischen Websites FedCM soll Dienste für föderierte Identitäten, die derzeit auf Drittanbieter-Cookies angewiesen sind, auch dann unterstützen, wenn Drittanbieter-Cookies aus Chrome entfernt werden. Wir gehen davon aus, dass FedCM nur eine Option für solche Dienste sein wird. Identitätsanbieter (IdPs) und vertrauende Seiten (RPs) können andere Technologien verwenden, die ihren Anforderungen besser entsprechen.

Anscheinend beruhen Bedenken hinsichtlich der Beziehung zwischen Nutzern und RPs und der Interoperabilität auf einem Missverständnis des FedCM-Vorschlags. Bei FedCM entscheiden die Identitätsanbieter, welche Informationen sie in welcher Form mit einem RP teilen, sobald sich der Nutzer auf der Website des RPs angemeldet hat. FedCM schreibt IdPs nicht vor, „eine eindeutige pseudonymisierte Kennung für jede [RP] zu erstellen, bei der sich der Nutzer authentifiziert“. Stattdessen kann jeder IdP in FedCM auswählen, ob er die tatsächliche Kennung des Nutzers, eine Website-spezifische Version dieser Kennung oder eine andere Version dieser Informationen freigeben möchte.

(Die FedCM-Spezifikation identifiziert die websiteübergreifende Korrelation als Datenschutzrisiko im Zusammenhang mit der API und spricht über gezielte (websitespezifische) Kennungen als mögliche Abhilfe. Die Entscheidung, ob gerichtete IDs verwendet werden, liegt jedoch in der Verantwortung der Identitätsanbieter und wird nicht vom Browser erzwungen.)

FedCM bietet bereits eine Nutzerauswahl in Bezug auf die Identität. Wenn ein Nutzer beispielsweise mehrere Identitäten beim selben IdP hat (z.B. ein Arbeitsprofil und ein privates Profil), kann er mit FedCM auswählen, mit welcher Identität er sich auf der Website des RP anmelden möchte. Darüber hinaus entscheidet jeder RP selbst, welche Identitätsanbieter auf seiner Website unterstützt werden. Ein Aspekt dieser Entscheidung ist der Mechanismus, auf den ein Identitätsanbieter setzt, sei es FedCM oder eine andere Technologie. Auch hier werden diese Auswahlmöglichkeiten für RPs oder IdPs nicht vom Browser vorgegeben.

Spam und Betrug bekämpfen

Private State Token API

Feedbackthema Zusammenfassung Chrome-Antwort
Umgang mit Bots Was passiert, wenn der Aussteller feststellt, dass Private State Tokens an Bots ausgestellt wurden? Damit Tokens, die für Bots ausgestellt wurden, nicht lange im System verbleiben, sollten Aussteller die Schlüssel, mit denen sie Tokens signieren, regelmäßig rotieren. So laufen alte Tokens, die mit einer potenziell fehlerhaften Ausstelllogik ausgestellt wurden, ab und Websites können neuere Tokens mit aktualisierter Ausstelllogik einlösen.
Einreichung von Formularen auf derselben Website Können Private State Tokens für Formularübermittlungen auf derselben Website verwendet werden, die eine vollständige Seitennavigation erfordern (d.h. Content-Type: application/x-www-form-urlencoded), anstatt einer Anfrage von den APIs „fetch“ oder „XMLHttpRequest“? Das wird derzeit in der ersten Version von Private State Tokens nicht unterstützt. Wir freuen uns über Feedback aus der Community, wenn es eine große Nachfrage nach diesem Anwendungsfall gibt.
Serverseitige Überprüfung Fragen dazu, ob Private State Tokens serverseitig verifiziert werden können Tokens werden beim Aussteller eingelöst. Dieser erstellt dann einen Erstattungseintrag, der das Token selbst oder einen signierten Wert enthalten kann, der aus dem Token abgeleitet wurde. Server können diesen Erstattungseintrag verwenden, um die Echtheit des Tokens zu überprüfen. Wir gehen davon aus, dass verschiedene Ausstellersysteme unterschiedliche Standards für die Interpretation ihrer Erstattungseinträge entwickeln werden.