Feedbackbericht – 1. Quartal 2025

Quartalsbericht für das 1. Quartal 2025 mit einer Zusammenfassung des Feedbacks aus dem Ökosystem zu den Privacy Sandbox-Vorschlägen und der Reaktion von Chrome.

Google hat diesen vierteljährlichen Bericht im Rahmen seiner Verpflichtungen gegenüber der Wettbewerbs- und Marktaufsichtsbehörde (Competition and Markets Authority, CMA) gemäß Paragraf 12, Paragraf 17(c)(ii) und Paragraf 32(a) erstellt. Dieser Bericht enthält Informationen zu den Fortschritten von Google bei den Privacy Sandbox-Vorschlägen, aktualisierte Zeitpläne, ausführliche Erläuterungen dazu, wie Google die Beobachtungen von Drittanbietern berücksichtigt hat, sowie eine Zusammenfassung der Interaktionen zwischen Google und der CMA, einschließlich Feedback von der CMA und der Herangehensweise von Google an die Bearbeitung des Feedbacks.

Google hält die CMA in ihren regelmäßigen Statusbesprechungen, die gemäß Paragraf 17(b) der Verpflichtungen angesetzt sind, über den Fortschritt bei den Privacy Sandbox-Vorschlägen auf dem Laufenden. Außerdem verwaltet das Team die Entwicklerdokumentation, die einen Überblick über die wichtigsten Funktionen für personalisierte Werbung und Änderungen an Cookies sowie Informationen zur API-Implementierung und zum Status bietet. Wichtige Neuigkeiten werden im Entwicklerblog veröffentlicht. Außerdem erhalten Entwickler über ihre jeweiligen Mailinglisten gezielte Updates.

Glossar mit Akronymen

ARA
Attribution Reporting API
CHIPS
Cookies mit unabhängigem partitioniertem Status
DSP
Demand-Side-Plattform
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Identitätsanbieter
IETF
Internet Engineering Task Force
IP-Adresse
Internet Protocol-Adresse
openRTB
Echtzeitgebote
NSZ
Origin-Testversion
PA API
Protected Audience API (früher FLEDGE)
PatCG
Private Advertising Technology Community Group
RP
Vertrauende Partei
RWS
Gruppen ähnlicher Websites (früher „First-Party-Sets“)
SSP
Supply-Side-Plattform
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
Nutzerauswahl Es ist unklar, wie der aktualisierte Ansatz von Google zur Verbesserung der Nutzerauswahl aussehen wird, wie er den Nutzern präsentiert wird und wie hoch die erwarteten Aktivierungs-/Deaktivierungsraten sein werden. Weitere Informationen sind erforderlich, um dies von der Einstellung von Drittanbieter-Cookies zu unterscheiden. Im April 2025 veröffentlichte Google einen Blogpost zu den Nächste Schritte für die Privacy Sandbox und den Schutz vor Tracking in Chrome. Darin gab das Unternehmen bekannt, dass es bei der aktuellen Vorgehensweise bleiben wird, Nutzern Drittanbieter-Cookies in Chrome anzubieten, und keine neue eigenständige Aufforderung für Drittanbieter-Cookies einführen wird.
Wir halten Sie auf dem Laufenden.
Fingerabdruck Google hat Verlagen und Webpublishern oder Werbetreibenden keine Informationen dazu mitgeteilt, wie sie Alternativen zu den Werbesystemen von Google nutzen können, ohne eine riskantere Nutzeridentität als gemeinsamen Abgleichsschlüssel (z. B. Fingerprinting) zu verwenden. Wir haben mehrere Anzeigensysteme von Drittanbietern hervorgehoben, die Lösungen für Publisher und Werbetreibende anbieten, die teilweise auf Privacy Sandbox-APIs basieren. Dazu gehören auch Werbesysteme von Drittanbietern in verschiedenen Märkten und Kanälen. Weitere Informationen und Fallstudien finden Sie im Abschnitt „Business Resources“ (Unternehmensressourcen) von privacysandbox.com unter diesem Link.
Privacy Sandbox Mit den Privacy Sandbox-APIs würden Internetdaten durch fertige Produkte von Google ersetzt. Da die Alternative von Google eine API ist, bietet Google Zugriff auf ein Produkt, das Google gehört und das Google verwaltet. Dieses Produkt unterliegt Nutzungsbedingungen, die Google nach eigenem Ermessen festlegen kann. Das ist kein Ersatz für Komponenten, die von anderen zur Herstellung eigener Endprodukte verwendet werden. Die Privacy Sandbox APIs wurden in enger Zusammenarbeit mit Regulierungsbehörden und einer Vielzahl von Stakeholdern im Ökosystem entwickelt und implementiert. Wie bei anderen Plattformtechnologien müssen bei Privacy Sandbox-APIs berücksichtigt werden, dass sie als Komponenten in den Endprodukten anderer verwendet werden. Wir begrüßen Bemühungen des Werbesystems, zusätzliche Technologien zu entwickeln, die mit den Privacy Sandbox-APIs zusammenarbeiten.
Nutzerauswahl Anfrage, ob der aktualisierte Ansatz von Google für Drittanbieter-Cookies in Chrome bestimmte rechtliche Anforderungen erfüllt, die sich auf die Nutzerfreundlichkeit der Plattform zur Einwilligungsverwaltung auswirken können. Im April 2025 veröffentlichte Google einen Blogpost zu den Nächste Schritte für die Privacy Sandbox und den Schutz vor Tracking in Chrome. Darin gab das Unternehmen bekannt, dass es bei der aktuellen Vorgehensweise bleiben wird, Nutzern Drittanbieter-Cookies in Chrome anzubieten, und keine neue eigenständige Aufforderung für Drittanbieter-Cookies einführen wird.
Wir halten Sie auf dem Laufenden.
Zeitplan und Einführung der Privacy Sandbox Anbieter von Anzeigentechnologien haben die Tests der Privacy Sandbox API pausiert und suchen nach überzeugenderen Gründen, um in diese Technologien für Produkt- und Marketingaktivitäten zu investieren. Ihre Entscheidungen zur Weiterinvestition werden stark von der Notwendigkeit beeinflusst, mehr Klarheit über den Zeitplan für die Nutzerauswahl zu erhalten, sowie von Bedenken hinsichtlich der Latenz der Protected Audience API (PA API) und der B&A-Roadmap. Außerdem gibt es Bedenken hinsichtlich der bevorstehenden Überprüfung der Verpflichtungen der CMA, insbesondere in Bezug auf die Rolle von Google als Hauptinitiator der Privacy Sandbox-Technologien ohne Drittanbieter-IDs und die allgemeine zukünftige Ausrichtung der Initiative, um Investitionsstrategien zu informieren. Im April 2025 veröffentlichte Google einen Blogpost zu den Nächste Schritte für die Privacy Sandbox und den Schutz vor Tracking in Chrome. Darin wurde angekündigt, dass Google den aktuellen Ansatz beibehalten wird, Nutzern Drittanbieter-Cookies in Chrome anzubieten, und dass keine neue eigenständige Aufforderung für Drittanbieter-Cookies eingeführt wird. Wir halten Sie auf dem Laufenden.

Chrome PA API-Auktionen sind im Jahresvergleich um 35% schneller. Außerdem haben wir eine deutliche Zunahme der parallelen Auktionen verzeichnet, was zu noch besseren Ergebnissen führt.

Unsere aktuelle B&A-Roadmap finden Sie hier.
Zeitplan für die Privacy Sandbox Was wurde auf der Zeitleiste der Privacy Sandbox aktualisiert? Auf der Zeitleiste der Privacy Sandbox wurde vor Kurzem eine Übersicht zur Topics API hinzugefügt.
Privacy Sandbox Gibt es Forschungsarbeiten zum Thema Datenschutz und Nützlichkeit, die Aufschluss über die Auswirkungen der Privacy Sandbox auf den Umsatz geben? Relevante Fallstudien aus der Branche, die sich mit diesen Fragen befassen, finden Sie hier. Die Ergebnisse der Privacy Sandbox-API-Tests finden Sie hier.
Privacy Sandbox-Akzeptanz Ein Early Adopter berichtete über anfängliche Herausforderungen mit den Privacy Sandbox APIs aufgrund der langsamen Einführung durch größere Unternehmen, was sich auf die Testeinführungen auswirkte. Trotzdem wurde der kooperative Ansatz des Privacy Sandbox-Teams und die Reaktion auf Feedback geschätzt. Wir freuen uns über das Feedback der Early Adopter. Wir möchten mit Early Adoptern zusammenarbeiten und werden uns auch weiterhin mit dem Werbesystem befassen und Feedback einholen, während wir die Rolle der Privacy Sandbox-Technologien bei der Unterstützung des Werbesystems bewerten.
Chrome-Tests Bedenken, ob die Privacy Sandbox-Tests nach dem Entfernen der Testlabels effektiv fortgesetzt werden können, da sich die Qualität des Traffics in Chrome mit deaktivierten Drittanbieter-Cookies (Modus B) und bei Nutzern, die Drittanbieter-Cookies in den Chrome-Einstellungen selbst deaktiviert haben, deutlich unterscheidet. Unsere Antwort ähnelt der aus den vorherigen Quartalen:

Das Privacy Sandbox-Team weiß, dass Unternehmen die Labels zur Einstellung von Cookies weiterhin verwenden möchten. Die Verlängerung der Verfügbarkeit der Labels ähnelt der Verlängerung eines Testzeitraums für einen Ursprung. Die Unterstützung für die Labels wurde bereits mehrfach erweitert. Wir planen, die Unterstützung für Labels zur Einstellung von Cookies weiter auszuweiten. Sobald es Neuigkeiten gibt, werden wir sie auf blink-dev veröffentlichen.

Registrierung und Attestierung

In diesem Quartal haben wir kein Feedback erhalten.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema Zusammenfassung Chrome-Antwort
Aktivierung/Deaktivierung Hemmt die Bestätigung von Google, dass die Entscheidung einer Website, die Topics API zu deaktivieren, in der Google Suche nicht als Rankingsignal verwendet wird, Google daran, die Entscheidung einer Website, die Topics API zu aktivieren, als Rankingsignal zu verwenden? Unsere Antwort ähnelt der aus den vorherigen Quartalen:

Das Privacy Sandbox-Team hat nicht mit der Google Suche abgestimmt oder von ihr verlangt, den Seitenrang als Anreiz für Websites zu verwenden, die Topics API zu implementieren. Die Entscheidung einer Website, die Topics API zu unterstützen oder nicht, wird in der Google Suche nicht als Rankingsignal verwendet.
Beobachtbarkeit der Nutzung Einen Beobachtbarkeitsmechanismus für eine SSP oder allgemeine Anzeigentechnologie anfordern, um zu sehen, ob ihre Implementierung der Topics API im Web verwendet wird. Wir prüfen derzeit, ob diese Funktion unterstützt werden soll. Wenn Sie der Meinung sind, dass diese Funktion eine hohe Priorität hat, geben Sie uns bitte Feedback.
Datenschutz Fragen zur Einwilligung und zum Risiko der Re-Identifikation Wir diskutieren dieses Problem derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.

Protected Audience API

Feedbackthema Zusammenfassung Chrome-Antwort
PA API und GAM/AdX Google sendet keine GAM-/AdX-Nachfrage an einen Publisher, der sich auf den Ad-Server eines konkurrierenden Publishers verlassen möchte. Google sollte konkurrierenden Publishern die Möglichkeit geben, alternative PA API-Auktionsverkäufer der obersten Ebene auszuwählen, um die endgültige Auktion zu steuern. Informationen aus der PA API sind für GAM verfügbar, aber für konkurrierende SSPs eingeschränkt. Daher können Publisher die Leistung der Nachfrage aus der PA API in GAM nicht mit der Nachfrage aus anderen Quellen vergleichen, z. B. aus AdX oder aus SSPs, die in die PA API eingebunden sind. Chrome-Antwort:
Der PA API-Standard ist flexibel und ermöglicht es verschiedenen Parteien, die Auktion der obersten Ebene durchzuführen. Diese Wahl hängt von den spezifischen Implementierungen und Funktionen ab, die vom Ad-Server des Publishers (GAM oder ein anderer) und anderen teilnehmenden Unternehmen im Ökosystem angeboten werden.
Das datenschutzorientierte Design der PA API schränkt detaillierte Berichte für alle Teilnehmer konsequent ein. Die spezifischen Daten, die aus der PA API-Auktion gemeldet werden, unterliegen für alle Teilnehmer, einschließlich SSPs, denselben API-definierten datenschutzfreundlichen Regeln und Einschränkungen.
Publisher verwenden die zusammengefassten, datenschutzfreundlichen Berichte der PA API, um die Leistung zu bewerten. So lässt sich der Gesamtbeitrag der über die PA API generierten Nachfrage bewerten und mit anderen Nachfragekanälen vergleichen. Dabei werden die Datenschutz-by-Design-Prinzipien der API eingehalten.

Antwort von Google Ad Manager:
Publisher müssen die Ad-Server-Funktionen von GAM nicht verwenden, um auf die AdX-Nachfrage zuzugreifen. Außerdem ist die PA API unabhängig davon, wer eine Auktion initiiert, sowohl bei Einzel- als auch bei Mehrfachkundenkonten.
Top-Level-Verkäufer Der Top-Level-Verkäufer (TLS) hat Zugriff auf Informationen, auf die keiner der anderen Komponentenverkäufer Zugriff hat. Dies wirft Bedenken hinsichtlich ungleicher Zugriffsrechte auf Informationen auf. Jede Entität kann der TLS sein. Um auf die AdX-Nachfrage zugreifen zu können, müssen Publisher jedoch GAM als Publisher-Anzeigenserver verwenden. Das ist ein Anreiz, GAM als Publisher-Anzeigenserver zu verwenden, was Google einen Wettbewerbsvorteil verschafft. Chrome-Antwort:
Das Design der PA API legt nicht fest, welche Entität als TLS fungieren kann. Die TLS-Rolle erfordert die Koordination der Auktion und den Zugriff auf zugehörige Auktionsinformationen gemäß der Struktur der API.

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 Anzeigenquellen 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 halten 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 andere Komponentenauktionen weiter, auch nicht an unsere eigenen, wie in diesem Update erläutert. Außerdem verwenden wir keine Informationen zu Auktionskonfigurationen für Komponenten, einschließlich Signalen, die Käufer an SSPs senden, in unseren eigenen Auktionen.
Wie bereits erwähnt, ist es für Publisher in GAM nicht erforderlich, die Ad-Server-Funktionen zu verwenden, um auf die AdX-Nachfrage zuzugreifen.

Wie bereits im Bericht zu Google Ads für das 2. und 3. Quartal 2024 erwähnt, werden auf den Buy-Side-Plattformen von Google – Google Ads (früher AdWords) und DV360 – Impressionen auch über Anzeigenplattformen von Drittanbietern gekauft, unter anderem über die PA API.
PA API und GAM/AdX Für Publisher ist es schwierig zu verstehen, warum die PA API für 100% des Inventars aktiviert werden soll, da der Zweck der Option nicht klar ist. Für SSPs, deren primärer Zugriff auf Inventar oft über eine mehrstufige Auktion erfolgt, bei der GAM als TLS dient, gibt es praktisch keine Möglichkeit, Tests durchzuführen oder über die PA API zu monetarisieren, ohne GAM zu verwenden. Chrome-Antwort:
Der PA API-Standard definiert technische Rollen (z. B. TLS- und Komponentenverkäufer) und den Auktionsprozess. So ist es flexibel, welche Plattformen diese Rollen ausführen.

Die Implementierung (z. B. Konfiguration, Koordination und Vereinbarungen) wird von den Implementierungsparteien (Publishern, SSPs und TLS-Anbietern) verwaltet, um die Teilnahme über das PA API-Framework zu ermöglichen.

Antwort von Google Ad Manager:
Wie in der Google Ad Manager-Hilfe beschrieben, bietet Ad Manager Publishern eine Einstellung, mit der Tests mit Komponentenverkäufern außerhalb von Google, z. B. anderen SSPs, für 100% des Inventars eines Publishers aktiviert werden können, in dem die API verfügbar ist. Dabei werden alle Stichprobenerhebungen oder Drosselungsmaßnahmen überschrieben, die in GAM angewendet werden könnten.

Wenn ein Publisher diese Einstellung aktiviert, wird in GAM immer dann versucht, eine Auktion auf oberster Ebene mit der bereitgestellten Komponentenauktion auszuführen, wenn ein Komponentenverkäufer, der nicht zu Google gehört, eine Auktionskonfiguration bereitstellt, sofern der Publisher die erforderliche Nutzereinwilligung dafür eingeholt hat. In GAM wird Publishern deutlich gemacht, dass sich diese Einstellung auf die Leistung auswirken kann, damit sie eine fundierte Entscheidung treffen können.
Serverseitig vs. On-Device Serverseitige Lösungen wie Bidding and Auction (B&A) können das Problem der Traffic-Steuerung bei gleichzeitigem Schutz der Privatsphäre lösen. Serverseitige Lösungen sind der einzige gangbare Weg und Google sollte On-Device-Lösungen aufgeben. Die Privacy Sandbox soll sowohl serverseitige (Bidder& Brokers-Dienste) als auch On-Device-Auktionslösungen unterstützen. So können verschiedene Anforderungen und Anwendungsfälle von Anzeigentechnologien erfüllt werden.
Auktionssicherheit Angriffe auf Gebote der PA API führen grundsätzlich zur Disqualifikation von Geboten und Auktionen auf dem Gerät. Dieses Problem wird von den Stakeholdern nicht als gelöst betrachtet. Sie fordern weiterhin technische Garantien, um sicherzustellen, dass PA API-Gebote nicht manipuliert werden, sowie einen umfassenden Debug-Modus, der eine Echtzeiterkennung von Vorfällen und eine effiziente Fehlerbehebung ermöglicht. Ein wichtiger Schwerpunkt der Privacy Sandbox ist die Gewährleistung der Auktionsintegrität der PA API, einschließlich der Minimierung potenzieller Angriffe. Das Design der API umfasst Integritätsmaßnahmen. Wir freuen uns über weitere technische Diskussionen zu spezifischen Bedenken.

Wir haben im Mai 2024 bei der W3C Anti-Fraud Community Group eine detaillierte Liste potenzieller Angriffe auf die PA API und unsere Maßnahmen zur Risikominimierung vorgestellt und diskutiert. Wir freuen uns über weitere Diskussionen und Feedback dazu, welche potenziellen „Angriffe auf Gebote der PA API“ ein Problem darstellen.
Zugriffe ohne Cookies Gibt es eine Möglichkeit, die PA API nur für traffic ohne Cookies zu aktivieren, z. B. für Tests? Anbieter von Anzeigentechnologien können feststellen, ob Drittanbieter-Cookies vorhanden sind oder nicht. Weitere Informationen finden Sie hier.
Arbeitsplatz-ID Bei der Seat-ID ist das Wissen um die Seat-ID für die meisten Gebotsanfragen unerlässlich. Das wirft Bedenken auf, die Seat-ID mit der Creative-Registrierung zu verknüpfen. Gilt das außerdem nur für die „Hauptanzeige“ oder auch für Komponentenanzeigen? Mit dem Vorschlag „BuyerAndSellerReportingId“ wird das Problem behoben, dass bei der Creative-Registrierung für die Hauptanzeige keine Käufer-Sitzplatz-ID angegeben wird. Diese Kennung soll dem Verkäufer die Sitzplatz-ID des Käufers mitteilen. Wir prüfen derzeit die Unterstützung für Komponentenanzeigen.
Monitoring und Berichte Funktionsanfrage für die Echtzeitüberwachung (Real-Time Monitoring, RTM): (1) RTM-Berichte für abgebrochene Auktionen senden sowie (2) neue vom Browser ausgefüllte Buckets, um zu verdeutlichen, welche Art von Stornierung stattgefunden hat. RTM ist offenbar keine geeignete Lösung, um die Teilnahmerate zu untersuchen. RTM ist als Monitoring-API mit niedriger Latenz konzipiert, um kritische, plötzliche und vorübergehende Ausfälle zu erkennen. Im Gegensatz dazu erfordert die Teilnahmerate keine Berichte mit niedriger Latenz und es handelt sich nicht um einen kritischen, plötzlichen vorübergehenden Ausfall. Bedenken hinsichtlich der Teilnahmeraten können am besten von den Verkäufern beantwortet werden, mit denen Käufer zusammenarbeiten, und nicht von Käufern, die im Browser recherchieren.

Außerdem sind abgebrochene Auktionen sehr häufig. Wenn der Browser RTM-Berichte für jede abgebrochene Auktion generieren würde, würden RTM-Berichte zu tatsächlichen Ausfällen möglicherweise übersehen.
Dokumentation
Klarstellung		 Es wurde eine Abweichung in der Dokumentation in der Erläuterung zur PA API gemeldet. Dort wird angegeben, dass der Nonce ein UUID-String sein sollte, tatsächlich wird aber ein Promise zurückgegeben. Hier finden Sie eine Erläuterung.
Frozen
Kontext		 Welche Optionen stehen bei der Arbeit mit einem eingefrorenen Kontext zur Verfügung, um Probleme und Herausforderungen im Zusammenhang mit (1) Bündeln, (2) externen Bibliotheken und (3) nicht unterstützten Datentypen zu beheben? Hier finden Sie eine Antwort auf diese Frage.
Spezifikationen Der Private Aggregation API wurde der generische Vorgang contributeToHistogramOnEvent hinzugefügt. Daher wurde die Definition in der PA API zu einem überladenen Vorgang. Web-IDL-Vorgänge dürfen nicht über die Schnittstelle, die Teilschnittstelle [...] hinweg überladen werden. Daher ist diese Definition jetzt ungültig. Dieses Problem weist auf eine vorübergehende Inkonsistenz zwischen den Spezifikationen der PA API und der Private Aggregation hin, während wir ähnliche Änderungen in beiden zusammenführen. Wir haben einen Pull-Request zusammengeführt, um das Problem zu beheben.
Interessengruppen Sie möchten wissen, wie Sie die Gebotsteilnahme einer Interessengruppe beenden, wenn eine Kampagne beendet wird. Hier einige Vorschläge:

Wir sind der Meinung, dass der Mechanismus mit der geringsten Latenz, der am wenigsten dauerhaft, aber auch derjenige mit dem geringsten Ressourcenverbrauch ist, bei dem die generateBid() über die Echtzeitgebotssignale angewiesen wird, keine Gebote mehr abzugeben.

Die zweite Option, die weniger Ressourcen verbraucht, besteht darin, in der Antwort auf Echtzeitgebotssignale eine negative Priorität für diese IG festzulegen. Dadurch wird verhindert, dass generateBid() überhaupt aufgerufen wird.

Die dritte Option, bei der noch weniger Ressourcen verbraucht werden, besteht darin, die Anzeigen aus dem IG zu entfernen. Bei IGs ohne Anzeigen wird die generateBid() nicht aufgerufen.

Die vierte Option, bei der noch weniger Ressourcen verbraucht werden, besteht darin, die biddingLogicURL aus dem IG zu entfernen. In diesem Fall kann die IG noch aktualisiert oder wieder beigetreten werden, um sie zu reaktivieren.

Weitere Optionen beziehen sich darauf, die IG zu verlassen, entweder über leaveAdInterestGroup() oder clearOriginJoinedAdInterestGroups() oder durch Ablauf der IG.

Wie oben erwähnt, haben die verschiedenen Optionen unterschiedliche Auswirkungen auf die Latenz und den Ressourcenverbrauch. Anbieter von Anzeigentechnologien können die Option auswählen, die für ihre spezifischen Anwendungsfälle am besten geeignet ist.
Zielgruppen Anfrage nach einem Mechanismus zum Ausführen logischer Vorgänge auf erstellte Zielgruppen (z.B. Möglichkeit, eine Ausrichtung auf eine Überschneidung von IG A und B vorzunehmen) Mit der PA API können Sie bereits jetzt logische Vorgänge auf Zielgruppen von derselben Website ausführen. Logische Zielgruppenoperationen auf verschiedenen Websites werden derzeit aus Datenschutzgründen nicht unterstützt, wie in unserem Datenschutzmodell erläutert. Wir führen weiterhin Studien in diesem Bereich durch und halten Sie über Neuigkeiten auf dem Laufenden.
Feature Request (Funktionsanfrage) Vorschlag zur Aufhebung der Einschränkung für zusätzliche Gebote, bei denen der TLS-Wert im Voraus bekannt sein muss. Wir diskutieren diesen Vorschlag derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Aktualisierter Ansatz für 3PCs in Chrome Werden Privacy Sandbox APIs wie die PA API für alle Chrome Stable-Nutzer allgemein verfügbar bleiben oder sind die APIs (oder ein Teil der APIs) nur für Nutzer verfügbar, die Drittanbieter-Cookies abgelehnt haben? Wir möchten nicht, dass die Entscheidung eines Nutzers, Drittanbieter-Cookies abzulehnen, sich auf die Verfügbarkeit der Privacy Sandbox APIs in der stabilen Chrome-Version auswirkt.
Erweiterte Signale Sind Pläne für eine Funktion geplant, die angibt, ob die TLS eine PA API-Auktion ausführen soll? Wir prüfen derzeit, ob diese Funktion unterstützt werden kann. Weitere Informationen zum Zeitplan teilen wir Ihnen mit, sobald sie verfügbar sind. Wir freuen uns auch über zusätzliches Feedback zu dieser Anfrage.
Deal-ID Bedenken, dass die KV-Serveranforderung im Vorschlag für die Deal-ID ein teurer und zeitaufwendiger serverseitiger Prozess sein kann. Mit dem Deal-ID-Vorschlag können SSPs während PA-Auktionen Metadaten der ausgewählten Deal-IDs vom Schlüssel/Wert-Server abfragen, sodass nicht alle dealbezogenen Metadaten auf dem Gerät vorab geladen werden müssen. Dieser Vorschlag wird auf Anfrage von SSPs entwickelt. Wir freuen uns über zusätzliches Feedback zum Werbesystem hier.

Wir verstehen, dass die Einrichtung des Schlüssel/Wert-Servers mit Arbeit verbunden ist. Wir sind jedoch der Meinung, dass dies insgesamt ein Vorteil für AdTech-Unternehmen ist. Wir freuen uns weiterhin über Feedback und Vorschläge, wie wir diesen Vorgang vereinfachen können.
Kanalübergreifendes Frequency Capping Anfrage für kanalübergreifendes Frequency Capping über die PA API. Das plattformübergreifende Frequency Capping hat datenschutzrechtliche Herausforderungen, für die wir keine Lösung gefunden haben.

Wir freuen uns über zusätzliches Feedback aus der Community, wenn diese Funktion für Sie eine hohe Priorität hat.
Berichte zu Deal-IDs und Nutzerlizenz-IDs Es wird die Möglichkeit angefragt, Deal- oder Sitzplatz-IDs in aggregierte Berichte aufzunehmen. Mit den Berichts-ID-Funktionen, an denen wir hier arbeiten , können Deal- und Sitzplatz-IDs in Berichten angegeben werden.

selectedBuyerAndSellerReportingId wird an reportResult() übergeben.Daher ist die einfachste Möglichkeit, sie zu erfassen, über Berichte auf Ereignisebene. Dazu wird die Deal-ID in die URL codiert, die an sendReportTo() übergeben wird. Wenn aggregierte Berichte verwendet werden sollen, ist das auch möglich.

Die Funktion für die Berichts-ID ist derzeit für 10% des Traffics über den Chrome-Stable-Kanal verfügbar. Wir prüfen derzeit, ob wir die Einführung auf 100 % ausweiten.
Interessengruppen Verwenden Sie dieselbe Prioritätsreihenfolge sowohl bei der Auswahl als auch bei der Bewertung von IGs und verwenden Sie diese Prioritätsreihenfolge in allen Bewertungsmodi. Wir diskutieren das Thema derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Interessengruppen Vorschlag, Zielgruppenaktivierung und -delegierung zu verwenden, um die Akzeptanz der Privacy Sandbox API zu erhöhen. Uns ist diese Anfrage von mehreren Stakeholdern bekannt und wir arbeiten an einer Lösung.

Wir freuen uns über weiteres Feedback aus der Community.
Interessengruppen Herausforderungen beim Erstellen von PA API-IDs, insbesondere bei der Delegierung und Inhaberschaft, wenn für mehrere Käufe oder im Namen von Publishern gehandelt wird. Wir haben von mehreren Stakeholdern die Anfrage erhalten, erweiterte IG-Delegierungen zu unterstützen. Wir sehen den Mehrwert von SSPs bei diesem Prozess.

Wir führen derzeit Recherchen durch, um die beste Lösung zu finden, mit der verschiedene Parteien am Prozess der Zielgruppenerweiterung teilnehmen können. Wir freuen uns über zusätzliches Feedback aus der Community.
Clientseitige Leistung Anforderung von Informationen zur Vereinfachung des clientseitigen Cachings von trustedBiddingSignals, um die Infrastrukturkosten und die Latenz zu optimieren. Wir diskutieren das Thema derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.

Geschützte Auktion (B&A-Dienste)

Feedbackthema Zusammenfassung Chrome-Antwort
K/V-Dienste Wie werden Anfragen vom Browser an den KV-Server des Verkäufers gruppiert? Wie sieht die Anfrage vom Browser für einen Verkäufer aus – eine GET- oder POST-Anfrage? Außerdem sind einige Erläuterungen zu den Anforderungen an die K-Anonymität erforderlich. Bei Version 1 sendet Chrome eine GET-Anfrage an den KV-Dienst des Verkäufers, um trustedScoringSignalsURL mit den Signalen in den Abfrageparametern der Anfrage abzurufen. Zu den Parametern gehören hostname, renderUrls, adComponentRenderUrls und experimentGroupId. Wir testen derzeit einige Erweiterungen, um zusätzliche Informationen für das Creative-Scannen zu senden. Diese Funktion ist aber noch nicht verfügbar.

Wenn Sie maxTrustedScoringSignalsURLLength auf „0“ setzen, kann Chrome alle Signale in einer einzigen Anfrage zusammenfassen, was möglicherweise die URL-Längenbeschränkung auf dem Server überschreitet. Dies ist jedoch nicht garantiert. Derzeit werden in Chrome Anfragen in denselben Batch aufgenommen, wenn sie innerhalb von 10 Millisekunden nacheinander gesendet werden können. Wir arbeiten jedoch daran, dies zu optimieren.

Bei der Arbeit mit trustedScoringSignals ist zu beachten, dass Chrome Caching-Header berücksichtigt. Header wie der Stale-While-Revalidate-Header „Cache-Control“ können die durchschnittliche Latenz verringern, indem Chrome die zwischengespeicherte Kopie verwendet (und den Cache für die nächste Auktion aktualisiert). Dadurch wird der Abruf der Signale effektiv aus dem kritischen Pfad entfernt.

Was die k-Anonymität angeht, scheint der entsprechende Abschnitt des Erläuterungsartikels veraltet zu sein. Ursprünglich sollten die URLs für vertrauenswürdige Signale k-anonym sein, aber diese Anforderung wurde aufgehoben. Wir entfernen diesen Satz aus der Erklärung.
B&A Services Das Upgrade auf die neueste Version von B&A dauert lange. Eine kürzere Build-Zeit oder vorgefertigte Images wären von Vorteil. Anbieter von Anzeigentechnologien können die Binärdateien selbst erstellen und mit den bereitgestellten Hashes validieren. Wir werden prüfen, ob wir in Zukunft vorgefertigte Artefakte anbieten oder die Build-Zeiten verbessern können.
API-Funktionsanfrage macOS-Kompatibilität für Build-Scripts, Container-Images und Aufruftools für Bidding & Auction Services (B&A), um die lokale Entwicklung und Tests zu erleichtern. Wir unterstützen derzeit amd64, was für die Bereitstellung auf den unterstützten Cloud-Plattformen (GCP und AWS) ausreicht. Wir prüfen möglicherweise in Zukunft die Unterstützung anderer Architekturen.
AWS Müssen für Produktionsbuilds IAM-Rollen erstellt werden? Ja, IAM-Rollen sind für die entsprechenden Berechtigungen und die Kommunikation mit Koordinatoren erforderlich. Die Schlüssel werden verwendet, um den Geheimtext von ProtectedAudienceInput zu entschlüsseln, der wie hier beschrieben auf dem Gerät generiert wird. Außerdem müssen diese Rollen die Server-/TEE-Attestierung von Produktionsbuilds mit denselben Koordinatoren bestehen. Weitere Informationen dazu finden Sie in unserem Leitfaden für die Selfservice-Kampagnenverwaltung.
B&A-Flags Definitionen der verfügbaren B&A-Flags in der Dokumentation auflisten lassen, da diese Definitionen derzeit im Terraform-Code, in cc-Dateien und Proto-Dateien enthalten sind. Werbetechnologieexperten würden von einer Dokumentation zu diesen Flags profitieren, da sie diese als vertrauenswürdige Quelle für die Anpassung von Bereitstellungen nutzen könnten. Wir prüfen die Möglichkeit, Beschreibungen für die Terraform-Flags zu dokumentieren, und freuen uns über zusätzliches Feedback in diesem Forum.
AWS
Bidding Service		 Ich benötige Informationen zum Gebotsservice bei AWS sowie zum Standard-Logging-Verhalten und zur Standardkonfiguration. Für die Fehlerbehebung bei Gebotsdienstleistungen innerhalb der TEE (z. B. Gebotsdienst) empfehlen wir die Fehlerbehebung mit Einwilligung von Ad Tech. So können Sie detailliertes Logging aktivieren und Anfrage-/Antwortdaten für Ihre spezifischen Testanfragen direkt von Ihrem Client erfassen, um die Fehlerbehebung zu erleichtern.
TEE K/V
Dokumentation 		Ich benötige eine Klarstellung zum Beginn der Durchsetzung von TKV, wie auf der Entwicklerwebsite angegeben. Wir informieren Sie rechtzeitig im Voraus, wenn die Verwendung von TEEs erforderlich ist. Bis dahin können Sie Ihren eigenen Server für Echtzeit-Schlüssel/Wert-Signale weiter verwenden.
Vorher-Nachher-Tests und -Analysen B/A-Analysen und -Tests sind weiterhin kostspielig und scheinen nicht für die Produktion bereit zu sein. Wir benötigen weitere Informationen zur Kostenanalyse und zu den Faktoren, die zur Bewertung der Produktionsbereitschaft geführt haben, um uns das genauer anzusehen.
Trusted Server Optimization Vorschlag, Parameter, die für Komponentenverkäufer spezifisch sind, in einem Parameter inputsPerSeller zusammenzuführen und als Wert einen JSON-String zu verwenden. Wir diskutieren diesen Vorschlag und freuen uns über zusätzliches Feedback hier.
Sicherheit Wie werden Sicherheitsrisiken durch TKV mithilfe von B&A minimiert? Externe Aufrufe an TKV können verhindert werden. Diese Funktion wird in der GCP derzeit vollständig unterstützt und kann konfiguriert werden.

Für AWS muss zusätzlicher Support entwickelt werden, da AWS App Mesh eingestellt wird, über das dies bisher möglich war. Hier können Sie uns zusätzliches Feedback geben.
B&A Services Bitte um Klarstellung der Aussage/Kommunikation zum Wert von HTTP-Streaming für die B&A-Optimierung. Die Privacy Sandbox unterstützt Streamingfunktionen bei der Übertragung von B&A-Daten, um die Latenz für AdTech-Anbieter zu verbessern, die sie verwenden. Die Leistungsoptimierung ist im gemischten Modus optional.
Prebid Informationen dazu, wie Sie zur Open-Source-Prebid-Bibliothek beitragen können, um B&A-Funktionen der PA API für das gesamte System zu aktivieren. Im März 2025 wurde in Chrome die Prebid-bevorzugte Optimierung in der stabilen Version eingeführt, wie in der öffentlichen B&A-Roadmap (siehe März 2025) dokumentiert.
Anpassung an Traffic Es wird um Mechanismen gebeten, mit denen Kontextsignale protokolliert werden können, die von B&A empfangen werden, um besser nachvollziehen zu können, wann IGs aktiviert werden, und die Logik für die Gebotsabsicht in der kontextbezogenen Antwort zu verbessern. So können Netzwerkressourcen besser genutzt werden, um „unnötigen Traffic“ zu vermeiden (auch als Traffic Shaping bezeichnet). Wir diskutieren derzeit einen Vorschlag hier und freuen uns über zusätzliches Feedback.
Dokumentation
Klarstellung		 Klärung erforderlich bezüglich des Fehlers „Service/Vsock proxy is not reachable“ (Dienst-/Vsock-Proxy ist nicht erreichbar), der bei der Einrichtung der B&A-Testintegration festgestellt wurde. Das liegt an den Mindestspeicheranforderungen.Die Erläuterung zur AWS-Konfiguration wurde entsprechend aktualisiert.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Echtzeitdaten Der Mangel an Echtzeitdaten wirkt sich auf alle in der Branche aus. Verzögerungen bei Echtzeitdaten sind ein ernstes Problem für Werbetreibende. Käufer wechseln zu Plattformen mit Google Analytics, da sie dort der einzige Ort sind, an dem sie nachweisen können, dass sie Zielgruppen erreichen. Die Verzögerungen bei Echtzeitdaten, die Teil der Attribution Reporting API (ARA) sind, werden als Datenschutzmechanismen implementiert, um die Möglichkeit von Werbetechnologien einzuschränken, Nutzer über Websites hinweg anhand von Berichten auf Ereignisebene zu erfassen. Die ARA bietet jedoch Flexibilität bei der Übermittlung von Attributionsberichten. So kann für Berichte auf Ereignisebene ein Mindestzeitraum von einer Stunde festgelegt werden und es gibt die Möglichkeit, zusammengefasste Berichte sofort an Anbieter von Anzeigentechnologien zu senden.
API-Verwendung Bestätigung der korrekten Konfiguration für einen webbasierten Attributionsablauf anfordern, insbesondere wenn Web-zu-Web- und Web-zu-App-Attribution parallel verwendet werden. Wenn Web-zu-Web- und Web-zu-App-Kampagnen parallel ausgeführt werden, sollte die Anzeigentechnologie nur eine Plattform für die Registrierung jeder Quelle oder jedes Triggers auswählen, um eine doppelte Zählung zu vermeiden. Wir empfehlen nach Möglichkeit die Verwendung des Betriebssystems, da es sowohl Web-zu-Web- als auch Web-zu-App-Attributionen vornehmen kann, sofern die Webquellen und Trigger korrekt delegiert wurden. Das bedeutet, dass Sie für Quellen mit dem Header „Attribution-Reporting-Register-OS-Source“ und für Trigger mit dem Header „Attribution-Reporting-Register-OS-Trigger“ antworten müssen.

Anhand des Attribution-Reporting-Support-Headers können Sie feststellen, ob es Unterstützung auf Chrome- und/oder Android-Ebene gibt. Der Header „Attribution-Reporting-Info“ ist nützlich, wenn in der Anfrage kein Header „Attribution-Reporting-Support“ vorhanden ist. In diesem Fall entscheidet der Browser basierend auf der Verfügbarkeit der Plattformunterstützung auf dem Gerät des Nutzers, ob die Plattform registriert wird.
API-Spezifikation Erläuterung zum HTTP-Anfrageheader für die Attribution-Reporting-Unterstützung, der von der Attribution Reporting API festgelegt wird, und ob der Header unabhängig von der Plattform sowohl Web- als auch Betriebssystemschlüssel enthalten soll. Der Attribution-Reporting-Support-Header ist davon abhängig, dass der Browser „GREASE“-Parameter hinzufügt, um sicherzustellen, dass die Server einen spezifikationskonformen strukturierten Header-Parser verwenden. Für diese Überschrift sollten nur Schlüssel aus strukturierten Wörterbüchern interpretiert werden. Die Werte und Parameter werden derzeit nicht verwendet. Ein Beispiel finden Sie hier.
Berichte auf Grundlage von Drittanbieter-Daten Ich benötige Hilfe bei der Behebung von Abweichungen bei der Analyse zwischen ARA und 3PC in Werbekampagnen. ARA unterstützt zwei Arten von Debug-Berichten, mit denen Abweichungen behoben werden können. Mit Berichten zur Fehlerbehebung bei der Attributionsleistung können Sie ARA-Ergebnisse ganz einfach mit den Ergebnissen anderer Analysetechnologien vergleichen. Ausführliche Debug-Berichte enthalten weitere Informationen und helfen Ihnen, potenzielle Probleme bei der Attributionsregistrierung zu beheben.
API-Verwendung Beim Testen von ARA wurden einige Probleme festgestellt: unzureichend detaillierte Berichte, die zu ungenauen Daten und einer wenig flexiblen Kampagnenoptimierung führen, hohe Grenzwerte, die kleinere Werbetreibende ausschließen, und Schwierigkeiten beim Vergleichen von Kampagnen aufgrund inkonsistenter Leistungskennzahlen. ARA bietet Flexibilität, da mehrere Parameter zur Verfügung stehen, die Werbetechnologieanbieter an ihre spezifischen Analyseanforderungen anpassen können. Berichte auf Ereignisebene unterstützen flexible Berichte auf Ereignisebene. So können Anbieter von Anzeigentechnologien ihre Berichtszeitraume, die Anzahl der Berichte, die sie erhalten können, und die Triggerdaten, die sie messen möchten, anpassen. So lässt sich die Auswirkung von Rauschen auf die Daten ändern und es können verschiedene Anwendungsfälle abgedeckt werden. Bei zusammengefassten Berichten haben Anbieter von Anzeigentechnologien ebenfalls verschiedene Möglichkeiten, ihre Konfigurationen anzupassen, z. B. die Anzahl der erfassten Dimensionen, die Batch-Frequenz und die Verwendung des Beitragsbudgets, um die Auswirkungen von Rauschen zu ändern und auch verschiedene Anwendungsfälle zu erreichen.
API-Spezifikation Frage zur Abhängigkeit von ARA von Drittanbieter-Plattformen, insbesondere dazu, ob es sich noch in einer Testphase befindet, in der diese Drittanbieter-Plattformen erforderlich sind. ARA wird unabhängig von Drittanbieter-Cookies aktiviert. Drittanbieter-Cookies müssen jedoch aktiviert sein, damit ARA-Übergangs-Debugberichte ARA-Ergebnisse mit cookiebasierten Attributionsergebnissen vergleichen können.
API-Verwendung Anfrage zur Registrierung von Quellen für die App-zu-Web-Attribution unter älteren Android-Versionen (11, 12 und 13) mit ARA. ARA wird derzeit auf Android S und höher (12+) unterstützt.
API-Verwendung ARA-Aktivierungsraten und -Vertriebsdetails anfordern Unsere Antwort hat sich gegenüber den vorherigen Quartalen nicht geändert:

„Wir haben keine Pläne, diese Informationen an das System weiterzugeben. Entwickler können die APIs aufrufen, in denen sie bereits Code bereitgestellt haben, um die Verfügbarkeit der Privacy Sandbox APIs zu schätzen.“
API-Verfügbarkeit Sind 3PCs aktiviert oder deaktiviert, wenn ARA aktiviert ist? Wenn ARA im Browser des Nutzers aktiviert ist, hat dies keine Auswirkungen auf die Cookie-Einstellungen des Nutzers. Es ist möglich, dass ARA aktiviert ist und der Nutzer Cookies entweder aktiviert oder deaktiviert hat.
Berichte Gibt es eine vordefinierte Liste von Werten, die wir im Header „Attribution-reporting-support“ erhalten können? Wie in unserer Anleitung erläutert, ist der Wert ein strukturiertes Header-Wörterbuch, dessen derzeit einzige definierte Semantik das Vorhandensein oder Fehlen der OS- und Webschlüssel ist. Alle anderen Teile der Kopfzeile sollten ignoriert werden. Mit anderen Worten: Für das Parsen ist ein strukturierter Header-Parser erforderlich, keine einfache Stringabgleichung.

Zusammenfassungsdienst

Feedbackthema Zusammenfassung Chrome-Antwort
Feature Request (Funktionsanfrage) Funktionsanfragen für den Aggregationsdienst:

Server-zu-Server-Integrationen, geräteübergreifende Messung, einfachere Multi-Touch-Attribution und Beitragsberichte, Omni-Channel-Attribution und Unterstützung für erweiterte ML-Optimierungsschleifen (z.B. Privates Modelltraining).		 Wir prüfen diese Anträge und geben weitere Informationen bekannt, sobald sie verfügbar sind.

Wir freuen uns über Feedback aus der Community dazu, ob diese Anfragen priorisiert werden sollten.
Feature Request (Funktionsanfrage) Bitte setzen Sie den EBS-Parameter „delete_on_termination“ in der Terraform-Umgebung auf „True“, um Bedenken hinsichtlich des Zurücksetzens beim Aktualisieren des Aggregations-Dienstsatzes auszuräumen. Wir prüfen diese Anfrage und teilen Ihnen weitere Informationen mit, sobald sie verfügbar sind.

Wir freuen uns über zusätzliches Feedback aus der Community dazu, ob dieser Antrag vorrangig behandelt werden sollte. Hier können Sie uns Ihr Feedback mitteilen.
Dokumentation
Klarstellung		 Sie möchten wissen, was geändert werden kann (z.B. Überwachungsgrenzwerte) und was unverändert bleiben sollte. Wir prüfen derzeit, ob wir zusätzliche Dokumentation und Anleitungen zu den verfügbaren Anpassungen für den Aggregationsdienst veröffentlichen.
Bereitstellung Klärung bezüglich des fehlgeschlagenen Bazel-Befehls bei der neuen Bereitstellung anfordern Ein fehlgeschlagener Deployment kann auf die in der Umgebung verwendete Bazel-Version zurückzuführen sein.

Die Dokumentation wird angepasst, um das Debuggen bei Terraform-Fehlern abzudecken und die erforderliche Bazel-Version anzugeben.

Private Aggregation API

Feedbackthema Zusammenfassung Chrome-Antwort
API-Verwendung Er bittet um Unterstützung bei einigen Implementierungsherausforderungen, z. B. bei potenziellen Datenverlusten aufgrund gemeldeter Einschränkungen des freigegebenen Speichers, bei Problemen mit hoher Kardinalität, die komplexe Zulassungslisten für den Aggregationsdienst erfordern (Wildcard empfohlen), und bei verlangsamten Tests aufgrund der Regel „Keine Duplikate“ des Aggregationsdienstes. Die Beschränkung von 20 Beiträgen (weitere Informationen) gilt pro Ausführung, nicht pro Monat. Außerdem können API-Caller dieses Limit überschreiben. Das Limit dient dazu, die Kosten für die Verarbeitung von Berichten im Aggregationsdienst zu verwalten, und nicht dazu, das Berichtstool einzuschränken.

Wir prüfen derzeit Ihre Anfrage zu Wildcard-Suchanfragen und teilen Ihnen weitere Informationen mit, sobald diese verfügbar sind.

Bezüglich der Regel „Keine Duplikate“ unterstützen wir vorübergehend den Debug-Modus, um diese Regel zu umgehen und Tests zu ermöglichen. Weitere Informationen
ID und Buckets filtern Ist es möglich, beim Aggregationsdienst denselben Bucket mit zwei verschiedenen Filter-IDs in zwei separaten Aggregationsläufen anzufordern, d.h., kann die Filter-ID als zusätzliche Partitionierung von Domains dienen? Ja, diese Funktion wird unterstützt. Bei einer Aggregation werden nur Beiträge mit einer Filter-ID verarbeitet, die mit der Liste in den Jobparametern übereinstimmt. Der Rest kann in separaten Ausführungen verarbeitet werden.
Multi-Touchpoint-Attribution Anfragen zur Klärung der Implementierung der Multi-Touch-Attribution (MTA):

1) Gibt es eine Obergrenze für die Anzahl der Beiträge, wenn der Aggregationswert 2^16 nicht überschreitet?

2) Ist die Anzahl der eindeutigen Aggregationsschlüssel (Buckets), die für einen bestimmten Kontext gespeichert werden können, begrenzt?

3) Wie verarbeitet der Aggregationsdienst Zusammenfassungsberichte, wenn jeder User-Agent (Browser) einen eindeutigen Aggregationsschlüssel hat, wie es bei MTA wahrscheinlich der Fall ist?		 1) Wir haben Standardlimits für Beiträge festgelegt. Der API-Aufrufer kann diese jedoch wie hier beschrieben überschreiben. Die Limits sollen API-Callern helfen, die Kosten für die Verarbeitung von Berichten im Aggregationsdienst zu verwalten.

2) Es gibt keine solche Begrenzung. Anbieter von Anzeigentechnologien sollten jedoch die Detaillierung der Aggregationsschlüssel berücksichtigen, um das Signal-Rausch-Verhältnis zu verbessern, wie hier erläutert.

3) Weitere Informationen finden Sie in dieser Anleitung, insbesondere unter Punkt 2) zu Signal-Rausch-Verhältnis.

Verdecktes Tracking einschränken

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

Feedbackthema Zusammenfassung Chrome-Antwort
Feature Request (Funktionsanfrage) Es wird beantragt, Sec-CH-UA-Robot zu den UA-CH-Clienthinweisen (User-Agent Client Hints) hinzuzufügen, da Server so automatisierten Traffic für die Inhaltsanpassung, Sicherheit und Analysen erkennen können. Dies ist ein wichtiger Anwendungsfall, der in anderen Standardsgruppen diskutiert wird (weitere Informationen finden Sie hier ). Wir empfehlen interessierten Parteien, daran teilzunehmen und Feedback zu geben. Wir sind jedoch der Meinung, dass UA-CH möglicherweise nicht die richtige Lösung ist, da HTTP-Anfrageheader leicht durch automatisierten Traffic manipuliert werden können.

IP-Schutz (früher Gnatcatcher)

Feedbackthema Zusammenfassung Chrome-Antwort
Datenschutz bei IP-Adressen Wenn IP-Adressen für Google verfügbar bleiben, widerspricht das den angegebenen Datenschutzzielen. Auch wenn Google angibt, Daten durch den IP-Schutz zu anonymisieren, müssen Nutzer in Chrome angemeldet sein, um den IP-Schutz zu nutzen. Google erfährt also weiterhin ihre Identität. Die Anmeldung dient dem Schutz vor Betrug und Missbrauch, vor allem der Zugriffsbeschränkung auf die Proxys.

Außerdem ist unser Token-Design aus Datenschutzgründen im Zusammenhang mit der Authentifizierungsvoraussetzung blind signiert. Das bedeutet, dass sich das bei der Anmeldung ausgestellte Token von dem Token unterscheidet, das beim Proxying verwendet wird. Daher können die ausgestellten Tokens später nicht mit der Google-Identität eines Nutzers verknüpft werden. Das bedeutet, dass Google nicht weiß, wer der Nutzer ist, wenn der Traffic dieses Nutzers im Inkognitomodus über einen Proxy geleitet wird, trotz der Authentifizierungsanforderung aus Betrugspräventionsgründen.
Datenschutz bei IP-Adressen Die Verwendung von IPs ist ein Schritt in die falsche Richtung. Sie können nicht wie Cookies aus dem Browser gelöscht werden und Nutzer haben nicht dieselben Transparenzeinstellungen wie bei Cookies. Wenn Cookies eingestellt werden, wird die Branche IP-Adressen als alternative Lösung verwenden und dabei den Selbsterhalt über den Datenschutz stellen. Als Plattform bietet Chrome Nutzern Funktionen, die das Surfen im Web verbessern. Für Chrome-Nutzer, die im Inkognitomodus surfen, bedeutet das einen erweiterten Schutz vor websiteübergreifendem Tracking, da die Verfügbarkeit von IP-Adressinformationen in Drittanbieterkontexten eingeschränkt wird.
Liste der maskierten Domains Was sind die Auswahlkriterien für die Liste der maskierten Domains (Masked Domain List, MDL)? In Chrome wurden Kriterien entwickelt, mit denen ermittelt wird, welche Domains in der MDL enthalten sein sollen und daher in einem Drittanbieterkontext maskierte IP-Adressen erhalten. Google arbeitet mit Disconnect.me zusammen, einem führenden Anbieter von Internetdatenschutzlösungen, der auch mit anderen Webbrowsern zusammenarbeitet. Chrome nutzt Disconnect.me, um Domains zu identifizieren, die den in Chrome festgelegten Kriterien entsprechen. Außerdem wurde in Chrome eine Methode entwickelt, mit der häufig verwendete JavaScript-Funktionen identifiziert werden, die konsistente Ergebnisse von stabilen und hochentropischen Web-APIs liefern und daher zur Erstellung probabilistischer IDs mit hoher Entropie verwendet werden können. Diese Funktionen werden dann erkannt, wenn sie auf Websites in einem Drittanbieterkontext geladen werden. Dies führt zu einer Liste von Domains, die Scripts mit diesen Merkmalen ausliefern, die Teil der MDL werden und daher per Proxy bereitgestellt werden. Bei der Erkennungspipeline, die nach diesen Mustern von API-Missbrauch sucht, werden alle Domains berücksichtigt, einschließlich der Domains von Google.
Betrugsprävention Feedback zu probabilistischen Reveal-Tokens (PRTs): Die vorgeschlagene 24-stündige Verzögerung und die Reveal-Raten beeinträchtigen die Echtzeiterkennung von Betrug. Fordern Sie kürzere Verzögerungen (1 Stunde) und höhere Preise (mindestens zweistellig) an. Weitere Vorschläge umfassen die Aktivierung von unterschiedlichen Preisen basierend auf Risikosignalen (VPNs, automatisierte Browser) und die gezielte Offenlegung bestimmter Tokens. Die meisten Entwickler, mit denen wir gesprochen haben, stellen ihren Kunden stündliche Berichte zur Verfügung und aktualisieren mehrmals täglich IP-Blocklisten. Eine kürzere Verzögerung ermöglicht häufigere Aktualisierungen. Bei einer Verzögerung von weniger als einer Stunde wird die Messung der indirekten Verweildauer in den stündlichen Statistiken wieder aktiviert. Allerdings steigt dadurch auch die Wahrscheinlichkeit, dass Nutzer wieder identifiziert werden können. Wir sind offen für die Möglichkeit, die Verzögerungszeiten zu verkürzen und die Offenlegungsrate basierend auf Studien zum Ökosystem und Feedback von Stakeholdern zu ändern. Weiteres Feedback kannst du hier geben.
Liste der maskierten Domains Frage zur Aufnahme einer Domain in die MDL, obwohl kein Werbenutzungsfall vorliegt Bedenken, dass dies die „IP-Bridging“-Technologie ermöglichen könnte, um Profile basierend auf IP-Adressen zu erstellen. Wir sind uns bewusst, wie wichtig es ist, für unseren listenbasierten Ansatz ein Einspruchsverfahren zu implementieren. Mit Einsprüchen können Unternehmen geltend machen, dass ihre Domain in der MDL nicht die Aufnahmekriterien erfüllt und entfernt werden sollte. Dadurch kann diese Domain weiterhin die ursprünglichen IP-Adressen der Nutzer in einem Drittanbieterkontext im Inkognitomodus erhalten.

Wir haben jetzt das Einspruchsverfahren eingeführt, damit Domaininhaber vor der Einführung des IP-Schutzes im Inkognitomodus in der stabilen Chrome-Version ausreichend Zeit haben, Einspruch einzulegen und eine Entscheidung zu erhalten.

Weitere Informationen zum Einlegen von Einsprüchen finden Sie hier.
Liste der maskierten Domains Feedback, dass Publisher die Auswirkungen prüfen, die sich daraus ergeben, dass ihre Partner in der MDL enthalten sind. Die GeoIP-Bestimmungen in der Erläuterung zum IP-Schutz haben ihn beruhigt. Chrome erkennt die Bedeutung der Unterstützung geografisch basierter Anwendungsfälle. Der Proxy weist IP-Adressen zu, die den ungefähren Standort des Nutzers, einschließlich des Landes, repräsentieren. Weitere Informationen finden Sie im Hilfeartikel IP-Standortbestimmung.
Liste der maskierten Domains Frage zur MDL, ob die Ausrichtung auf Länderebene noch verfügbar ist. Chrome erkennt die Bedeutung der Unterstützung von standortbasierten Anwendungsfällen. Der Proxy weist IP-Adressen zu, die den ungefähren Standort des Nutzers, einschließlich des Landes, repräsentieren. Weitere Informationen finden Sie im Hilfeartikel IP-Geolokalisierung.
Betrugserkennung Bedenken hinsichtlich der Auswirkungen des IP-Schutzes auf Systeme zur Betrugserkennung Sehen Nutzer Proxy-IPs oder einen Header? Sehen SSPs und DSPs für eine bestimmte Verwendung dieselbe Proxy-IP-Adresse? Inkonsistenzen können sich auf die Betrugserkennung und OpenRTB auswirken. Nutzer, die im Inkognitomodus mit aktiviertem IP-Schutz surfen und Anfragen an Domains auf der MDL senden, erhalten eine Proxy-IP-Adresse, die auf einem definierten Geofeed basiert. Organisationen können anfordern, dass PRTs als zusätzlicher Header für Proxy-Traffic übergeben werden, wobei nach einer Verzögerung eine kleine Stichprobe der ursprünglichen IP-Adressen offengelegt werden kann. Wir gehen davon aus, dass viele SSPs ihre Proxy-IP-Adresse in serverseitigen Gebotsanfragen an ihre Nachfragepartner weitergeben. Es ist jedoch nicht garantiert, dass die Gewinner-DSPs zum Zeitpunkt der Impression dieselbe Proxy-IP-Adresse sehen.
Betrugserkennung Fragen zur Aktualisierungshäufigkeit der IP-Standortdatei, zum Aktualisierungszeitpunkt für Details zur Meldung betrügerischen Verhaltens und PRTs sowie dazu, wie betrügerische Aktivitäten mithilfe von Anzeigentechnologien erkannt werden sollten. Die Erläuterung zu PRTs ist live, ebenso wie die Liste der Proxy-IP-Adressen und ihrer zugeordneten geografischen Regionen. Wir empfehlen, diese Datei regelmäßig auf Aktualisierungen und Änderungen zu prüfen, da IP-Adressen im Laufe der Zeit rotieren. Die öffentliche E-Mail-Adresse, unter der Missbrauch gemeldet werden kann, wird kurz vor der Einführung bekannt gegeben.
Geolocation Anfrage für eine öffentliche Liste der IP-Adressen, die für Proxys verwendet werden. Die Datei, in der IP-Adressen ungefähren Standorten für den IP-Schutz zugeordnet werden, finden Sie hier. Diese Datei wird regelmäßig aktualisiert.
API-Verwendung Es wird behauptet, dass der IP-Schutz standardmäßig aktiviert ist und Nutzer keine Möglichkeit haben, ihn zu deaktivieren. Der IP-Schutz ist für Nutzer im Inkognitomodus von Chrome auf Android- und Desktop-Plattformen verfügbar. Nutzer können den IP-Schutz deaktivieren. Bei unternehmensverwalteten Versionen von Chrome kann der IP-Schutz aktiviert werden, ist aber standardmäßig deaktiviert.
API-Verwendung Anfrage zur Verfügbarkeit eines experimentellen Flags zum Aktivieren und Testen des IP-Schutzes in Chrome Canary- und Beta-Releases. Derzeit gibt es kein Testflag, mit dem die vollständige Funktion zum Schutz von geistigem Eigentum getestet werden kann. Bei den funktionalen Tests wird nur Proxy-Traffic zu Google-Domains verwendet.
Datenschutz bei IP-Adressen Wie funktionieren die Einstellungen für 3rd-Party-Prompts, wenn ein Browser in den Inkognitomodus wechselt? Drittanbieter-Cookies sind im Inkognitomodus standardmäßig blockiert.
Inkognitomodus Ich möchte wissen, ob der IP-Schutz im Inkognitomodus funktioniert, wenn der Nutzer nicht in Chrome angemeldet ist. Der IP-Schutz ist nicht aktiv, wenn sich der Nutzer nicht vor dem Starten des Inkognitomodus in Chrome angemeldet hat. Das dient der Betrugs- und Missbrauchsprävention, insbesondere der Zugriffsbeschränkung auf die Proxys. Der IP-Schutz verwendet die Clientauthentifizierung, um die Möglichkeiten von böswilligen Akteuren einzuschränken, die Proxys zu nutzen, um Angriffe auf Dienste im mDL zu verstärken. Daher ist der IP-Schutz nur für Nutzer verfügbar, die sich mit dem Google-Konto authentifiziert haben, mit dem sie im Chrome-Browser angemeldet sind, bevor sie ein neues Inkognitofenster öffnen.
Inkognitomodus Anfragen zur Bewertung der Auswirkungen von IP-Schutz vor der Einführung, einschließlich:
(1) Vorschlag zur Verwendung eines Browserstatus-Flags oder aggregierter API-Berichte zur Quantifizierung der Nutzung des Inkognitomodus;
(2) Senden eines IP-Schutz-Headers für einen bestimmten Zeitraum vor Aktivierung der Funktion; und
(3) Bereitstellung der Funktion für einen kleinen, bekannten Prozentsatz des Traffics zur Extrapolation.		 Uns ist bewusst, dass es im Interesse der Branche liegt, den Umfang und die Auswirkungen des Schutzes geistigen Eigentums zu verstehen und zu messen. Chrome arbeitet jedoch daran, die Privatsphäre der Nutzer zu schützen, die sich für den Inkognitomodus entscheiden. Chrome bietet keine Methode, um Nutzer zu erkennen, die im Inkognitomodus surfen. Außerdem wurden Maßnahmen ergriffen, um andere Signale einzuschränken, die den Browsermodus des Nutzers verraten könnten.

Wir überlegen, wie wir diese Tests ermöglichen können, ohne die Privatsphäre der Nutzer zu beeinträchtigen, die im Inkognitomodus surfen. Wir freuen uns über zusätzliches Feedback aus der Community.

Eindämmung von Bounce-Tracking

Feedbackthema Zusammenfassung Chrome-Antwort
Compliance Die Weigerung von Google, die Verwendung der datenschutzkonformen Bounce Tracking Mitigations-Technologie zuzulassen, hat keine rechtliche Grundlage und macht das Einlegen von Einsprüchen bei der Privacy Sandbox sinnlos. Wie wir in unserem letzten Feedbackbericht erläutert haben, hat der Compliance-Status keinen Bezug zur Anwendung von BTM. Google trifft keine Entscheidungen hinsichtlich der Compliance bei der Implementierung von BTM. BTM zielt wie andere Chrome-Datenschutzmaßnahmen darauf ab, Nutzern mehr Kontrolle darüber zu geben, ob und wie ihre Daten weitergegeben werden.

Das im Bericht des CMA für die 2. und 3. Quartal erwähnte Verfahren zur Einlegung von Einsprüchen durch Dritte bezieht sich auf Bereiche, in denen Google Entscheidungen über die Aufnahme oder den Ausschluss einzelner Unternehmen in Listen trifft.
Compliance Diskussion darüber, wie Browser die Einhaltung der rechtlich erforderlichen Einwilligungen im Rahmen der DSGVO sicherstellen. Dabei werden Szenarien hervorgehoben, in denen Browser Aktionen (z. B. Weiterleitungen oder Cookie-Einstellungen) unterdrücken können, in denen Nutzer ausdrücklich eingewilligt haben, was zu einem Konflikt zwischen rechtlicher Einwilligung und Datenschutzeinstellungen des Browsers führt. Der Browser kann nicht erkennen, welche Beziehung zwischen einem Nutzer und einer Website besteht. Außerdem gibt es beim aktuellen BTM-Verhalten bereits Umgehungsmöglichkeiten, mit denen Nutzer ausdrücklich ihre Einwilligung zum Tracking von Absprungen für eine bestimmte Website geben können.

Weitere Informationen zur Einhaltung der Anforderungen finden Sie in unseren häufig gestellten Fragen zum Datenschutz.
Mehrzweckstandorte Ich möchte wissen, ob Übergänge von WebView oder App-zu-Web (Chrome) gemäß BTM als „Websites mit doppeltem Verwendungszweck“ eingestuft werden. Der Browser kann nicht erkennen, ob eine Ausstiegskette über eine Weiterleitung von einer WebView oder App gestartet wurde.

Aus diesem Grund werden diese Zugriffe von BTM nicht gesondert behandelt. Stattdessen wird der Ablauf als websiteübergreifender Ausstieg ab „about:blank“ interpretiert und das Standardverhalten wird fortgesetzt.

Websiteübergreifende Datenschutzgrenzen stärken

Feedbackthema Zusammenfassung Chrome-Antwort
API-Verwendung Bedenken hinsichtlich des potenziellen Missbrauchs von RWS in Verbindung mit dem IP-Schutz Wenn IP-Adressen für Organisationen in einem RWS-Set freigegeben werden, könnten diese Organisationen dazu veranlasst werden, sich mehreren RWS-Sets anzuschließen, um Zugriff auf portable IP-Adressdaten für das Tracking von Inkognito-Nutzern zu erhalten. Die festgelegten Anforderungen für verknüpfte Websites, Dienstwebsites und Sets insgesamt, die durch automatisierte Validierungen erzwungen werden, verringern den potenziellen Anreiz, mehrere Sets zusammenzuführen.

Wenn Sie Nutzeraktivitäten über Sets hinweg über IP-Adressen zusammenführen möchten, muss eine MDL-Domain in einem Set enthalten sein. Dazu ist eine Abstimmung zwischen dem Setinhaber und dem Domaininhaber erforderlich. Dieses Risiko gilt auch für einzelne Websites (d.h. ohne Gruppen ähnlicher Websites), die mit MDL-Domains koordiniert werden.

Hier finden Sie weitere Informationen zu dieser Frage.

Fenced Frames API

Feedbackthema Zusammenfassung Chrome-Antwort
Native Anzeigen Feedback, dass abgegrenzte Frames in ihrer aktuellen Form nicht mit dem Geschäftsmodell für native Anzeigen kompatibel sind, da Anzeigen flexibel an die umgebenden Inhalte angepasst werden müssen. Wir prüfen weiterhin die Anforderungen des Werbesystems und das aktuelle Angebot für eingerahmte Videoanzeigen. Wie bereits erwähnt, sind abgegrenzte Frames frühestens 2026 erforderlich.

Shared Storage API

Feedbackthema Zusammenfassung Chrome-Antwort
API-Fehler In Chrome wird ein Fehler protokolliert, wenn der Budgetierungsmechanismus der Shared Storage API die Ausführung des Vorgangs „selectURL“ verhindert, obwohl dies ein normales Verhalten ist. Bitten Sie Chrome, die Protokollierungsebene von „Fehler“ auf „Warnung“ oder „Information“ herabzustufen, da der Fehler für den Aufrufer nicht behoben werden kann. Die Änderung wurde implementiert und ist in Chrome M134 enthalten, das seit dem 4. März 2025 verfügbar ist.

CHIPS

Feedbackthema Zusammenfassung Chrome-Antwort
API-Dokumentation Es ist eine Klarstellung erforderlich, was der Sicherheitsschutz von partitionierten Cookies im Vergleich zu SameSite=Lax/Strict-Cookies ist. Vorschlag: In der Dokumentation sollte ausdrücklich darauf hingewiesen werden, dass partitionierte Cookies nicht den gleichen Schutz vor XSS- und CSRF-Angriffen bieten wie SameSite=Lax/Strict-Cookies. Wir aktualisieren die Erläuterung und die Spezifikation, um die Semantik und den Schutz durch partitionierte Cookies zu verdeutlichen.

FedCM

Feedbackthema Zusammenfassung Chrome-Antwort
Benutzeroberfläche und Sicherheit Feedback, dass die FedCM-Benutzeroberfläche zu ähnlich der bisherigen One-Tap-Anmeldung von Google ist, dass die FedCM-Leistung aufgrund fehlender passiver Präsentationsaufzeichnungen schwer zu quantifizieren ist, und eine Empfehlung für eine stärkere Dokumentation in Bezug auf PKCE. Wir arbeiten aktiv mit Stakeholdern zusammen, um ihr Feedback zu berücksichtigen. Derzeit werden unter anderem Möglichkeiten diskutiert, wie Identitätsanbieter bessere Messwerte erhalten können, um die FedCM-Leistung zu erfassen, und mögliche Verbesserungen, um neue Anwendungsfälle für FedCM im Zusammenhang mit Abos zu berücksichtigen.
API-Verwendung Wenn ein Nutzer die Seite aktualisiert und „navigator.credentials.get“ aufruft, um sich anzumelden, wird ein Pop-up-Fenster angezeigt, in dem er klicken muss, um fortzufahren. Dies führt zu einer Verzögerung, die sich auf die Nutzerfreundlichkeit auswirkt. Können vertrauende Seiten (Relying Parties, RPs) das von navigator.credentials.get zurückgegebene Token im Cache speichern, um die Nutzerfreundlichkeit zu verbessern? RPs können eigene Cookies verwenden, um das Token zu speichern. RPs können dann ihre eigenen Cookies prüfen, um festzustellen, ob ein Nutzer angemeldet ist, bevor sie navigator.credentials.get aufrufen. Weitere Informationen
Mehrere Identitätsanbieter auswählen Wie würden die Anmeldeoptionen für mehrere Identitätsanbieter (IdPs) in FedCM im Browser angezeigt? In der Entwicklerdokumentation finden Sie Informationen dazu, wie mehrere Identitätsanbieter angezeigt werden. Stakeholder können diese Funktion ausprobieren, indem sie das Flag „fedcm-multi-idp“ unter chrome://flags aktivieren.
Browser und Identitätsanbieter Kann ein Browser wie Chrome selbst als Identitätsanbieter fungieren? Browser könnten ihre gespeicherten Konto- und Profildaten als vertrauenswürdige Authentifizierungsquelle verwenden. Da Browser geändert werden können (z.B. über Erweiterungen), können E-Mail-Bestätigungen, die direkt über den Browser erfolgen, ohne zusätzliche serverbasierte Bestätigung nicht als vertrauenswürdig eingestuft werden. Daher wird eine rein clientbasierte Lösung nicht empfohlen.

Weitere Informationen zu diesem Thema
API-Spezifikation Diskussion darüber, ob der Parameter für den Algorithmus „IdentityCredential.disconnect()“ erforderlich oder optional sein sollte. Dieser Fehler wurde jetzt behoben. Weitere Informationen
API-Sicherheit Bedenken hinsichtlich Tokenlecks beim FedCM-Anmeldevorgang, wenn ein RP eine XSS-Sicherheitslücke hat Ein Angreifer könnte navigator.credentials.get in schädlichem Code ausführen, um das Token zu erhalten. FedCM schafft keine neuen XSS-Risiken. Diese Risiken sind Webanwendungen und bestehenden Authentifizierungsprotokollen inhärent. Um diese Risiken zu minimieren, sollten RPs den aud-Anspruch in ID-Tokens prüfen und nur Behauptungen akzeptieren, die von ihrem eigenen Ursprung ausgestellt wurden. Wie hier erläutert, gibt es weithin anerkannte Best Practices zur Sicherung dieser Tokenübertragung, die derzeit für die Verwendung mit FedCM verfügbar sind.

Außerdem kann die Storage Access API mit FedCM verwendet werden. Storage Access API-Aufrufe werden automatisch gewährt, wenn zuvor ein FedCM-Aufruf erfolgt ist. Dadurch sollte der eingebettete Weiterleitungsvorgang aktiviert werden, der im GitHub-Problem beschrieben wird.
API-Spezifikation „client_metadata_endpoint“ ist ein Pflichtfeld in der Antwort des Konfigurationsendpunkts für FedCM. Ein leeres Objekt ist eine gültige Antwort und Chromium ignoriert eine 404-Antwort stillschweigend. Das bedeutet, dass der Endpunkt in der Praxis als optional behandelt wird. Wir sind der Meinung, dass die Spezifikation entsprechend geändert werden könnte und der client_metadata_endpoint zu einem optionalen Feld werden sollte.
API-Verwendung Bedenken hinsichtlich der Schwierigkeit, FedCM-Implementierungen zu testen, da die browsergesteuerten Benutzeroberflächen nicht über das DOM zugänglich sind. Wir unterstützen die Browserautomatisierungs-APIs für Regressionstests, mit denen diese Probleme möglicherweise behoben werden können. Diese APIs sind hier dokumentiert.
API-Spezifikation Der Parameter „login_url“, der ein erforderlicher Teil der Antwort des Konfigurationsendpunkts ist, wurde in Abschnitt 3.2 der Spezifikation nicht dokumentiert. Wir haben die Dokumentation aktualisiert und den Parameter „login_url“ in Abschnitt 3.2 aufgenommen.
API-Spezifikation Bedenken hinsichtlich eines potenziellen Tracking-Vektors in FedCM Ein IdP kann IDs als Pfadparameter in die Endpunkte einfügen, die in der Antwort des Konfigurationsendpunkts (accounts_endpoint, client_metadata_endpoint) angegeben sind, und diese IDs verwenden, um die Anfragen für Konto- und Clientmetadaten zu korrelieren. Wir haben zwar keine Hinweise darauf, dass Identitätsanbieter IDs in diese Endpunkte einfügen, prüfen aber derzeit Maßnahmen, um dieses Problem zu beheben. Weitere Informationen

Spam und Betrug bekämpfen

Private State Tokens API (und andere APIs)

In diesem Quartal haben wir kein Feedback erhalten.