Feedbackbericht – 1. Quartal 2023

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

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google verpflichtet, vierteljährlich öffentliche 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 API, FLEDGE API und Attribution Reporting API 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
Tests und Testversionen Relevanz der Tests für die Bewertung durch die CMA, wenn die Privacy Sandbox APIs zum Zeitpunkt des Tests noch nicht fertig sind Die Entwicklung der Privacy Sandbox APIs schreitet zügig voran. Sie sind bereits im Origin Trial zum Testen verfügbar und werden diesen Sommer allgemein für 100% des Traffics eingeführt.

Außerdem haben wir die Zeitpläne für bestimmte Funktionen (z. B. FLEDGE-Berichte auf Ereignisebene, FLEDGE-Rendering mit iFrames) verdeutlicht, die erst 2026 eingestellt werden.

Wir empfehlen der Branche, die APIs zu testen und der CMA Feedback dazu zu geben, was die Tester nach der Einstellung von Drittanbieter-Cookies voraussichtlich benötigen werden. Dies kann bei der Bewertung der wahrscheinlichen Auswirkungen der Einstellung von Drittanbieter-Cookies helfen.
Nutzersteuerung Klare Anleitung für das Ökosystem zu den Auswirkungen der Privacy Sandbox APIs auf die Nutzereinstellungen Wir können keine Rechtsberatung dazu anbieten, welche Nutzersteuerungen im System verwendet werden dürfen. Gleichzeitig testen wir in Chrome für einen sehr kleinen Prozentsatz der Nutzer die aktualisierten Privacy Sandbox-Einstellungen („Verbesserter Datenschutz bei Werbung“), um die Privacy Sandbox-Technologien weiter zu verbessern. Die Updates umfassen verständlichere, hilfreichere Formulierungen und Layouts. Sobald Chrome diese Verbesserungen bewertet und entschieden hat, ob sie auf eine größere Gruppe ausgeweitet werden sollen, können weitere Informationen an das System weitergegeben werden.
Datenleck Risiko, dass selbst erhobene Daten bei einem manipulierten Browser an Google und andere Dritte weitergegeben werden In unserer Erläuterung zu FLEDGE wird deutlich, dass die Daten einer Anzeigentechnologie nur mit derselben Anzeigentechnologie geteilt werden (entweder mit ihren Worklets oder ihren vertrauenswürdigen Servern) oder wenn sie von dieser Anzeigentechnologie ausdrücklich freigegeben werden (z. B. wenn ein Käufer einem Verkäufer die Anzeigen-URL zeigt, die er schalten möchte). Die einzige Ausnahme ist, dass die K-Anonymitätsprüfung von einem global zentralisierten Server durchgeführt werden muss. Wir investieren weiterhin erhebliche Ressourcen in diesen Bereich. In der Erläuterung zur K-Anonymität erfahren Sie mehr darüber, wie wir den Datenschutz betrachten.

Darüber hinaus können wir Ihnen gerne weitere Details dazu nennen, wie die beim Design des K‑Anonymitätsservers verwendeten AdTech-Schutzmaßnahmen funktionieren.
Zusätzliches Diskussionsforum W3C um ein zusätzliches Forum für nicht technische Akteure des Ökosystems bitten, um Feedback zu geben Das Feedback-Formular für die Privacy Sandbox eignet sich für allgemeine und spezifische Kommentare, technische und nicht technische.
Die Improving Web Advertising Business Group ist ein Forum für Diskussionen über wöchentliche Anrufe und ein GitHub-Repository.
Auf der Feedbackseite zur Privacy Sandbox werden weitere Möglichkeiten zum Geben von Feedback und zur Teilnahme an Diskussionen erläutert. Außerdem finden weiterhin Veranstaltungen wie öffentliche Sprechstunden statt, bei denen Fragen gestellt und Inhalte geteilt werden können. Außerdem hat Chrome im letzten Quartal mehr als ein Dutzend Branchenveranstaltungen ausgerichtet oder daran teilgenommen.
Erläuterung zum Zeitplan Klarstellung zum genauen Datum der allgemeinen Verfügbarkeit im 3. Quartal 2023 Gemäß dem Zeitplan auf PrivacySandbox.com soll die allgemeine Verfügbarkeit mit der Veröffentlichung von Chrome-Version 115 beginnen.
reCAPTCHA Auswirkungen von Sandbox-APIs auf den Anwendungsfall „Spamerkennung“ von reCATPCHA Wir erhalten regelmäßig Feedback von reCAPTCHA, um sicherzustellen, dass sich Privacy Sandbox-Vorschläge nicht wesentlich auf die Websicherheit oder den Betrug auswirken. Das Unternehmen entwickelt einen eigenen Plan, um sich auf die Einstellung von Drittanbieter-Cookies vorzubereiten und darauf anzupassen. Diese Frage sollte daher am besten von ihm beantwortet werden.
Chrome-Erweiterungen Werden Privacy Sandbox-Technologien wie Maßnahmen gegen verdecktes Tracking (Anti Covert Tracking, ACT) auf Chrome-Erweiterungen angewendet? Wir haben noch keine Ankündigung dazu gemacht, ob das Gesetz für Chrome-Erweiterungen gilt. Wenn eine Technologie jedoch Informationen über einen Nutzer heimlich erhebt, entspricht dies nicht unseren Datenschutzprinzipien.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema Zusammenfassung Chrome-Antwort
TAG-Designüberprüfung Die TAG hat eine frühe Designüberprüfung von Topics veröffentlicht. Wir bleiben Topics treu und haben auf der Seite mit den neuesten Updates und in diesem Artikel ein Update zu unseren Plänen veröffentlicht. Wir haben Punkt für Punkt auf die TAG-Überprüfung geantwortet und unsere Vision auf höherer Ebene hier geteilt. Die Topics API wird weiterhin zu den APIs gehören, die im Werbesystem im Laufe des Jahres 2023 getestet werden sollten. Wir hoffen, dass das Feedback aus den Tests und die Erfahrungen der Implementierer einen wertvollen Beitrag zu zukünftigen Bemühungen um plattformübergreifende Standards in diesem Bereich leisten werden. Wir freuen uns darauf, weiterhin mit dem gesamten System zusammenzuarbeiten, um einen möglichen Übergang zu erleichtern, bei dem die Topics API ein vereinbarter Standard mit browserübergreifender Kompatibilität sein könnte.
Herangehensweise an Themen Unterstützung für den offenen Ansatz von Chrome bei der Entwicklung der Topics API Wir freuen uns über Ihr Feedback und möchten auch in Zukunft mit der Branche zusammenarbeiten, um eine Topics API zu entwickeln, die für das gesamte Ökosystem von Nutzen ist.
(Auch im 3. Quartal 2022 gemeldet)
Die Thementaxonomie ist nicht detailliert genug.		 Die Taxonomie für allgemeine Themen umfasst keine detaillierteren Themen, einschließlich regionaler. Update zu Q1:

Wir arbeiten kontinuierlich an Verbesserungen der Taxonomie. Im 2. Quartal werden wir eine aktualisierte Taxonomie für die Topics API ankündigen. Bei der Entwicklung dieser neuen Taxonomie haben wir eng mit Unternehmen aus der gesamten Branche zusammengearbeitet.
Wir suchen aktiv nach Feedback zur Taxonomie, die für das Werbesystem am nützlichsten wäre. Bei der Entscheidung, ob die Anzahl der Themen erweitert oder detailliertere Themen aufgenommen werden sollen, sollten Sie einige Aspekte berücksichtigen, darunter: 1) potenzielle Auswirkungen auf den Datenschutz (mehr Themen können das Risiko von Fingerprinting erhöhen) und 2) die Möglichkeit, zuvor beobachtete Themen abzurufen (bei mehr Themen ist die Wahrscheinlichkeit geringer, dass eine Anzeigentechnologie das ausgewählte Thema in der Vergangenheit bereits gesehen hat).
(wurde auch im 4. Quartal 2022 gemeldet)
Auswirkungen auf selbst erhobene Signale		 Das Themensignal kann sehr wertvoll sein und andere interessenbezogene Signale aus selbst erhobenen Daten dadurch abwerten. Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist. Topics wurde entwickelt, um diesen Anwendungsfall zu unterstützen. Uns ist bekannt, dass einige große Publisher befürchten, dass Topics sich negativ auf ihre Strategien für selbst erhobene Daten auswirken wird. Wir freuen uns auf die Tests, die uns Aufschluss über die Auswirkungen von Topics auf Publisher geben werden.
Anwendungsfälle für Themen, die nicht mit Werbung in Verbindung stehen Verwendung von Topics zu anderen Zwecken als der Auslieferung interessenbezogener Werbung Topics wurde für den Anwendungsfall der interessenbezogenen Werbung entwickelt, der unserer Meinung nach für das kostenlose und offene Web von entscheidender Bedeutung ist. Wir suchen derzeit nach Feedback zu anderen Anwendungsfällen und prüfen diese.
Standard-Opt-in-Status Auswirkungen regionaler Gesetzgebung auf die Standardeinstellungen für die Einwilligung in Topics Wir sind nicht in der Lage, uns zu rechtlichen Meinungen zu äußern.
(Auch im 3. Quartal 2022 gemeldet)
Falsch kategorisierte Websites		 Ausrichtung von Anzeigen, wenn Themen für eine bestimmte Website falsch kategorisiert sind Update zu Q1:
Im 2. Quartal werden wir einen aktualisierten Klassifikator für die Topics API ankündigen. Wir freuen uns auf die Zusammenarbeit mit dem gesamten System.
Als Reaktion auf das aktuelle Feedback werden Websites anhand einer von Menschen zusammengestellten Überschreibungsliste mit den beliebtesten Websites und einem On-Device-ML-Modell klassifiziert. In Chrome werden derzeit Optionen geprüft, mit denen Websites zur Topics-Klassifizierung beitragen können. Alle Verbesserungen der Nützlichkeit müssen gegen die Datenschutz- und Missbrauchsrisiken abgewogen werden. Zu den Risiken gehören beispielsweise: Websites, die sich selbst kennzeichnen, um Themen unterschiedliche (und potenziell sensible) Bedeutungen zuzuordnen; Websites, die ihre Themen aus finanziellen Gründen falsch darstellen; Websites, die Themen angreifen, um ihre Nützlichkeit für andere zu verringern (z. B. durch Spamming der Themen des Nutzers mit bedeutungslosem Rauschen). Die Öffentlichkeit kann diese Komponenten untersuchen. Die entsprechenden Tools sind über chrome://topics-internals oder dieses Collab verfügbar. Wir gehen davon aus, dass sich die Klassifizierung durch Tests im Laufe der Zeit verbessern wird. Wir freuen uns über Feedback zu Beispielen für Websites, die möglicherweise falsch kategorisiert wurden.
Themenklassifikator Anfordern, dass zusätzliche Informationen mit den Gründen zurückgegeben werden, wenn „Keine Themen“ an den Aufrufer zurückgegeben wird, um Fehler zu beheben Wir verstehen und schätzen, dass Entwickler bei der Integration der Topics API in ihre Systeme Debug-Tools hilfreich finden. Wenn wir jedoch zusätzliche Informationen offenlegen (z. B. den Grund, warum keine Themen zurückgegeben wurden), können wir versehentlich Informationen weitergeben, die es Dritten ermöglichen, zusätzliche Details zu ermitteln (z. B. ob ein Nutzer im Inkognitomodus ist oder die API deaktiviert hat). Das kann den Datenschutz der Nutzer beeinträchtigen. Wir planen derzeit keine zusätzlichen Tools zur Fehlerbehebung. Wir freuen uns aber über Feedback dazu, welche Tools hilfreich wären.
Private Information Retrieval (PIR) Anfrage zur Einführung von Private Information Retrieval in der Topics API Wir haben die Verwendung von PIR bereits untersucht und die Vor- und Nachteile hier beschrieben.
Gebotsstream Werden Themen im Gebotsteam getrennt von vom Verkäufer definierten Zielgruppen dargestellt? Die Topics API ist ein von Chrome entwickelter Privacy Sandbox-Vorschlag, der sich vom Vorschlag für vom Verkäufer definierte Zielgruppen des IAB Tech Lab unterscheidet. Wir gehen davon aus, dass die beiden im Bidstream klar voneinander getrennt sind. Weitere Informationen zur Darstellung von Themen in OpenRTB-Gebotsanfragen

Protected Audience API (früher FLEDGE)

Feedbackthema Zusammenfassung Chrome-Antwort
Verfügbarkeit der FLEDGE-Funktion Klarstellung der Zeitpläne für Tests und Implementierung von FLEDGE-Funktionen wie der Erzwingung von Fenced Frames und der k-Anonymität. Wir haben den Status verschiedener FLEDGE-Funktionen und deren voraussichtliche Verfügbarkeit veröffentlicht. Wir freuen uns über Feedback zu dieser Ankündigung, da wir FLEDGE kontinuierlich weiterentwickeln.
Einschränkungen beim Rendern von Produkten Lockerung der Einschränkungen für Anzeigen aus mehreren Elementen für FLEDGE-Abgeschirmte Frames beantragen Wie wir im Februar angekündigt haben, bleibt die Verwendung von abgegrenzten Frames bis mindestens 2026 optional. Das Verhalten von iframes wird durch urn-iframes unterstützt. Wir freuen uns auf weitere Diskussionen zu diesem Thema.
Skalierbarkeitsprobleme FLEDGE-Leistung bei steigender Nutzung Wir gehen dem Feedback nach und versuchen, mehr Kontext zu erhalten, damit wir umsetzbare Lösungen vorschlagen können. Im ersten Schritt haben wir das Feedback in zwei Kategorien unterteilt:
  1. SSP-gestützte Filterung zur Optimierung der Anzahl der Abfragen pro Sekunde (Queries per Second, QPS) sowohl a) für die SSP als auch b) für die DSPs.
  2. Logik für die tägliche Aktualisierung von Interessengruppen zur Optimierung der QPS-Last auf DSPs.
(wurde auch im 3. Quartal 2022 gemeldet)
Sichtbarkeit der Gebotslogik		 Bedenken, dass die DSP-Gebotslogik in JavaScript freigegeben wird Update zu Quartal 1:

Wir haben einen Vorschlag veröffentlicht, der die Möglichkeit von Angreifern einschränkt, Daten auf explorative Weise (Force Browsing) vom Server anzufordern. Wir freuen uns über Feedback oder Unterstützung für den Vorschlag von Akteuren aus dem Google-System.
Probleme beim Testen Kleinere DSPs können FLEDGE jetzt richtig testen und das Risiko verringern, dass Werbetreibende nur an Tests mit größeren DSPs interessiert sind. Wir arbeiten gerne mit kleineren DSPs zusammen und empfehlen dringend, die Tests für DSPs und Werbetreibende aller Größen auszuweiten, sobald FLEDGE allgemein verfügbar ist. Wir würden gerne wissen, wie wir sie am besten beim Testen von FLEDGE mit anderen im Ökosystem unterstützen können. Wir freuen uns auch über Ideen und Initiativen der Branche, um Werbetreibende zu motivieren, mit kleineren DSPs zu testen.
Dynamisches Remarketing Ist dynamisches Remarketing nach der Einstellung von Drittanbieter-Cookies mit FLEDGE weiterhin möglich? Wir überlegen, wie wir auf diese Frage reagieren können. Wir würden uns freuen, wenn Akteure im Google-Werbenetzwerk uns weitere Informationen dazu senden, wie sie dynamisches Remarketing einsetzen möchten.
Betrug/Missbrauch Wie kann das System die Risiken reduzieren und verhindern, dass sich böswillige Akteure oder Käufer als erwünschte Zielgruppe präsentieren? Wir freuen uns auf weitere Gespräche mit Akteuren aus dem Werbesystem zu Betrug und Missbrauch und begrüßen weiteres Feedback in diesem Bereich.
Nutzereinstellungen Speichern und Verwenden von Nutzereinstellungen bei der Anzeigenauswahl Bei bestimmten Anzeigen ist die entsprechende Anzeigentechnologie am besten in der Lage, Einstellungen dafür vorzunehmen, welche Creatives ausgeliefert werden oder wie sie ausgewählt werden.
Vorschlag für quantitative Tests Sollten quantitative Tests für eine aussagekräftige Auswertung auf Traffic ohne Drittanbieter-Cookies oder mit SSPs durchgeführt werden, die nur FLEDGE verwenden? Wie kann das Mischen von Signalen aus Drittanbieter-Cookies vermieden werden? Wir freuen uns über dieses Feedback und arbeiten mit der CMA zusammen, um Tests zu entwickeln, die ein zuverlässiges Bild der Auswirkungen der Einstellung von Drittanbieter-Cookies und der Einführung der Privacy Sandbox-Vorschläge auf das Ökosystem liefern. Wir empfehlen Ihnen, zusätzliches Feedback zum Vorschlag der CMA für quantitative Tests direkt an die CMA weiterzuleiten.
Klarere Dokumentation Bitte um klarere Dokumentation zur Auktionskonfiguration In den kommenden Wochen werden wir einen Blogpost mit einer zusätzlichen Übersicht zu FLEDGE-Auktionsberichten veröffentlichen.
Parallelisierung Unterstützt der Gebots- und Auktionsdienst die Parallelisierung? Eine Anzeigentechnologie, die Gebot-/Auktionsserver verwendet, kann mehrere Server starten, die Ergebnisse parallel ausliefern können.
Minderung des Missbrauchsrisikos Reicht der FLEDGE-K-Anonymitätsserver mit privaten Status-Tokens aus, um den Datenschutz der Nutzer zu gewährleisten? Die Motivation für die k-Anonymität liegt weniger im Microtargeting als in der Absicherung während der Übergangsphase, in der FLEDGE Berichte auf Ereignisebene zulässt. Wir haben weitere Informationen geteilt und freuen uns über zusätzliches Feedback.
ES-Modulkonflikt Antrag auf Streichung von generateBid als globale Funktion, da sie mit dem ES-Modul in Konflikt steht Wir besprechen diesen Antrag und freuen uns über zusätzliches Feedback.
Komponentenauktion Mehr Kontrolle für Publisher bei Auktionsdesigns Gebots- und Auktionsplan zur Unterstützung von Komponentenauktionen, wie bei Chrome auf dem Gerät
B&A-Zeitachsen Klarheit über den Zeitplan für Anbieter von Anzeigentechnologien, die B/A-Server testen möchten Wir haben die B&A-Erläuterung und den Abschnitt zum Zeitplan aktualisiert, um klare Definitionen der Zeitpläne für die verschiedenen Phasen von Chrome-B&A-Tests zu enthalten, nachdem wir sie an die CMA angepasst haben.
Zeitlimit-Kontrollschema Verbesserung des Zeitlimit-Kontrollmechanismus, der derzeit für FLEDGE verfügbar ist Das ist ein interessanter Vorschlag. Wir werden diesen Vorschlag der Warteschlange hinzufügen und über unsere Entwicklungen berichten.
Creative-Gebotsstreams Möglichkeit, ein erfolgreiches Gebot basierend auf dem Creative zu überprüfen und zu filtern Das ist ein interessanter Vorschlag. Wir werden diesen Vorschlag der Warteschlange hinzufügen und über unsere Entwicklungen berichten.
reportWin Vorschlag, zusätzliche Informationen zum Gebot mit der höchsten Punktzahl von einem anderen Inhaber einer Interessengruppe als dem Gewinner in der Funktion reportWin bereitzustellen Das ist ein interessanter Vorschlag. Wir werden prüfen, ob wir zusätzliche Signale in die zusammengefassten Berichte aufnehmen können. Hier können Sie uns zusätzliches Feedback geben.
Ereignistypen Ereignistypen bei der Integration mit FLEDGE plattformübergreifend standardisieren Das ist ein interessanter Vorschlag. Wir werden diesen Vorschlag der Warteschlange hinzufügen und über unsere Entwicklungen berichten. Dies erfordert eine Abstimmung mit unseren weiteren Bemühungen in diesem Bereich, da es sich nicht nur auf FLEDGE, sondern auch auf andere Privacy Sandbox-APIs auswirken würde. Hier können Sie uns weiteres Feedback geben.
Langfristige Lösungen für Berichte auf Ereignisebene Interesse daran, bestimmte Daten wie highestScoringOtherBid auch nach der Einstellung von Drittanbieter-Cookies verfügbar zu halten Wie wir im Blogpost vom Februar angekündigt haben, werden Berichte zu Auktionsgewinnen auf Ereignisebene noch mindestens bis 2026 unterstützt. Weitere Details können wir derzeit nicht bekannt geben. Wir freuen uns aber über zusätzliches Feedback dazu, warum bestimmte Daten nach der Einstellung von Drittanbieter-Cookies verfügbar bleiben sollten.
Limit für Interessengruppen Wie viele Interessengruppen kann ein einzelner Browser einem Ursprung hinzugefügt werden? In Chrome sind bis zu 1.000 Interessengruppen pro Inhaber und bis zu 1.000 Inhaber von Interessengruppen zulässig. Sie sollen als Leitlinien dienen und nicht im normalen Betrieb überschritten werden.
Signale auf Ereignisebene Unterstützung für einen Vorschlag zur Bereitstellung von Signalen auf Ereignisebene für generateBid und reportWin, die für das Training von Modellen für maschinelles Lernen verwendet werden können Unsere Entscheidung zu browserbasierten Signalen und von AdTech-Anbietern definierten Signalen haben wir hier veröffentlicht. Wir freuen uns über zusätzliches Feedback.
Gebotsskript Fügen Sie die Nutzer-ID in die URL zum Gebotsskript ein. Das ist nicht möglich, da für FLEDGE die zusätzliche Anforderung gilt, dass das Tupel aus dem Inhaber der Interessengruppe, der URL des Gebotsscripts und dem gerenderten Creative k-anonym sein muss, damit eine Anzeige ausgeliefert werden kann.
Erzwingung der k-Anonymität Wird die k-Anonymität für das Paar „componentAd, size“ erzwungen? Ja, das ist richtig. Weitere Informationen finden Sie unter turtledove/issues/312.
Anforderungen an Gebots- und Auktionsdienste Wie unterstützen B&A-Dienste Teilnehmer, die On-Device-FLEDGE- und andere B&A-Dienste einbinden? Wir arbeiten noch an der endgültigen Version des Designs und freuen uns über zusätzliches Feedback.
Post-View-Attribution Wird die Post-View-Attribution unterstützt? Derzeit gibt es keine Standarddefinition für die Sichtbarkeit. Wir verwenden das Creative selbst, um ein Wiedergabeereignis zu markieren. Weitere Informationen finden Sie unter turtledove/issues/452.
Ausrichtung auf ähnliche Zielgruppen Unterstützt die Privacy Sandbox das „Lookalike-Targeting“? Hier finden Sie weitere Informationen zu diesem Anwendungsfall. Wir freuen uns über weitere Beiträge.
API für Echtzeit-Monitoring Vorschlag für einen Echtzeit-FLEDGE-Monitoring-Ansatz Wir besprechen den Vorschlag und freuen uns über zusätzliches Feedback.
FLEDGE-Berichte reportWin und reportResult sollten in zufälliger Reihenfolge erfolgen, um eine Über- oder Untererfassung zu vermeiden. reportResult() muss zuerst vom Verkäufer und dann vom Käufer ausgeführt werden, damit Verkäufersignale aus reportResult() in reportWin() einbezogen werden können.reportWin() Weitere Informationen finden Sie in diesem Hilfeartikel.
Benutzerdefinierte Schlüssel/Wert-Server Werden benutzerdefinierte K/V-Server in Zukunft unterstützt? Wir diskutieren die Frage hier und freuen uns über weitere Beiträge.
Auktion auf oberster Ebene Muss man der Ad-Server sein, um Auktionsmechanismen der obersten Ebene auszuführen? In der FLEDGE API wird nicht angegeben, welche Partei sie aufrufen muss. Im Design von FLEDGE gibt es keine Anforderungen in diesem Sinne. Jeder kann eine FLEDGE-Auktion abhalten (einschließlich Auktionen mit mehreren Verkäufern). Wie im Bericht zu 4. Quartal 2022 erwähnt, können mit FLEDGE alle Publisher die Struktur der Auktion auswählen, einschließlich der Auswahl von Verkäufern auf oberster Ebene und Komponentenverkäufern.
API-Bereich Wird FLEDGE mit selbst erhobenen Daten arbeiten? Im 2. Quartal 2023 werden wir Inhalte veröffentlichen, in denen klargestellt wird, dass selbst erhobene Daten mit FLEDGE sowohl 1) als Logik zur Bestimmung der Zugehörigkeit zu einer Interessengruppe als auch 2) als Gebotshinweise für Nutzer zur Verwendung bei der anschließenden Generierung der Gebotslogik verwendet werden können.
Domainübergreifende Interessengruppen Möglichkeit, domainübergreifende Interessengruppen zu erstellen Alle Informationen, die zum Zeitpunkt des Hinzufügens eines Browsers zu einer Interessengruppe verfügbar sind, können für diese Zielgruppe verwendet werden. Wenn Drittanbieter-Cookies eingestellt werden, ist die Verfügbarkeit von websiteübergreifenden Daten zur Erstellung von Interessengruppen eingeschränkt.
Clientseitige Gebotslogik Vorhandene serverseitige Gebotslogik auf die Clientseite portieren Wir möchten mehr darüber erfahren, welche Bereiche im Migrationsprozess schwierig sind oder derzeit fehlen. Wir freuen uns über zusätzliches Feedback oder Erkenntnisse.
K/V-Serverwerte Müssen K/V-Serverwerte vom Typ „String“ sein? Der Wert muss ein String sein, aber Objekte können in JSON oder Protocol Buffers gespeichert und in einen String serialisiert werden.
Sperrliste für Werbetreibende Welche Signale sind für Käufer für eine Werbetreibenden-Blockliste geeignet? Der entsprechende Ort befindet sich entweder in auctionSignals oder in perBuyerSignals.
Gebotseinheit Unterstützung verschiedener Gebotseinheiten wie CPI und CPM Wir würden gerne mehr darüber erfahren, warum dies angesichts des aktuellen Designs erforderlich ist, und würden uns zusätzliches Feedback von Ihnen wünschen.
Auktionslogik Entscheidet der Browser oder der Ad-Server über den Gewinner einer Auktion? Die Auswahl der Gewinner erfolgt in der Sandbox und alle Entscheidungen werden durch den Code des Verkäufers getroffen. Der Browser bietet lediglich eine versiegelte, private Umgebung, in der der Code von Käufern und Verkäufern ausgeführt wird.
Berechtigungsrichtlinie Wird die aktuelle FLEDGE-Berechtigungsrichtlinie nach Ablauf des Ursprungstests weiterhin erzwungen? Für den Origin-Test sind die aktuellen Standard-Zulassungslisten für beide Funktionen vorübergehend und werden geändert. Wir möchten wissen, wie viel Zeit die Werbetreibenden für die Vorbereitung auf die Änderung benötigen, bevor wir sie einführen.
Signalgrößenbeschränkung Anfragen für vertrauenswürdige Bidding-Signale werden für mehrere Interessengruppen mit derselben trustedBiddingSignalsUrl zusammengeführt. Das Größenlimit von 2 MB ist eine Einschränkung. Die Einschränkung gilt für On-Device-Caller, um eine Überlastung der Ressourcen auf dem Gerät zu verhindern. Für Anrufer von einem B&A-Server gilt eine weniger strenge Einschränkung.
Signale für die Berichterstellung Fügen Sie ein zusätzliches Signal hinzu, „script-errors“, um die Anzahl der clientseitigen Fehler pro Inhaber der Interessengruppe und pro computeBid oder reportWin / reportResult abzurufen. Wir prüfen mögliche Datenschutzbedenken im Zusammenhang mit diesem Vorschlag und würden uns freuen, wenn Akteure aus dem Werbesystem uns weitere Informationen dazu geben würden, warum dies erforderlich ist.
K-Anon-Fenstergröße Erhöhen Sie die K-Anon-Fenstergröße über das aktuelle Limit von 7 Tagen. Wir prüfen diese Option derzeit und freuen uns auf zusätzliche Informationen aus der Community.
Geräteleistung Wie geht FLEDGE mit der Geräteleistung um, wenn sich der Nutzer in einer großen Anzahl von Interessengruppen befindet? FLEDGE bietet mehrere Zeitüberschreitungs-, Priorisierungs- und Grenzwertoptionen für SSPs und DSPs, die Werbetreibenden eine detaillierte Steuerung in Situationen ermöglichen, in denen die Geräteleistung ein Grund sein kann, die Teilnahme an Auktionen einzuschränken, wenn sich das Gerät in einer großen Anzahl von Interessengruppen befindet.
Tests von B&A-Diensten Bitten Sie die Akteure des Ökosystems, während der Testphase ihren eigenen Server zu verwenden, damit mehr Protokolle für das Debuggen verfügbar sind. Mit B&A können Nutzer die Server von genehmigten Cloud-Anbietern starten und skalieren. Um den Datenschutz für Nutzer zu gewährleisten, wird die Ausführung in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) erzwungen. Wir werden demnächst eine Erläuterung zum Debuggen von B&A TEE veröffentlichen und entwickeln Funktionen, die dies unterstützen. Wir suchen nach zusätzlichem Feedback zu diesem Thema.
Regulatorische Anforderungen Wird FLEDGE mit Cloud-Anbietern in verschiedenen Ländern zusammenarbeiten, um die Einhaltung lokaler behördlicher Anforderungen zu unterstützen? Wir sind immer offen für Vorschläge für andere Cloud-Anbieter. Derzeit planen wir jedoch, mindestens die Google Cloud Platform und AWS zu unterstützen, wenn die Einstellung von Drittanbieter-Cookies erzwungen wird. Weitere Informationen finden Sie in diesem Hilfeartikel.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Analyse der Auswirkungen von Rauschen Anleitung zum Ausführen einer Datenanalyse zu den Auswirkungen von Rauschen Wir haben zusätzliche Informationen zu Rauschen und zu Designentscheidungen geteilt, mit denen sich die Auswirkungen von Rauschen auf Daten aus der Anzeigentechnologie ändern lassen.

Eine ausführlichere Anleitung ist ebenfalls verfügbar.
Nullberichte Klarheit bei der Implementierung von Berichten mit Nullwerten Wir arbeiten derzeit an einem Vorschlag zur Implementierung von Null-Berichten und werden bald weitere Details bekannt geben. Durch die Implementierung von Nullberichten können wir Berichtsverzögerungen reduzieren, ohne den Datenschutz zu beeinträchtigen.
Geräuschpegel Rauschen anhand der Länge des Attributionszeitraums anpassen Wir begrüßen diesen Vorschlag und prüfen, ob er in die Spezifikation aufgenommen werden kann. Hier können Sie uns zusätzliches Feedback geben.
Triggerdatengröße Warum ist die Größe der Triggerdaten auf 3 Bit begrenzt? Die Größe ist auf 3 Bit und 8 verschiedene Werte beschränkt, damit die Menge der website- und kontextübergreifenden Informationen über einen Nutzer begrenzt ist. Wir möchten Sie bitten, Feedback zu der aktuellen Parameterisierung für Berichte auf Ereignisebene zu geben.
Trigger für Berichte auf Ereignisebene Priorisierung innerhalb eines Deduplizierungsschlüssels zulassen Wir arbeiten an Lösungen für dieses Problem und freuen uns über weitere Informationen.
Unterstützung bei der Fehlerbehebung Klarheit bei der Fehlerbehebung nach der Einstellung von Drittanbieter-Cookies Wir möchten das Debuggen nach der Einstellung von Drittanbieter-Cookies unterstützen und überlegen uns derzeit, welche Optionen dafür infrage kommen. Wir freuen uns über weitere Rückmeldungen und Ideen.
Alternativen zu Klick-Conversions Weitere Informationen zu Alternativen für Klick-Conversions anfordern Wir empfehlen allen Marktteilnehmern, die Attribution Reporting API als langlebiges privates Analysesystem für entsprechende Anwendungsfälle der Conversion-Analyse zu verwenden. Es gibt auch andere Alternativen. Anbieter von Anzeigentechnologien müssen die passende Lösung basierend auf ihren Anforderungen an Datenschutz und Funktionalität auswählen.
Anwendungsfälle für die Abrechnung Klarheit darüber, inwiefern die Attribution Reporting API Anwendungsfälle für die conversionbasierte Abrechnung unterstützt Wir arbeiten daran, eine öffentliche Mitteilung zu veröffentlichen, in der der Umfang der Attribution Reporting API für die Abrechnung erläutert wird. Die Attribution Reporting API wurde ursprünglich nicht so konzipiert, dass sie die CPA-Abrechnung direkt unterstützt. Sie unterstützt die CPC- und CPM-Abrechnung, die Abrechnungsstruktur, die von der Mehrheit der Anbieter von Anzeigentechnologien verwendet wird.
Diese Funktion wird möglicherweise in Zukunft unterstützt, wenn wir weiteres Feedback zum Werbesystem erhalten.
Unterstützung für Anwendungsfälle Dokumentation zu Anwendungsfällen für die Measurement API Wir arbeiten daran, die Dokumentation für alle Privacy Sandbox-Berichtsoberflächen zu verdeutlichen.
Klickqualität Signal zur Unterscheidung zwischen beabsichtigten und unbeabsichtigten Klicks auf eine Anzeige hinzufügen Wir besprechen die Anfrage und freuen uns über weitere Informationen.
Analysetool Unterstützung von Analyselösungen für mehrere DSPs Die Attribution Reporting API kann von Analyseanbietern verwendet werden, um Duplikate zwischen mehreren DSPs zu entfernen. Außerdem schlagen wir vor, in attributionsrc eine Liste von URLs zu unterstützen. So können DSPs Attribution Reporting API-Anfragen von Analyseanbietern einfacher unterstützen. Wir freuen uns über zusätzliches Feedback zum obigen Vorschlag.
Berichte auf Ereignisebene Anfordern, dass die Anzahl der Tage vor dem Versand des Berichts direkt verfügbar ist Diese Anfrage kann bereits anhand der derzeit verfügbaren Informationen von Anzeigentechnologien berechnet werden. Wir haben bisher kein weiteres Feedback zum Thema erhalten, sind aber für Feedback offen.
source_registration_time Fügen Sie source_registration_time in Attributionsberichten auf Ereignisebene hinzu. Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback dazu, ob die Akteure im Ökosystem diese Funktion für nützlich halten.
Inkognitomodus Sind Analyselösungen verfügbar, wenn der Nutzer im Inkognitomodus ist? Nein. Messlösungen sind nicht verfügbar, wenn ein Nutzer im Inkognitomodus ist. Drittanbieter-Cookies sind im Inkognitomodus standardmäßig deaktiviert.
Data-Clean-Rooms Sind Measurement APIs mit Clean Rooms kompatibel? Ein typischer Data-Clean-Room ist eine Umgebung, in der individuelle Daten zu eindeutigen Kennungen aus verschiedenen Quellen in eine Datenbank hochgeladen werden, um Analysen auf der Grundlage der Zusammenführung dieser zugrunde liegenden Daten durchzuführen. Die beiden Analyseframeworks für Privacy Sandbox APIs sind Berichte auf Ereignisebene und Zusammenfassungsberichte. Berichte auf Ereignisebene enthalten zwar eine von der Anzeigentechnologie bereitgestellte Ereignis-ID, die in einem Data Cleanroom verwendet werden kann, die zugehörigen Informationen zur Conversion sind jedoch begrenzt und ungenau. Verschlüsselte aggregierbare Berichte können nicht direkt in einem Clean Room verwendet werden. Die vom Aggregationsdienst bereitgestellten Zusammenfassungsergebnisse können jedoch als Eingabe für von Ihnen durchgeführte Analysen oder als ergänzende Informationen verwendet werden.

Zusammenfassungsdienst

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 4. Quartal 2022 gemeldet)
Verzögerungen bei Berichten		 Wie lange dauert es, bis die Berichte verfügbar sind? Update zu Q1 2023:

Auf Grundlage des Feedbacks unserer Partner haben wir Vorschläge unterbreitet, wie sich die Verzögerung verringern und die Auswirkungen der Verzögerung abmildern lassen.

Beide Vorschläge wurden von Werbetechnologien während WICG-Anrufen unterstützt.
Regel „Keine Duplikate“ Wie gehen Sie mit einem „verzögerten aggregierbaren Bericht“ um, wenn aggregierbare Berichte mit derselben freigegebenen ID bereits verarbeitet wurden? Wir haben einen Vorschlag zur Einführung einer zusätzlichen Berichtsverzögerung für die freigegebenen Informationen aggregierbarer Berichte und zur Definition einer freigegebenen ID für den Aggregationsdienst veröffentlicht, um die Auswirkungen von Verzögerungsverlusten auf die Aggregate API teilweise zu beheben. Wir freuen uns über Ihr Feedback zum Vorschlag.
Datenverarbeitung Unterstützung für mehrere Datenübertragungen unter Berücksichtigung der Differential Privacy mithilfe des Datenschutzbudgets aktivieren Wir prüfen derzeit die Möglichkeit, das Datenschutzbudget flexibler zu verwenden, um diesen Anwendungsfall zu ermöglichen. Bitte geben Sie uns Feedback.
(Auch im 2. Quartal 2022 gemeldet) Nutzerfreundlichkeit von Suchanfragen Aktivieren Sie die Abfrage von Schlüsselaggregaten. Update zu Quartal 1 2023:

Der Funktionswunsch wird derzeit geprüft. Wir haben aber noch keine konkreten Vorschläge.
Einschränkungen bei Ursprungstests Klärung des Umfangs des Aggregationsdienstes, z. B. der „Regel ohne Duplikate“, die derzeit nicht im Ursprungstest angewendet wird. Wir arbeiten daran, unsere Dokumentation zu aktualisieren, um zu verdeutlichen, was im Ursprungstest und in der allgemeinen Verfügbarkeit verfügbar sein wird.

Private Aggregation API

Feedbackthema Zusammenfassung Chrome-Antwort
Budget für Beiträge zur privaten Aggregation Das L1-Beitragsbudget ist zu restriktiv. Jeder Aufruf der Private Aggregation API wird als Beitrag bezeichnet. Zum Schutz der Privatsphäre der Nutzer ist die Anzahl der Beiträge, die von einer einzelnen Person erfasst werden können, begrenzt.
Wenn Sie alle aggregierbaren Werte für alle Aggregationsschlüssel summieren, muss die Summe unter dem Beitragsbudget liegen.

Im aktuellen Design wird der Beitrag einer bestimmten Quelle für die letzten 24 Stunden (als rollierender Zeitraum) begrenzt. Das ist das im Feedback erwähnte L1-Beitragsbudget. Wir empfehlen Entwicklern, die von ihnen angegebenen Werte anhand des erwarteten Volumens zu skalieren und nicht einfach den Wert 1 zu verwenden. Daher kann es sinnvoll sein, für die häufigeren Ereignisse einen kleineren Wert zu verwenden, um zu vermeiden, dass das Budget aufgebraucht wird.

Wir möchten derzeit Feedback zum Beitragsbudget der Private Aggregation API erhalten, sowohl hinsichtlich der numerischen Grenze als auch des Gültigkeitsbereichs. Wir überlegen, den Umfang von „pro Ursprung“ auf „pro Website“ umzustellen und die vorhandene Beschränkung auf einen Zeitraum von zehn Minuten mit einer größeren täglichen Beschränkung zu verschieben.

Verdecktes Tracking einschränken

User-Agent-Reduzierung/User-Agent-Client-Hints

Feedbackthema Zusammenfassung Chrome-Antwort
UA-R-Einführung Von den 10.000 wichtigsten Websites im Vereinigten Königreich senden nur 1% der Websites,die programmatische Anzeigen verwenden, HTTP-Clienthinweise. Nicht migrierte DSPs können sich auf die Funktionen zur Betrugsprävention auswirken. Bei einer Analyse desselben Datensatzes haben wir festgestellt, dass die Anzahl der Websites, auf denen UA-CH verwendet wird, deutlich über dem im Feedback angegebenen Wert von 1% liegt, wenn die Verwendung von UA-CH über das HTML-<meta>-Tag und die JavaScript-APIs berücksichtigt wird. Aufgrund dieser und anderer Fakten, einschließlich Feedback aus dem Werbesystem, sind wir zuversichtlich, dass wir die schrittweise Einführung von Phase 6 der UA-Einschränkung gemäß dem veröffentlichten Zeitplan fortsetzen können und dabei die CMA auf dem Laufenden halten. Wir weisen darauf hin, dass Websites fast zwei Jahre Zeit hatten, sich auf die Umstellung vorzubereiten. Für Websites, die noch nicht bereit sind, ist weiterhin ein Testzeitraum verfügbar.
Tipps für weitere Formfaktoren UA-CH soll zusätzliche Formfaktoren wie Fernseher und VR bereitstellen Wir begrüßen diesen Vorschlag und prüfen, ob er in das Design aufgenommen werden kann. Wir freuen uns auf Ihr zusätzliches Feedback.
Automatisierte Tests Behebung des UA-CH-Fehlers in der headless Chrome-Version vor der Veröffentlichung von UAR-Phase 6 Der betreffende Fehler wurde behoben.
UA-CH-Unterstützung auf iOS-Geräten Auf einer Website, die für Werbeanwendungen auf detaillierte UA-Informationen angewiesen ist, wird darauf hingewiesen, dass Chrome für iOS nicht unterstützt wird. Für andere iOS-Browser als Safari (einschließlich Chrome auf iOS) muss das WebKit-Projekt UA-CH unterstützen, bevor sie aktiviert werden können, da sie den Netzwerkstack steuern.

IP-Schutz (früher Gnatcatcher)

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 4. 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. Unsere Antwort hat sich seit dem 4. Quartal 2022 nicht geändert:

„Wir arbeiten mit Stakeholdern zusammen, damit Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Wir suchen Feedback aus der Branche zur Detailgenauigkeit der IP-Standortbestimmung.“
Gesetzliche Vorschriften Wenn eine Region weniger als 1 Million Einwohner hat, würde der aktuelle Grenzwert von 1 Million für den IP-Schutz verhindern, dass Websites IP-Adressen zur Einhaltung von Vorschriften verwenden. Wir arbeiten mit Stakeholdern zusammen, damit Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Wir möchten Feedback zum Thema Einhaltung der gesetzlichen Bestimmungen zum Schutz geistigen Eigentums von der Community erhalten.
Minderung des Missbrauchsrisikos Dritte können den IP-Schutz umgehen, indem sie nicht maskierte IP-Adressen an andere weitergeben. Uns ist bewusst, dass das aktuelle IP-Schutz-Angebot technisch nicht verhindern kann, dass Dritte nicht maskierte IP-Adressen mit anderen teilen. Wir arbeiten an Maßnahmen, mit denen dieses Missbrauchsrisiko vermieden werden kann.

Wir freuen uns über Feedback und Diskussionen, während wir den Vorschlag weiterentwickeln. Insbesondere möchten wir wissen, ob es Anwendungsfälle gibt, in denen Parteien der Meinung sind, dass sie nicht maskierte IP-Adressen mit anderen Parteien teilen müssen.
Netzwerkblockierung Mithilfe von IP-Schutz-Proxys können Dritte die Netzwerkblockierung umgehen. Die Entität, die die Blockierung durchführt, muss den IP-Schutz für dieses Szenario deaktivieren. Wir haben auf das Problem reagiert und freuen uns über zusätzliches Feedback.
IP-Adressblocklisten, die vom Vorschlag zum Schutz vor IP-Adressen betroffen sind Viele Anbieter von Anzeigentechnologien verwenden eine grundlegende Blockierungsliste mit IP-Adressen, z. B. die TAG-IP-Liste für Rechenzentren, um Gebote für Anzeigeninventar zu verhindern, das mit hoher Wahrscheinlichkeit betrügerisch ist (oder zumindest nicht monetarisiert werden kann). Wenn eine Anzeigentechnologie auch ein Tracker ist und dem Vorschlag zum Schutz geistigen Eigentums unterliegen könnte, kann dieses Unternehmen möglicherweise keine grundlegende Prüfung von Anzeigen durchführen, bevor es Werbeinventar kauft. Wir freuen uns über weiteres Feedback und Diskussionen zu potenziellen Problemen und Lösungen im Zusammenhang mit dem Vorschlag zum Schutz geistigen Eigentums. Eine Möglichkeit besteht darin, ähnliche Listen auf den IP-Schutz anzuwenden, damit keine Proxys für Clients verwendet werden, die von zuvor gemeldeten IP-Adressen stammen.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 4. Quartal gemeldet) Domainlimit Mehr verknüpfte Domains beantragen Unsere Antwort hat sich seit dem 4. Quartal 2022 nicht geändert:

"Wir haben in WICG-Anrufen klargestellt, dass Chrome eine praktikable Lösung bereitstellen möchte, die auch die Datenschutzinteressen der Nutzer berücksichtigt. In diesem Zusammenhang würden wir uns Feedback von der Community zu bestimmten Anwendungsfällen wünschen, 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.“
Alternative FPS-Einreichung Vorschlag für eine alternative Möglichkeit zum Einreichen globaler Listen für FPS Derzeit arbeiten wir daran, Sets von Google-Partnern in Chrome einzuführen. Dazu haben wir ein zentrales GitHub-Repository eingerichtet, in dem Sets eingereicht werden können. Wir hoffen, dass FPS eine Lücke bei bestehenden Webplattformlösungen schließen wird, um auf die Einstellung von Drittanbieter-Cookies vorbereitet zu sein. Wir erwarten, dass wir von ihnen erfahren, wie FPS von Website-Betreibern genutzt wird. Wenn die Liste der Sets im Laufe der Zeit wächst und sich das System an eine Welt ohne Drittanbieter-Cookies anpasst, können wir den Prozess so weit optimieren, dass wir alternative dezentrale Systeme wie das vorgeschlagene in Betracht ziehen können. Wir gehen davon aus, dass wir mit dem aktuellen Verfahren feste Zeiträume festlegen werden, damit wir den Aufnahmeprozess im Laufe der Zeit weiterentwickeln können. Wir können diese Idee noch einmal aufgreifen, sobald der Einreichungsprozess ausgereift ist.
Repo-Moderation Einführung der Community-Moderation für das FPS-Submission-Repository, um Missbrauch zu verhindern. Böswillige Akteure können den Prozess ganz einfach überlasten, indem sie mithilfe von Einmal-E-Mail-Adressen Sets vorschlagen. Ein überwältigendes Volumen an Anfragen kann sich auf die Verarbeitung echter Setvorschläge auswirken. Wir versuchen, die Prüfungen so objektiv wie möglich zu gestalten, indem wir auf technische Validierungschecks zurückgreifen. Wir sind der Meinung, dass dies der skalierbarste Ansatz für den Einreichungsprozess ist. Außerdem möchten wir dafür sorgen, dass der Prozess gegen Spam- und Burner-Anmeldungen resistent ist.
Zugehörige Teilmengen Kann FPS Anwendungsfälle für Drittanbieter-/SaaS-Abläufe über zugehörige Untergruppen unterstützen? Drittanbieter-/SaaS-Abläufe sind derzeit kein Anwendungsfall, der für Sets mit selbst erhobenen Daten infrage kommt. Wir freuen uns über zusätzliches Feedback dazu, wie websiteübergreifende Cookies für diese Anwendungsfälle verwendet werden.
FPS + CHIPS-Integration Integration von FPS und CHIPS zur Unterstützung von Anwendungsfällen wie A/B-Tests anfordern Wir besprechen diesen Anwendungsfall und überlegen, ihn in einem WICG-Anruf weiter zu erörtern. Wir freuen uns über zusätzlichen Input.
DSGVO Vorschlag für eine neue FPS-Untergruppe, die nach den Konzepten der DSGVO modelliert werden soll Wir haben diesen Vorschlag intern besprochen und ihn anhand anderer erhaltener Rückmeldungen sowie unserer Datenschutzziele bewertet. In dieser Antwort erklären wir, warum wir diesen Vorschlag derzeit nicht weiterverfolgen.
Speicher Voraussichtliche Änderung der Browserspeichergröße, wenn die FPS-Liste eingebunden wird Es gab bereits Präzedenzfälle, in denen Browser diese Art von Listen mit minimaler Arbeitsspeicherbelastung gespeichert haben, z. B. die Disconnect Tracking Protection List. Die Liste der selbst erhobenen Sets wird zwar lokal auf jeden Chrome-Client kopiert, wir werden die Dateigröße aber weiterhin im Blick behalten und sind zuversichtlich, dass wir den Arbeitsspeicherverbrauch optimieren können.

Fenced Frames API

Feedbackthema Zusammenfassung Chrome-Antwort
Einschränkungen für eingezäunte Frames Klarere Informationen zu den Einschränkungen durch Fenced Frames Im März haben wir unseren Erläuterungsartikel zu eingezäunten Frames aktualisiert. Dort finden Sie Informationen zu den Funktionen. Wir freuen uns über zusätzliches Feedback.
Zugriffsinformationen maximieren Zugriff auf Informationen zu benachbarten Frames erweitern Wir möchten gerne mehr darüber erfahren, warum dies eine Anforderung des Systems ist, und freuen uns über weiteres Feedback.
Fenced Frames und iFrames Fragen zur Funktionsparität zwischen umzäunten Frames und iFrames Alle verfügbaren Privacy Sandbox APIs und Berichte sind für Iframes und FencedFrames gleichermaßen verfügbar.
Größe von eingezäunten Frames ändern Die Einschränkung von Änderungen der Framegröße wirkt sich auf bestimmte Anwendungsfälle aus. Wir würden uns gern über die Arten von Anwendungsfällen informieren, die von der Einschränkung betroffen sind, und würden uns zusätzliches Feedback von Ihnen wünschen.

Shared Storage API

Feedbackthema Zusammenfassung Chrome-Antwort
Worklets von Drittanbietern Können Dritte in Shared Storage schreiben, das nach Herkunft partitioniert ist? Oder andere Worklets für Analysen durch Drittanbieter aufrufen? Der Ursprung des Browser-Kontexts, in dem der Code ausgeführt wird, bestimmt, in wessen freigegebenen Speicher die Daten geschrieben werden. Wenn einer Seite Drittanbietercode hinzugefügt wird, kann dieser Code als iFrame mit eigenem Browserkontext eingebettet werden. Dadurch kann der Drittanbietercode auf seinen eigenen Ursprung schreiben. Der Code des Drittanbieters kann auch als Script statt als iFrame eingebettet werden. Dadurch wird der Browserkontext nicht geändert und der Drittanbieter kann auf den freigegebenen Speicher des Einbettungsanbieters schreiben. Nur der Inhaber des freigegebenen Speichers kann Daten daraus lesen.
Deduplizierung Für Interaktionen außerhalb des Chrome-Systems ist keine Deduplizierung möglich. Der freigegebene Speicher soll Chrome-Browser-basierte eindeutige Reichweitenergebnisse in Chrome liefern. Wir möchten mit Anbietern von Anzeigentechnologien zusammenarbeiten, um herauszufinden, wie diese Daten in ihren Modellen für eine größere Reichweite verwendet werden können. Uns ist bewusst, dass die Ergebnisse selbst möglicherweise nur einen Teil der Interaktionen abdecken. Wir möchten mit Anbietern von Anzeigentechnologien zusammenarbeiten, um zusätzliche Modellierungsmethoden zu untersuchen, die zusätzlich verwendet werden könnten.
Conversion-Tracking-Zeitraum Lookback-Window für die Conversion-Rate anfordern, um Änderungen der Conversion im Zeitverlauf zu sehen Dies kann durch die Verarbeitung der verschiedenen Conversion-Pfade auf der Clientseite mit Shared Storage implementiert werden. Dies bietet zusätzliche Flexibilität für erweiterte Analysen über sicheren, nicht partitionierten Browserspeicher.
Gültigkeitszeitraum des Artikels Verlängerung des Ablaufzeitraums auf 90 Tage beantragen Die Datenaufbewahrungsrichtlinie wurde im November 2022 aktualisiert. Darin wird angegeben, dass jeder Schlüssel 30 Tage nach dem letzten Schreibvorgang gelöscht wird. Wir freuen uns über weiteres Feedback, damit wir besser nachvollziehen können, ob die neue Richtlinie für das gesamte System geeignet ist.
Creative-Rotation Die Anwendungsfälle für die Creative-Rotation spiegeln keine tatsächlichen Aktionen nach der Auktion wider. Wir möchten von weiteren AdTech-Unternehmen auf Käuferseite wissen, ob die Dokumentation zur Creative-Rotation korrekt ist.

CHIPs

In diesem Quartal haben wir kein Feedback erhalten.

FedCM

Feedbackthema Zusammenfassung Chrome-Antwort
Endpunkt für Identitätsbestätigung Zulassen beliebiger Anfragen an den Endpunkt für Identitätsbestätigungen Wir haben mit Mozilla zusammengearbeitet, um mit diesem Pull-Request die Möglichkeit von Websites einzuschränken, nutzerunabhängige Anfragen mit Anmeldedaten zu senden, ohne Nutzer zu belästigen. Wir werden auch weiterhin anderes Feedback prüfen und darauf reagieren.
Identität vorab ausfüllen Kann FedCM verwendet werden, um Anmeldeformulare mit einem Identitätsanbieter aus der FedCM-Liste vorab auszufüllen? Bei diesem Anwendungsfall besteht die Gefahr, dass Daten preisgegeben werden, wenn eine Website, die keine Interaktion mit dem Nutzer hatte, den letzten IDP abfragen kann, den der Nutzer verwendet hat. Wir besprechen dieses Problem und freuen uns über zusätzliches Feedback.
Kontextbezogene Kontoauswahl Vorschlag, kontextbezogene Signale in die Benutzeroberfläche für die Kontoauswahl einzufügen Wir prüfen diesen Vorschlag und freuen uns auf weitere Diskussionen.

Spam und Betrug bekämpfen

Private State Tokens API (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Umfrage zur Erfassung von Funktionen Anfang des ersten Quartals haben wir die Ergebnisse unserer Umfrage zu den Funktionen für verschiedene Anwendungsfälle zur Betrugsprävention erfasst und veröffentlicht (Video, Ergebnisse). Wir werden dieses Feedback bei der Entwicklung neuer Vorschläge und Prototypen für maßgeschneiderte, datenschutzfreundliche APIs für Betrugsprävention berücksichtigen. Wir gehen davon aus, dass wir die Entwicklung priorisieren werden, wenn es einen ausreichenden Bedarf gibt und es bereits Technologien gibt, auf denen wir aufbauen können, um die Funktion im Web einzuführen und gleichzeitig die Privatsphäre der Nutzer zu schützen. So wurde beispielsweise die Geräte- und Bootintegrität hoch bewertet. Viele Plattformen haben APIs, über die eine Bewertung der Geräteintegrität sicher geteilt werden kann. Daher ist dies ein guter Kandidat für explorative Datenanalysen in den Communitygruppen.
Feedback zu „PST Intent to Ship“ Im Rahmen der Absichtserklärung zur Veröffentlichung haben wir Bedenken erhalten, da wir eine ältere Version von Privacy Pass verwenden. Außerdem haben wir Feedback erhalten, dass die Spezifikation in bestimmten Abschnitten unklar war und verbessert werden sollte, um die Browserkompatibilität zu verbessern. Wir planen, viele der vorgeschlagenen Änderungen an den Spezifikationen vor der Veröffentlichung in der GA sowie einige API-Änderungen zu implementieren. Das Feedback kam direkt zum Ende des ersten Quartals. Wir arbeiten daher an den GitHub-Problemen und werden sie mit konkreten Details und einem Update zu unserem Einführungsplan (der zum Zeitpunkt der Veröffentlichung dieses Feedbackberichts in Bearbeitung ist) beheben.

Wir sind offen für größere Änderungen an der API. Wir sind jedoch der Meinung, dass es am besten ist, die allgemeine Verfügbarkeit zu starten und praktisches Feedback von mehr Entwicklern einzuholen. Wir hoffen, diese Diskussion fortsetzen und die Browserstandardisierung vorantreiben zu können. Sollte ein neuer Standard eingeführt werden, werden wir prüfen, ob wir ihn übernehmen und einen Plan für eine sorgfältige Umstellung entwickeln sollten.