Feedbackbericht – Q2 und Q3 2024

Quartalsbericht für das 2. und 3. Quartal 2024 mit einer Zusammenfassung des Feedbacks aus der Community zu den Privacy Sandbox-Vorschlägen und der Reaktion von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google zugestimmt, vierteljährlich öffentliche Berichte zum Prozess der Beteiligung der Stakeholder an seinen Privacy Sandbox-Vorschlägen zu veröffentlichen (siehe Paragraf 12 und Paragraf 17(c)(ii) der Verpflichtungen). Am 22. Juli 2024 gab Google bekannt, dass Drittanbieter-Cookies (3rd-Party-Cookies, 3PCs) in Chrome nicht eingestellt werden. Stattdessen schlug das Unternehmen vor, einen aktualisierten Ansatz zur Optimierung der Nutzerauswahl einzuführen. Daher hat Google mit Zustimmung der CMA keinen öffentlichen Bericht für das 2. Quartal 2024 an die CMA eingereicht, um Google und der CMA ausreichend Zeit zu geben, die Auswirkungen der Ankündigung durch Google zu berücksichtigen.

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 das Feedback, das das Chrome-Team zu einem bestimmten Thema erhalten hat, zusammengefasst und in absteigender Reihenfolge nach Anzahl 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 geprü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 der Festlegung einer Position speziell für diese öffentliche Berichterstattung entwickelt. Entsprechend dem aktuellen Schwerpunkt der Entwicklung und Tests haben wir vor allem Fragen und Feedback zu den APIs Topics, Protected Audience und Attribution Reporting erhalten.

Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingegangen ist, wird von Chrome möglicherweise noch nicht berücksichtigt.

Glossar der Abkürzungen

ARA

Attribution Reporting API

CHIPS

Cookies mit unabhängigem 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

NSZ

Origin-Testzeitraum

PAT API

Protected Audience API (früher FLEDGE)

PatCG

Private Advertising Technology Community Group

RP

Vertrauende Partei

RWS

Sets ähnlicher Websites (früher First-Party-Sets)

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
Einstellung von Drittanbieter-Cookies (3PCD)	Welche Pläne hat Google für die Verwendung von Drittanbieter-Cookies und wie werden die langfristigen Auswirkungen auf die digitale Werbebranche bewertet?	Wir schlagen einen aktualisierten Ansatz vor, der Nutzern mehr Auswahlmöglichkeiten bietet. Wie hier beschrieben, werden wir 3PCs nicht einschränken, sondern eine neue Funktion in Chrome einführen, mit der Nutzer eine fundierte Entscheidung treffen können, die für ihr gesamtes Websurfen gilt. Diese Entscheidung kann jederzeit angepasst werden. Wir besprechen diesen neuen Ansatz mit den Regulierungsbehörden und werden vor der Einführung mit der Branche zusammenarbeiten.
Nutzerauswahl	Die Mitteilung zur Nutzerauswahl hat das Interesse an der Einführung der Privacy Sandbox-Lösungen beeinträchtigt. Wir haben gemischte Rückmeldungen zur Ankündigung der Nutzerauswahl erhalten, darunter auch Anfragen zu Funktionen wie Monitoring.	Mit dem aktualisierten Ansatz wird die Nutzerauswahl erweitert. Es bleibt jedoch wichtig, dass Entwickler datenschutzfreundliche Alternativen zu websiteübergreifenden IDs haben. Wir können noch keine Details dazu nennen, wie die neue Funktion aussehen wird. Wir gehen aber davon aus, dass die Anzahl der Zugriffe ohne Cookies in Chrome deutlich zunehmen wird. Das bedeutet, dass die Privacy Sandbox APIs für Unternehmen weiterhin von entscheidender Bedeutung sind. Wir werden auch weiterhin in Privacy Sandbox-Technologien investieren, um Datenschutz und Dienste kontinuierlich zu verbessern.
UI für die Nutzerauswahl	Fragen zum Zeitplan für die Deaktivierungs-/Einwilligungsfunktionen, zum gewünschten Nutzertyp und dazu, wie sich die Benutzeroberfläche auf automatisierte Testumgebungen auswirkt	Wir haben derzeit keine Neuigkeiten zum Zeitplan. Nachdem wir uns entschieden hatten, 3PCD nicht weiterzuverfolgen, wollten wir so schnell wie möglich ein Update für das System bereitstellen. Sobald wir mehr wissen, informieren wir Sie über den Zeitplan für die Nutzerauswahl.
Chrome-Tests	Anfrage zur weiteren Verfügbarkeit von Chrome-gestützten Testlabels zur Messung der Marktakzeptanz und der wirtschaftlichen Auswirkungen von 3PCD nach dem 1. Halbjahr 2024.	Uns ist bewusst, dass Tester auch nach dem Ende der Chrome-gestützten Tests in der ersten Jahreshälfte 2024 weiterhin beschriftete Browsergruppen für Tests und Koordination verwenden möchten. Wir prüfen die nächsten Schritte für Labels im Hinblick auf die Ankündigung zur Nutzerauswahl. In der Zwischenzeit hat das Chrome-Team angekündigt, den Support für gekennzeichnete Browsergruppen bis Chrome-Meilenstein 132 zu verlängern, der bis Januar 2025 läuft.
Privacy Sandbox für Android	Die Privacy Sandbox für Android und die Privacy Sandbox für Chrome sind untrennbar miteinander verbunden. Wir können die Privacy Sandbox ohne Android nicht richtig bewerten. Der typische Kaufprozess, der geräteübergreifende und Multi-Touch-Aspekte umfasst, ist sowohl für die Privacy Sandbox in Chrome als auch für die Privacy Sandbox unter Android von entscheidender Bedeutung.	Bitte beachten Sie, dass die Privacy Sandbox für Android nicht unter die Verpflichtungen von Google gegenüber der CMA fällt. Wenn sich das Feedback auf Zeitpläne und die Einführung von Android bezieht, können wir derzeit keine Neuigkeiten mitteilen. Wir arbeiten jedoch weiter an Android, das wir als unabhängigen Arbeitsstream zur Verbesserung des Datenschutzes betrachten. Wie bereits erwähnt, hängt die Verfügbarkeit von Privacy Sandbox APIs unter Android auch davon ab, wie oft Nutzer ihre Geräte aktualisieren. Google hat keinen Einfluss darauf.
Modus B: Traffic begrenzt	Die über die Auktion B verfügbaren Zugriffe über die Anzeigenauktion sind niedriger als erwartet.	Es gibt mehrere Gründe, warum das Auktionsvolumen für die Protected Audience API (PA API) unter den Erwartungen liegen könnte. Beispiele: – Die Unternehmen, die die PA API bisher eingebunden haben, haben nur Bannerformate verwendet. – Sell-Side-Plattformen starten möglicherweise nicht immer eine Auktion. – Ein Browser hat möglicherweise keine Interessengruppen. – Es gibt möglicherweise keine Gebote. Uns ist jedoch kein Fall bekannt, bei dem jemand versucht hat, die PA API zu testen und keinen Traffic erhalten hat.
Ausfallsichtbarkeit	Einblick in Ausfälle und Probleme, die sich auf die Privacy Sandbox APIs auswirken.	Für die Privacy Sandbox APIs, die Dienste außerhalb des Browsers haben, gibt es eine öffentliche Statusseite. Für das Chrome-Team hat die Zuverlässigkeit unserer Plattform und aller wichtigen APIs, die von großen Websites und Diensten im Web verwendet werden, oberste Priorität. Dazu gehören auch die Privacy Sandbox-Technologien. Bisher gab es nur einen Ausfall. Das Problem bezog sich auf eine vorübergehende Konfiguration für Tests bei 1%. Die experimentelle Konfiguration, die zu diesem Ausfall geführt hat, wird bald nicht mehr benötigt. Wir sind zuversichtlich, dass dieses Problem nicht mehr auftritt, sobald die APIs auf normale Weise in Chrome aktiviert sind.
Cookie-Grafikstudie	Was ist die Sichtweise von Chrome auf die CookieGraph-Methode, die in diesem Artikel im Privacy Sandbox-Framework beschrieben wird?	Darin werden einige interessante Punkte zur Erkennung und Verbreitung von eigenen Cookies aufgeführt, die von anderen Domains als den vom Nutzer aufgerufenen Cookies gesetzt werden. Wie der Artikel betont, sind diese Cookies äußerst nützlich, um Analysen und Informationen zur Interaktion der Nutzenden mit einer Website zu sammeln. Diese Daten sind für Entwickler entscheidend, um Nutzern eine bessere Browsererfahrung zu bieten. Das Hauptargument ist fehlerhaft, da eigene Cookies als websiteübergreifendes Tracking-Vektor betrachtet werden. Dies gilt jedoch nur unter den sehr aggressiven Annahmen, die im Artikel beschrieben werden: Nutzer sind bereit, ihre personenidentifizierbaren Informationen mit der Website zu teilen. Geräte haben einen stabilen Fingerabdruck, mit dem Nutzer websiteübergreifend erfasst werden können. Beachten Sie, dass dies Vektoren der Re-Identifikation sind, die ohne den Einsatz von eigenen Cookies ausgenutzt werden können (z. B. durch serverseitige Datenfreigabe) und nicht mit unseren aktuellen Bemühungen zur Verfolgung zustandsbasierter Tracking-Mechanismen wie Drittanbieter-Cookies ausgenutzt werden müssen. Abschließend möchten wir darauf hinweisen, dass in dem Papier Analyse- und Werbe-Cookies mit Tracking-Cookies und streng notwendige Cookies mit nicht-Tracking-Cookies gleichgesetzt werden, was nicht unbedingt der Fall ist. Tatsächlich sind selbst erhobene Analysen oder anbieterspezifische Dienste, die auf eine Website beschränkt sind, wie z. B. Suchmaschinen-Widgets, Chat-Widgets oder Load Balancer-Cookies, oft auf eine einzige Domain beschränkt. Umgekehrt können einige streng notwendige Cookies zu Website-Tracking zu Betrugspräventionszwecken verwendet werden.
UX-Änderungen	Die UX-Änderungen in Chrome 112, durch die die Einstellungen für selbst erhobene Cookies in den Abschnitt „Websitedaten auf dem Gerät“ der Chrome-Einstellungen verschoben werden, könnten es Nutzern erschweren, alle Cookies zu blockieren.	Diese Änderung wurde vorgenommen, um die Kontrollen für Drittanbieter-Cookies (oder nicht partitionierten Speicher) von allen anderen Websitedaten zu trennen. Die Einstellungen für Drittanbieter-Cookies sind im Bereich „Datenschutz und Sicherheit“ zu finden. Die Einstellungen für selbst erhobene Cookies und alle anderen Arten von Websitedaten, von denen wichtige Websitefunktionen in der Regel abhängen, sind unter „Websitedaten auf dem Gerät“ zusammengefasst. Wir werden weiterhin auf Feedback zu diesem Thema prüfen, sind jedoch der Meinung, dass die aktuelle Trennung ein gutes Gleichgewicht zwischen der Sichtbarkeit sinnvoller Datenschutzeinstellungen und der Wahrung einer funktionalen Browsernutzung schafft.
Abrechnung und Zahlung	Abrechnungen und Zahlungen werden noch nicht vollständig getestet, da die Tester mehr in das Testen anderer Bereiche von Privacy Sandbox APIs investieren.	Wann und was Entwickler und Unternehmen testen, liegt in ihrer Entscheidung. Die APIs sind seit September 2023 allgemein für Tests verfügbar.
Test	Nicht der gesamte experimentelle Traffic, den DSPs von SSPs erhalten, ist gekennzeichnet. Einige DSPs haben angegeben, dass der Anteil der zu testenden Impressionen ohne Label in den Test- und Kontrollgruppen unterschiedlich sein kann.	Chrome kann nicht steuern, ob Unternehmen Labels in Gebotsanfragen weiterleiten. Wir stellen eine Methode zum Abrufen eines Labels aus dem Browser bereit. Die Labels können dann an Partner übergeben werden, wenn deren Partner diese Labels nicht direkt lesen können.
3PCD in Android WebView	Anleitung zum Aktivieren des Flags „Test Third Party Cookie Phaseout“ (Einstellung von Drittanbieter-Cookies testen) in Android WebView zum Testen der Einstellung.	Drittanbieter-Cookies sind in Android WebView standardmäßig blockiert.
Differential Privacy zur Minimierung von Risiken beim Modelltraining	Warum wird Differential Privacy beim Modelltraining verwendet?	Differenzielle Privatsphäre in Kombination mit vertrauenswürdigen Ausführungsumgebungen (Trusted Execution Environments, TEEs) ist bei der Modellerstellung unerlässlich, um Datenlecks zu verhindern und sensible Daten vor Bedrohungen zu schützen. So wird sichergestellt, dass Modellgewichte keine Daten einzelner Nutzer offenlegen.

Registrierung und Bestätigung

Feedbackthema	Zusammenfassung	Chrome-Antwort
Registrierung	Klärung der Funktionsweise der Attestierung zwischen dem registrierten Ursprung und dem Ursprung der Anzeigentechnologie mit www-Subdomain	Die Anzeigentechnologie muss nur bei https://example.com eingerichtet werden. Wenn sie ihre Attestierung in https://example.com/.well-known/privacy-sandbox-attestations.json platzieren, wird die https://www.example.com abgedeckt, da es sich um eine Subdomain handelt.
API-Spezifikation	Vorschlag, dem Repository ein JSON-Schema für die Attestierungsdatei hinzuzufügen.	Wir prüfen diesen Vorschlag und freuen uns über zusätzliches Feedback hier.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema	Zusammenfassung	Chrome-Antwort
Gewichtung von Themen	Das Wichtigste bei Themen ist die Seltenheit eines bestimmten Signals. Das aktuelle Design sollte weiterentwickelt werden, damit neben jedem beobachteten Thema ein Gewichtungswert hinzugefügt werden kann. Das Gewicht ist die relative Gewichtung eines bestimmten Themas für einen Browser im Vergleich zu allen Browsern, die das Thema verwenden.	Wir möchten mehr darüber erfahren, warum die Seltenheit eines Signals das wichtigste Signal ist. Wir freuen uns über zusätzliches Feedback zum Nutzen dieses Anwendungsfalls.
Zuverlässigkeit von Topics	Google muss stärkere Zusicherungen zur Zuverlässigkeit von Topics im Zeitverlauf geben.	Änderungen an unseren APIs werden auf der Grundlage des Feedbacks aus der Umgebung weiterhin vorgenommen und im Vorfeld öffentlich diskutiert. Unser Vorschlag für eine überarbeitete Governance-Struktur würde zusätzliche Sicherheit bieten.
Klassifikator	Die Websites von Publishern werden häufig falsch klassifiziert oder ihnen werden zu allgemeine Themen zugewiesen, die keinen sinnvollen Zweck erfüllen.	Wie in unserer Erläuterung zur Themenklassifizierung beschrieben, werden Websites anhand einer Kombination aus einer von Menschen zusammengestellten Überschreibungsliste mit den beliebtesten Websites und einem On-Device-Modell für maschinelles Lernen klassifiziert. In Chrome werden derzeit Optionen für Websites geprüft, die 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 das Selbstlabeln als Methode verwenden, um verschiedene (und potenziell sensible) Bedeutungen in Themen einzubetten; und – Websites, die Themen angreifen, um ihre Nützlichkeit für andere zu verringern (z.B. Spamming der Themen des Nutzers mit bedeutungslosem Rauschen). Diese Komponenten sind öffentlich zugänglich. Die verfügbaren Tools sind über chrome://topics-internals oder dieses Colab 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.
API-Frage	Bedenken, dass die Topics API SSPs, die mit schädlichen Inhalten Einnahmen erzielen, dauerhafte und wettbewerbswidrige Vorteile bietet	Wie bei 3PCs ist es für den Browser nicht wichtig, an wen er Topics zurückgibt, solange diese Entität registriert und attestiert ist.
(Auch in früheren Quartalen erfasst) Nützlichkeit für unterschiedliche Arten von Stakeholdern	Da der Topics-Klassifikator derzeit zur Definition der entsprechenden Themen nur den Hostnamen der Seite verwendet, tragen große Websites mit vielfältigem Content allgemeine Themen bei, während kleine Websites Nischenthemen mit höherem Werbewert beisteuern.	Unsere Antwort ähnelt der aus den vorangegangenen Quartalen: Wie bei Drittanbieter-Rezensionen gibt es Unterschiede beim Wert der Informationen, die von verschiedenen Websites stammen. Websites mit Nischenthemen haben einen uneinheitlichen Wertbeitrag: Nicht alle Websites mit Nischeninteressen haben einen wirtschaftlich wertvollen Kontext und tragen daher zu einem geringeren Wert bei. Dies sind die Websites, die von der Topics API profitieren. Wir haben die Möglichkeit einer Klassifizierung auf Seitenebene statt auf Websiteebene in Betracht gezogen. Bei einer solchen Klassifizierung ergeben sich jedoch erhebliche Datenschutz- und Sicherheitsbedenken.
Klassifikator	Kleineren Websites wird häufig eine falsche oder gar keine Klassifizierung zugewiesen, sodass sie nicht am Wertaustausch teilnehmen können.	Bezüglich des angeblichen Schadens sind bestimmte Websites, die möglicherweise falsch klassifiziert werden, nicht stärker davon betroffen als andere Websites. Die kontextbezogenen Informationen einer Website sind nämlich immer für Auktionen auf der Website verfügbar, was auch bei einer Falschklassifizierung vergleichbare Informationen zum richtigen Thema liefern würde. Themen werden in der Regel verwendet, um potenziell nützliche Werbeinformationen von externen Websites anstelle von eigenen Websites zu erfassen.
Taxonomieversion	Wie können wir auf die Taxonomieversion zugreifen, um die Abwärtskompatibilität zu gewährleisten?	Die Taxonomieversion ist Teil des Anfrageheaders, der mit einer Themen-basierten Abrufanfrage gesendet wird. Beispiel: Bei der Kopfzeile „(1 2);v=chrome.1:2:5, ();p=P000000000“ lautet die Version „chrome.1:1:2“. Dabei steht chrome.1 für die Konfigurationsversion, 2 für die Taxonomieversion und 5 für die Modellversion. Dies wird in der Spezifikation beschrieben und wurde auch der Erläuterung hinzugefügt.
Topics-Daten	Anfrage zur Klärung, wie Topics-Daten aktualisiert werden	Die Taxonomieaktualisierung ist nicht angegeben. So können Browseranbieter flexibel implementieren. Im Folgenden finden Sie die Heuristiken für das Taxonomieupdate von Chrome von Version 1 auf Version 2: – Für Themen aus Version 1 und Version 2 wird ein einzelner Taxonomiebaum verwaltet. – Dieselbe Themen-ID steht für dieselbe Bedeutung. – Der Baum wächst immer weiter – neue Themen oder Verbindungen werden hinzugefügt und immer weiter verkleinert. – Einige Themen oder Links können jedoch in einer Version "inaktiv" sein, was den Eindruck einer Löschung oder Neuorganisation erweckt. Beispiele: – Für „Kleintransporter“ ist jetzt „LKWs, Vans & SUVs“ als übergeordnetes Element vorhanden. – „Ausländische Sprachen lernen“ hat jetzt „Ausbildung“ als zweite übergeordnete Einheit und die ursprüngliche übergeordnete Einheit „Referenz“ wird inaktiv. Auswirkungen von „inaktiven“ Themen: Diese Themen werden nicht für die neue Klassifizierung verwendet. Sie werden jedoch bei der Durchsetzung von Nutzerblockierungen berücksichtigt: Wenn ein Nutzer ein Thema in V1 blockiert hat, bleiben seine untergeordneten Themen in V2 blockiert, auch wenn das untergeordnete Thema in V2 unter einem anderen übergeordneten Thema angezeigt wird.
Klassifikator	Ich möchte die Ursachen und Korrekturoptionen für fehlerhafte Klassifizierungen erfahren.	Zuerst möchten wir darauf hinweisen, dass die Themen einer Website in Chrome nur als Eingabe für den Topics-Algorithmus verwendet werden, um die Interessen eines Nutzers zu Werbezwecken zu ermitteln. Sie wurde nicht für andere, allgemeinere Klassifizierungszwecke entwickelt. Uns ist die Gesamtgenauigkeit unseres Klassifizierungsmodells wichtig. Wir versuchen, die Genauigkeit und Trefferquote nach Möglichkeit zu verbessern, aber auf globaler Ebene und nicht auf Ebene der einzelnen Websiteklassifizierung. Das liegt daran, dass eine Falschklassifizierung, falls sie auftritt, nicht der einzelnen Website schadet, die falsch klassifiziert wurde. Stattdessen wird die Qualität des Topics-Signals bei der Auswahl einer Anzeige auf anderen Websites beeinträchtigt. Bei der Auswahl von Anzeigen auf der fälschlicherweise klassifizierten Website sind die tatsächlichen Themen der Website bereits bekannt und können als Eingabe für Werbeanfragen verwendet werden. Hier können Sie uns weiteres Feedback geben.
API-Tests	Können Topics und die Privacy Sandbox-APIs im Allgemeinen mit Chromium getestet werden?	Die Topics API ist nicht in Chromium enthalten, sondern in Chrome.
Topics-Aufrufer	Antrag auf Verbesserung des Mehrwerts von Topics mithilfe von TEE-Diensten für AdTech-Teams, um die Kosten der erweiterten Analyse auf datenschutzkonforme Weise zu decken.	Hier finden Sie ähnliches Feedback. Wir haben die Inverse Häufigkeit in Betracht gezogen und schließlich nach der Modellierung der Inverse Häufigkeit festgestellt, dass sie gemäß dem von Käufern und Verkäufern bereitgestellten Wert nicht gut mit dem Themenwert korreliert. Hier können Sie uns weiteres Feedback geben.
API-Spezifikationen	Kann die Topics API durch die Browser-Einstellung für Interessenkohorte blockiert werden?	Hier haben wir auf dieses Feedback reagiert. Die Topics API ist eine Weiterentwicklung von FLoC und entspricht der Berechtigungsrichtlinie von FLoC. Wie in der Erläuterung erläutert, wird durch die alte Permissions-Policy: interest-cohort=() aus FLoC auch die Berechnung von Themen unterbunden.
Themenrang	Zählen wir als die Top-5-Themen die Häufigkeit von Website-Besuchen basierend auf jedem infrage kommenden Anrufer oder immer auf der Grundlage des gesamten Besuchsverlaufs des Browsers? Werden Themen für jeden Anrufer separat bewertet?	Sie basiert auf der Häufigkeit eines Teils des Browserverlaufs. Ein Eintrag im Browserverlauf (eine Seite) darf nur teilnehmen, wenn die Seite mindestens einen Topics-Aufrufer hatte. Weitere Informationen zum Speichern des Themenverlaufs finden Sie hier. Wie in unserer Ankündigung zu Verbesserungen der Topics API erläutert, hängt das Ranking von der Häufigkeit und einer binären Prioritätsstufe ab. Weitere Informationen finden Sie hier und hier. Sie hängt jedoch nicht von der Häufigkeit der Anrufe ab. Das bedeutet nicht, dass alle Aufrufer in der nächsten Epoche die fünf wichtigsten Themen erhalten. Wie in der Erläuterung erläutert, können nur Anrufer, die festgestellt haben, dass der Nutzer innerhalb der letzten drei Wochen eine Website zum betreffenden Thema besucht hat, das Thema erhalten. Der Browser muss jedoch erfassen, welche Top-5-Themen für welchen Anrufer beobachtet wurden (entspricht den Top-5-Themen mit Anruferdomains in der Spezifikation). Du kannst uns hier weiteres Feedback zu diesem Problem geben.

Protected Audience API (früher FLEDGE)

Feedbackthema	Zusammenfassung	Chrome-Antwort
(wurden auch in vorherigen Quartalen erfasst) Kosten	Ist es teurer, TEEs in öffentlichen Clouds als in lokalen Rechenzentren für Anzeigentechnologien auszuführen?	Unser aktuelles TEE-Sicherheitsmodell profitiert von den Praktiken bei Implementierungen öffentlicher Clouds. Weitere Informationen finden Sie in der Erläuterung der TEE-Anforderungen für öffentliche Clouds. Aktuelle hardwarebasierte TEEs schützen beispielsweise nicht vor allen physischen Angriffen. Unsere unterstützten öffentlichen Cloud-Anbieter AWS und GCP haben Maßnahmen zur Risikominimierung bei physischem Zugriff entwickelt und implementiert, einschließlich Zugriffen durch Mitarbeiter. Einige AdTech-Unternehmen haben uns mitgeteilt, dass die Ausführung von Cloud-Diensten teurer ist als lokale AdTech-Rechenzentren. Andere AdTechs werden jedoch in öffentlichen Clouds ausgeführt – sei es aus Kostengründen oder wegen anderer Vorteile. Wir prüfen weiterhin Optionen zur Erweiterung unserer TEE-Unterstützung, auch außerhalb öffentlicher Clouds. In diesem Zusammenhang forschen wir an lokalen Rechenzentren und arbeiten mit der Branche zusammen, um potenzielle Lösungen für die Bereitstellung solcher Unterstützung zu finden. In der aktuellen Phase der Forschung können wir nicht garantieren, dass dies zu einer praktikablen Lösung für das Ökosystem führt.
PA API und Google Ad Manager (GAM)	GAM kann kein faires Marktergebnis erzielen. In GAM können Anzeigen nicht rechtzeitig bereitgestellt werden. Außerdem kann nicht angegeben werden, wie viele Anzeigen über die PA API ausgeliefert wurden. Außerdem lässt sich nicht festlegen, welche Methode zur Auslieferung einer Anzeige ausgewählt wird, z. B. indem die PA API für bestimmte Anzeigenflächen deaktiviert wird.	Google Ad Manager-Antwort: GAM optimiert die Latenz bei der Anzeigenbereitstellung über die PA API und arbeitet kontinuierlich daran, dass der zusätzliche Umsatzgewinn für Publisher aus der PA API-Nachfrage die Kosten überwiegt, die aufgrund der zusätzlichen Latenz der PA API-Auktion entstehen. Erste Tests zeigen, dass Publisher mit der Protected Audience API bei Traffic ohne Drittanbieter-Cookies eine Steigerung des Nettoumsatzes erzielen. Dies deutet darauf hin, dass die zusätzliche Nachfrage durch die Protected Audience API die Kosten aufgrund der Latenz übertrifft. Weitere Informationen zu unserem Ansatz finden Sie in unseren FAQs. Darüber hinaus bietet GAM Publishern Berichte zu Anzeigen, die über die PA API ausgeliefert wurden. Dazu gehören Anzeigen, die ausgeliefert werden, wenn GAM Komponentenanbieter ist, sowie Anzeigen, die über andere Komponentenverkäufer ausgeliefert wurden, wenn GAM ein Top-Level-Verkäufer ist. Weitere Informationen zum Melden von Inhalten finden Sie in der Hilfe. In GAM können Publisher die Verwendung der PA API für ihren Traffic über eine Steuerelement auf der Benutzeroberfläche aktivieren oder deaktivieren. Weitere Informationen finden Sie in der Google Ads-Hilfe. Wir freuen uns über Feedback zu weiteren Steuerungsmöglichkeiten, die Publisher wünschen, und werden Funktionsanfragen gemäß unserem standardmäßigen Prozess zur Funktionspriorisierung priorisieren.
PA API und GAM/AdX	Google hat offenbar entschieden, keine PA API-Impressionen zu kaufen, bei denen die endgültige Verkaufsentscheidung nicht von GAM getroffen wird. Das ist vergleichbar mit AdWords, bei dem nur Anzeigen von Google gekauft werden. Dies scheint ein klarer Missbrauch der Marktposition zu sein, da GAM/AdX wie jede andere Anzeigenplattform eine Auktionskonfiguration für Komponenten an einen alternativen Verkäufer der obersten Ebene senden könnte.	Antwort des Managers der Google Ads Platform: Das ist nicht die Position von Google. Auf den Buy-Side-Plattformen von Google (Google Ads und DV360) werden Impressionen von Anzeigenplattformen außerhalb von Google gekauft. Dies gilt sowohl für PA API-Impressionen als auch Nicht-PA API-Impressionen.
Marktreaktion	Bedenken von Mozilla: Die Funktion „Geschützte Zielgruppe“ von Google schützt Werbetreibende (und Google) mehr als Sie	Wir schätzen die Einschätzung von Mozilla und werden uns auch weiterhin in öffentlichen Standardsforen mit dem Feedback von Mozilla auseinandersetzen. Ein Thema der Bewertung ist, dass mit der aktuellen Implementierung der PA API noch nicht alle geplanten Schutzmaßnahmen erzwungen werden. Unser Ansatz zur Markteinführung mit der PA API zielt darauf ab, die richtige Balance zwischen der Förderung der Einführung und der schnellen Umsetzung von Datenschutzmaßnahmen zu finden. Im Rahmen dieser Initiative haben wir eine Roadmap für die Einführung von Datenschutzeinschränkungen erstellt, um die Einbindung in die APIs zu erleichtern und uns Zeit zu geben, mehr Feedback einzuholen, das wir in die zukünftigen Schutzmaßnahmen einfließen lassen können (z.B. VAST-Funktionen in abgegrenzten Frames). Wir begrüßen auch die aktuelleren Mitteilungen von Mozilla zu seinem eigenen Ansatz in Bezug auf Datenschutz und digitale Werbung: Ein kostenloses und offenes Internet sollte nicht auf Kosten des Datenschutzes gehen und Onlinewerbung durch Produkt und Infrastruktur verbessern.
(Auch in früheren Quartalen gemeldet) Auktionsergebnisse	Bei einer einzelnen Auktion werden mehrere Rendering-URLs mit der entsprechenden Bewertung zurückgegeben. So können bei nativer Werbung leichter Duplikate entfernt und Probleme mit der Nutzererfahrung und Latenz vermieden werden.	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir haben die Möglichkeit in Betracht gezogen, mehrere Render-URLs und die jeweilige Bewertung aus einer einzelnen PA API-Auktion zu teilen, haben sie aber aus Datenschutzgründen nicht implementiert. Wir können nachvollziehen, dass Sie nicht möchten, dass einem Nutzer auf einer einzelnen Seite dieselbe Anzeige mehrmals präsentiert wird. Wir prüfen Ihre Anfrage daher. Wir freuen uns über zusätzliches Feedback dazu, welche zusätzliche Unterstützung in der PA API erforderlich ist, um den Anwendungsfall „Native Advertising“ optimal zu unterstützen.
Leistung	Bedenken hinsichtlich der Latenz, die sich auf die PA API auswirkt.	Wir haben Bedenken hinsichtlich der Latenz gehört. Das ist einer der Gründe, warum wir im Rahmen der PA API eine Reihe von Funktionen entwickelt haben, mit denen SSPs sowohl Limits für die DSP-Latenz festlegen als auch Verbesserungen vornehmen können, um die Latenz zu verringern. Wir haben vor Kurzem unseren Leitfaden zu Best Practices für Latenz aktualisiert. Dort finden Sie weitere Informationen dazu, wie Sie diese Funktionen optimal nutzen können. Außerdem arbeiten wir kontinuierlich an neuen Latenzverbesserungen, von denen einige hier zu sehen sind.
Top-Level-Verkäufer	Google sollte Publishern die Möglichkeit geben, alternative PA API-Auktionsverkäufer der obersten Ebene auszuwählen.	Die PA API ist unabhängig davon, wer eine Auktion initiiert, sowohl bei Einzel- als auch bei Mehrfachkundenkonten. Ob und wie einzelne Unternehmen PA API-Auktionen unterstützen, liegt in deren alleiniger Verantwortung.
(wurde auch in früheren Quartalen erfasst) Ausschließendes Targeting	Lösung für einen Anwendungsfall anfordern, bei dem ein Werbetreibender keine Anzeigen für eine bestimmte Zielgruppe schalten möchte	Wir unterstützen das ausschließende Targeting auf Anzeigenplattformen über zusätzliche (kontextbezogene) Gebote. So können Werbetreibende verhindern, dass Anzeigen für eine bestimmte Zielgruppe ausgeliefert werden. Details finden Sie in diesem Hilfeartikel und in diesem GitHub-Problem. Wir arbeiten auch an Lösungen, um auszuschließendes Targeting auf Interessengruppen für Gebote über die PA API zu unterstützen. Wir freuen uns über zusätzliches Feedback.
(wurde auch in früheren Quartalen erfasst) Native Anzeigen	Unterstützung für eingegrenzte Frames für native Anzeigen anfordern	Wir prüfen derzeit, ob wir diesen Anwendungsfall unterstützen können, und besprechen hier mögliche Lösungen und Umgehungsmöglichkeiten.
WebView	Zur Klarstellung des Szenarios, bei dem IG bei Chrome beigetreten ist, war für in WebView durchgeführte Auktionen nicht verfügbar.	Wir möchten diese Anwendungsfälle unterstützen, sobald eine ausreichende Datenschutzinfrastruktur verfügbar ist. Derzeit haben wir keine weiteren Ankündigungen zu machen. Du kannst uns aber gern hier zusätzliches Feedback geben.
Negative IGs	Anfrage zur Aktualisierung der URL-Verarbeitung, um negative IGs über das Feature für Anfänger-Header zu unterstützen.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback hier.
Diversitätsfilterung	Anfrage zur Implementierung des Diversitätsfilters bei der Auslieferung von nativer Werbung in der PA API mit mehreren Verkäufern und mehreren Auktionen	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
(wurde auch in früheren Quartalen gemeldet) Blockierungsfilter	Anforderung einer Anleitung zum Erzwingen von Regeln für die Blockierung von Publishern (Filter), wenn native Anzeigen in der PA API mit mehreren Verkäufern ausgeliefert werden	Eine Anleitung dazu finden Sie hier. Wir freuen uns über zusätzliches Feedback.
Einschränkungen	Einschränkungen auf Domainebene statt auf Subdomainebene zulassen	Einschränkungen auf Subdomain- oder Ursprungsebene richten sich nach dem grundlegenden Sicherheitsmodell des Webs. Dies ist also unser Standarddesign. Weitere Informationen dazu finden Sie in diesem Artikel und in diesem Artikel.
Vertrauenswürdige Gebote	Anfragen für User-Agent- und zugehörige Client-Hinweise in Anfragen für vertrauenswürdige Gebotssignale.	Wir verfolgen diese Funktionsanfrage und freuen uns über zusätzliches Feedback.
(wurde auch in vorherigen Quartalen gemeldet) Mehrere Identitäten	Mehrere Anzeigengruppen in einem Gebot verwenden	Dies wird derzeit in der PA API nicht unterstützt, da dies zu einer Änderung des zugrunde liegenden Datenschutzmodells führen würde. Wir freuen uns über weitere Diskussionen hier.
(wurde auch in früheren Quartalen gemeldet) Leistung	Wenn Sie mehr Logik auf den Client verschieben, kann das die Seitenleistung und die Nutzererfahrung beeinträchtigen und sich negativ auf die SEO-Werte der Website auswirken.	Wir besprechen dieses Problem und freuen uns über zusätzliches Feedback. Hier können Sie uns Ihr Feedback mitteilen.
Auktionsdynamik	Die PA API reduziert die Informationen zur Auktionsdynamik (z. B. wer teilnimmt, wer die einzelnen Komponenten der Auktion gewinnt usw.). Das erschwert die Rückverfolgbarkeit von Publishern und macht es schwierig zu erkennen, ob Deals eingehalten werden.	Hier haben wir eine Lösung für das Tracking von Deals vorgeschlagen. Wir planen, einige der vorhandenen Felder zu ändern und einige neue Felder innerhalb des IG-Objekts zu erstellen, um DealID und SeatIDs zu speichern und zu ermöglichen, dass diese von „generateBid“ weitergegeben werden, um eine Punktzahl für Ad oder ausgehenden Traffic über Berichte auf Ereignisebene zu erzielen. Dies sollte für den Anwendungsfall des Deals ausreichend Unterstützung bieten. Wir freuen uns über Feedback zu anderen Metadaten, die Anzeigentechnologie-Anbieter für die Auktionsdynamik als wichtig erachten, damit Publisher dies auch weiterhin tun können. Wir empfehlen Anbietern von Anzeigentechnologien, konkrete Beispiele für Metadaten anzugeben, auf die sie sich beziehen, und anzugeben, von welcher Partei an welche Partei sie weitergegeben werden müssen.
GAM	Bedenken hinsichtlich der Anforderung, GAM als Publisher-Anzeigenserver zu verwenden, um auf die AdX-Nachfrage zuzugreifen.	Antwort von Google Ad Manager: In GAM müssen Publisher nicht die Ad-Server-Funktionen verwenden, um auf die Anzeigenplattformfunktionen zuzugreifen.
(wurde auch in vorherigen Quartalen erfasst) Komponenten-Auktion	Die Gewinner von Auktionen für PA API-Komponenten sind für GAM sichtbar, was Bedenken hinsichtlich ungleicher Zugriffsrechte auf Informationen aufwirft.	Unsere Antwort bleibt unverändert: Antwort von Google Ad Manager: „Wir legen seit Jahren großen Wert auf Fairness bei Auktionen. Dazu gehört auch unser Versprechen, dass kein Preis aus den nicht garantierten Werbequellen eines Publishers, einschließlich der Preise für nicht garantierte Werbebuchungen, vor der Gebotsabgabe in der Auktion an einen anderen Käufer weitergegeben wird. Dieses Versprechen haben wir später in unseren Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bekräftigt. Bei PA API-Auktionen möchten wir unser Versprechen einhalten und das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion in Auktionen mit mehreren Verkäufern nicht mit anderen Auktionsteilnehmern teilen. Zur Klarstellung: Wir geben den Preis der kontextbezogenen Auktion nicht an Komponentenauktionen weiter, auch nicht an unsere eigenen, wie in diesem Update erläutert. Darüber hinaus verwenden wir keine Informationen zu Auktionskonfigurationen für Komponenten, einschließlich Signalen, die Käufer SSPs im Rahmen unserer eigenen Auktion zur Verfügung stellen. Wir würden Änderungen an der PA API begrüßen, die es Komponentenverkäufern ermöglichen, ihre Auktionskonfigurationen so anzugeben, dass sie für den Verkäufer der obersten Ebene unkenntlich sind.“
GAM	Wird GAM eine Umsatzbeteiligung für die Durchführung/Berichterstattung von Auktionen der obersten Ebene anfordern, wenn GAM weder an der Erstellung einer IG- noch einer PA API-Komponentenauktion beteiligt war?	Antwort von Google Ad Manager: Wenn Publisher GAM als Ad-Server verwenden, führt GAM die Auktion auf oberster Ebene durch und berechnet eine Anzeigenbereitstellungsgebühr für die Ad-Server-Funktionen. Diese Gebühr entspricht der Gebühr, die außerhalb von PA API-Auktionen anfällt. Wenn die Anzeige, die die Auktion gewonnen hat, jedoch von einem Komponentenverkäufer stammt, der nicht zu GAM gehört, d. h. GAM weder an der Erstellung der Auktion für IG- noch für PA API-Komponenten teilgenommen hat, übernimmt GAM nicht die Abrechnung und erhebt keine prozentuale Mediengebühr.
Klickfreundlichkeit	Gilt für die Registrierung der Klickereignisse dieselbe differenzielle Privatsphäre?	Für diese Funktion sind derzeit keine Einschränkungen für „k-anon“ geplant, da „Anzahl der Klicks“ nur als Browsersignal in der Funktion generateBid() verfügbar ist. Es ist nicht als neues Attribut in Berichten auf Ereignisebene verfügbar.
Leistung	Hohe Kosten für ausgehenden Traffic aufgrund der bedingungslosen Antwort auf kontextbezogene Gebotsanfragen	Aus Datenschutzgründen können wir nicht direkt angeben, welche Demand-Side-Plattformen IGs haben. Wir arbeiten jedoch an alternativen Lösungen, die Statistiken liefern und gleichzeitig den Datenschutz wahren.
Native und Out-Stream-Anzeigen	Aktualisierte Informationen zu den Richtlinien für native und Outstream-Anzeigen in Chrome	Die Position von Chrome hängt vom jeweiligen Anwendungsfall ab. Bei Videos geht es bei Chrome darum, die Zusammenarbeit mit unseren APIs zu praktikablen In-Stream-Videolösungen zu fördern. Bislang ist das einzige konkrete Angebot, das uns bekannt ist, das Angebot von GAM. Wir sammeln hier aktiv Feedback zu nativen Anzeigen und planen, Werbetechnologieanbieter bald mit weiteren Entdeckungsschritten zu beteiligen.
Echtzeit-Monitoring (RTM)	Bei Zugriffen mit Labels werden keine RTM-Berichte gesendet.	Wir sind uns dieser Lücke bewusst und arbeiten an einer Lösung. Wir werden hier ein Update veröffentlichen, sobald es verfügbar ist.
Unterstützung für Zielgruppenerweiterungen	Anfrage zur Unterstützung von Zielgruppenerweiterungen/vom Verkäufer zusammengestellten Zielgruppen in der PA API	Wir arbeiten an einer Lösung für diesen Anwendungsfall. Wir sammeln Feedback aus der Community dazu, was wir entwickeln und unterstützen sollten. Wir melden uns mit einem Update, sobald wir mehr wissen. Du kannst uns gern hier zusätzliches Feedback geben.
Debugging	In den Chrome-Entwicklertools gibt es kein Steuerfeld, mit dem die detaillierte Leistung der PA API überwacht werden kann. Die Gesamtleistung kann beispielsweise von der Anzahl der Anzeigengruppen oder der Anzahl der Käufer beeinflusst werden.	Dieses Feedback bezieht sich auf die Funktionen der Chrome-Entwicklertools-Benutzeroberfläche, die das Monitoring unterstützen. Am 7. Oktober haben wir die Möglichkeit eingeführt, benutzerdefinierte Ereignisse zu konfigurieren, die als Grundlage für Monitoring und Benachrichtigungen verwendet werden können. Weitere Informationen finden Sie hier. Wir hoffen, dass wir mit diesem Update einen Großteil dieses Feedbacks berücksichtigen konnten. Wir freuen uns über weiteres Feedback zu dieser Funktion, sei es zu den unterstützten Datenpunkten oder zur Nutzerfreundlichkeit für Entwickler. Bitte geben Sie es in der entsprechenden GitHub-Diskussion ein.
Signale	Bedenken, ob DSPs dafür sorgen können, dass perBuyerSignals unabhängig von den Ergebnissen kontextbezogener Auktionen an SSPs gesendet werden.	Es wird davon ausgegangen, dass es bei der kontextbezogenen Auktion nur ein Gewinnergebot von einer DSP gibt, oder besser gesagt, ein Gebot, das in einer nachfolgenden PA API-Auktion überboten werden soll. Für den PA API-Vorgang entscheidet die SSP, alle DSPs einzuladen, von denen sie wissen möchte, ob sie eine Nachfrage (in Form einer On-Device-Gebotsanfrage) haben. Es ist durchaus möglich und sogar sehr wahrscheinlich, dass eine DSP, die die kontextbezogene Auktion verloren hat, noch einmal zur Teilnahme an der PA API-Auktion eingeladen wird. Bei dieser „erneuten Einladung“ leitet die DSP, falls sie sich zur Annahme entscheidet, alle Signale an die SSP weiter, die der Ad Verifier berücksichtigen möchte, sofern für diese Kampagne vorhanden. Mit anderen Worten: Bei der PA API-Auktion kann die DSP immer die Signale pro Käufer an die SSP senden, unabhängig davon, was bei der kontextbezogenen Auktion passiert ist.
Signale	Anforderung, dem an generatedBid() übergebenen browserSignals-Objekt „prevClicks“ hinzuzufügen.	Diese Anfrage kann durch unseren Vorschlag zur Unterstützung von Klicksignalen gelöst werden. Wir haben diese Funktion in unserem letzten Blogpost und in der entsprechenden Erläuterung angekündigt. Hier können Sie uns zusätzliches Feedback zu diesem Vorschlag geben.
(wurde auch in vorherigen Quartalen erfasst) Modellierungssignale	Erhöhung der Anzahl der Bits von Modellierungssignalen von 12 Bit auf 30 Bit beantragen	Wir haben auf dieses Feedback mit einem Gegenvorschlag hier reagiert. Wir arbeiten aktiv mit der Branche zusammen, um ihre Meinung zu unserem Vorschlag zu erfahren. Derzeit wägen wir die Vorteile für die Branche gegen die Auswirkungen auf Chrome-Nutzer und andere Stakeholder ab.
Dokumentation	Anleitung zur Verwendung von Schlüssel/Wert-Servern (K/V-Servern) und TEEs anfordern	Eine Anleitung zur Verwendung von TEEs im Zusammenhang mit K/V-Diensten finden Sie in den Details zum Design des K/V-Dienst-Vertrauensmodells.
Lebensdauer negativer IGs	Verlängerung der Lebensdauer von auszuschließenden Keywords auf 365 Tage beantragen	Mithilfe von auszuschließenden Keywords wird verhindert, dass Anzeigen ausgeliefert werden.Böswillige Akteure können sie jedoch weiterhin verwenden, um Informationen über Nutzer zu erhalten, was das Risiko einer erneuten Identifizierung birgt. Eine Möglichkeit für einen Angriff besteht beispielsweise darin, wiederholt hohe Gebote mit auszuschließenden Keywords abzugeben, um herauszufinden, ob ein Nutzer bestimmte Websites besucht hat oder nicht. Wenn wir eine TTL von 365 Tagen beibehalten, haben böswillige Akteure viel mehr Daten über negative Statistiken, was zu erheblich größeren Datenschutzrisiken führt. Aus diesem Grund können wir diesem Antrag aus Datenschutzgründen nicht nachkommen.
API-Spezifikationen	Welche Werte können als Werte eingefügt werden, die als Teil von perBuyerSignals übergeben werden? Kann dieser Wert vom Verkäufer willkürlich festgelegt werden?	Unter „perBuyerSignals“ können Verkäufer Käufern alle Informationen zur Verfügung stellen, die sie in der Auktion zur Verfügung stellen möchten. Die Entscheidung, welche Inhalte eingefügt werden, liegt allein bei den Nutzern. Weitere Informationen
Ersatz von Anzeigengrößen-Makros	Ich benötige Hilfe, weil die Makroersetzungen für die Anzeigengröße nicht funktionieren.	Weitere Informationen dazu werden wir bald veröffentlichen.
Post Bid SSP Macro Replacement: Spoofing Top Level URL	Welche Mechanismen kann Chrome einführen, damit Anbieter von Bestätigungsdiensten die URL der obersten Ebene im Rahmen der Privacy Sandbox bestätigen können? Gibt es alternative Datenpunkte oder Signale, die in eingezäunten Frames verwendet werden können, um die Richtigkeit der von der SSP bereitgestellten Top-Level-URL zu gewährleisten?	Hier können Sie sich über zusätzliches Feedback freuen.
Feature Request (Funktionsanfrage)	Anfrage zur Bereitstellung von UACH mit niedriger Entropie bei updateURL-Abrufen und bei Postbacks für Echtzeitberichte.	Diese Anfragen werden hier diskutiert. Wir freuen uns über zusätzliches Feedback hier und hier.
Feature Request (Funktionsanfrage)	Anfordern, dass das Debug-Design mit Einwilligung des vertrauenswürdigen Servers aktiviert wird, wenn ein bestimmter Client zum Senden von herunterskalierten Berichten auf Ereignisebene vom Typ „forDebuggingOnly“ über forDebuggingOnly.reportAdAuctionWin() und forDebuggingOnly.reportAdAuctionLoss() ausgelöst wurde.	Wir verfolgen diese Anfrage derzeit und werden das System aktualisieren, sobald es Neuigkeiten gibt. Hier können Sie uns zusätzliches Feedback geben.
API-Verwendung	Anfrage: Anleitung zum Zählen der Reichweite von einzelnen Nutzern und der Reichweite von Impressionen	Wir besprechen einen Vorschlag zum Lesen von IGs in einem Shared Storage-Worklet, für das Sie dann private aggregierte Berichte senden können. Weitere Informationen finden Sie in diesem Artikel. Wir freuen uns über Feedback zum Vorschlag und seiner Nützlichkeit für das Werbesystem.
API-Verwendung	Unklarheit darüber, was Publisher testen sollten, welche APIs wichtig sind, welche aktiviert werden sollten und was noch kommt.	Wir arbeiten daran, Publisher und ihre Rolle im Werbesystem besser zu unterstützen.
API-Verwendung	Ist es möglich, den Worklet-Ereignissen für Anzeigenauktionen Ereignis-Listener hinzuzufügen?	Das ist über normale Ereignisse nicht möglich, aber mit Ereignissen im Chrome Devtools Protocol wird dieser Anwendungsfall teilweise abgedeckt. Regelmäßige Ereignisse wirken sich wahrscheinlich auf Isolations-/Datenschutz-Properties aus. Weitere Informationen
K-Anonymität	Sie möchten wissen, welche Anforderungen an das Anzeigen-Rendering gelten (z.B. dass die Anzeige mindestens 50 Nutzer gesehen hätten, wenn sie ausgeliefert werden dürfte).	Die Entwicklerdokumentation bietet einen Überblick über unsere Erwartungen an zukünftige Entwicklungen. Insbesondere wird erklärt, dass der anfängliche Grenzwert für die k-Anonymität k=10 Personen beträgt. Die blink-dev-Mailingliste enthält aktuelle Informationen zu den Entwicklungen in Chrome. Wie im Thread zur K-Anonymität in der Mailingliste erläutert, erzwingen wir die Anonymisierungsvorgabe derzeit experimentell für etwa 1% des stabilen Chrome-Traffics, aber nie für die explizit gekennzeichneten Segmente („Modus A“ und „Modus B“).
Chafing	Kann die TEE K/V-Chaffing vorübergehend entfernt oder reduziert werden, sodass nicht alle N Shards aufgerufen werden müssen, bis ein gewisser Ausgleich zwischen Datenschutz und Nutzen (z.B. K/V-Leistung/Kosten)?	Diese Anfragen werden nur für nicht produktionsnahe Instanzen verarbeitet, bei denen das Verheddern kontrolliert werden kann. Für Produktionsinstanzen ist weiterhin ein Chaffing erforderlich. Wir können die Situation erst dann bewerten, wenn wir Feedback zur Verwendung außerhalb der Produktion erhalten.
Chafing	Anfrage zum Hinzufügen eines Flags, um das Verwirrfunken von Debug-/Nicht-Produktions-K/V-Binärdateien zu deaktivieren.	Dieses Flag ist mit der Version 1.0.0 verfügbar.
API-Fehler	Die API funktioniert nach dem Upgrade auf Chrome 126 nicht mehr, obwohl sie in den Einstellungen aktiviert war.	Dieses Problem hängt mit der Chrome-Flag „enable-fenced-frames“ zusammen, die von Nutzern zu Entwicklungszwecken aktiviert wurde. Wenn Sie dieses Flag auf die Standardeinstellung zurücksetzen, wird das Problem behoben.
Berichte	Anforderung, dass die Aktivierung der Echtzeitberichts-API für Käufer nicht verkäuferabhängig ist.	Diese Anfrage wird hier bearbeitet. Die RTM-Lösung wurde vor Kurzem veröffentlicht. Wir freuen uns auf Feedback, insbesondere von AdTech-Anbietern, die die Funktion bereits nutzen.
Berichte	Anfordern von Drittanbieterberichten: Während DSPs und SSPs Impressionsbenachrichtigungen von Chrome erhalten, ist das bei technischen Anbietern der mittleren Schicht standardmäßig nicht der Fall.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier.

Geschützte Auktionsdienste

Feedbackthema	Zusammenfassung	Chrome-Antwort
TEEs	Die Anforderung von Google für ein manuelles Onboarding gemäß technischen Standards ist eine starke Einschränkung der Wahl des Cloud-Anbieters. Sie können die angewendeten technischen Standards befolgen, ohne das Bureau of Cloud Providers nachzuholen. Die späte Verzögerung von alternativen Anbietern 2025 (frühzeitig) ist inakzeptabel, da sie Netzwerkeffekte mit sich bringt, die die Trinkgelder für die Lösungen von Google fördern.	Der Aggregationsdienst ist der einzige Dienst, der in einem TEE-Dienst ausgeführt werden muss, um einige Anwendungsfälle für Anzeigentechnologien zu unterstützen. Der Aggregationsdienst unterstützt sowohl Amazon Web Services (AWS) als auch Google Cloud Platform (GCP). Basierend auf dem Feedback von Anbietern von Anzeigentechnologien sind wir der Meinung, dass dieser Support in dieser Phase ausreicht. Zusätzliche Cloud-Anbieter: Google hat detaillierte Kriterien für TEEs bei öffentlichen Cloud-Anbietern veröffentlicht. Damit soll sichergestellt werden, dass die TEE-Lösung die Datenschutz- und Sicherheitsziele der Privacy Sandbox erfüllt. Insbesondere werden auf den Privacy Sandbox TEE-Servern unverschlüsselte websiteübergreifende Nutzerdaten verarbeitet, z.B. Daten von Publisher- und Werbetreibendenwebsites für den Aggregationsdienst. Sie müssen sicher sein, um die Datenschutzziele der APIs zu erfüllen. Eine sichere Umgebung ist ebenfalls erforderlich, damit die APIs weiterhin die vertraulichen Geschäftsinformationen von Unternehmen schützen. So wird beispielsweise verhindert, dass andere Teilnehmer an PA API-Auktionen auf die proprietären Geschäftsdaten eines Käufers zugreifen. Unser Wissen ist derzeit nicht möglich, da es keine TEE-Technologie gibt, mit der Nutzerdaten vollständig vor potenziell bösartigen Betreibern geschützt werden. Daher haben wir mehrere Anforderungen festgelegt, um die Vertrauenswürdigkeit des Cloud-Anbieters zu überprüfen. Wir sind uns nicht sicher, worauf sich „Bureau of Cloud Providers“ bezieht, und es ist nicht Teil der Anforderungen. Wir freuen uns über Feedback zu den Anforderungen. Außerdem prüfen wir kontinuierlich, ob wir neue Anbieter unterstützen sollten. Dabei berücksichtigen wir auch Anfragen, die über den in der Erläuterung beschriebenen Prozess eingereicht wurden. Bisher haben wir nur eine Anfrage zur Unterstützung von Azure erhalten, die wir derzeit prüfen.
B&A	Es ist schwierig, die technische Komplexität und Machbarkeit des B&A-Dienstes zu beurteilen, da sich das Design ständig weiterentwickelt.	Um diese Bedenken auszuräumen, haben wir auf GitHub ausführliche Erläuterungen zum Design von B&A veröffentlicht, Zeitpläne zur Verfügbarkeit und eine Roadmap mit Funktionen, die die PA API unterstützen. Wir unterstützen Anbieter von Anzeigentechnologien, die B&A implementieren möchten, und sammeln Feedback von der Branche auf GitHub.
B&A	Ich suche nach einer Anleitung und einer besseren Möglichkeit, die Kosten für die Verwendung von TEE für B&A zu berechnen, um sie zu verwenden oder von der On-Device-Nutzung zu migrieren.	Vor Kurzem haben wir den Leitfaden zur Konfiguration von K/V-Serverinstanzen veröffentlicht, der Tools zur genaueren Kostenmessung enthält.
K/V-Server	Anzeigenprüfer, der die vollständige Seiten-URL an den K/V-Server für die Anzeigenüberprüfung anfordert.	Wir prüfen derzeit die Möglichkeit, die vollständige Seiten-URL für die Anzeigenüberprüfung an den K/V-Server weiterzuleiten, der in einem TEE ausgeführt wird. Die URL der gesamten Seite ist in K/V BYOS nicht verfügbar.
Auktionssicherheit	Wir sind auf der Suche nach Auktionssicherheitsfunktionen, um zu verhindern, dass böswillige Akteure auf sensible Daten zugreifen und nicht als Identitätsdiebstahl fungieren. Welche Funktionen schützen Auktionen vor Replay-Angriffen und wie können Sicherheitsvorkehrungen implementiert werden?	Das aktuelle Sicherheitsmodell von B&A kann die Auktionsintegrität schützen. B&A wird in einem TEE ausgeführt, um die Signale und den Code der Anzeigentechnologie vor böswilligen Akteuren zu schützen. In der B&A-Architektur fließt eine verschlüsselte B&A-Anfragenutzlast (Anfrageverschlüsselungstext) vom Client über einen nicht vertrauenswürdigen Ad-Server zum SellerFrontEnd-Dienst (SFE, der von SSPs in TEE ausgeführt wird). Der Geheimtext der Anfrage enthält eine zeitstempelbasierte Generierungs-ID. Der SFE prüft den Zeitstempel der Anfrage und lehnt alle wiederholten Anfragen ab, die nicht innerhalb von +/- n Sekunden zur Serverzeit liegen. Darüber hinaus kann B&A eine gepolsterte Antwortnutzlast mit fester Größe für die Server-zu-Server-Kommunikation zurückgeben. Diese Lösungen können dazu beitragen, Replay-Angriffe über das System zu minimieren, wenn ein böswilliger Akteur versucht, dieselbe Anfragen-Nutzlast noch einmal zu senden, um mehr über den Inhalt zu erfahren. B&A ist dabei, Sicherheitsmodelle in Erläuterungen zu dokumentieren und zu aktualisieren.
Signale über -K/V-Server	Anfrage, perBuyerSignals, die über den K/V-Dienst gesendet werden, in die Anfrage für vertrauenswürdige Gebotssignale aus Chrome aufzunehmen.	Wir prüfen derzeit, ob Informationen aus perBuyerSignals, die an einen K/V-Server in einem TEE übertragen werden, einschließlich der vollständigen Seiten-URL berücksichtigt werden können.
K/V-Server	Bitte um eine mehrphasige Einführungszeitleiste für Datenschutzeinschränkungen in K/V und B&A.	Wir verstehen den Wunsch nach einem mehrstufigen Ansatz bei der Einführung von TKV und schätzen Ihre spezifischen Anfragen zu K/V und B&A. Nach sorgfältiger Prüfung haben wir uns jedoch dazu entschieden, die Datenschutzmaßnahmen in diesen APIs vorerst nicht zu lockern. Wir sind der Ansicht, dass diese Maßnahmen wie Chaffing entscheidend sind, um die Privatsphäre der Nutzer zu schützen und das Vertrauen in die Privacy Sandbox aufrechtzuerhalten.
K/V-Server	Suche nach Anleitungen zum Skalieren des K/V-Speichers über eine kompatible Konfiguration.	Der kürzlich veröffentlichte Leitfaden zur Größenbemessung von K/V-Serverinstanzen kann Ihnen dabei helfen. Das Tool liefert die Abfragen pro Sekunde (in der Erläuterung als „RPS“ bezeichnet) für jede Kombination von Parametern.
K/V-Server	Fügen Sie Verkäuferinformationen zur K/V-Serveranfrage hinzu.	Wir diskutieren das Thema und freuen uns über zusätzliches Feedback in diesem Artikel.
K/V + B&A-Dienstleistungen	Bitte um Klärung des Zeitplans oder der Roadmap für die Veröffentlichung von K/V und B&A.	Sowohl für K/V- als auch für B&A-Auktionen gibt es Phasen und Zeitpläne: Für K/V-Server in Verbindung mit On-Device-PA API-Auktionen (im Vergleich zu B&A) ist die öffentliche Zeitachse hier verfügbar. Informationen dazu, wie „Allgemeine Verfügbarkeit“ für K/V definiert wird, finden Sie im Abschnitt zur Roadmap, in dem die Funktionen für Beta und GA definiert werden. Informationen zu B&A finden Sie in diesem Zeitplan und in dieser Roadmap. Wir definieren Skalierungstests als „vollständig stabile Tests im Produktionsmaßstab“. Hier finden Sie Informationen zu den Funktionen, die in dieser Phase verfügbar sind. B&A hat auch die Alpha- und Beta-Phasen, sodass die Skalierungstests die Obermenge von Funktionen früherer Phasen umfassen. Bitte teilen Sie uns sowohl für das K/V- als auch für das B&A-Team mit, ob diese Phasendefinitionen Klarheit darüber schaffen, was wann verfügbar sein wird. Wenn es noch Lücken gibt, lassen Sie es uns bitte wissen. Wir können diese Angaben gerne konkretisieren, um die Planung zu unterstützen.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Marktreaktion	Die Anforderung, dass konkurrierende Attributionssysteme nur Berichte auf Ereignisebene und zusammenfassende/zusammengefasste Berichte innerhalb enger Grenzen verwenden dürfen, ist eine willkürliche Einschränkung des Wettbewerbs. Dadurch werden gerätespezifisches Retargeting und Attribution auf Ereignisebene in Echtzeit verhindert, selbst wenn Absicherungen zur Einhaltung des Datenschutzes vorhanden sind (z.B. De-Identifikation).	Das erwähnte Design basiert auf den Datenschutzzielen der API, z.B. dem Schutz von websiteübergreifenden Informationen, die von einer Website an eine andere weitergegeben werden. ARA unterstützt beispielsweise die Attribution auf Ereignisebene über Ereignisberichte. Ereignisberichte werden mit einer Verzögerung von mindestens einer Stunde angezeigt. Dies ist erforderlich, um die Verknüpfung des Berichts auf Ereignisebene mit der Identität des Nutzers auf der Website des Werbetreibenden zu erschweren. Dazu werden wie hier beschrieben Side-Channel-Angriffe getrackt. Es gibt aber auch andere Möglichkeiten zur Attribution als die ARA. So können Sie beispielsweise direkt Informationen von Nutzern erheben, die wissentlich identifizierende Daten zur Verfügung stellen. Wir freuen uns über Feedback zu Anwendungsfällen, die mit den aktuellen Datenschutzgrenzen der Privacy Sandbox APIs nicht erreicht werden können.
Für verschiedene Oberflächen	Bestätigung anfordern, ob ARA- und Shared Storage APIs Anwendungsfälle für mehrere Oberflächen unterstützen und wo dies nachgewiesen wird.	Derzeit unterstützen ARA und Shared Storage keine mehrfachen Oberflächen (geräteübergreifend). Die geräteübergreifende Attribution zwischen Apps und Web (über ARA) wird unterstützt.
(Auch in vorherigen Quartalen erfasst) Geräteübergreifend	Unterstützt ARA geräteübergreifende Conversions?	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Die geräteübergreifende Nutzung stellt neben der 3-Parties-Kennzeichnung neue Herausforderungen in Bezug auf den Datenschutz dar. Außerdem gibt es aufgrund der Vielzahl von Geräten und Plattformen, die Nutzer verwenden können, Herausforderungen bei der Technologiebereitstellung. Wir prüfen derzeit mögliche Lösungen, konzentrieren uns aber auf die wichtigen Anwendungsfälle, die derzeit von ARA unterstützt werden. Wir haben derzeit keinen Zeitplan für die geräteübergreifende Unterstützung.
Skalierung	Bedenken dazu, ob die Attribution Report API (ARA) derzeit konfiguriert ist und zuverlässig eingeführt und für alle Chrome-Nutzer skaliert werden kann.	ARA ist derzeit für alle Chrome-Nutzer verfügbar und funktioniert wie erwartet. Außerdem testen und überwachen wir weiterhin die Zuverlässigkeit und Skalierbarkeit, da immer mehr AdTech-Unternehmen ARA testen. Wir freuen uns über zusätzliches Feedback zum Google-System. Hier können Sie es uns mitteilen.
(Auch in früheren Quartalen gemeldet) Deduplizierung	Bedenken hinsichtlich der vorgeschlagenen Beschränkung des Attributionsmechanismus auf Geräten, die es Publishern erschwert, die Logik nach der Attribution für Zusammenfassungsberichte effektiv anzuwenden, einschließlich der Deduplizierung mehrerer Conversions desselben Typs für denselben Anzeigenklick.	Unsere Antwort bleibt unverändert: Die Deduplizierung über Geräte und Messpipelines hinweg ist eine bekannte und aktuelle Herausforderung, der sich auch Werbetechnologien heute mit 3 PCs stellen müssen. Mit ARA können Anbieter von Anzeigentechnologien festlegen, wann bestimmte Conversions registriert werden sollen, und bestimmte Metadaten hinzufügen, um anzugeben, welche Analysepipelines sie zum Erfassen der Conversions verwendet haben (d.h. Teil des Aggregationsschlüssels), die mit anderen Analysepipelines verglichen werden können. Wir freuen uns über zusätzliches Feedback zum Google-System in diesem Artikel.
Conversion-Tracking	Funktion mit Conversions aus mehreren Domains	Wir besprechen diese Anfrage in diesem Artikel und freuen uns über zusätzliches Feedback zum Google Play-Ökosystem.
Berichte	Der Browser wartet mindestens zwei, aber bis zu 30 Tage, bevor die Conversion gesendet wird. Das kann ein Problem darstellen, da die meisten Stakeholder-Werbetreibenden Performance-Werbetreibende sind, die in nahezu Echtzeit arbeiten.	Die standardmäßigen Berichtszeitraume für Berichte auf Ereignisebene sind 2, 7 und 30 Tage. Mit flexiblen Berichten auf Ereignisebene können Anbieter von Anzeigentechnologien die Anzahl und Länge der Berichtszeitraume von den Standardwerten ändern. Berichtszeitraume können auf mindestens eine Stunde geändert werden. Das kann für Werbetreibende, die sich für die Leistung interessieren, hilfreich sein. Weiteres Feedback zu diesem Thema nehmen Sie gern auf dieser Seite entgegen.
Online-zu-Offline-Attribution	Gibt es in ARA Implementierungsoptionen für Online-zu-Offline-Werbung oder gibt es andere Vorschläge zur Messung der Offline-zu-Online-Attribution?	Derzeit ist keine Unterstützung für Anwendungsfälle mit Online-zu-Offline-Analysen in der ARA geplant. Bei dieser Art von Support müssen erhebliche Datenschutz- und Sicherheitsanforderungen berücksichtigt werden. Wir freuen uns über zusätzliches Feedback zum Ökosystem in Bezug auf Anwendungsfälle für diese Unterstützung. Hier können Sie uns Ihr Feedback mitteilen.
Debug-Berichte	Wie kann die AdID so gespeichert und/oder abgerufen werden, dass sie für Chrome-Registrierungen (Quelle/Trigger) für die App-zu-Web-Attribution verfügbar ist?	Damit die Debug-Berichte aktiviert werden können, muss die Anzeigentechnologie nachweisen, dass sie den Nutzer bereits über App und Web zusammenführen kann. So soll sichergestellt werden, dass die Debug-Berichte keine neuen Informationen enthalten. Der Anbieter von Anzeigentechnologien kann die Zusammenführung nachweisen, indem er einen eindeutigen Schlüssel pro Nutzer angibt. Dieser Join-Schlüssel kann die AdID oder ein selbst erhobener Join-Schlüssel sein. Wenn die Anzeigentechnologie die Anzeigen-ID verwendet, unterstützt Chrome den Zugriff auf die Anzeigen-ID nicht nativ über den Browser. Die API erwartet, dass jede Anzeigentechnologie eine eigene Methode zur Weitergabe der Anzeigen-ID während der Webregistrierung hat.
Bucket-Detaillierungsgrad	Ist es möglich, pro Werbetreibenden unterschiedliche Bucket-Strategien zu verwenden?	Wir empfehlen, verschiedene Ansätze zur Skalierung des Beitragsbudgets auszuprobieren, um den für Ihre Anwendungsfälle am besten geeigneten zu finden. ARA wurde entwickelt, um flexibel und anpassbar zu sein und eine Vielzahl von Anwendungsfällen für Anzeigentechnologien zu unterstützen. Daher empfehlen wir, mit verschiedenen Bucketing-Strategien pro Werbetreibendem oder Branche zu experimentieren. Die Verwendung verschiedener Bucketing-Strategien kann nützlich sein, wenn Werbetreibende unterschiedliche Messwerte haben, die sie verfolgen möchten, und das Volumen der Messwerte.
Dokumentation	Anfrage für zusätzliche Dokumentation zur Implementierung von App<>Web für ARA	Die Dokumentation zu App<> Web für ARA finden Sie hier.
Leistung	Die Anzahl der ARA-bezogenen Anfragen kann die Server eines Publishers im Vergleich zur Anzahl der keepalive-Anfragen, die für die Website erforderlich sind, stark belasten. Wenn Sie Quell-Ereignisse in einer einzelnen Anfrage zusammenfassen, lässt sich die Auslastung eines Servers reduzieren. Eine Möglichkeit besteht darin, ein Array von JSON-codierten Objekten	Mit JavaScript-Logik in Kombination mit der API ist es bis zu einem gewissen Grad möglich, Quell-Ereignisse basierend auf einer bestimmten Logik zu bündeln. Wir prüfen diesen Antrag derzeit und freuen uns über zusätzliches Feedback von der Community hier.
Feature Request (Funktionsanfrage)	Vorschlag für eine Problemumgehung, da keine Server-zu-Server-Integration unterstützt wird.	Derzeit planen wir nicht, eine Unterstützung für die Server-zu-Server-Integration in ARA zu implementieren. Es gibt viele Datenschutzherausforderungen, die weiter berücksichtigt werden müssen, um die Server-zu-Server-Integration zu unterstützen. Hier können Sie uns Feedback zu weiteren Anwendungsfällen für die Server-zu-Server-Unterstützung geben.
Dokumentation	Anfordern einer Kurzanleitung, in der die wichtigsten Teile von ARA und die Einrichtung mit einigen einfachen Anwendungsfällen erläutert werden.	Eine Kurzanleitung für ARA finden Sie hier. Wir arbeiten daran, diese Dokumentation im Laufe des Jahres weiter zu verbessern. Hier können Sie uns Feedback zu bestimmten Anwendungsfällen oder Szenarien geben, für die zusätzliche Dokumente erforderlich sind.
API-Verwendung	Empfehlung zur Skalierung von Beiträgen mit vielen kleinen Werten	Wir empfehlen, verschiedene Ansätze zur Skalierung des Beitragsbudgets auszuprobieren, um den für Ihre Anwendungsfälle am besten geeigneten zu finden. Für ein Szenario mit vielen kleinen Werten empfehlen wir, mit verschiedenen Epsilon-Werten zu experimentieren, um Wendepunkte zu ermitteln, an denen das Rauschen des Epsilons für Ihren Anwendungsfall akzeptabel ist. Weitere Informationen finden Sie in unserem Forschungspapier zur Optimierung von Zusammenfassungsberichten in ARA.
Flexible Ereignisebene	Wann wird die flexible Ereignisebene (mehrere Triggerspezifikationen) implementiert?	Derzeit werden auf flexibler Ereignisebene die folgenden Aspekte der Registrierungskonfiguration unterstützt: die Anzahl der Berichte, die pro Quelle generiert werden können, die Anzahl und Länge der Berichtszeiträume sowie die Kardinalität der Triggerdaten. Wir sammeln derzeit zusätzliches Feedback zum System hinsichtlich flexibler Verbesserungen auf Ereignisebene, planen aber derzeit keine Implementierung. Wir freuen uns über zusätzliches Feedback zu Anwendungsfällen, die von einigen der hier aufgeführten flexiblen Verbesserungen auf Ereignisebene profitieren könnten.
Bucket-Verarbeitung	Anfrage zur Begrenzung aggregierter Beiträge für Buckets sowie zur künftigen Erweiterbarkeit und Abwärtskompatibilität.	Wir besprechen diese Anfrage und würden uns über zusätzliches Feedback hier freuen.
Epsilon	Was passiert mit dem Epsilon-Bereich, wenn ARA allgemein verfügbar wird?	ARA wurde im 3. Quartal 2023 allgemein in Chrome eingeführt. Derzeit sind keine Änderungen am Zeitraum für den Epsilonwert geplant. Unser Vorschlag für eine überarbeitete Governance-Struktur würde zusätzliche Sicherheit bieten, falls Änderungen vorgesehen sind.
Berichte	Berichte zu unbekannten Auslösern von Fehlern enthalten keine Quellattribute im Berichtskörper.	Wie in der Spezifikation beschrieben, müssen im Berichtstext für trigger-unknown-error keine anderen Felder vorhanden sein. Wir sind uns bewusst, dass die Tabelle mit den Beschreibungen der Felder im Berichtstext möglicherweise irreführend war, da die quellenbezogenen Felder je nach zugrunde liegender Ursache des Fehlers vorhanden sein können oder nicht. Beispielsweise kann ein interner Fehler vor der Logik für den Abgleich der Quelle auftreten. Das bedeutet, dass keine Quelldaten zum Ausfüllen des Debug-Berichts verfügbar sind. Die Dokumentation wurde jetzt aktualisiert, um dies zu verdeutlichen.
API-Verwendung	Wenn Sie mit zwei Analysezielen arbeiten, also „Anzahl“ und „Wert“, sollten Sie sowohl das Beitragsbudget als auch das Epsilon aufteilen?	Wenn Sie zwei Analyseziele verwenden, empfehlen wir, das Beitragsbudget aufzuteilen.
Berichte	Unterstützt ARA die Multi-Touch-Attribution oder Berichte zur Beitragsleistung?	ARA unterstützt derzeit keine Multi-Touchpoint-Attribution und keine Unterstützungsberichte. Derzeit ist dies nicht geplant. Wir freuen uns über zusätzliches Feedback zu Anwendungsfällen und ihrer Priorität hier.
API-Fehler	In der Dokumentation für ARA wird angegeben, dass XOR verwendet wird, um Schlüsselelemente der Quell- und Triggeraggregation zu kombinieren. In der Praxis wird jedoch OR verwendet. Diese Abweichungen können zu Verwirrung und Fehlern bei der Implementierung führen.	Die Dokumentation wurde aktualisiert, um anzugeben, dass es sich hierbei um einen Fehler handelt.

Zusammenfassungsdienst

Feedbackthema	Zusammenfassung	Chrome-Antwort
Aggregationsjobs	Mehrere Präfixe in Aggregationsjobs zulassen	Wir prüfen dieses Feedback und haben hier einen Vorschlag veröffentlicht. Hier können Sie uns Feedback zum Vorschlag geben.
Feature Request (Funktionsanfrage)	Änderung des Terraform-Scripts so, dass die Änderung der IAM-Richtlinie des Kontos übersprungen wird, wenn „service_account_token_creator_list“ nicht festgelegt ist (oder leer ist).	Wir untersuchen das Problem hier und würden uns über zusätzliches Feedback freuen.
API-Verwendung	Eine Klärung des Terraform-Plans, in dem immer Änderungen angezeigt werden, ist erforderlich.	Dieses Problem wurde in der AgS 2.8-Version behoben.
API-Verwendung	Ich suche nach Empfehlungen für die Einrichtung von Einstellungen für die Aggregationshäufigkeit pro Werbetreibendem mit flexibler Beitragsfilterung.	Mit ARA ist die Batchverarbeitung nach Werbetreibendem derzeit möglich. Die flexible Beitragsfilterung kann in komplexeren Fällen verwendet werden, in denen ein Anbieter von Anzeigentechnologien die Beiträge eines Berichts nach verschiedenen Häufigkeiten weiter segmentieren möchte. Weitere Informationen zu Batch-Aufträgen finden Sie hier und zur Verwendung von Filter-IDs mit ARA hier. Außerdem arbeiten wir an weiteren Informationen zum Filtern von IDs.
Feature Request (Funktionsanfrage)	Fordern Sie Unterstützung für „log_sum_exp“ im Aggregationsdienst (AgS) an.	Wir haben diesen Stakeholder um weitere Informationen zum Anwendungsfall gebeten. Wir melden uns bei dir, sobald wir weitere Informationen haben.
Feature Request (Funktionsanfrage)	Wir möchten mehr Protokolle, Statistiken und andere Messwerte sehen, wenn Probleme mit der Anzeigenplattform und potenzielle Probleme mit einer bereitgestellten Anzeigenplattform auftreten.	Wir haben unsere Dokumentation aktualisiert und weitere Fehler, Abhilfemaßnahmen und Beschreibungen hinzugefügt. Hier finden Sie die entsprechenden Informationen. Wir freuen uns über zusätzliches Feedback zu Fehlern, Messwerten, Logs usw., die nicht dokumentiert oder verfügbar sind und welche Details hilfreich wären.
API-Tests	Welchen Endwert wird das Epsilon nach der Testphase haben?	Derzeit sind keine Änderungen am Zeitraum für den Epsilonwert geplant. Wir empfehlen Testern, mit verschiedenen Parametern zu experimentieren und Feedback zu geben.
Berichte	Der Bericht wird generiert, aber im Rückgabecode wird immer noch PRIVACY_BUDGET_AUTHORIZATION_ERROR angezeigt.	Um diesen Fehler zu vermeiden, haben wir Hinweise zur Angabe des richtigen Ursprungs und der zusammengefassten Berichte zusammengestellt. Wir freuen uns über zusätzliches Feedback zum Problem, insbesondere wenn es sich um wiederkehrende Fehler handelt.
Key Discovery	Wie sieht der Vorschlag für die Schlüsselerkennung aus?	Wir haben noch keinen Zeitplan für die Einführung des Vorschlags zur Schlüsselerkennung, aber wir fordern hier Feedback von der Community dazu ein.
Anpassung	Ich suche nach Anpassungsoptionen für den Aggregationsdienst.	Anpassungen des Aggregationsdienstes sind innerhalb des TEE nicht möglich, aber für einige Komponenten außerhalb des TEE. Dies liegt an den Datenschutz- und Sicherheitsstandards, die wir innerhalb des TEE einhalten müssen. Wir arbeiten daran, unsere Dokumentation zu aktualisieren, damit Werbefachleute die Architektur besser verstehen und sehen, welche Komponenten anpassbar sind. Bestimmte Anpassungen können nicht unterstützt werden. Daher empfehlen wir Anzeigentechnologien, nach Möglichkeit unsere Standardkonfigurationen zu verwenden.
Spot- und On-Demand-Instanzen im Vergleich	Wurde das System mit Spot-Instanzen und On-Demand-Instanzen getestet? Gibt es neben der potenziellen vorübergehenden Nichtverfügbarkeit noch weitere Nachteile bei der Verwendung von Spot-Instanzen?	Wir haben keine Priorität auf Tests mit Spot-Instanzen gelegt, da wir Anbietern von Anzeigentechnologien die Verwendung von On-Demand-Instanzen empfehlen. Der Nachteil von Spot-Instanzen besteht darin, dass der Job bei Verbrauch des Budgets unterbrochen wird. Wenn das Budget aufgebraucht ist und der Job unterbrochen wird, bevor die Anzeigentechnologie den Zusammenfassungsbericht erhält, können die Anzeigentechnologien den Job nicht einfach noch einmal ausführen, sondern müssen eine Budgetwiederherstellung beantragen. Die Budgetwiederherstellung wird nur bei schwerwiegenden Fehlern empfohlen, um die Privatsphäre zu schützen. Wir empfehlen Anbietern von Anzeigentechnologien, Autoscaling zu konfigurieren, um die Kosten zu minimieren. Wenn Sie für das Autoscaling „0“ auswählen, werden keine Instanzen ausgeführt, bis ein Job angefordert wird. Beachten Sie, dass dies die Latenz erhöhen kann, da Instanzen zum Zeitpunkt der Anfrage hochgefahren werden.
Bekannte Fehler und Lösungen	Klärung erforderlich: Job für Aggregationsdienst zeigt „Dienstfehler“ an	Hier finden Sie weitere Informationen zu diesem Problem. Wir haben auch einige unserer Fehlermeldungen aktualisiert, um sie aussagekräftiger zu gestalten. Beispielsweise geben wir jetzt genauere Berechtigungs-/Authentifizierungsfehler bei AWS aus, während diese Fehler zuvor als interne Fehler angezeigt wurden. Wir haben die Dokumentation zu Fehlercodes und Maßnahmen zur Fehlerbehebung aktualisiert. Wir freuen uns über zusätzliches Feedback zu Fehlern, die nicht dokumentiert oder verfügbar sind, und dazu, welche Details hilfreich wären. Bitte senden Sie uns dazu eine Nachricht.

Private Aggregation API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Key Design	Leitfaden für die Schlüsselentwicklung für die Private Aggregation anfordern	Wir haben zwar keinen speziellen Leitfaden für die private Aggregation, aber sowohl das Aggregation Service Load Testing Framework als auch der Leitfaden zur erweiterten Schlüsselverwaltung können als Ressourcen verwendet werden.
Beitragsbudget	Auf welcher Ebene wird das Beitragsbudget berechnet und begrenzt?	Das Beitragsbudget beträgt 2^16 in einem rollierenden 10-Minuten-Fenster und 2^20 in einem rollierenden 24-Stunden-Fenster.

Verdecktes Tracking einschränken

Reduzierung des User-Agents/Client-Hints für User-Agent

In diesem Quartal gibt es kein Feedback.

IP-Schutz (früher Gnatcatcher)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Android	Wie ist der Plan für die Einführung des IP-Schutzes für Android?	Wir arbeiten an der Einführung von Anti-verdeckten Tracking-Funktionen in Android, einschließlich IP-Schutz, haben aktuell aber keine konkreten Pläne.
API-Verwendung	Gibt es oder wird es eine Betrugsausnahme für den IP-Schutz geben?	Wir bemühen uns, ein Gleichgewicht zwischen dem Schutz der Nutzer vor dem Tracking im Web anhand ihrer IP-Adressen und der Minimierung von Unterbrechungen des normalen Betriebs von Servern zu finden, einschließlich der Verwendung von IP-Adressen zum Schutz vor Missbrauch. Leider können wir derzeit noch keine weiteren Details nennen. Wir hoffen aber, sie in Kürze bekannt geben zu können.
Identifizierung schädlicher Schauspieler	Bedenken hinsichtlich der Effektivität herkömmlicher Sicherheitsmaßnahmen gegen schädliche IP-Adressen	Der IP-Schutz stellt keinen Proxy für Anfragen von Erstanbietern bereit. Daher gehen wir davon aus, dass die meisten Intrusion Detection Systems (IDS) nicht betroffen sind. Wir planen, in Zukunft weitere Details zu den Maßnahmen zur Betrugsprävention und zu Problemen mit der Websitezugänglichkeit für Nutzer im Inkognitomodus zu veröffentlichen.
Maskierung von IP-Adressen	Wird die IP-Adresse für beide Websites maskiert, wenn die Website des Nachrichtenanbieters (1. Partei) dieselbe Domain wie die Werbewebsite (3. Partei) verwendet? Wenn nicht, wie lassen sich die beiden Unterschiede voneinander unterscheiden?	Der IP-Schutz schlägt derzeit einen listenbasierten Ansatz vor, um zu ermitteln, welcher Drittanbieter-Traffic über die Proxys fließt. Auch wenn ein Ursprung auf dieser Liste steht, wird er nicht über einen Proxy angesteuert, wenn der Zugriff im Kontext von selbst erhobenen Daten erfolgt. Wir arbeiten derzeit an den Details dazu, welche Drittanbieterdomains anfangs priorisiert werden und wie wir Kontexte von selbst erhobenen Daten und von Drittanbietern für den IP-Schutz präzise definieren werden.
Maskierung von IP-Adressen	Bedenken hinsichtlich des IP-Schutzes und dessen Auswirkungen auf Betrugsbekämpfungssysteme	1Ps sind von unseren Plänen zum Schutz geistigen Eigentums nicht betroffen. Websites wie Foren sollten daher zur Beilegung von Streitigkeiten Zugriff auf IP-Adressen haben. Wir planen, in Zukunft weitere Details zu den Bedenken hinsichtlich Werbebetrugs zu veröffentlichen.
Maskierung von IP-Adressen	Ist die IP-Adresse in den Headern der betroffenen Domains maskiert?	Die Nutzer werden anhand ihrer Pre-Proxy-IP-Adresse, die ihren aktuellen Standort darstellt, einem geografischen Gebiet zugewiesen. Weitere Informationen

Eindämmung von Bounce-Tracking

Feedbackthema	Zusammenfassung	Chrome-Antwort
API-Spezifikation	Es ist eine Klarstellung erforderlich, wie Chrome die erweiterte Navigation behandelt, wenn ein Tab geschlossen wird.	Wir haben dieses Problem behoben und die Spezifikation entsprechend aktualisiert.
Nav-Tracking	Diskussion eines Ansatzes zur Minimierung von Tracking mit einer endlichen Anzahl von Links zur Reduzierung der Entropie bei websiteübergreifenden Anfragen.	Wir diskutieren dieses Thema hier weiter mit anderen Browseranbietern und freuen uns über zusätzliches Feedback und konkrete Vorschläge zu diesem Thema aus der Branche.

Datenschutzbudget

Wie in der GitHub-Erläuterung und auf der Entwicklerwebsite erwähnt, wird Privacy Budget nicht mehr aktiv
als Teil der Privacy Sandbox-Vorschläge betrachtet.

Websiteübergreifende Datenschutzgrenzen stärken

Gruppen ähnlicher Websites (früher „First-Party-Sets“)

Feedbackthema	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen gemeldet) Domainlimit für Gruppen ähnlicher Websites	Anfrage zur Erhöhung des Limits für verknüpfte Domains innerhalb von RWS	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir gehen derzeit nicht davon aus, dass die maximale Anzahl erhöht wird. Das Limit wurde auf der Grundlage von Datenschutzüberlegungen für Nutzer, Feedback von Stakeholdern des W3C-Systems und vergleichbaren Implementierungen in anderen Browsern festgelegt. Weitere Informationen finden Sie in unseren Blogposts 1 und 2. Wir empfehlen, Anwendungsfälle zu untersuchen, in denen ein websiteübergreifender Cookie-Zugriff über die numerische Beschränkung hinaus erforderlich ist, und unsere Informationen zu Anwendungsfällen für Identität, authentifizierter Einbettungen und Anwendungsfällen in der Werbung zu nutzen. Wenn die Nutzersitzungen an Anmeldeaktionen gebunden sind, empfehlen wir die Verwendung der FedCM API (Federated Credential Management), um die Funktionalität beizubehalten. Wir freuen uns über Feedback zu anderen Anwendungsfällen, die möglicherweise erforderlich sind. Hier können Sie uns Ihr Feedback mitteilen.
Websiteübergreifende Cookie-Verarbeitung	Von einer Subdomain festgelegte websiteübergreifende Cookies werden in nachfolgenden Anfragen von der Hauptdomain nicht übergeben. Das Problem tritt auch bei korrekten CORS- und Anmeldedatenkonfigurationen auf.	Hier finden Sie Informationen zur korrekten Verwendung der requestStorageAccessFor API. Dabei muss der vollständige Ursprung (d. h. Subdomains) angegeben werden, damit websiteübergreifende Cookies bei nachfolgenden Abrufanfragen gesendet werden können.
Nutzerauswahl	Anfrage nach weiteren Informationen zu „requestStorageAccessFor“, die von RWS nach der Einführung der Nutzerauswahl verwendet wird, insbesondere dazu, wie die implizite oder explizite Nutzergeste, die derzeit den Zugriff auf Drittanbieter-Apps ermöglicht, im neuen System funktioniert.	Wir gehen davon aus, dass das Verhalten von RWS in beiden Modi (d.h. unabhängig davon, ob die Nutzer sich für das Beibehalten oder das Einschränken ihrer Drittanbieter-Cookies entschieden haben) mit dem vorhandenen Verhalten bzw. Versandverhalten in Chrome übereinstimmt, wenn Drittanbieter-Cookies zugelassen sind, im Vergleich zu Drittanbieter-PCs, die mit aktiviertem RWS blockiert sind (Einstellung „Ähnliche Websites dürfen Ihre Aktivitäten in der Gruppe sehen“). Wir empfehlen, zuerst hasStorageAccess aufzurufen, um zu prüfen, ob das eingebettete Element bereits Zugriff auf nicht partitionierte websiteübergreifende Cookies hat, bevor du requestStorageAccess aufrufst. Die Methode hasStorageAccess gibt „true“ zurück, wenn der Nutzer 3PCs zulässt. „requestStorageAccessFor“ erfordert derzeit keine Nutzergeste, wenn 3PCs zulässig sind. Wir haben ein neues GitHub-Problem erstellt, um zu diskutieren und festzulegen, wie das Verhalten in diesem Fall sein sollte. Wir freuen uns über zusätzliches Feedback aus der Community.
API-Verwendung	Bedenken hinsichtlich der Unklarheit bei der Verwendung von RWS für „kommerzielle“ Zwecke, was ihre Akzeptanz erschwert. Der Stakeholder hat Interesse an der Gruppierung von Publikationen für zielgerichtete Werbung bekundet.	RWS sollen die Hauptfunktionen der Website und die wichtigsten User Journeys unterstützen. Wir empfehlen die Verwendung unserer speziellen Werbe-APIs für Anwendungsfälle im Zusammenhang mit zielgerichteter Werbung.
API-Verwendung	Es wurde ein Problem mit requestStorageAccess gemeldet, bei dem localStorage-Daten, aber keine Cookies festgelegt werden konnten.	Das Problem wurde durch einen Tippfehler im SameSite-Attribut verursacht. Achten Sie auf die korrekte Schreibweise und setzen Sie sie für Drittanbieter-Cookies ausdrücklich auf „Keine“.
API-Spezifikation	Diskrepanzen in den JSON-Schemas im Repository, z. B. eine falsche Platzierung des Felds „contact“ und Verbesserungsvorschläge, einschließlich der Verwendung des Suchbegriffs „oneOf“ zur Gewährleistung der Konsistenz	Wir prüfen dieses Feedback und werden in naher Zukunft prüfen, ob wir diese Verbesserungen am Schema vornehmen können. Du kannst uns gern hier zusätzliches Feedback geben.
Zugriff von Drittanbietern auf RWS	Mit der Einwilligung des Nutzers darf ein Anbieter die Drittanbieterdomains angeben, die ebenfalls auf die RWS API-Daten zugreifen dürfen.	Wenn Sie Drittanbietern erlauben, ihre eigenen nicht partitionierten Daten mit RWS-Websitedaten zu kombinieren, würde dies den Schutz der Privacy Sandbox für websiteübergreifendes Tracking beeinträchtigen. Wir prüfen jedoch die Möglichkeit, Drittanbietern die Verwaltung von Daten zu ermöglichen, die in einer RWS partitioniert sind. Hier können Sie uns Feedback zum Design einer solchen Lösung geben.

Fenced Frames API

Feedbackthema	Zusammenfassung	Chrome-Antwort
API-Frage	Bedenken, dass Fenced Frames ohne Netzwerkzugriff die Markensicherheit und den Betrugsschutz für Werbetreibende beeinträchtigen könnten.	Wir verfolgen dieses Problem im Rahmen unseres Plans zur Durchsetzung von abgegrenzten Frames. Wir werden uns bald Lösungen ansehen, die mit der Durchsetzung von abgegrenzten Frames kompatibel sind. Sobald es ausreichend ausgearbeitete Vorschläge gibt, teilen wir sie mit.
API-Frage	Ist die Fenced Frames API weiterhin für 2026 geplant?	Wie in unserer öffentlichen Ankündigung angegeben, sind abgegrenzte Frames frühestens ab 2026 erforderlich.
API-Fehler	Wenn reportEvent() Klickdaten aus einem plattformübergreifenden Unterframe erfolgreich sendet, überschreibt setReportEventDataForAutomaticBeacons() die Daten des übergeordneten Frames nicht.	Wir besprechen dieses Problem und würden uns über zusätzliches Feedback hier freuen.

Shared Storage API

Feedbackthema	Zusammenfassung	Chrome-Antwort
App-Werbung	In der Privacy Sandbox für Android gibt es kein Äquivalent zur Shared Storage API.	Wir bewerten Lösungen für Android basierend auf den Anforderungen des Anwendungsfalls und den Plattformeinschränkungen. Aktuell gibt es keine Pläne dazu, wir würden uns aber sehr über zusätzliches Feedback von der Community zu diesem Thema freuen.
API-Verwendung	Verwirrung bezüglich der Notwendigkeit eines zusätzlichen JavaScript-Worklets für die Implementierung der Shared Storage API.	Wir prüfen dieses Feedback und überlegen, unsere Dokumentation zu aktualisieren, um die Notwendigkeit zusätzlicher Worklet-Scripts für die Share Storage API zu erläutern.
Unzuverlässig	Die Shared Storage API könnte sich aufgrund der Kritik am Datenschutz erheblich ändern oder eingestellt werden. Sie ist daher keine zuverlässige Grundlage.	Wir haben keine Pläne, die Infrastruktur für freigegebenen Speicherplatz wesentlich zu ändern oder einzustellen. Die wichtigsten angekündigten Änderungen betreffen das Ausgabe-Gatter „Select URL“ (URL auswählen), für das eingekapselte Frames erforderlich sind und Berichte auf Ereignisebene eingestellt werden. Diese Änderungen treten jedoch erst mindestens 2026 in Kraft.

CHIPS

Feedbackthema	Zusammenfassung	Chrome-Antwort
Partitionierte Cookies	Chrome unterscheidet Partitionsschlüssel nicht basierend auf Frame-Ancestors, was im Gegensatz zu Firefox zu Inkonsistenzen führt.	Chrome hat das „Vorgänger-Ketten-Bit“ übernommen, um das Sicherheitsproblem und die Abweichung vom Verhalten von Firefox zu beheben. Weitere Informationen dazu finden Sie hier.
Partitionierte Cookies	Eingebettete Iframes mit unterschiedlichen Zugriffsebenen auf den Speicher teilen und überschreiben dasselbe partitionierte Cookie, was zu Inkonsistenzen bei den Authentifizierungsstatus führt.	Für diese spezielle Konfiguration empfehlen wir, nicht partitionierte Cookies mit einem Aufruf der Storage Access API zu verwenden. Weitere Informationen dazu finden Sie hier.
Partitionierte Cookies	Werden partitionierte Cookie-Jars gelöscht, wenn Drittanbieter-Cookies deaktiviert werden? Gibt es eine Möglichkeit, dieses Verhalten zu testen?	Aktuell gibt es keine konkreten Pläne dazu. Entwickler können diese Funktion jedoch testen, indem sie partitionierte Cookies manuell über das Chrome DevTools-Steuerfeld „Anwendung“ > „Cookies“ löschen.

FedCM

Feedbackthema	Zusammenfassung	Chrome-Antwort
Registrierungsbereich und Auswahl der Organisation für Identitätsanbieter (IdP)	Frage zur Erweiterung der IdP-Registrierung von der aktuellen Richtlinie für denselben Ursprung auf eine Richtlinie für dieselbe Website. Durch diese Änderung wird eine umfassendere und flexiblere Identitätsverwaltung ermöglicht. So können beispielsweise auf der Begrüßungsseite einer Universität mehrere Subdomain-basierte Identitätsanbieter registriert werden, ohne dass separate ursprungsspezifische Registrierungen erforderlich sind. Feedback zur Verbesserung der Fehlerbehebung, zum Umgang mit genehmigten Kunden für die stille Vermittlung, zur Klärung des Cookie-Verhaltens, zur Anpassung des Pop-up-Texts und zur Behebung von Zeitüberschreitungsproblemen.	Wir haben Ihr Feedback zur Kenntnis genommen und überlegen, wie eine Auswahlmöglichkeit für Organisationen in FedCM integriert werden könnte. Wir freuen uns über zusätzliches Feedback aus der Community, damit wir diesen Ansatz weiter optimieren können.
IdP-Cookies	Diskussion über die Auswirkungen der Implementierung kurzlebiger Sitzungscookies im Rahmen des Vorschlags für gerätegebundene Sitzungsanmeldedaten. Es gibt Bedenken hinsichtlich der Nutzerfreundlichkeit in FedCM, da abgelaufene IdP-Cookies ein für Nutzer sichtbares Modalfenster für die Verlängerung erfordern.	Die vorgeschlagene DBSC sollte die Cookie-Verlängerung ohne Nutzerinteraktion ermöglichen, um eine kontinuierliche Nutzererfahrung zu gewährleisten. Weitere Informationen zu diesem Thema
API-Spezifikation	Frage zur Eignung der Verwendung von „NetworkError“ in der FedCM API-Spezifikation, wenn die Größe des „providers“-Arrays nicht 1 entspricht.	Wir sind der Meinung, dass „TypeError“ für diese Situation besser geeignet wäre, da es sich um einen Programmierfehler und nicht um ein Netzwerkproblem handelt. Wir werden diese Änderung prüfen und die Möglichkeit untersuchen, diese Einschränkung in zukünftigen Updates aufzuheben, wenn wir den Support für mehrere Identitätsanbieter weiter vorantreiben. Du kannst uns gern hier zusätzliches Feedback geben.

Spam und Betrug bekämpfen

Private State Token API (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Test zur Einstellung und Modus B	Bedenken hinsichtlich des Einstellungstests, Modus-B-Tests, der möglichen Einstellung von Private State Tokens (PSTs) und der Möglichkeit einer neuen API, die besser für den Anwendungsfall zum Schutz vor Betrug geeignet ist.	Der Test zur Einstellung und Modus-B-Tests bleiben unverändert. Wir informieren Sie über alle Updates im Dev-Blog. Es ist nicht geplant, PST-Dateien einzustellen. Wir besprechen die fortlaufende Entwicklung von Funktionen und Updates auf GitHub. Wir haben keine neuen APIs angekündigt, freuen uns aber über Feedback, wie PST-Dateien die Betrugsbekämpfung besser verhindern können.
API-Feedback	Anfrage zur Möglichkeit, Tokens zu widerrufen, um einen Anwendungsfall zur Betrugsprävention zu beheben.	Der Aussteller kann zwar alle Tokens widerrufen, indem er die verwendeten Schlüssel ändert, aber der Widerruf einzelner Tokens ist mit der API nicht möglich. Dazu müsste der Aussteller die Tokenausgabe und -einlösung verknüpfen können, was das Datenschutzmodell von PST verletzt, das das Tracking zwischen den beiden Ereignissen verhindert.