Feedbackbericht – 1. Quartal 2023

Vierteljährlicher Bericht für das 1. Quartal 2023 mit einer Zusammenfassung des Feedbacks aus der Community zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google sich bereit erklärt, vierteljährlich 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
Testen und testen	Relevanz der Tests als Grundlage für die Bewertung durch die CMA, wenn die Privacy Sandbox APIs vor Testbeginn noch nicht abgeschlossen sind	Die Entwicklung der Privacy Sandbox APIs schreitet zügig voran. Sie stehen bereits im Ursprungstest zur Verfügung und sind in diesem Sommer für 100% des Traffics allgemein verfügbar. Außerdem haben wir die Fristen für bestimmte Funktionen (z. B. Berichte auf FLEDGE-Ereignisebene und FLEDGE-Rendering mit iFrames) verdeutlicht, die nicht vor 2026 betroffen sein werden. Wir empfehlen, die APIs zu testen und der CMA Feedback dazu zu geben, was die Tester nach der Einstellung von Drittanbieter-Cookies erwarten. Dies kann dazu beitragen, die wahrscheinlichen Auswirkungen der Einstellung von Drittanbieter-Cookies einzuschätzen.
Nutzersteuerung	Klare Leitlinien zu den Auswirkungen der Nutzereinstellungen der Privacy Sandbox APIs	Wir können Ihnen keine Rechtsberatung dazu bieten, welche Einstellungen für Nutzer von Google verwendet werden dürfen. Gleichzeitig testet Chrome im Rahmen unserer fortwährenden Bemühungen, die Privacy Sandbox-Technologien zu verbessern, einem kleinen Prozentsatz der Nutzer aktualisierte Nutzereinstellungen für die Privacy Sandbox („Erweiterter Datenschutz bei Anzeigen“). Die Updates umfassen klarere, hilfreichere Sprache und Layouts. Nachdem Chrome diese Optimierungen ausgewertet und entschieden hat, ob sie auf ein größeres Publikum ausgeweitet werden sollen, kann das Team weitere Informationen mit dem System teilen.
Datenleck	Das Risiko, dass selbst erhobene Daten an Google und andere Parteien durchsickern, wenn der Browser kompromittiert wird	Aus unserer FLEDGE-Erläuterung geht klar hervor, dass die Daten eines einzelnen Anzeigentechnologie-Anbieters nur mit dieser AdTech-Technologie geteilt werden (entweder mit seinen Worklets oder seinen vertrauenswürdigen Servern) oder wenn diese explizit von diesem AdTech-Team freigegeben werden (z. B. zeigt ein Käufer einem Verkäufer die URL der Anzeige, die er anzeigen möchte). Die einzige Ausnahme ist, dass die k-Anonymitätsprüfung von einem globalen, zentralisierten Server durchgeführt werden muss. Dies ist ein Bereich, dem wir weiterhin erhebliche Ressourcen zur Verfügung stellen. Ausführliche Informationen zu unserem Datenschutzbedenken finden Sie in der Erläuterung zur k-Anonymität. Darüber hinaus sind wir offen, weitere Informationen zur Funktionsweise der werbetechnischen Schutzmaßnahmen zu geben, die beim Design des k-Anonymitätsservers angewendet werden.
Zusätzliches Diskussionsforum	Bitte um ein zusätzliches Forum beim W3C für Spieler ohne technisches Ökosystem, um Feedback zu geben.	Das Feedback-Formular für die Privacy Sandbox eignet sich für allgemeine und spezifische Kommentare, sowohl technisch als auch nicht-technisch. Die Improving Web Advertising Business Group ist ein Forum für Diskussionen in wöchentlichen Telefonaten und über ein GitHub-Repository. Auf der Privacy Sandbox-Seite Feedback auf developer.chrome.com werden andere Möglichkeiten erläutert, wie Sie Feedback geben und sich an Diskussionen beteiligen können. Chrome bietet auch weiterhin Veranstaltungen wie öffentliche Sprechstunden an, um Fragen und das Teilen von Inhalten zu erleichtern. Außerdem hat Chrome im letzten Quartal mehr als ein Dutzend Branchenveranstaltungen veranstaltet oder daran teilgenommen.
Erläuterung des Zeitplans	Klarstellung zum genauen Datum für die allgemeine Verfügbarkeit im 3. Quartal 2023	Gemäß dem auf PrivacySandbox.com veröffentlichten Zeitplan ist die allgemeine Verfügbarkeit für den Beginn der Einführung von Chrome-Version 115 geplant.
reCAPTCHA	Auswirkungen von Sandbox APIs auf den Anwendungsfall der Spamerkennung von reCATPCHA	Wir erhalten regelmäßig Feedback von reCAPTCHA, um sicherzustellen, dass die Privacy Sandbox-Angebote keine wesentlichen Auswirkungen auf die Websicherheit oder Betrug haben. Sie entwickeln einen eigenen Plan, um sich auf die Einstellung von Drittanbieter-Cookies vorzubereiten und sie entsprechend anzupassen. Daher sollte diese Frage am besten beantwortet werden.
Chrome-Erweiterungen	Gelten Privacy Sandbox-Technologien wie Anti Covert Tracking (ACT) auch für Chrome-Erweiterungen?	Wir haben keine Ankündigungen dazu gemacht, ob ACT möglicherweise auf Chrome-Erweiterungen angewendet wird. Würde eine Technologie jedoch unheimlich Informationen über einen Nutzer sammeln, entspricht dies nicht unseren Datenschutzprinzipien.

Relevante Inhalte und Werbung zeigen

Themen

Feedback-Design	Zusammenfassung	Chrome-Antwort
Überprüfung des TAG-Designs	Die TAG hat „Early Design Review of Topics“ veröffentlicht.	Wir sind nach wie vor an der Topics API und haben Ihnen auf der Seite mit den neuesten Updates und in diesem Artikel aktuelle Informationen dazu veröffentlicht. Wir haben auf die Überprüfung durch die TAG Punkt für Punkt geantwortet und hier unsere übergeordnete Vision mitgeteilt. Die Topics API wird weiterhin Teil der Sammlung von APIs sein, die 2023 im Werbesystem getestet werden sollte. Wir hoffen, dass das Feedback, das wir erhalten, Tests und die Erfahrung für Implementierungen, bei zukünftigen Bemühungen um browserübergreifende Standards in diesem Bereich einen wertvollen Beitrag leisten werden. Wir freuen uns darauf, auch weiterhin daran zu arbeiten, eine mögliche Umstellung zu erleichtern, wenn die Topics API ein vereinbarter Standard mit browserübergreifender Kompatibilität sein könnte.
Herangehensweise an die Topics API	Unterstützung für den offenen Ansatz von Chrome bei der Entwicklung der Topics API	Wir wissen das zu schätzen und freuen uns auf die weitere Zusammenarbeit mit der Branchengruppe, um eine Topics API zu entwickeln, die einen Mehrwert für das Ökosystem insgesamt bietet.
(Auch bekannt im 3. Quartal 2022) Thementaxonomie nicht detailliert genug	Die Taxonomie der breit gefassten Themen enthält keine detaillierteren Themen, einschließlich regionsspezifischer.	Update zum 1. Quartal: Wir arbeiten kontinuierlich daran, die Taxonomie zu verbessern. Im 2. Quartal werden wir eine aktualisierte Taxonomie für die Topics API bekannt geben. Um diese neue Taxonomie zu erstellen, haben wir eng mit Unternehmen aus der ganzen Welt zusammengearbeitet. Wir suchen aktiv nach Feedback zur Taxonomie, die für die Plattform am hilfreichsten wäre. Bei der Beurteilung, ob Sie die Anzahl der Themen erweitern oder detailliertere Themen einbeziehen sollten, sind einige Aspekte zu berücksichtigen. Dazu gehören 1) mögliche Auswirkungen auf den Datenschutz (mehr Themen können Fingerprinting-Risiko mit sich bringen) und 2) Möglichkeit, zuvor beobachtete Themen abzurufen (z. B. bei mehr Themen ist die Wahrscheinlichkeit geringer, dass ein Anzeigentechnologie-Anbieter das ausgewählte Thema in der Vergangenheit gesehen hat).
(Auch bekannt im 4. Quartal 2022) Auswirkungen auf eigene Signale	Topics-Signale können sehr wertvoll sein und daher andere selbst erhobene interessenbezogene Signale abwerten.	Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist, und Topics wurde dafür entwickelt. Wir verstehen, dass einige große Publisher befürchten, dass sich die Topics API negativ auf ihre Strategien für selbst erhobene Daten auswirkt. Wir freuen uns auf Tests im Ökosystem, die Einblicke in die Auswirkungen von Topics auf Publisher liefern.
Anwendungsfälle für nicht werbebezogene Themen	Verwendung von Topics zu anderen Zwecken als zur Darstellung interessenbezogener Werbung	Topics wurde für den Anwendungsfall interessenbezogener Werbung entwickelt, der unserer Ansicht nach für das kostenlose und offene Web von entscheidender Bedeutung ist. Wir bitten derzeit um Feedback zu anderen Anwendungsfällen und evaluieren diese derzeit.
Standard-Aktivierungsstatus	Auswirkungen der regionalen Gesetzgebung auf die Einwilligungsstandardeinstellung für die Topics API	Es ist nicht unsere Position, rechtliche Meinungen zu äußern.
(Auch im 3. Quartal 2022 gemeldet) Falsch kategorisierte Websites	Anzeigenausrichtung, wenn Themen für eine bestimmte Website falsch kategorisiert werden	Update für das 1. Quartal: Im 2. Quartal werden wir einen aktualisierten Klassifikator für die Topics API bekannt geben und freuen uns darauf, mit der Plattform zusammenzuarbeiten. Aufgrund des aktuellen Feedbacks werden Websites durch eine Kombination aus einer von Menschen zusammengestellten Überschreibungsliste mit den beliebtesten Websites und einem On-Device-ML-Modell klassifiziert. Chrome prüft weiterhin, welche Websites zur Klassifizierung von Themen beitragen können. 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 die eigene Kennzeichnung nutzen, um verschiedene (und potenziell sensible) Bedeutungen in Themen zu codieren; Websites, die ihre Themen aus finanziellen Gründen falsch darstellen; Websites, die Themen angreifen, um ihren Nutzen für andere zu stumpfen (z. B. Spamming der Themen des Nutzers mit bedeutungslosem Rauschen). Diese Komponenten sind über chrome://topics-internals oder dieses Collab für die Öffentlichkeit zugänglich. Im Rahmen der Tests gehen wir davon aus, dass sich die Klassifizierung mit der Zeit verbessern wird. Wir freuen uns über Feedback zu Beispielen für Websites, die möglicherweise falsch kategorisiert wurden.
Themenklassifikator	Anfrage zum Zurückgeben zusätzlicher Informationen mit den Gründen, wenn „No Topics“ zu Debugging-Zwecken an den Aufrufer zurückgegeben wird	Wir wissen, dass Debugging-Tools für Entwickler hilfreich sind, wenn sie die Topics API in ihre Systeme einbinden. Wenn wir jedoch zusätzliche Informationen offenlegen (z. B. den Grund, warum keine Topics zurückgegeben wurden), können ungewollt Informationen weitergegeben werden, die es Parteien ermöglichen, zusätzliche Details herauszufinden (z. B. wenn sich ein Nutzer im Inkognitomodus befindet, die API deaktiviert hat usw.), was den Datenschutz beeinträchtigt. Wir planen derzeit zwar nicht, weitere Fehlerbehebungstools anzubieten, sind aber offen für Feedback, welche Tools hilfreich wären.
Private Information Retrieval (PIR)	Anfrage für die Topics API zur Einführung des Abrufs von privaten Informationen	Wir haben die Verwendung von PIR bereits untersucht und die Vor- und Nachteile hier genannt.
Gebotsstream	Werden die Topics API im Gebotsstream getrennt von den Seller Defined Audiences repräsentiert?	Die Topics API ist ein von Chrome entwickeltes Privacy Sandbox-Angebot und unterscheidet sich vom IAB Tech Lab-Vorschlag Seller-Defined Audiences (Verkäuferdefinierte Zielgruppen) des IAB Tech Lab. Wir erwarten, dass beide innerhalb des Bidstream unterschiedlich repräsentiert werden. Weitere Informationen zur Repräsentation von Topics in OpenRTB-Gebotsanfragen

Protected Audience API (früher FLEDGE)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Verfügbarkeit von FLEDGE-Funktionen	Erläuterungen zum Zeitplan für das Testen und die Implementierung von FLEDGE-Funktionen wie Fenced Frame Erzwingung, K-Anonymität usw.	Wir haben einen Blogpost über verschiedene FLEDGE-Funktionen mit einem Umfang veröffentlicht und erfahren, wann diese unterstützt werden. Im Zuge der Weiterentwicklung von FLEDGE freuen wir uns über zusätzliches Feedback.
Einschränkungen beim Produktrendering	Anfrage zur Aufhebung der Einschränkungen für Anzeigen mit mehreren Teilen für FLEDGE Fenced Frames	Wie im Februar angekündigt, bleibt die Verwendung von Fenced Frames bis mindestens 2026 optional und das Verhalten von iFrames wird von urn-iFrames unterstützt. Wir würden uns freuen, wenn Sie mehr darüber diskutieren möchten.
Probleme mit der Skalierbarkeit	FLEDGE-Leistung bei steigender Nutzung	Wir nehmen das Feedback ernst und verstehen mehr Kontext, um umsetzbare Lösungen vorzuschlagen. Der erste Schritt bestand darin, das Feedback in zwei Kategorien zu unterteilen: SSP-gesteuerte Filterung zur Optimierung der Abfragen pro Sekunde (Queries per Second, QPS) auf a) sich selbst und b) auf den DSPs. DailyUpdate-Logik der Interessengruppe zur Optimierung der QPS-Last auf DSPs.
(Auch bekannt im 3. Quartal 2022) Sichtbarkeit der Gebotslogik	Bedenken, dass die DSP-Gebotslogik in JavaScript offengelegt wird	Update zum 1. Quartal: Wir haben einen Vorschlag veröffentlicht, der die Möglichkeit von Angreifern, Daten explorativ (durch erzwungenes Browsen) vom Server anzufordern, und wir freuen uns, dass Spieler im System Feedback geben oder den Vorschlag unterstützen.
Probleme beim Testen	Möglichkeit für kleinere DSPs, FLEDGE richtig zu testen und das Risiko zu minimieren, dass Werbetreibende nur an Tests mit größeren DSPs interessiert sind	Wir arbeiten mit kleineren DSPs zusammen und empfehlen dringend, erweiterte Tests unter DSPs und Werbetreibenden jeder Größe durchzuführen, da FLEDGE allgemein verfügbar ist. Wir würden gerne erfahren, wie wir sie am besten beim Testen von FLEDGE mit anderen im System unterstützen können. Außerdem freuen wir uns über Ideen und Branchenbemühungen, Werbetreibende zu Tests mit kleineren DSPs zu motivieren.
Dynamisches Remarketing	Ist dynamisches Remarketing mit FLEDGE auch nach der Einstellung von Drittanbieter-Cookies möglich?	Wir überlegen, diese Frage zu beantworten, und begrüßen es, wenn die Spieler im System weitere Informationen dazu mit uns teilen, 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 gewünschte Zielgruppe positionieren?	Wir freuen uns darauf, mit den Akteuren des Ökosystems weiter über Betrug und Missbrauch zu sprechen, und freuen uns über weiteres Feedback in diesem Bereich.
Nutzereinstellungen	Prozess zum Speichern der Nutzereinstellungen und Verwendung bei der Anzeigenauswahl	Bei bestimmten Anzeigen ist die entsprechende Anzeigentechnologie am besten geeignet, um steuern zu können, welche Creatives ausgeliefert oder wie sie ausgewählt werden.
Vorschlag für quantitative Tests	Sollte der Test für faire Quantitative Tests mit Traffic ohne Drittanbieter-Cookies oder mit SSPs durchgeführt werden, die nur FLEDGE verwenden? Wie kann die Vermischung von Signalen aus Drittanbieter-Cookies vermieden werden?	Wir wissen dieses Feedback zu schätzen und arbeiten gemeinsam mit der CMA an Tests, die ein zuverlässiges Bild der Auswirkungen der Einstellung von Drittanbieter-Cookies und der Einführung von Privacy Sandbox-Vorschlägen auf der Plattform liefern. Wir empfehlen dir, der CMA zusätzliches Feedback zum Vorschlag der CMA zu den Quantitativen zu geben.
Klarere Dokumentation	Umfassendere Dokumentation zur Auktionskonfiguration anfordern	In den kommenden Wochen möchten wir Ihnen einen Blogpost mit zusätzlichen Informationen zu FLEDGE-Auktionsberichten zur Verfügung stellen.
Parallelisierung	Wird die Parallelisierung vom Dienst für Gebote und Auktionen unterstützt?	Ein AdTech-Anbieter, der Gebots- oder Auktionsserver verwendet, kann mehrere Server starten, die Ergebnisse parallel ausliefern können.
Missbrauchsbekämpfung	Reicht der k-Anonymitätsserver von FLEDGE mit Private State Tokens aus, um den Datenschutz für Nutzer zu gewährleisten?	Die Motivation für k-Anonymität liegt weniger auf Microtargeting, sondern eher auf einem Backstop in der Zwischenphase, in der FLEDGE Berichte auf Ereignisebene ermöglicht. Wir haben weitere Anmerkungen dazu und freuen uns auf zusätzliches Feedback.
Konflikt im ES-Modul	Anfrage zum Löschen von generateBid als globale Funktion, da sie mit dem ES-Modul in Konflikt steht	Wir besprechen diese Anfrage und freuen uns über zusätzliches Feedback.
Komponentenauktion	Anforderung von Publishern, mehr Kontrolle über das Auktionsdesign zu haben	Gebots- und Auktionsplan zur Unterstützung von Komponentenauktionen, genau wie bei Chrome auf dem Gerät.
B&A-Zeitpläne	Klarheit über den Zeitplan für Anzeigentechnologie-Anbieter, die B&A-Server testen möchten	Wir haben gerade die B&A-Erklärung aktualisiert und den Abschnitt „Zeitachse“ aktualisiert, um nach Absprache mit der CMA klare Definitionen von Zeitplänen für verschiedene Phasen von Chrome-B&A-Tests zu enthalten.
Schema für Zeitüberschreitung	Verbesserung des derzeit für FLEDGE verfügbaren Zeitüberschreitungskontrollschemas	Das ist ein interessanter Vorschlag. Wir fügen diese in die Warteschlange der zu untersuchenden Vorschläge auf und berichten über unsere Entwicklungen.
Creative-Gebotsstreams	Überprüfung und Filterung eines erfolgreichen Gebots auf Basis des Creatives	Das ist ein interessanter Vorschlag. Wir fügen diese in die Warteschlange der zu untersuchenden Vorschläge auf und berichten über unsere Entwicklungen.
reportWin	Vorschlag zur Bereitstellung zusätzlicher Informationen zum Gebot mit der höchsten Punktzahl von einem anderen Inhaber der Interessengruppe als dem Gewinner in der Funktion reportWin	Das ist ein interessanter Vorschlag. Wir werden in Betracht ziehen, in aggregierten Berichten weitere Signale hinzuzufügen. Hier können Sie uns zusätzliches Feedback geben.
Ereignistypen	Standardisierung von Ereignistypen über Measurement APIs bei Einbindung in FLEDGE	Das ist ein interessanter Vorschlag. Wir fügen diese in die Warteschlange der zu untersuchenden Vorschläge auf und berichten über unsere Entwicklungen. Es muss mit unseren umfassenderen Bemühungen in diesem Bereich koordiniert werden, da es andere Privacy Sandbox APIs über FLEDGE hinaus betreffen würde. An dieser Stelle freuen wir uns über zusätzliches Feedback.
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 bereits im Blogpost vom Februar angekündigt, werden Auktionsgewinne auf Ereignisebene bis „mindestens 2026“ unterstützt. Wir können Ihnen derzeit keine weiteren Details mitteilen. Wir freuen uns aber über Feedback dazu, warum es wichtig ist, bestimmte Daten auch nach der Einstellung von Drittanbieter-Cookies verfügbar zu halten.
Begrenzung für Interessengruppen	Wie groß ist die Anzahl der Interessengruppen, denen ein Ursprung einen einzelnen Browser hinzufügen kann?	In Chrome sind bis zu 1.000 Interessengruppen pro Inhaber und bis zu 1.000 Interessengruppeninhaber zulässig. Diese sind als Leitlinien gedacht und sollen im normalen Betrieb nicht erreicht werden.
Signale auf Ereignisebene	Unterstützung für einen Vorschlag mit Signalen auf Ereignisebene für generateBid und reportWin, die für das Training von maschinellem Lernen verwendet werden können	Wir haben unsere Entscheidung zu browserbezogenen und anzeigentechnologiespezifischen Signalen hier bekannt gegeben und würden uns über zusätzliches Feedback freuen.
Gebotsskript	Nehmen Sie die User-ID in die URL zum Gebotsskript auf.	Dies ist nicht möglich, da für FLEDGE die zusätzliche Anforderung gilt, dass das Tupel des Interessengruppeninhabers, die Gebotsskript-URL und das gerenderte Creative k-anonym sein müssen, damit eine Anzeige ausgeliefert wird.
K-anon-Maßnahmen	Wird k-Anonymität für das Paar (componentAd, size) erzwungen?	Ja. Weitere Informationen finden Sie unter turtledove/issues/312.
Anforderungen für Gebots- und Auktionsdienste	Wie unterstützen B&A-Dienste Teilnehmer bei der Einbindung von FLEDGE auf dem Gerät und andere in B&A-Dienste?	Das Design ist noch nicht fertig und wir würden uns über hier zusätzliches Feedback freuen.
Post-View-Attribution	Wird die Post-View-Attribution unterstützt?	Derzeit gibt es keine Standarddefinition von Sichtbarkeit. Wir verlassen uns beim Markieren eines Aufrufereignisses auf das Creative selbst. Weitere Informationen finden Sie unter turtledove/issues/452.
Ähnliches Targeting	Kann die Privacy Sandbox ein ähnliches Targeting unterstützen?	Wir besprechen hier den Anwendungsfall und würden uns über zusätzliche Informationen freuen.
Echtzeit-Monitoring API	Vorschlag für einen FLEDGE-Monitoringansatz in Echtzeit	Wir besprechen diesen Vorschlag und wir freuen uns auf zusätzliche Informationen.
FLEDGE-Berichte	reportWin und reportResult sollten in zufälliger Reihenfolge angegeben werden, um eine übermäßige oder unzureichende Berichterstellung zu vermeiden.	reportResult() muss vom Verkäufer vor reportWin() ausgeführt werden, damit Verkäufersignale aus reportResult() in reportWin() aufgenommen werden können. Weitere Informationen finden Sie in der Erläuterung.
Server mit benutzerdefinierten Schlüsselwerten (K/V)	Werden benutzerdefinierte K/V-Server in Zukunft unterstützt?	Wir diskutieren diese Frage hier und freuen uns über jeden weiteren Beitrag.
Auktion auf oberster Ebene	Muss man der Ad-Server sein, um Auktionsmechanismen auf oberster Ebene ausführen zu können?	Die FLEDGE API gibt nicht an, welche Partei sie aufrufen muss. Es gibt keine entsprechenden Anforderungen beim FLEDGE-Design. Jeder kann die FLEDGE-Auktion ausführen (einschließlich Auktionen mit mehreren Verkäufern). Wie im Bericht „Q4 2022“ erwähnt, kann jeder Publisher mit FLEDGE die Struktur der Auktion auswählen, einschließlich der Auswahl von Top-Level- und Komponentenverkäufern.
API-Bereich	Soll FLEDGE mit selbst erhobenen Daten verwendet werden?	Im 2. Quartal 2023 werden wir Inhalte veröffentlichen, in denen erläutert wird, dass selbst erhobene Daten mit FLEDGE tatsächlich 1) als Logik zur Bestimmung der Zugehörigkeit zu Interessengruppen verwendet werden können und 2) sie als Signale für Nutzergebote zur Verwendung in der nachfolgenden Generierung der Gebotslogik verwendet werden können.
Domainübergreifende Interessengruppen	Möglichkeit, domainübergreifende Interessengruppen zu erstellen	Diese Zielgruppe kann mit allen Informationen, die zum Zeitpunkt des Hinzufügens eines Browsers zu einer Interessengruppe verfügbar sind, verwendet werden. Wenn Drittanbieter-Cookies nicht mehr verwendet werden, ist die Verfügbarkeit websiteübergreifender Daten zum Erstellen von Interessengruppen eingeschränkt.
Clientseitige Gebotslogik	Vorhandene serverseitige Gebotslogik auf Clientseite übertragen	Wir möchten mehr darüber erfahren, in welchen Bereichen der Portierungsprozess eine Herausforderung darstellt oder derzeit nicht möglich ist. Wir freuen uns über zusätzliches Feedback oder weitere Informationen.
k/v-Serverwerte	Müssen K/V-Serverwerte vom Typ String sein?	Der Wert muss ein String sein, kann aber Objekte in JSON oder Protokollpuffer speichern und als String serialisieren.
Sperrliste für Werbetreibende	Welche Signale sind angemessen, um einen Käufer für eine Sperrliste für Werbetreibende bereitzustellen?	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 über zusätzliches Feedback freuen.
Auktionslogik	Wird der Gewinner einer Auktion vom Browser oder Ad-Server ermittelt?	Die Auswahl der Gewinner wird in der Sandbox ausgeführt und alle Entscheidungen werden durch den Code des Verkäufers getroffen. Der Browser bietet einfach eine versiegelte, private Umgebung, in der Käufer- und Verkäufercode ausgeführt wird.
Berechtigungsrichtlinie	Wird die aktuelle FLEDGE-Berechtigungsrichtlinie nach Ende des Ursprungstests weiterhin erzwungen?	Für den Ursprungstest sind die aktuellen Standard-Zulassungslisten beider Funktionen temporär und werden geändert. Wir würden gern erfahren, wie lange sich Anzeigentechnologie-Anbieter auf die Änderung vorbereiten müssen, bevor wir sie durchsetzen.
Einschränkung der Signalgröße	Anfragen für vertrauenswürdige Gebotssignale werden über mehrere Interessengruppen mit derselben trustedBiddingSignalsUrl zusammengeführt. Das Größenlimit von 2 MB ist eine Einschränkung.	Die Einschränkung gilt für Aufrufer auf dem Gerät, um zu verhindern, dass die Ressourcen auf dem Gerät überlastet werden. Für Aufrufer von einem B&A-Server gilt eine gelockertere Einschränkung.
Signale für die Berichterstellung	Fügen Sie ein zusätzliches Signal (Skriptfehler) hinzu, damit die Anzahl der clientseitigen Fehler pro Interessengruppeninhaber und pro computeBid oder reportWin / reportResult abgerufen werden kann.	Wir ziehen potenzielle Bedenken im Hinblick auf den Datenschutz in Betracht und begrüßen die Akteure des Ökosystems, um weitere Informationen darüber zu teilen, warum dies erforderlich ist.
K-Anon-Fenstergröße	Erhöhen Sie die K-Anon-Fenstergröße über das aktuelle Limit von 7 Tagen.	Dies wird derzeit geprüft und wir erwarten (und freuen uns) derzeit auf zusätzlichen Input aus der Umgebung.
Geräteleistung	Wie handhabt FLEDGE die Geräteleistung, wenn der Nutzer einer großen Anzahl von Interessengruppen angehört?	FLEDGE bietet mehrere Optionen für Zeitüberschreitung, Priorisierung und Limits über SSPs und DSPs hinweg, mit denen Anzeigentechnologie-Anbieter in Situationen, in denen die Geräteleistung möglicherweise die Teilnahme an Auktionen einschränken könnte, wenn das Gerät einer großen Anzahl von Interessengruppen zugeordnet ist, genau steuern können.
B&A-Services testen	Spieler der Umgebung bitten, während der Testphase ihren eigenen Server zu verwenden, damit mehr Logs für die Fehlerbehebung zur Verfügung stehen	Mit B&A können Nutzer die Server von genehmigten Cloud-Anbietern starten und skalieren. Aus Datenschutzgründen setzen wir voraus, dass die Ausführung in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) erfolgt. Wir werden demnächst eine Erläuterung zur Fehlerbehebung bei B&A TEE veröffentlichen und entsprechende Funktionen entwickeln. Wir benötigen zusätzliches Feedback zu diesem Thema.
Regulatorische Anforderungen	Arbeitet FLEDGE mit Cloud-Anbietern in verschiedenen Ländern zusammen, um lokale Vorschriften einzuhalten?	Wir sind immer offen für Vorschläge für andere Cloud-Anbieter, planen jedoch mindestens eine Unterstützung von GCP und AWS, wenn die Einstellung von Drittanbieter-Cookies erzwungen wird. Weitere Informationen finden Sie in dieser Erläuterung.

Digitale Anzeigen analysieren

Attribution Reporting (und andere APIs)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Analyse der Lärmbelastung	Anleitung zur Durchführung einer Datenanalyse auf die Auswirkungen von Lärm	Wir haben zusätzliche Dokumentation zu Störfaktoren und Designentscheidungen zur Verfügung gestellt, mit denen sich die Auswirkungen von Störfaktoren auf Daten in der Anzeigentechnologie ändern lassen. Eine ausführlichere Anleitung ist ebenfalls verfügbar.
Null-Berichte	Klarheit bei der Implementierung von Null-Berichten	Wir arbeiten derzeit an einem Vorschlag zur Implementierung von Null-Berichten und werden bald weitere Details bekannt geben. Durch die Implementierung von Null-Berichten können wir Verzögerungen bei Berichten reduzieren, ohne den Datenschutz zu gefährden.
Geräuschpegel	Geräuschpegel basierend auf der Länge des Attributionsfensters anpassen	Wir begrüßen diesen Vorschlag und werden ihn in die Spezifikation aufnehmen. Hier kannst du uns zusätzliches Feedback geben.
Datengröße für Trigger	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-/kontextübergreifenden Informationen zu einem Nutzer begrenzt ist. Wir freuen uns über Feedback dazu, ob die aktuelle Parametrisierung für Berichte auf Ereignisebene sinnvoll ist.
Trigger für Berichte auf Ereignisebene	Priorisierung innerhalb eines Deduplizierungsschlüssels zulassen	Wir arbeiten derzeit an Lösungen für dieses Problem und freuen uns auf zusätzliche Anregungen.
Unterstützung bei der Fehlerbehebung	Klarheit bei der Fehlerbehebung nach der Einstellung von Drittanbieter-Cookies	Wir möchten die Fehlerbehebung nach der Einstellung von Drittanbieter-Cookies unterstützen und arbeiten dabei an Optionen. Wir freuen uns über zusätzliches Feedback und Ideen.
Alternativen für Klick-Conversions	Weitere Informationen zu Alternativen für Klick-Conversions anfordern	Wir empfehlen, die Attribution Reporting API als langlebiges privates Messsystem für geeignete Anwendungsfälle zur Conversion-Analyse zu verwenden. Es gibt auch andere Alternativen und Anbieter von Anzeigentechnologien müssen sich bei der Entscheidung für eine Lösung auf der Grundlage ihrer Anforderungen an Datenschutz und Dienstprogramm entscheiden.
Anwendungsfälle für die Abrechnung	Klarheit darüber, inwiefern Attributionsberichte Conversion-basierte Abrechnungen unterstützen	Wir arbeiten derzeit an öffentlichen Stellen, um den Abrechnungsbereich der Attribution Reporting API zu verdeutlichen. Die Attribution Reporting API war ursprünglich nicht so definiert, dass die CPA-Abrechnung direkt unterstützt wird. Unterstützt werden CPC- und CPM-Abrechnungen, also die Abrechnungsstruktur, die von den meisten Anzeigentechnologie-Anbietern verwendet wird. Dies können wir in Zukunft unterstützen, wenn wir zusätzliches Feedback aus der Umgebung erhalten.
Support für Anwendungsfälle	Dokumentation zum Anwendungsfall für die Measurement API	Wir arbeiten daran, die Dokumentation für alle Meldeoberflächen der Privacy Sandbox zu präzisieren.
Klickqualität	Signal hinzufügen, um zwischen absichtlichen und unbeabsichtigten Klicks auf eine Anzeige zu unterscheiden	Wir besprechen die Anfrage gerade und freuen uns über weitere Anregungen.
Analysetool	Unterstützung von Analysetools für mehrere DSPs	Die Attribution Reporting API kann von Anbietern von Messungen zur Deduplizierung zwischen mehreren DSPs verwendet werden. Außerdem vorschlagen wir die Unterstützung einer Liste von URLs in attributionsrc, wodurch DSPs die Attribution Reporting API-Anfragen des Anbieters von Analysen einfacher unterstützen können. Wir freuen uns über zusätzliches Feedback zum obigen Vorschlag.
Berichte auf Ereignisebene	Sie können die Anzahl der Tage vor dem Senden des Berichts anfordern.	Diese Anfrage kann bereits von Anzeigentechnologie-Anbietern anhand der derzeit verfügbaren Informationen berechnet werden. Wir haben kein anderes Feedback zu dieser Anfrage erhalten, sind aber offen für Feedback.
source_registration_time	Fügen Sie source_registration_time in Attributionsberichte auf Ereignisebene hinzu.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback dazu, ob die Spieler die Funktion als nützlich empfinden.
Inkognitomodus	Sind Analysetools verfügbar, wenn der Nutzer den Inkognitomodus verwendet?	Nein. Analysetools sind nicht verfügbar, wenn sich ein Nutzer im Inkognitomodus befindet. Drittanbieter-Cookies sind im Inkognitomodus standardmäßig deaktiviert.
Data-Clean-Rooms	Sind Measurement APIs mit Data-Clean-Rooms kompatibel?	Ein typischer Daten-Clean-Room ist eine Umgebung, in der einzelne ID-Daten aus verschiedenen Quellen in eine Datenbank hochgeladen werden, um Analysen basierend auf der Zusammenführung der zugrunde liegenden Daten durchzuführen. Die beiden Mess-Frameworks für Privacy Sandbox APIs sind Berichte auf Ereignisebene und zusammenfassende Berichte. Berichte auf Ereignisebene enthalten zwar eine von AdTech bereitgestellte Ereignis-ID, die in einem Daten-Cleanroom verwendet werden könnte. Die damit verbundenen Informationen auf Conversion-Seite sind jedoch begrenzt und ungenau. Verschlüsselte aggregierte Berichte können nicht direkt in einem Data-Clean-Room verwendet werden. Die vom Aggregationsdienst bereitgestellten zusammenfassenden Ergebnisse können jedoch als Eingabe für von Ihnen durchgeführte Analysen oder als ergänzende Informationen verwendet werden.

Aggregationsdienst

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 4. Quartal 2022 gemeldet) Verzögerungen bei der Berichterstellung	Wie hoch ist die erwartete Verzögerung bei der Berichterstellung?	Update für das 1. Quartal 2023: Nach dem Feedback unserer Partner haben wir Vorschläge zur Reduzierung der Verzögerung und zur Reduzierung der Auswirkungen von Verzögerungen gemacht. Beide Vorschläge wurden im Rahmen von WICG-Gesprächen von Anzeigentechnologie-Anbietern unterstützt.
Keine duplizierte Regel	Wie gehen Sie mit einem verzögerten aggregierten Bericht um, wenn aggregierte Berichte, die dieselbe gemeinsame ID haben, bereits verarbeitet wurden?	Wir haben einen Vorschlag veröffentlicht, wie eine zusätzliche Berichtsverzögerung zu den Informationen in aggregierten Berichten und die Definition einer gemeinsamen ID für den Aggregationsdienst hinzugefügt werden können, um die Auswirkungen des Verzögerungsverlusts auf die Aggregate API teilweise zu beheben. Wir freuen uns über jedes Feedback zum Vorschlag.
Datenverarbeitung	Anfrage zur Aktivierung der Unterstützung für mehrere Datenübertragungen unter Verwendung von Privacy Budget unter Berücksichtigung des Differential Privacy	Wir besprechen die Möglichkeit einer flexibleren Nutzung des Privacy Budget-Budgets, um diesen Anwendungsfall zu ermöglichen, und würden uns über zusätzliches Feedback freuen.
(Auch im 2. Quartal 2022 berichtet) Ergonomie der Abfrage	Abfrage-Aggregatfunktion von Schlüsseln aktivieren.	Update vom 1. Quartal 2023: Die Funktionsanfrage wird noch bearbeitet, aber derzeit haben wir keine Vorschläge.
Einschränkungen des Ursprungstests	Es wurde der Umfang des Aggregationsdiensts erläutert, z. B. die Regel „no Duplicates“ (Regel ohne Duplikate), die derzeit im Ursprungstest nicht angewendet wird.	Wir aktualisieren unsere Dokumentation, um klarzustellen, was im Ursprungstest und in GA verfügbar sein wird.

Private Aggregation API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Budget für private Zusammenfassungsbeiträge	Das L1-Beitragsbudget ist zu restriktiv.	Jeder Aufruf der Private Aggregation API wird als Beitrag bezeichnet. Aus Datenschutzgründen ist die Anzahl der Beiträge, die von einer Einzelperson erhoben werden können, begrenzt. Wenn Sie alle aggregierbaren Werte aller Aggregationsschlüssel addieren, muss die Summe kleiner als das Beitragsbudget sein. Mit dem aktuellen Design haben wir ein rollierendes Zeitfenster für die Beiträge für einen bestimmten Berichtsursprung in den letzten 24 Stunden festgelegt. Dies ist das im Feedback erwähnte Beitragsbudget für Stufe 1. Wir empfehlen Entwicklern, die beigesteuerten Werte auf Basis des erwarteten Volumens zu skalieren (also nicht nur mit einem Wert von 1). Daher kann es sinnvoll sein, für die häufigsten Ereignisse einen kleineren Wert zu verwenden, damit das Budget nicht aufgebraucht wird. Wir benötigen derzeit Feedback zum Beitragsbudget der Private Aggregation API, das sowohl die numerische Grenze als auch den Umfang betrifft. Wir erwägen, den Bereich von pro-Ursprung zu pro Website zu verschieben und die vorhandene Bindung in ein zehnminütiges Fenster mit einer größeren Tagesgrenze zu verschieben.

Verdecktes Tracking begrenzen

Reduzierung des User-Agents/User-Agent-Client-Hints

Feedback-Design	Zusammenfassung	Chrome-Antwort
UA-R-Akzeptanz	Von den Top 10.000 Websites im Vereinigten Königreich sendet nur 1% der Websites,für die Programmatic Advertising genutzt wird, HTTP-Client-Hinweise. DSPs, die nicht migriert wurden, können sich auf die Funktionen zur Betrugsbekämpfung auswirken.	Eine Analyse desselben Datensatzes hat ergeben, dass die Anzahl der Websites, die UA-CH nutzen, deutlich höher ist, wenn Sie die UA-CH-Nutzung über das HTML-<meta>-Tag und die JavaScript-APIs berücksichtigen. Auf der Grundlage dieser und anderer Fakten, einschließlich des Feedbacks aus der Umgebung, sind wir zuversichtlich, dass wir mit der schrittweisen Einführung der Phase 6 der UA-Reduktion gemäß dem veröffentlichten Zeitplan fortfahren und die CMA auf dem Laufenden halten. Uns ist aufgefallen, dass es fast zwei Jahre Vorlaufzeit zur Vorbereitung auf die Umstellung gab. Für Websites, die ihrer Meinung nach noch nicht bereit sind, ist noch ein Test zur Einstellung verfügbar.
Hinweise für zusätzliche Formfaktoren	Anfrage für UA-CH zur Bereitstellung zusätzlicher Formfaktoren wie TV, VR	Wir begrüßen diesen Vorschlag und arbeiten daran, ihn in das Design einzubringen. Wir freuen uns über zusätzliches Feedback.
Automatisierte Tests	Anfrage zur Behebung des UA-CH-Fehlers in der monitorlosen Chrome-Version vor dem Versand von UAR-Phase 6	Der betreffende Fehler wurde behoben.
UA-CH-Unterstützung unter iOS	Eine Website, die detaillierte UA-Informationen für Anzeigen nutzt, weist darauf hin, dass Chrome unter iOS nicht unterstützt wird.	Für iOS-Browser ohne Safari (einschließlich Chrome unter iOS) muss das WebKit-Projekt UA-CH unterstützen, bevor sie aktiviert werden können, da sie den Netzwerkstack steuern.

IP Protection (früher Gnatcatcher)

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 4. Quartal gemeldet) Anwendungsfälle zur Standortbestimmung	Der IP-Schutz kann dazu führen, dass in Zukunft legitime Anwendungsfälle wie die Personalisierung von Inhalten aufgrund der Standortbestimmung nicht mehr funktionieren.	Unsere Antwort entspricht dem Stand vom 4. Quartal 2022: „Wir arbeiten mit Stakeholdern zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Wir würden uns über Feedback der Plattform zum Detaillierungsgrad der IP-Standortbestimmung freuen.“
Gesetzliche Vorschriften	Wenn eine Region weniger als eine Million Einwohner hat, würde der aktuelle Grenzwert von 1 Million für den IP-Schutz verhindern, dass Websites IP-Adressen zur Einhaltung gesetzlicher Vorschriften verwenden.	Wir arbeiten mit allen Beteiligten zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle für IP-Adressen unterstützt. Wir bitten um Feedback zur Einhaltung der gesetzlichen Vorschriften zum IP-Schutz.
Missbrauchsbekämpfung	Parteien können den IP-Schutz umgehen, indem sie nicht maskierte IP-Adressen an andere weitergeben.	Wir sind uns des Risikos bewusst, dass der aktuelle Entwurf zum Schutz von IP-Adressen Parteien technisch nicht davon abhält, nicht maskierte IP-Adressen an andere weiterzugeben. Wir arbeiten an Risikominderungen, um dieses Missbrauchsrisiko zu vermeiden. Während der Überarbeitung des Vorschlags freuen wir uns über mehr Feedback und Diskussionen. Insbesondere geht es um Anwendungsfälle, bei denen Parteien der Ansicht sind, dass sie nicht maskierte IP-Adressen an andere Parteien weitergeben müssen.
Blockierung des Netzwerks	Parteien können die Netzwerkblockierung mithilfe von IP-Schutz-Proxys umgehen.	Die Entität, die den Block blockiert, muss den IP-Schutz für dieses Szenario deaktivieren. Wir haben auf das Problem reagiert und würden uns über zusätzliches Feedback freuen.
Sperrlisten von IP-Adressen, die vom Vorschlag zum IP-Schutz betroffen sind	Viele AdTech-Unternehmen verwenden eine einfache Sperrliste von IP-Adressen (z. B. die IP-Liste des TAG-Rechenzentrums), um Gebote für Anzeigeninventar zu verhindern, das mit hoher Wahrscheinlichkeit betrügerisch (oder zumindest nicht monetarisierbar) ist. Falls eine Anzeigentechnologie ebenfalls ein Tracker ist und dem Vorschlag zum Schutz von IP-Adressen unterliegen könnte, verliert dieses Unternehmen möglicherweise die Möglichkeit, vor dem Kauf von Anzeigeninventar eine grundlegende Überprüfung von Anzeigen durchzuführen.	Wir freuen uns auf mehr Feedback und Diskussionen zum IP-Schutzvorschlag zu potenziellen Problemen und Lösungen. Eine Möglichkeit besteht darin, ähnliche Listen auf den IP-Schutz anzuwenden, damit Clients, die von zuvor markierten IP-Adressen stammen, nicht über einen Proxy weitergeleitet werden.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch in Q4 gemeldet) Domainlimit	Anfrage zur Erweiterung der Anzahl verknüpfter Domains	Unsere Antwort bleibt im Vergleich zum 4. Quartal 2022 unverändert: „Wir haben in den WICG-Anrufen deutlich gemacht, dass Chrome bestrebt ist, eine brauchbare Lösung bereitzustellen, bei der auch die Datenschutzinteressen der Nutzer berücksichtigt werden. In diesem Zusammenhang würden wir uns über Feedback von der Community zu bestimmten Anwendungsfällen freuen, die vom Domainlimit betroffen sein könnten, damit das Team überlegen kann, wie diese Anwendungsfälle angegangen werden können, während gleichzeitig die Privatsphäre der Nutzer geschützt bleibt.“
Alternative fps-Einreichung	Vorschlag für eine alternative Möglichkeit, globale Listen für FPS einzureichen	Derzeit bereiten wir die Auslieferung von First-Party-Sets (FPS) in Chrome vor und haben ein zentrales GitHub-Repository eingerichtet, um Set-Einreichungen zu akzeptieren. Da wir hoffen, dass FPS die Lücke mit bestehenden Webplattformlösungen in Vorbereitung auf die Einstellung von Drittanbieter-Cookies schließen wird, erwarten wir, von ihnen zu lernen, wie die Website-Autoren die FPS nutzen. Da die Liste der Sets mit der Zeit wächst und sich das System an die Welt der Post-Drittanbieter-Cookies anpasst, können wir den Prozess so weit entwickeln, dass wir alternative dezentralisierte Systeme wie das vorgeschlagene in Betracht ziehen können. Bei dem aktuellen Prozess erwarten wir, festgelegte Lebensdauern einzuführen, mit denen wir den Aufnahmeprozess im Laufe der Zeit weiterentwickeln können. Wir können diese Idee noch einmal aufgreifen, sobald der Einreichungsprozess ausgereift ist.
Repository-Moderation	Führen Sie eine Moderation des Repositorys der FPS-Einreichung durch die Community durch, um Missbrauch zu verhindern. Böswillige Akteure können den Prozess mit Brenner-Ursprüngen zum Vorschlagen von Sets leicht überfordern. Eine überwältigende Menge an Anfragen kann die Vorgänge für echte Satzvorschläge beeinträchtigen.	Wir versuchen, die Prüfungen mit technischen Validierungsprüfungen so objektiv wie möglich zu gestalten. Wir denken, dass dies der skalierbarste Ansatz für den Einreichungsprozess ist. Aus diesem Grund werden wir auch dafür sorgen, dass der Prozess vor Spam- bzw. Burner-Übermittlungen geschützt ist.
Zugeordnete Teilmengen	Ist FPS in der Lage, Anwendungsfälle von Drittanbietern/SaaS-Abläufen über verknüpfte Teilmengen zu unterstützen?	Die Drittanbieter-/SaaS-Abläufe sind kein Anwendungsfall, der derzeit im Bereich von Erstanbieter-Sets berücksichtigt wird. Wir freuen uns über zusätzliches Feedback dazu, wie websiteübergreifende Cookies für diese Anwendungsfälle verwendet werden.
FPS- und CHIPS-Integration	Anfrage zur Einbindung von FPS und CHIPS, um Anwendungsfälle wie A/B-Tests zu unterstützen	Wir besprechen diesen Anwendungsfall und erwägen, dies auch in einem WICG-Gespräch näher zu besprechen. Hier können Sie weitere Informationen einholen.
DSGVO	Vorschlag für eine neue Teilmenge der FPS, die nach DSGVO-Konzepten modelliert werden soll	Wir haben diesen Vorschlag intern besprochen und gegen anderes Feedback sowie unsere Datenschutzziele abgewogen. In dieser Antwort erläutern wir, warum wir diesen Vorschlag derzeit nicht verfolgen.
Arbeitsspeicher	Erwartete Änderung der Größe des Browserspeichers bei Einbindung der FPS-Liste	Es gibt Fälle, in denen Browser diese Arten von Listen mit minimaler Auswirkung auf den Arbeitsspeicher speichern, z. B. die Schutzliste für das Tracking beim Trennen der Verbindung. Die Liste der First-Party-Sets wird zwar lokal in jeden Chrome-Client kopiert, wir werden jedoch die Dateigröße weiterhin überwachen und sind zuversichtlich, dass wir den Speicherbedarf optimieren können.

Fenced Frames-API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Einschränkungen für Fenced Frames	Klarheit hinsichtlich der durch Fenced Frames auferlegten Einschränkungen	Im März haben wir unsere Erläuterung zu Fenced Frames aktualisiert, die Informationen zu den Funktionen enthält. Wir freuen uns über jegliches zusätzliches Feedback.
Zugriffsinformationen maximieren	Anfrage zum Ausweiten des Zugriffs auf Informationen um benachbarte Frames	Wir möchten genauer verstehen, warum dies eine Anforderung seitens der Plattform ist, und freuen uns über jedes zusätzliches Feedback.
Fenced Frames und iFrames	Fragen zur Funktionsgleichheit zwischen Fenced Frames und iFrames	Alle verfügbaren Privacy Sandbox APIs und Berichte sind für iFrames und FencedFrames auf die gleiche Weise verfügbar.
Größe von Umzäunten Frames ändern	Das Einschränken von Frame-Größenänderungen wirkt sich auf bestimmte Anwendungsfälle aus.	Wir würden gern mehr über die Arten von Anwendungsfällen erfahren, die von der Einschränkung betroffen sind, und würden uns über zusätzliches Feedback freuen.

Shared Storage API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Drittanbieter-Worklets	Können Drittanbieter in freigegebenen Speicher, nach Ursprung partitioniert, schreiben? Oder rufen Sie andere Worklets für die Messung durch Drittanbieter auf?	Der Ursprung des Browserkontexts, von dem aus der Code ausgeführt wird, bestimmt, in welchen freigegebenen Speicher die Daten geschrieben werden. Wenn Drittanbietercode in eine Seite eingefügt wird, kann dieser als iFrame mit eigenem Browserkontext eingebettet werden. Dadurch kann der Code des Drittanbieters in seinen eigenen Ursprung schreiben. Der Drittanbietercode kann auch als Skript statt als iFrame eingebettet werden. Dadurch wird der Browserkontext nicht gewechselt und der Drittanbieter kann in den freigegebenen Speicher des Einbettungselements schreiben. Beachten Sie, dass nur der Eigentümer des freigegebenen Speichers Lesezugriff auf den freigegebenen Speicher hat.
Deduplizierung	Für Interaktionen außerhalb der Chrome-Umgebung ist keine Deduplizierung möglich.	Ein freigegebener Speicher soll Google Chrome-basierte Unique Reach-Ausgaben ermöglichen. Wir möchten mit Anzeigentechnologie-Anbietern zusammenarbeiten, um zu verstehen, wie diese Ergebnisse im Rahmen ihrer breiteren Reichweitenmodelle genutzt werden können. Uns ist bewusst, dass die Ausgaben selbst möglicherweise nur einen Teil der Interaktionen ausmachen, und sind an der Zusammenarbeit mit Anzeigentechnologien interessiert, um zusätzliche Modellierungsmethoden zu untersuchen, die übereinandergelegt werden könnten.
Lookback-Window für Conversions	Fordern Sie ein Lookback-Window für die Conversion-Rate an, um Änderungen bei den Conversions im Laufe der Zeit zu sehen.	Dies kann implementiert werden, indem die verschiedenen Conversion-Pfade auf der Clientseite mithilfe von freigegebenem Speicher verarbeitet werden. Dies bietet gegenüber dem sicheren nicht partitionierten Browserspeicher mehr Flexibilität bei erweiterten Analysen.
Ablaufdatum des Elements	Beantragen Sie eine Verlängerung der Gültigkeitsdauer von 90 Tagen.	Die Richtlinie zur Datenaufbewahrung wurde im November 2022 aktualisiert und besagt, dass jeder Schlüssel nach 30 Tagen nach dem letzten Schreibvorgang gelöscht wird. Wir freuen uns über zusätzliches Feedback, um besser beurteilen zu können, ob die neue Richtlinie für das System geeignet ist.
Creative-Rotation	Anwendungsfälle für die Creative-Rotation spiegeln nicht die tatsächlichen Aktionen nach der Auktion wider.	Wir würden gern von weiteren AdTech-Unternehmen auf Käuferseite erfahren, ob die Dokumentation zur Creative-Rotation korrekt ist oder nicht.

Chips

In diesem Quartal gab es kein Feedback.

FedCM

Feedback-Design	Zusammenfassung	Chrome-Antwort
Endpunkt der Identitätsbestätigung	Lassen Sie explizit beliebige Anfragen an den Endpunkt der Identitätsbestätigung zu.	Wir haben bei dieser Pull-Anfrage mit Mozilla zusammengearbeitet, um die Möglichkeit von Websites einzuschränken, ursprungsübergreifende Anfragen mit Anmeldedaten im Hintergrund zu senden, ohne die Nutzer zu stören. 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 kann es zu Datenlecks kommen, wenn eine Website, die nicht mit dem Nutzer interagiert hat, den letzten vom Nutzer verwendeten IdP abfragen kann. Wir besprechen dieses Problem genauer und würden uns über zusätzliches Feedback freuen.
Kontextbezogene Kontoauswahl	Vorschlag zum Hinzufügen von Kontextsignalen in der Benutzeroberfläche zur Kontoauswahl	Wir prüfen diesen Vorschlag und freuen uns auf weitere Gespräche.

Spam und Betrug bekämpfen

Private State Token API (und andere APIs)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Umfrage zu Funktionen	Zu Beginn des 1. Quartals haben wir die Erhebung der Umfrageergebnisse abgeschlossen, für die Funktionen für verschiedene Anwendungsfälle zur Betrugsbekämpfung erforderlich sind. Diese haben wir öffentlich freigegeben (Minuten, Ergebnisse).	Wir planen, dieses Feedback bei der Entwicklung neuer Vorschläge und Prototypen für zweckgebundene, datenschutzfreundliche APIs zur Betrugsbekämpfung zu berücksichtigen. Wir gehen davon aus, dass wir die Entwicklung priorisieren werden, wenn ein ausreichender Bedarf besteht und es vorhandene Technologien gibt, auf die wir aufbauen können, um die Funktionen im Web unter Wahrung des Datenschutzes für Nutzer einzuführen. Beispielsweise wurde die Geräte- und Bootintegrität hoch eingestuft und viele Plattformen haben vorhandene APIs, die eine sichere Bewertung der Geräteintegrität ermöglichen. Daher ist sie ein guter Kandidat für die Recherche in den Community-Gruppen.
Feedback zum PST-Versandabsicht	Im Rahmen der Versandabsicht haben wir die Bedenken erhalten, dass wir eine ältere Version des Datenschutzpasses verwenden. Wir haben auch Feedback erhalten, dass die Spezifikation in bestimmten Abschnitten unklar war und verbessert werden sollte, um die Browserkompatibilität zu verbessern.	Viele der vorgeschlagenen Spezifikationsänderungen sowie einige API-Änderungen sollen implementiert werden, bevor wir sie in Google Analytics veröffentlichen. Da das Feedback am Ende des 1. Quartals eingetroffen ist, erhalten Sie von uns eine Antwort auf die GitHub-Probleme mit spezifischen Details und aktualisieren unseren Einführungsplan (der zum Zeitpunkt der Veröffentlichung dieses Feedbackberichts noch in Arbeit ist). Wir sind offen dafür, die größeren Änderungen an der API in Betracht zu ziehen. Wir sind jedoch der Meinung, dass wir am besten mit der allgemeinen Verfügbarkeit fortfahren und praktisches Feedback von mehr Entwicklern einholen können. Wir hoffen, diese Diskussion fortzusetzen und weiter an der Browserstandardisierung zu arbeiten. Wenn sich ein neuer Standard entwickelt, werden wir einen Plan für den sorgfältigen Übergang in Betracht ziehen.