Feedbackbericht – 4. Quartal 2022

Vierteljährlicher Bericht für das 4. Quartal 2022 mit einer Zusammenfassung des Feedbacks, das wir zu den Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome erhalten haben.

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 Zusammenfassung Chrome-Antwort
(Auch in F3 erwähnt)

Nützlichkeit für verschiedene Arten von Stakeholdern		 Bedenken, dass die Privacy Sandbox-Technologien größere Entwickler bevorzugen und dass (kleinere) Nischenwebsites einen höheren Beitrag leisten als generische (größere) Websites Unsere Antwort im 3. Quartal bleibt unverändert:

„Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch Selbstausübung des eigenen Unternehmens verzerrt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb in der digitalen Werbung sowie auf Publisher und Werbetreibende unabhängig von ihrer Größe berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird.

Im Zuge der Tests der Privacy Sandbox wird unter anderem analysiert, wie erfolgreich die neuen Technologien für verschiedene Stakeholder sind. Feedback ist dabei von entscheidender Bedeutung, insbesondere spezifisches und umsetzbares Feedback, das uns bei der weiteren Verbesserung der technischen Designs helfen kann.

Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen, in dem Marktteilnehmer mehr Informationen erhalten und die vorgeschlagenen Ansätze kommentiert werden können.“
(Auch in F3 gemeldet)
Anträge auf Dokumentation		 Anfragen nach weiteren Ressourcen zur Verwaltung von Tests, Analysen und Implementierungen Update zum 4. Quartal:

Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden. Wir werden auch weiterhin versuchen, mehr Material zur Verfügung zu stellen, damit Entwickler nachvollziehen können, wie sie von den neuen Technologien profitieren können. Im letzten Quartal haben wir privacysandbox.com den Bereich „News & Updates“ hinzugefügt und eine umfassende Übersicht darüber veröffentlicht, wie die Privacy Sandbox die Anzeigenrelevanz in Zukunft erhöhen kann.
Core Web Vitals Wie wirkt sich die Latenz der Privacy Sandbox API auf Core Web Vitals aus? Bei der Entwicklung der Privacy Sandbox APIs ist es wichtig, die Latenz auf ein Minimum zu beschränken. Wir gehen derzeit davon aus, dass sich die API-Latenz nur minimal auf die Core Web Vitals-Werte einer Website auswirken sollte, da die meisten APIs nach dem ersten Rendern der Website aufgerufen werden. Wir werden die APIs weiterhin im Blick behalten und Verbesserungen vornehmen, um die Latenz weiter zu verringern, und freuen uns auf kontinuierliche Tests und Feedback.

Die Latenz im Echtzeitgebotsprozess wird im Bereich „FLEDGE“ unter „Leistung von FLEDGE-Auktionen“ behandelt
Interoperabilität Bedenken hinsichtlich der Interoperabilität mit anderen potenziellen Lösungen Das Ziel der Privacy Sandbox ist es, Nutzer vor websiteübergreifendem Tracking zu schützen und gleichzeitig die Anforderungen der Webplattform zu erfüllen. Wir möchten dies erreichen, indem wir auf veraltete Browsertechnologien verzichten, die solches websiteübergreifendes Tracking ermöglichen (z. B. Drittanbieter-Cookies), und stattdessen neue Technologien anbieten, die speziell für bestimmte Anwendungsfälle entwickelt wurden.

Die Privacy Sandbox-Angebote verbessern den Datenschutz, indem die Daten eingeschränkt werden, die auf dem Gerät eines Nutzers verbleiben. Die Angebote schränken die Möglichkeit einer Website, Daten zu teilen oder anderweitig zu verarbeiten, nachdem sie vom Browser erfasst wurden, nicht durch technische Einschränkungen ein. Die Technologien hindern Unternehmen daher nicht daran, „Data Stewardship“-Vereinbarungen oder ein ähnliches Vertragsverhältnis einzugehen. Ebenso wird die Möglichkeit der Nutzer nicht eingeschränkt, der Weitergabe ihrer Daten auf andere Weise zuzustimmen.

Google hat sich dazu verpflichtet, die Privacy Sandbox-Technologien in gleicher Weise auf alle Websites anzuwenden, einschließlich der Produkte und Dienste von Google. Nachdem Chrome die Unterstützung von Drittanbieter-Cookies eingestellt hat, wird auch deutlich, 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 verfolgen.

Relevante Inhalte und Werbung zeigen

Themen

Feedback-Design 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 der Google-Suchergebnisse verwendet wird Auf einigen Websites wird die Topics API möglicherweise deaktiviert. Das Privacy Sandbox-Team hat das Ranking von Seiten als Anreiz für Websites zur Einführung der Topics API nicht koordiniert oder von der Organisation der Google Suche angefordert. Google hat der CMA bestätigt, dass die Entscheidung einer Website, die Topics API zu deaktivieren, nicht als Ranking-Signal verwendet wird.
Themenklassifikator Fügen Sie zusätzlich zum Hostnamen auch die URLs und Seiteninhalte hinzu, um das Thema einer Webseite zu bestimmen und so den Nutzen für die verschiedenen Beteiligten zu verbessern. Der Browserverlauf eines Nutzers ist derzeit anhand der Hostnamen einer Website klassifiziert. Chrome prüft weiterhin Optionen zur Berücksichtigung von Metadaten auf Seitenebene (z. B. alle oder einige Komponenten der Seiten-URL und/oder des Inhalts) bei der Klassifizierung von Themen. Jegliche Verbesserungen des Nutzens müssen gegen die Risiken in Bezug auf Datenschutz und Missbrauch abgewogen werden.

Zu den Risiken gehören beispielsweise:
– Websites, die Metadaten auf Seitenebene ändern, um verschiedene (und potenziell sensible) Bedeutungen in Themen zu codieren;
– Websites, die Metadaten auf Seitenebene ändern, um ihre Themen aus finanziellen Gründen falsch darzustellen;
– Websites, die Metadaten auf Seitenebene dynamisch als Methode für websiteübergreifendes Tracking ändern
(Auch im 3. Quartal gemeldet)
Auswirkungen auf eigene Signale		 Topics-Signale können sehr wertvoll sein und werden daher andere selbst erhobene interessenbezogene Signale abgewertet. Unsere Antwort hat sich gegenüber dem 3. Quartal nicht geändert:

„Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist, und Topics wurde speziell dafür entwickelt. Wie [in unserem Bericht zum 3. Quartal] beschrieben, haben andere Stakeholder des Ökosystems Bedenken geäußert, dass Topics möglicherweise nicht nützlich genug ist, um einen Mehrwert zu bieten. In allen Fällen ist die Verbesserung der Taxonomie ein fortlaufender Prozess und wir gehen davon aus, dass sich die Taxonomie durch Tests und Eingaben weiterentwickeln wird.“
Taxonomie aktualisieren Wie wird die Taxonomieliste aktualisiert? Wir sind aktiv auf der Suche nach Feedback zur Taxonomie, die für die Plattform am hilfreichsten wäre. Die im ursprünglichen Vorschlag der Topics API enthaltene Taxonomie wurde für Funktionstests entwickelt. Chrome erwägt derzeit mehrere Ansätze zur Aktualisierung der Taxonomie. So kann Chrome beispielsweise den kommerziellen Nutzen für jedes Thema berücksichtigen, um zu bestimmen, welche Kategorie in zukünftigen Versionen berücksichtigt werden soll.
Topics-Leistung der regionalen Klassifikatoren Der Themenklassifikator schneidet in regionalen Domains schlecht ab Die Verbesserung des Klassifikators ist ein fortlaufender Prozess. Aufgrund des Feedbacks, das wir erhalten haben, wird eine Möglichkeit in Betracht gezogen, die Liste der Topics-Überschreibungen zu erweitern. Unsere Analyse zeigt, dass sich dadurch die globale Abdeckung und die Genauigkeit verbessern werden.

Die Klassifizierung der Topics API umfasst zwei wichtige Komponenten: (1) eine Überschreibungsliste mit den Top-10.000 Websites und deren Themen und (2) ein On-Device-ML-Modell, das Hostnamen in Themen klassifiziert. Durch Erweitern der Überschreibungsliste (1) können wir die Leistung der Klassifizierung für die Regionen verbessern, in denen der Klassifikator unter Umständen schlecht abschneidet.
Eine Woche Epoche Die einwöchige Epoche ist zu lang für Nutzende, die kurzfristige Entscheidungen treffen möchten. Wir prüfen aktiv, welche Epochen geeignet sind, und freuen uns über mehr Feedback dazu, was eine bessere Epoche für das System wäre.
HTTP-Header-Abruf Bedenken, dass nicht genügend Informationen zum Abrufen von Themen über den HTTP-Header vorhanden sind An den Headern und „fetch()“ wird gearbeitet. Weitere Informationen finden Sie hier. Wir haben der Erklärung auch Informationen zum Überspringen von Beobachtungen hinzugefügt.
Mit der Topics API sollen nur Werbetreibende unterstützt werden, nicht Nutzer. Topics/Privacy Sandbox scheint ein branchenorientierter Ansatz zu sein. Der Nutzen für die Nutzenden ist nicht so klar wie der Nutzen für die Branche. Wir glauben, dass die Topics API interessenbezogene Werbung unterstützt, die das Web kostenlos und offen halten, und wir glauben auch, dass der Datenschutz im Vergleich zu Drittanbieter-Cookies deutlich verbessert wird. Das Entfernen von Drittanbieter-Cookies ohne realisierbare Alternativen kann sich negativ auf Publisher auswirken und zu schlechteren Vorgehensweisen führen.
Diese sind weniger privat, nicht transparent und nicht realistisch zurücksetzbar oder von den Nutzern nicht kontrolliert. Viele Unternehmen testen aktiv die Topics API und die Sandbox APIs. Unser Ziel ist es, Tools zur Verbesserung des Datenschutzes und zur Unterstützung des Webs zur Verfügung zu stellen.


Die W3C Technical Architecture Group hat vor Kurzem ihre Erstansicht zur Topics API veröffentlicht, auf die wir öffentlich antworten werden. Da wir von der Plattform Fragen dazu erhalten haben, was diese Überprüfung für die Entwicklung und Einführung der Topics API bedeuten könnte, möchten wir unseren Plan noch einmal bestätigen, sie dieses Jahr als stabile Version von Chrome zur Verfügung zu stellen. Google schätzt den Beitrag der W3C Technical Architecture Group zwar, hält ihn jedoch für äußerst wichtig, die Bemühungen, Topics in Absprache mit der CMA und der Plattform weiter zu entwickeln und zu testen, weiter zu verfolgen.
Datenleck Bedenken, dass Topics ohne Erlaubnis auf andere Websites durchsickert werden könnten Aufgrund des Designs der Topics API ist es recht unwahrscheinlich, dass Daten von einem einzelnen Publisher (und selbst einer kleineren Gruppe von Publishern) in irgendeiner Weise gehackt werden können. Publisher-Websites haben außerdem die vollständige Kontrolle über die Topics API und können den Zugriff auf diese API über die Berechtigungsrichtlinie verbieten.
Zu wenig Werbetreibende zum Testen Publisher befürchten, dass sie Werbetreibenden den Wert der Topics API derzeit nicht demonstrieren können. Für die zweite Jahreshälfte 2023 planen wir, alle werbebezogenen APIs für Integrationstests zur Verfügung zu stellen und die Analyse des Werts von Topics für Werbetreibende zu ermöglichen. Die Tests und Veröffentlichung der Ergebnisse werden von der CMA beaufsichtigt, die die Daten, Analysen und Methodiken überprüft. Die Plattform wird ermutigt, Feedback mit Google und der CMA zu teilen.
Themen und FLEDGE Weitere Informationen zur Verwendung von Topics in der Gebotslogik von FLEDGE anfordern Es ist möglich, Topics in der Gebotslogik von FLEDGE zu verwenden. Ein Integrationsleitfaden mit weiteren Details zur Implementierung ist ebenfalls in Arbeit.
Benutzerdefiniertes Ranking für Themen, die aufgerufen werden Zulassen, dass Rankings an den Anrufer angepasst werden Die Herausforderung beim benutzerdefinierten Themenranking oder bei den 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 ein Fingerprinting-Vektor.
Themen – Prioritätsliste für Anrufer Anrufern erlauben, eine nach Priorität geordnete Liste von Themen anzugeben, die von der Topics API je nach Eignung zurückgegeben werden. Wir diskutieren derzeit über diese Idee und freuen uns über zusätzliche Anregungen.

FLEDGE

Feedback-Design Zusammenfassung Chrome-Antwort
Google Ad Manager Bedenken, dass Google Ad Manager als Entscheidungsträger für FLEDGE-Auktionen dient und Google Publisher-Tags und Google Ad Manager bevorzugt Mit FLEDGE kann jeder Publisher die Struktur der Auktion auswählen, einschließlich der Top-Level- und Komponentenverkäufer. Alle Käufer und Verkäufer in einer Komponentenauktion wissen, wer der Top-Level-Verkäufer ist, und können entscheiden, ob sie bieten möchten.
Nicht genügend Teilnehmer zum Testen von FLEDGE Anfrage, mehr Unternehmen zum Testen von FLEDGE zu ermutigen, z. B. durch Verbesserung der API-Funktionalität und Abraten von datenschutzkonformen Alternativen wie Fingerprinting Die Privacy Sandbox wird in mehreren Phasen und in enger Zusammenarbeit mit der CMA und der ICO durchgeführt. Durch funktionale FLEDGE-Tests wurde die erforderliche Stabilität und Leistungsfähigkeit nachgewiesen. Google ermutigt die Plattform weiterhin, die Sandbox APIs zu testen. Vor Kurzem hat Google die Dokumentation Anzeigenrelevanz maximieren veröffentlicht, in der gezeigt wird, wie FLEDGE und andere APIs nach der Einstellung von Drittanbieter-Cookies dabei helfen können, wichtige Anwendungsfälle für die Werbebranche zu unterstützen.

In anderen Bereichen der Privacy Sandbox werden bereits Maßnahmen zur Eindämmung des Trackings unterstützt (siehe UA-CH, IP Protection und Bounce-Tracking) und werden im Laufe der Zeit weiter verbessert. Das Ziel von Google ist es nicht, FLEDGE zur einzigen praktikablen Targeting-Lösung zu machen, sondern arbeitet weiter mit der Branche und den Regulierungsbehörden zusammen, um die besten datenschutzfreundlichen Anzeigentechnologien im Chrome-Browser zu entwickeln.
Anwendungsfälle für maschinelles Lernen Weitere Informationen dazu, wie Machine Learning-Anwendungsfälle zum Trainieren von Algorithmen für die Auktionsgebote in FLEDGE und Attributionsberichten unterstützt werden Wir wissen, wie wichtig es ist, Testern dabei zu helfen, die nützlichsten Methoden zur Anwendung der Privacy Sandbox-Technologien zu finden. Wir haben damit begonnen, spezielle Hinweise zur Nutzung der verschiedenen Aspekte der Privacy Sandbox APIs als Input für maschinelles Lernen zu veröffentlichen. Im aktuellen Artikel „Anzeigenrelevanz maximieren“ wird erläutert, wie die Werbebranche diese Signale für maschinelles Lernen nutzen kann. Wir planen, solche Leitlinien auch in Zukunft zu veröffentlichen.
FLEDGE-Schlüssel/Wert-Server (K/V) abfragen Warum kann der K/V-Server öffentlich abgefragt werden? Der K/V-Server möchte Echtzeitsignale für FLEDGE-Auktionen bereitstellen. Daher muss der K/V-Server von dem Ort aus zugänglich sein, an dem diese FLEDGE-Auktionen ausgeführt werden, d. h. auf Nutzergeräten. Er muss also öffentlich verfügbar sein. Ein auf dem K/V-Server gespeicherter Wert kann nur von einer Partei abgerufen werden, die bereits einen Schlüssel hat. Wenn also ein Anzeigentechnologie-Anbieter die Schlüssel nur an Browser übermittelt, die zur Interessengruppe gehören, und keine Schlüssel verwendet, die zufällig erraten werden können, können ihn nur Browser abrufen, die den Wert für die Auktion benötigen.
Wie funktioniert das Targeting nach Datum/Uhrzeit? Unterstützung für Datumsobjekte in der Gebotslogikfunktion. Dazu haben Sie verschiedene Möglichkeiten. Die Käufer können ihren Verkäufer um das aktuelle Datum und die aktuelle Uhrzeit bitten. Es sollte für die Verkäufer einfach sein, diese Informationen allen Käufern zur Verfügung zu stellen. Käufer können auch Datum und Uhrzeit in ihrer Echtzeit-Schlüssel/Wert-Antwort angeben. Schließlich können Käufer das Datum und die Uhrzeit als Teil ihrer kontextabhängigen Antwort in den käuferspezifischen Signalen angeben, die ein Verkäufer an das Skript "generateBid" des Käufers übergeben könnte.
Nutzereinstellungen Nutzer können festlegen, ob Creatives nach Werbetreibenden blockiert werden sollen, wenn sie über FLEDGE oder alternative Lösungen ausgeliefert werden. Nutzer können Google Ads APIs in Chrome deaktivieren. Bei bestimmten Anzeigen können Sie mit der entsprechenden Anzeigentechnologie am besten steuern, welche Creatives ausgeliefert oder wie sie ausgewählt werden.
Präzisere Zeitpläne Fordern Sie weitere Informationen zur Verfügbarkeit von Datenschutzmaßnahmen in FLEDGE an, z. B. zur Anforderung von Fenced Frames. Wir planen, im 1. Quartal detailliertere Zeitpläne zu veröffentlichen.
Verwirrung bei der Berichterstellung Sie möchten mehr darüber erfahren, wie die FLEDGE-Berichterstellung mit anderen APIs wie Fenced Frames und der Private Aggregation API funktioniert. 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 Einbindung von FLEDGE in Standard-Echtzeitgebote. Die zwei Hauptaspekte, die es einem Anzeigentechnologie-Anbieter erschweren, Echtzeitgebote abzugeben, sind der Zugriff auf Daten auf Ereignisebene und eine einfachere Integration in die ARA. Wir planen, ab dem 1. Quartal Updates und Erläuterungen zu beiden zu veröffentlichen.
Leistung von FLEDGE-Auktionen Bericht von Testern, dass FLEDGE-Auktionen eine hohe Latenz haben Wir freuen uns über Berichte von Testern, die ihre Ergebnisse und Anwendungsfälle teilen. Außerdem haben wir einige Vorschläge zur Verbesserung der Leistung von FLEDGE gemacht.

Parallel dazu haben wir dem Browser Tools hinzugefügt, mit denen Entwickler besser feststellen können, was Auktionen langsam macht. Außerdem haben wir systematisch die beobachteten Hauptquellen der Latenz berücksichtigt. Zu den jüngsten Verbesserungen gehören Zeitüberschreitungen bei langsamen Auktionen, eine schnelle Gebotsfilter-Filtertechnik, die Möglichkeit, FLEDGE-Worklets zu verwenden, um die Zahlung von Startkosten zu vermeiden, und fortlaufende Arbeit, um die kontextbezogene Anzeigenanfrage parallel ausführen zu können, mit der FLEDGE-Startzeit und den Netzwerkabrufen. Wir gehen davon aus, dass die Latenzoptimierung als fortlaufender Austausch zwischen Chrome-Entwicklern und FLEDGE-Testern fortgesetzt wird, da sie die API in der Praxis nutzen.
Speicherlimit für die Größe der Interessengruppe Anfrage zur Erhöhung des Limits für die Größe einer einzelnen Interessengruppe von 50 KB. Wir prüfen diese Anfrage aktiv und brauchen Feedback dazu, welcher Limitwert funktioniert.
Von FLEDGE bereitgestellte Daten mit eigenen Cookies kombinieren Wird FLEDGE die Einbindung in die selbst erhobenen Daten eines Werbetreibenden unterstützen? FLEDGE wurde für die Unterstützung von Werbung mit selbst erhobenen Daten entwickelt, die ein Werbetreibender bereits hat. Mit FLEDGE sollen Werbetreibende jedoch nicht das Browserverhalten einer Person auf anderen Websites als der eigenen Website des Werbetreibenden kennenlernen. Die Verknüpfung von selbst erhobenen Daten mit dem Surfverhalten außerhalb der Website ist nicht zielführend.

In den kommenden Wochen werden wir Ihnen Einbindungsanleitungen mit weiteren Details dazu zur Verfügung stellen, wie FLEDGE die Einbindung selbst erhobener Daten unterstützt.
k-Anonymitätswert Wie wird der Wert „K“ für „k-anon“ bestimmt und wird er veröffentlicht? Der Wert „K“ steht noch nicht fest. Im Laufe der Entwicklung unserer Pläne werden wir weitere Informationen dazu bekannt geben. Wir möchten mehr darüber erfahren, wie ein unbekannter k-Wert die Vorbereitung von FLEDGE und den Umfang des ML-Modelltrainings beeinträchtigen kann, und freuen uns über zusätzliches Feedback zu diesem Thema.
Mehrere SSPs unterstützen Wie werden mehrere SSPs in FLEDGE unterstützt? FLEDGE unterstützt Auktionen mit mehreren Verkäufern, wie in diesem Angebot beschrieben.
Transparenz der Gebotslogik Bedenken, dass die DSP-Gebotslogik in JavaScript offengelegt wird Mit dem aktuellen Design der Gebotslogik können andere Nutzer auf JavaScript zugreifen. Wir würden uns jedoch über mehr Feedback dazu freuen, warum dies für DSPs Anlass zur Sorge geben könnte.
prebid.js Wie sieht der Zeitplan für die Unterstützung von prebid.js in FLEDGE aus? Nur Prebid.js-Versionen 7.14 und höher unterstützen das FLEDGE-Modul. Alle Publisher, die an Tests interessiert sind, müssen das FLEDGE-Modul hinzufügen und ihre Prebid-Instanz upgraden.
Benutzerdefinierte Funktionen in FLEDGE Wie werden benutzerdefinierte Funktionen (UDF) in FLEDGE unterstützt? Dies sind Funktionen, die von Endnutzern programmiert werden können, um die Funktionalität der API zu erweitern. Die Erläuterung finden Sie hier. Da dies noch in der Ausarbeitungsphase ist, freuen wir uns über zusätzliches Feedback zu Anwendungsfällen.
Lockerung der Einschränkung für denselben Ursprung für Interessengruppen-Ressourcen Anfrage zur Lockerung der Same-Origin-Beschränkung für Interessengruppen-Ressourcen, um bestimmte AdTech-Anwendungsfälle zu ermöglichen In der aktuellen Implementierung von FLEDGE müssen biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl und trustedBiddingSignalsUrl denselben Ursprung haben wie der Inhaber der Interessengruppe.

Die Einschränkung besteht, um bestimmte Exploits durch Angreifer zu verhindern, wie hier beschrieben.
Inhaberschaft von Interessengruppen Anfrage zur Beschränkung, ob ein Anzeigentechnologie-Team „joinInterestGroup“ websiteübergreifend für dieselben Interessengruppen verwenden kann Unser Fokus liegt darauf, wie Zielgruppen verwendet werden, nicht, wie sie aufgebaut sind. Wir besprechen mögliche Ansätze hier und würden uns über zusätzliche Vorschläge freuen.
Ablauf des Schlüssel/Wert-Serverschlüssels Diskussion über das Entfernen von Serverschlüsseln, nachdem die entsprechenden Interessengruppen abgelaufen sind Wir testen derzeit Möglichkeiten, wie wir mit dem Ablauf von Schlüsseln umgehen können. Hier können Sie dazu Feedback geben.

Digitale Anzeigen analysieren

Attribution Reporting (und andere APIs)

Feedback-Design Zusammenfassung Chrome-Antwort
Traffic des Ursprungstests Der Traffic des aktuellen Ursprungstests reicht nicht aus, um Dienstprogrammtests durchzuführen. Mit den aktuellen Ursprungstests können Akteure der Plattform Funktionstests durchführen, um sicherzustellen, dass die API wie vorgesehen funktioniert. Uns ist bewusst, dass für Dienstprogrammtests mehr Traffic erforderlich ist, sobald die Entwicklung der verschiedenen Privacy Sandbox APIs ausgereift ist. Laut aktuellem Zeitplan für Tests wird dies bis zum 3. Quartal 2023 (d. h. sobald die Technologien für die Anwendungsfälle eingeführt und für 100% des Chrome-Traffics verfügbar sind) erfolgen (siehe aktuellen Zeitplan auf privacysandbox.com). Wir freuen uns über zusätzliches Feedback zu Anwendungsfalltests, die zusätzlichen Traffic erfordern.
Überschneidung bei den Funktionen der verschiedenen Privacy Sandbox-Mess-APIs Wenn sich mehrere Messmethoden über die Privacy Sandbox überschneiden, erhöht sich die Komplexität, z. B. bei der Attribution Reporting API und der Private Aggregation API. Wir arbeiten an einer besseren Dokumentation, um die verschiedenen Anwendungsfälle für die APIs zu verdeutlichen, und freuen uns über zusätzliches Feedback zu den Bereichen, für die es noch keine Erklärungen gibt. Die Attribution Reporting API ist beispielsweise speziell für die Conversion-Messung vorgesehen, während die Private Aggregation API und Shared Storage APIs für allgemeine Zwecke sind, die eine breitere Palette von Anwendungsfällen für websiteübergreifende Messungen unterstützen sollen.
Fehlgeschlagene Berichtsanfrage wiederholen Erläuterung, wie oft eine Berichtsanfrage nach Scheitern versucht wird. Hier finden Sie eine Anleitung dazu. Zusammengefasst: Berichte werden nur gesendet, wenn der Browser ausgeführt wird bzw. online ist. Nach dem ersten Fehler beim Senden wird nach fünf Minuten noch einmal versucht, den Bericht zu senden. Nach dem zweiten Fehler wird nach 15 Minuten ein neuer Versuch erstellt. Danach wird der Bericht nicht mehr gesendet.
Verzögerung der Auswertung Wie hoch ist die erwartete Verzögerung bei der Berichterstellung? Wir freuen uns über mehr Feedback zu Verzögerungen bei der Berichterstellung, die wir während der Datenerhebung beobachten, um diese Verzögerungen parallel weiter zu analysieren.
Seiten vorab rendern Funktioniert die ARA-Zuordnung auf Pre-Rendering-Seiten? Die Registrierung für die Attribution wird auf vorab gerenderten Seiten bis zur Aktivierung zurückgestellt, d. h., wenn ein tatsächlicher Klick oder Aufruf erfolgt. Das bedeutet, dass der Ping der „attributionsrc“-Anfrage aufgeschoben wird.
Conversion-Steigerung messen Messung der Conversion-Steigerung mit A/B-Tests auf derselben Domain Websites können die Conversion-Steigerung mithilfe von A/B-Tests auf derselben Domain über Attributionsberichte messen. Sie können ihre A/B-Parameter als Schlüssel mit der Aggregate API codieren und erhalten dann zusammenfassende Berichte für die Conversion-Werte nach diesen Schlüsselgruppen.
(Auch in Q3 erfasst) Domainübergreifende Conversions Domainübergreifendes Tracking (z. B. mit zwei oder mehr Zielen) Update für das 4. Quartal:

Wir haben einen Vorschlag veröffentlicht, um die Zielbeschränkung für Landingpages aufzuheben, mit der domainübergreifende Unterhaltungen erfasst werden können. Dieser Vorschlag wurde implementiert.
(Auch in Q3 angegeben)
Einstellung für Ablauf im Conversion-Bericht 		Anfrage zur Unterstützung des Berichtsfilters / Ablauf von weniger als 24 Stunden Update für das 4. Quartal:

Wir haben diese Pull-Anfrage veröffentlicht, durch die Ablauf- und Berichtszeiträume entkoppelt werden, um den Kompromiss zwischen Berichtsverzögerung und Conversion-Ablauf zu minimieren. Diese Funktion wird jetzt in M110 eingeführt.
Betrug und Missbrauch Anfragen von Werbetreibenden und Werbetreibenden, die Daten basierend auf den Publisher-Websites, auf denen ihre Anzeigen geschaltet werden, zu segmentieren und aggregieren zu können. Dies würde auch einen besseren Einblick in potenzielle betrügerische Anzeigenpraktiken ermöglichen. Dieses Feedback wird hier aktiv diskutiert und wir freuen uns über zusätzliche Anregungen.
(Auch in Q3 gemeldet) Verzögerung bei Berichten auf Ereignisebene Die Verzögerung von 2 bis 30 Tagen bei Berichten auf Ereignisebene kann für bestimmte Anwendungsfälle zu lang sein. Bei Berichten auf Ereignisebene gibt es standardmäßig einen Zeitraum von 2, 7 und 30 Tagen. Dies kann mithilfe des Parameters „expiry“ geändert werden. AdTech-Unternehmen können die Ablaufzeit auf einen Zeitraum von mindestens einem Tag konfigurieren, um potenzielle Berichte in weniger als zwei Tagen zu erhalten. Wir beschränken den Detaillierungsgrad von Abläufen zum Schutz der Privatsphäre auf einen Tag, da eine detailliertere Berichterstellung dazu führen kann, dass Angriffe zeitverzichtbar sind. Außerdem können unabhängige Ablaufparameter für Berichte auf Ereignisebene und aggregierte Berichte festgelegt werden. Weitere Informationen Außerdem hat Google Ads keine speziellen Berichtszeiträume, die andere Anzeigentechnologien nicht über die Attribution Reporting API erhalten.
Dieselbe Anforderung für den Berichtsursprung Antrag auf Entfernung der Anforderung, dass der Ursprung der Registrierungsquelle mit dem Ursprung der Conversion-Registrierung identisch sein muss Zur Lösung dieses Anwendungsfalls schlagen wir vor, die Registrierung mit HTTP-Weiterleitungen zu delegieren. Wir freuen uns über zusätzliches Feedback zu dieser neuen Anleitung.
Conversion-Tracking Es muss unterschieden werden, ob die Conversion vor oder nach einer vom Werbetreibenden festgelegten Zeit erfolgt ist. Die Attribution Reporting API unterstützt das Festlegen eines Ablauffensters und einer Priorität für die Quellenattribution. Wenn Sie beide Methoden verwenden, ist es technisch möglich, eine Conversion, die innerhalb von X Tagen erfolgte, getrennt von einer Conversion zuzuordnen, die nach X erfolgte.
Geräuschsimulation Anfrage zur Simulation des unterschiedlichen Conversion-Volumens pro Bucket, um die Auswirkungen auf Werbetreibende mit weniger Conversions zu verstehen Wir arbeiten daran, dies in zukünftigen Versionen von Noise Lab zu simulieren. Wir freuen uns über zusätzliches Feedback.
Berichterstellung auf Mobilgeräten Wird der Bericht auch dann gesendet, wenn Chrome auf Mobilgeräten im Hintergrund ausgeführt wird? Selbst auf Mobilgeräten wird der Bericht derzeit nicht gesendet, wenn Chrome im Hintergrund ausgeführt wird. Das wird sich wahrscheinlich ändern, wenn die API in die Android Privacy Sandbox integriert wird. Weitere Informationen Beachten Sie, dass die Privacy Sandbox für Android nicht Teil der von der CMA akzeptierten Selbstverpflichtungen ist.
Datenverfügbarkeit Bedenken, dass Google über die Privacy Sandbox APIs künftig zusätzlichen Zugriff auf Daten erhält 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.

Es gibt jedoch einige mögliche Abhilfemaßnahmen: Methoden wie das Aggregieren über längere Zeiträume lösen dieses Problem. Dennoch ist es unklar, ob Schlussfolgerungen auf Basis sehr kleiner Datensegmente (z. B. ein oder zwei Käufe) für Werbetreibende von Bedeutung sind. Während des Ursprungstests hat Google die Tester ermutigt, die Möglichkeit zu nutzen, mit einer Vielzahl von Datenschutz- und Rauschparametern zu experimentieren, damit sie genaueres Feedback zu diesem Problem geben können.

Verdecktes Tracking begrenzen

Reduzierung des User-Agents

Feedback-Design Zusammenfassung Chrome-Antwort
Reduzierung des User-Agents verzögern, bis die Webumgebung bereit ist Die Zeit reicht nicht aus, um dich auf die bevorstehenden Änderungen bei der Reduzierung des User-Agents einzustellen. Wir bearbeiten dieses Feedback im vollständigen Bericht unter „Bedenken von Stakeholdern“ im Abschnitt „Interaktion von Google mit der CMA“.
Reduzierung des User-Agents verzögern, bis die Webumgebung bereit ist Anfrage zur Verzögerung der Einführung der Reduzierung des User-Agents, bis strukturierte User-Agents bereitgestellt wurden Das Google Ads-Team hat im Oktober 2021 vorgeschlagen, OpenRTB im Oktober 2021 als strukturierten User-Agent zu verwenden (siehe Spezifikation). Dieser wurde in das im April 2022 veröffentlichte Spezifikationsupdate 2.6 integriert.

Wir haben Belege dafür, dass SUA heute bereitgestellt und verfügbar ist. Der Scientia Mobile-Blogpost zeigt, wie SUA mit UA-CH und der WURFL API erstellt wird.

###

User-Agent-Client-Hints

Feedback-Design Zusammenfassung Chrome-Antwort
UA-CH mit anderen Anti-Covert-Tracking-Techniken testen Anleitung zum Testen aller vorgeschlagenen Privacy Sandbox APIs und Fingerprinting-Techniken in einem ganzheitlichen Ansatz Unser Testplan wurde so konzipiert, dass er den asynchronen Zeitplan für die Entwicklung einiger Anti-Fingerprinting-Maßnahmen im Gegensatz zu den anderen Sandbox-Vorschlägen widerspiegelt. Sie berücksichtigt die Tatsache, dass einige Anti-Fingerabdruck-Maßnahmen (z.B. Privacy Budget, IP-Schutz und Eindämmung von Bounce-Tracking) erst vollständig entwickelt und allgemein verfügbar sein werden, nachdem Drittanbieter-Cookies eingestellt wurden.

Diese Anti-Fingerabdruck-Maßnahmen werden zwar nicht in quantitative Tests einbezogen, unterliegen aber einer qualitativen Bewertung auf der Grundlage der zum Zeitpunkt des Stillstands verfügbaren Fakten.
(Auch im 2. Quartal gemeldet)
Leistung		 Bedenken hinsichtlich der Latenz beim Abrufen von Hinweisen über Critical-CH (beim ersten Seitenaufbau) Siehe Abschnitt zu UA-CH unten
Unzureichendes Feedback Das Feedback der Community über die Änderung von UA-CH reicht möglicherweise nicht aus, was zu Bedenken hinsichtlich eines mangelnden Bewusstseins auf der Plattform führt. Wir haben unsere Pläne bereits vorab bekannt gegeben, um eine sorgfältige Einführung zu gewährleisten, bei der Störungen minimiert werden.

Die Pläne für eine Reduzierung des User-Agents und die UA-CH API wurden der W3C Anti-Fraud Community Group am 18. März 2022 sowie am 20. Januar 2022 sowohl der Web Payments Working Group als auch der Web Payments Security Interest Group vorgestellt. Während oder nach den Vorträgen wurden keine nennenswerten Bedenken geäußert.

Google hat proaktiv mit mehr als 100 Websitebetreibern zusammengearbeitet, um Feedback zu erhalten. Darüber hinaus hat Google auch Blink-Dev-Kanäle verwendet, um die Einführung der User-Agent-Reduzierung basierend auf dem Feedback von Stakeholdern der Plattform öffentlich zu kommunizieren.
Dauer Geäußerte Bedenken hinsichtlich des Zeitplans für die Einführung und der Bereitschaft in der Branche Siehe Abschnitt zu UA-CH unten
Status der Chrome-Plattform Aktualisierung der Chromestatus-Seite für UA-CH angefordert Der Eintrag „Chromestatus“ wurde am 19. Dezember zu „Gemischte Signale“ aktualisiert.

IP Protection (früher Gnatcatcher)

Feedback-Design Zusammenfassung Chrome-Antwort
Aktivieren oder deaktivieren Ist der Datenschutz für IP-Adressen aktiviert oder deaktiviert? Wir möchten allen Nutzern IP-Schutz bieten. Aus diesem Grund evaluieren wir derzeit Optionen für den IP-Schutz.
Anwendungsfall für IP-Adressen für selbst erhobene Daten Ist es möglich, mit IP-Adressen Nutzerpfade nach dem IP-Schutz über eigene Domains hinweg zusammenzufassen? Wie bereits bereits veröffentlicht, liegt der Fokus beim Schutz von IP-Adressen anfangs auf das Tracking im Zusammenhang mit Drittanbietern. Eigene Domains sind davon nicht betroffen.
Anwendungsfälle für AdTech Wie können Unternehmen mit IP-Schutz Maßnahmen zur Betrugsbekämpfung ergreifen? 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 (Abschnitt 20) haben wir gesagt, dass wir den Schutz von geistigem Eigentum nicht implementieren werden, ohne angemessene Anstrengungen zu unternehmen, um Websites dabei zu unterstützen, Spam und Betrug zu bekämpfen. Eine unserer wichtigsten Prioritäten ist es zu verstehen, wie sich der IP-Schutz auf Anwendungsfälle und Erkennungsfunktionen zur Betrugsbekämpfung auswirkt, damit wir weiter in datenschutzfreundliche Technologien investieren können, die Unternehmen helfen, die Websicherheit zu wahren. Wir fördern Feedback und Feedback zu neuen Vorschlägen, die auf die Bedürfnisse von Unternehmen im Bereich Sicherheit und Betrugsbekämpfung ausgerichtet sind, auch wenn sich Signale im Laufe der Zeit ändern.
Betrug und Missbrauch Schließt der IP-Schutz den Schutz vor DoS-Angriffen (Denial of Service) ein? Unser Ziel ist es, den Datenschutz zu verbessern und gleichzeitig das Web zu schützen, und der Schutz vor Denial-of-Service-Angriffen ist ein wichtiger Anwendungsfall für die Bekämpfung von Missbrauch. Wir hoffen, die Auswirkungen auf den DoS-Schutz sowohl durch das Design des IP-Schutzes selbst als auch durch neue Lösungen gegen Missbrauch zu minimieren. Da der IP-Schutz sich zunächst auf eingebettete Dienste von Drittanbietern konzentriert, haben einige Stakeholder darauf hingewiesen, dass er sich nur begrenzt auf den DoS-Schutz für eigene Websites auswirken sollte. Wir erfordern jedoch weiterhin öffentliches Feedback, um das Risiko für DoS-Anwendungsfälle zu bewerten, insbesondere für eingebettete Dienste von Drittanbietern.

Parallel dazu erforschen wir Mechanismen für Missbrauchsfeedback und zum Blockieren von Clients, mit denen Websites oder Dienste Spamnutzer blockieren können, ohne den Nutzer zu identifizieren.
Inhaltsfilterung Inhaltsfilterung mit IP-Schutz Verschiedene Unternehmen haben unterschiedliche Anforderungen in Bezug auf das Filtern von Inhalten und die Anpassung der User Experience. Viele Anwendungsfälle dieser Art basieren derzeit nicht auf IP-Adressen und sollten daher vom IP-Schutz nicht betroffen sein. Beispielsweise kann ein Publisher, der seinen Inhalt anpassen und mehr Interaktionen erzielen möchte, Erstanbieter-Cookies oder von Drittanbietern partitionierte Cookies (CHIPs) verwenden, um die Interessen eines Nutzers und frühere Interaktionen mit dem Publisher zu verstehen. Oder ein AdTech-Partner, der sich auf die Auslieferung der richtigen Anzeige für den richtigen Nutzer konzentriert, kann FLEDGE und Topics einbinden, um beispielsweise ähnliche Anzeigenergebnisse zu erzielen wie bisher mit Drittanbieter-Cookies oder anderen websiteübergreifenden Tracking-Technologien.

Wir prüfen außerdem, wie der IP-Schutz neue datenschutzfreundliche Funktionen bietet, z. B. die ungefähre Standortbestimmung, um das Filtern von Inhalten weiter zu unterstützen, wenn die vorhandenen Mechanismen 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 in F3 bekannt)
Anwendungsfälle zur Standortbestimmung		 Der IP-Schutz kann dazu führen, dass in Zukunft legitime Anwendungsfälle wie die Personalisierung von Inhalten nicht mehr funktionieren. Update für das 4. Quartal:

Wir arbeiten mit allen Beteiligten zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Hier finden Sie Feedback zum Detaillierungsgrad der IP-Standortbestimmung.

Privacy Budget

Feedback-Design Zusammenfassung Chrome-Antwort
Klarere Dokumentation Mehr Beispiele, damit Stakeholder abschätzen können, wie die Dinge nach der Implementierung des Privacy Budgets eingeschränkt sein könnten Der Vorschlag zum Datenschutzbudget wird derzeit noch diskutiert und von keinem Browser implementiert. Das früheste Datum der skalierten Verfügbarkeit ist das früheste Datum, an dem das Privacy Budget erzwungen werden konnte. Dies wird erst nach der Entfernung von Drittanbieter-Cookies im Jahr 2024 der Fall sein. Momentan haben wir keine weiteren Dokumente für Sie.

Wir informieren Sie über weitere Details, sobald das Angebot feststeht. In der Zwischenzeit können Sie uns gern Feedback geben, das uns bei der Ausarbeitung des Vorschlags helfen würde.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedback-Design Zusammenfassung Chrome-Antwort
(Auch in Q3 gemeldet) Domainlimit Anfrage zur Erweiterung der Anzahl verknüpfter Domains Update für das 4. Quartal:

Wir haben FPS für lokale Tests veröffentlicht, einschließlich eines Verfahrens zum Einreichen von Simulationssätzen auf GitHub und einem Flag zum lokalen Testen von rSA und rSAFor. Außerdem haben wir zwei offene Meetings für Entwickler von FPS veranstaltet, um weiterhin Fragen zu Anwendungsfällen für die entsprechende Untergruppe zu beantworten. Wir empfehlen Entwicklern, die FPS-Funktion zu testen und Feedback dazu zu geben, wie sich das Domainlimit für die entsprechende Untergruppe auf die Nutzbarkeit von fps für ihre Anwendungsfälle auswirken würde.

Wir haben in den WICG-Anrufen deutlich gemacht, dass Chrome sich dazu verpflichtet hat, eine nutzungsfreundliche Lösung anzubieten, bei der auch die Datenschutzinteressen der Nutzer berücksichtigt werden. In diesem Zusammenhang würden wir uns über Feedback der Community zu bestimmten Anwendungsfällen freuen, die möglicherweise vom Domainlimit betroffen sind. So kann das Team überlegen, wie diese Anwendungsfälle angegangen werden können, während gleichzeitig die Privatsphäre der Nutzer geschützt bleibt.
Bitte um weitere Details zu den Maßnahmen zur Missbrauchsbekämpfung Was passiert, wenn eine Domain zu einer Gruppe hinzugefügt wird, in die sie nicht eingewilligt haben? Am 2. Dezember 2022 haben wir Richtlinien zur Einreichung von First-Party-Sets veröffentlicht.

Wie in den Einreichungsrichtlinien erläutert, folgt jedes Änderungsmanagement einem Validierungsprozess auf GitHub, einschließlich der Validierung der Inhaberschaft, um dieses Risiko zu mindern.
Missbrauchsbekämpfung Bedenken, dass First-Party-Set-Formationen ausgenutzt werden können Wir arbeiten an Möglichkeiten, die technischen Prüfungen auf Untergruppen auszuweiten, und suchen aktiv um zusätzliche Informationen von der Community.
Anwendungsfälle für Werbung Fragen dazu, ob First-Party-Sets zur Unterstützung der Anzeigenausrichtung verwendet werden sollten Wir unterstützen derzeit keine Anwendungsfälle für die Anzeigenausrichtung für First-Party-Sets. Wir empfehlen daher, die dafür verfügbaren Ads APIs zu verwenden.
(Auch in F3 gemeldet) Richtlinie Bedenken, dass der FPS nicht mit den CMA-Verpflichtungen im Hinblick auf die anwendbaren Datenschutzvorschriften im Einklang steht, da die DSGVO die Anzahl der Websites in einem Satz nicht begrenzt, während der Anbieter eine Beschränkung von drei Websites vorsieht Unsere Antwort im 3. Quartal bleibt unverändert:

„Google verpflichtet sich weiterhin zur CMA, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch das eigene Unternehmen von Google verzerrt wird. Außerdem werden die Auswirkungen auf den Wettbewerb bei digitaler Werbung, Publisher und Werbetreibende sowie die Auswirkungen auf den Datenschutz und die Einhaltung der Datenschutzprinzipien gemäß den anwendbaren Datenschutzvorschriften berücksichtigt. Aus den geäußerten Bedenken geht keine Auskunft über eine Inkompatibilität mit der DSGVO hervor. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird.“
Alternativer Vorschlag DSGVO-zertifizierte Sets Zusätzlich zum Feedback, das die Plattform im Hinblick auf den Vorschlag zur Einführung von DSGVO-geprüften Sets gegeben hat, hat Chrome Bedenken hinsichtlich der folgenden Einschränkungen dieser alternativen Lösung:

  • „DSGVO-Validierte Sets“ stimmen mit der DSGVO überein (obwohl nicht wirklich klar ist, was damit gemeint ist). Im Gegensatz dazu sehen die Verpflichtungen von Google vor, dass Google die „Auswirkungen auf den Datenschutz“ im Allgemeinen berücksichtigen muss. In ihrer Entscheidung über die Annahme der Verpflichtungen weist die CMA darauf hin, dass dies nicht der Pflicht von Google entspricht, die „Einhaltung der Datenschutzprinzipien gemäß den anwendbaren Datenschutzvorschriften“ zu berücksichtigen, die, wie die CMA erläutert, die Tatsache widerspiegelt, dass Google an die anwendbaren Datenschutzvorschriften gebunden ist – sowohl im Hinblick auf die Verpflichtungen als auch im Allgemeinen.
  • Wir haben Bedenken bezüglich des Datenschutzes bezüglich des Vorschlags, Domains in mehreren Sätzen anzeigen zu lassen. First-Party-Sets sind für bestimmte Anwendungsfälle vorgesehen, für die derzeit Drittanbieter-Cookies erforderlich sind, ohne dass ein umfassendes websiteübergreifendes Tracking aktiviert wird. Wenn Sie zulassen, dass Domains mit mehreren Sets verknüpft werden können, würde ein wichtiger Datenschutz im Angebot „First-Party-Sets“ entfernt werden, ohne dass weitere bedeutende Einschränkungen eingeführt werden.
  • Im Rahmen der DSGVO wird außerdem vorgeschlagen, „ein Set als eine Gruppe von Datenverantwortlichen und Auftragsverarbeitern zu definieren, die eine gemeinsame Nutzungsrichtlinie gemeinsam nutzen“. Dies ähnelt der Anforderung in unserem ursprünglichen Vorschlag für First-Party-Sets, dass alle Parteien in einem Set eine gemeinsame Datenschutzerklärung haben müssen. Wir haben diese Anforderung inzwischen aufgrund des ausgiebigen Feedbacks aus dem System entfernt, in dem wir Bedenken bezüglich datenschutzerklärungbasierter Anforderungen geäußert haben. Beispielsweise haben Website-Publisher das Feedback erhalten, dass eine gemeinsame Datenschutzerklärung aufgrund von Produkt- und geografischen Abweichungen sowie anderen Herausforderungen von Mitgliedern der W3C-Community nicht praktikabel ist (1, 2, 3). Wir sind der Meinung, dass auch bei diesem Vorschlag dieselben Herausforderungen auftreten würden.

Seit der Einführung dieser Alternative hat Chrome das Angebot für First-Party-Sets aktualisiert und Richtlinien für die Einreichung zur Erstellung neuer Sets veröffentlicht.

Fenced Frames-API

Feedback-Design Zusammenfassung Chrome-Antwort
Einschränkungen für abgegrenzte Frames während der Over-the-Air Welche Einschränkungen gelten aktuell für den Ursprungstestzeitraum in Bezug auf Fenced Frames? Wir arbeiten an einer Dokumentation zu den Einschränkungen und zum Implementierungsstatus und werden sie im ersten Quartal 2023 veröffentlichen.
Mehrere Anzeigen in einem einzelnen Fenced Frame Anfrage zur Anzeige mehrerer Werbetreibender in einem Fenced Frame in einer Auktion Diese Anfrage befindet sich aktuell noch nicht in der Entwicklungsphase. Wir freuen uns aber über zusätzliches Feedback, falls Spieler die Funktion als wichtig einstufen.
Web-Bundles Welche Anforderungen und welche Unterstützung gelten für Web Bundles mit Fenced Frames? Ob dies in Zukunft erforderlich sein wird, können wir derzeit noch nicht sagen. Alle Änderungen werden im Voraus angekündigt und werden erst umgesetzt, wenn Drittanbieter-Cookies eingestellt werden. Den aktuellen Status können Sie in dieser Erklärung nachlesen.

Shared Storage API

Feedback-Design Zusammenfassung Chrome-Antwort
Freigegebener Speicher für AdTech Ungewissheit hinsichtlich der Nutzung des gemeinsam genutzten Speichers für AdTech-Anwendungsfälle Shared Storage und die Private Aggregation API können für verschiedene Messzwecke verwendet werden, die eine websiteübergreifende Speichermessung erfordern. Einige Beispiele sind hier aufgeführt.

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

Chips

Feedback-Design Zusammenfassung Chrome-Antwort
(Auch in F3 gemeldet) Partitionierte Anforderung Bei eigenen Cookies muss eine explizite Verhaltensanforderung für das Attribut „Partitioniert“ festgelegt werden. Update für das 4. Quartal:

Nach Diskussionen zu GitHub- und PrivacyCG-Aufrufen haben wir uns einig, dass partitionierte Cookies für eigene Cookies den Partitionierungsschlüssel (A, A) verwenden, wobei „A“ die Website der obersten Ebene ist. Dieses Verhalten wird in der Erklärung und in der Spezifikation dokumentiert.
Cookie-Verwaltung Gibt es Tools zum Verwalten/Verwalten von eigenen oder Drittanbieter-Cookies? Mit den Chrome-Entwicklertools und NetLog können Websites mit aktivierter Blockierung von Drittanbieter-Cookies getestet werden. Beide Tools melden, wenn Cookies aufgrund der Nutzerkonfiguration blockiert werden. Wir freuen uns über Feedback zu zusätzlichen Prüfwebsites.

FedCM

Feedback-Design Zusammenfassung Chrome-Antwort
Der IdP benötigt RP-Kenntnisse, um eine Sitzung zuzulassen Problem, wenn ein Nutzer versucht, sich über zwei verschiedene RPs beim Feide-IdP anzumelden Mögliche Lösungen für dieses Problem finden Sie hier.
Interoperabilität Bedenken hinsichtlich der Auswirkungen von FedCM auf die Beziehung zwischen Nutzern und den Websites, auf denen sie sich über FedCM anmelden, sowie „Interoperabilität“ zwischen Websites FedCM ist bestrebt, weiterhin Dienste für föderierte Identitäten zu unterstützen, die derzeit auf Cookies von Drittanbietern basieren, nachdem Drittanbieter-Cookies aus Chrome entfernt wurden. Wir gehen davon aus, dass FedCM nur eine Option für solche Dienste sein wird. Identitätsanbieter (IdPs) und vertrauende Parteien (RPs) können andere Technologien verwenden, die ihren Anforderungen besser entsprechen.

Offenbar sind Bedenken hinsichtlich der Beziehung zwischen Nutzer und RP sowie der „Interoperabilität“ auf ein Missverständnis des FedCM-Vorschlags zurückzuführen. Sobald sich der Nutzer auf der Website des RP angemeldet hat, kann FedCM selbst entscheiden, welche Informationen in welcher Form an den RP weitergegeben werden. Gemäß FedCM müssen Identitätsanbieter „für jedes [RP], bei dem sich der Nutzer authentifiziert wird, eine eindeutige pseudonymisierte Kennung erstellen“. Vielmehr steht FedCM für jeden IdP offen, um zu entscheiden, ob er die tatsächliche ID des Nutzers, eine websitespezifische Version dieser ID oder eine andere Version dieser Informationen teilen möchte.

In der FedCM-Spezifikation wird die websiteübergreifende Korrelation als Datenschutzrisiko im Zusammenhang mit der API identifiziert. Außerdem werden gezielte Kennungen (pro Website) als mögliche Abhilfe behandelt. Die Entscheidung, ob gerichtete Kennungen verwendet werden sollen, bleibt jedoch den IdPs überlassen, nicht dem Browser.

FedCM bietet bereits eine Auswahlmöglichkeit für Nutzer in Bezug auf ihre Identität. Wenn ein Nutzer beispielsweise mehrere Identitäten mit demselben IdP hat (z.B. ein Arbeitsprofil und ein privates Profil), bietet FedCM eine Möglichkeit für den Nutzer, auszuwählen, mit welcher Identität er sich auf der RP-Website anmelden möchte. Darüber hinaus entscheidet jeder RP selbst, welche IdPs auf seiner Website unterstützt werden. Ein Aspekt dieser Entscheidung ist die Berücksichtigung des Mechanismus, auf den sich ein IdP stützt, unabhängig davon, ob es sich um FedCM oder eine andere Technologie handelt. Auch hier gibt der Browser keine Auswahlmöglichkeiten für RPs oder IdPs vor.

Spam und Betrug bekämpfen

Private State Token API

Feedback-Design Zusammenfassung Chrome-Antwort
Umgang mit Bots Was passiert, wenn der Aussteller feststellt, dass Private State Tokens für Bots ausgestellt wurden? Damit Tokens, die an Bots ausgegeben werden, nicht über längere Zeit im System verbleiben, sollten Aussteller die Schlüssel zum Signieren von Tokens regelmäßig rotieren, damit alte Tokens, die gemäß einer potenziell fehlerhaften Ausstellungslogik ausgestellt wurden, ablaufen und Websites neuere Tokens mit aktualisierter Ausstellungslogik einlösen.
Formulareinreichungen auf derselben Website Können Private State Tokens für Formularübermittlungen auf derselben Website verwendet werden, die eine ganzseitige Navigation (z.B. Content-Type: application/x-www-form-urlencoded) anstelle einer Anforderung von den Fetch-/XMLHttpRequest-APIs umfassen? Dies wird derzeit in der ersten Version der Private State Tokens nicht unterstützt. Wenn es eine starke Nachfrage nach diesem Anwendungsfall gibt, freuen wir uns über Feedback.
Serverseitige Überprüfung Fragen dazu, ob Private State Tokens serverseitig bestätigt werden können Tokens werden beim Aussteller eingelöst und der Aussteller erstellt dann einen Einlösungsdatensatz, der das Token selbst oder einen vom Token abgeleiteten signierten Wert enthalten kann. Server können diesen Einlösungsdatensatz verwenden, um die Authentizität des Tokens zu überprüfen, und wir gehen davon aus, dass verschiedene Ausstellersysteme unterschiedliche Standards für die Interpretation ihrer Einlösungsdaten entwickeln werden.