Feedbackbericht – 2. Quartal 2025

Vierteljährlicher Bericht für das 2. Quartal 2025, in dem das Feedback aus dem Ökosystem zu Privacy Sandbox-Vorschlägen und die Reaktion von Chrome zusammengefasst werden.

Google hat diesen vierteljährlichen Bericht im Rahmen seiner Verpflichtungen gegenüber der Wettbewerbs- und Marktaufsichtsbehörde (Competition and Markets Authority, CMA) gemäß den Absätzen 12, 17(c)(ii) und 32(a) erstellt. Dieser Bericht umfasst die Fortschritte von Google bei den Privacy Sandbox-Vorschlägen, aktualisierte Zeitplanerwartungen, ausführliche Erklärungen dazu, wie Google die Beobachtungen von Drittanbietern berücksichtigt hat, und eine Zusammenfassung der Interaktionen zwischen Google und der CMA, einschließlich des Feedbacks der CMA und des Ansatzes von Google zur Berücksichtigung des Feedbacks.

Google hat die CMA in regelmäßigen Statusbesprechungen, die gemäß Absatz 17(b) der Verpflichtungen geplant sind, über die Fortschritte bei den Privacy Sandbox-Vorschlägen auf dem Laufenden gehalten. Außerdem verwaltet das Team die Entwicklerdokumentation, die Übersichten zu den wichtigsten Funktionen für private Werbung und Cookie-Änderungen sowie Informationen zur API-Implementierung und zum Status enthält. Wichtige Neuigkeiten werden im Entwicklerblog veröffentlicht. Außerdem werden gezielte Updates an die Mailinglisten der einzelnen Entwickler gesendet.

Berücksichtigung von Beobachtungen Dritter

Glossar der Akronyme

ARA
Attribution Reporting API
CHIPS
Cookies Having Independent Partitioned State
DSP
Demand-Side-Plattform
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Identitätsanbieter
IETF
Internet Engineering Task Force
IP
IP-Adresse
openRTB
Echtzeitgebote
NSZ
Origin Trial
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

Feedback-Thema Zusammenfassung Chrome Response
Zukunft der Privacy Sandbox Angesichts der Ankündigung, dass kein Mechanismus zur Auswahl durch Nutzer für 3PCs eingeführt wird, sind einige APIs nützlicher als andere, wenn 3PCs vorhanden sind. Andere müssten weiterentwickelt werden, um nützlich zu sein. Neben den Privacy Sandbox-APIs gibt es weitere potenzielle Bereiche, in die Chrome investieren könnte. Wir wissen das Feedback zu schätzen und tauschen uns weiterhin mit Stakeholdern aus, um die Rolle der Privacy Sandbox-APIs in Zukunft zu bewerten und neue Bereiche für zukünftige Investitionen zu erkunden. Dies geschieht im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Privacy Sandbox Einige Teilnehmer des Ökosystems sind enttäuscht von der Ankündigung, keinen Mechanismus zur Auswahl durch Nutzer für 3PCs einzuführen. Sie sind jedoch stolz auf die geleistete Arbeit, wissen um die technischen Herausforderungen innerhalb der Privacy Sandbox und haben den Wert ihrer Zusammenarbeit mit Chrome sowie den Nutzen des Market Testing Grant hervorgehoben. Wir freuen uns über das Feedback und stimmen zu, dass Chrome mit Entwicklern zusammenarbeiten kann und sollte, um Technologien zu entwickeln, die den Datenschutz im Internet verbessern und gleichzeitig ein werbeunterstütztes Internet ermöglichen.
Freigabe von Browserdaten Die browserbasierte Datenfreigabe ist eine überzeugende Technologie, die das Potenzial hat, Marktineffizienzen und Vertrauensprobleme zu beheben. Der Browser hat als Drittanbieter-Ausführungskontext für die Zusammenarbeit einen Wert. Wir freuen uns über das Feedback und stimmen zu, dass Chrome eine Rolle dabei spielen kann und sollte, Entwicklern bei der Entwicklung von Technologien zu helfen, die das Vertrauen zwischen zusammenarbeitenden Entwicklern und Nutzern stärken.
Chrome-Traffic Wie hoch ist der Anteil des cookielosen Traffics in Chrome und der Anteil des Traffics im Inkognitomodus? Wie die CMA in ihrer Mitteilung zur Absicht, Zusagen freizugeben, anmerkt, wirkt sich der Inkognitomodus nur auf einen sehr kleinen Teil der Browsingaktivitäten aus. Im Vereinigten Königreich und im EWR macht der Chrome-Inkognitomodus weniger als 10% der Aufrufe auf Geräten mit dem Android-Betriebssystem und weniger als 10 % der Aufrufe auf Geräten mit dem Windows-Betriebssystem aus. Diese Messwerte beziehen sich nur auf Aufrufe in Chromium-basierten Chrome-Browsern im Vereinigten Königreich und im EWR.
Wir geben keine Daten zu Browsern weiter, die Drittanbieter-Cookies blockieren.
Entwickler können mithilfe von Storage Access-Headern festlegen, wann Cookies partitioniert werden, und entsprechende Gegenmaßnahmen ergreifen.
Chrome-Testlabels Was ist der Plan für die 1% des cookieless Traffics, der 2024 für Tests aktiviert wurde? Derzeit haben wir keine Pläne, die wir teilen können, aber wir beabsichtigen, sie öffentlich zu teilen, sobald sie verfügbar sind.
Chrome-Tests Umfasst die aktuelle Einrichtung des Testlabels eine Behandlung für Szenarien, in denen sowohl Drittanbieter-Cookies als auch Privacy Sandbox-APIs verfügbar sind? Die aktuelle Einrichtung der Testlabels umfasst die Behandlung von Drittanbieter-Cookies und Privacy Sandbox-APIs in Form von Modus A.
Privacy Sandbox Einige Werbetreibende finden Privacy Sandbox-APIs komplex und sind aufgrund früherer Vorbereitungsübungen apathisch. Sie fragen sich, wie sich der Vorteil für Early Adopters quantifizieren lässt, und suchen nach Informationen zu den Auswirkungen von Remarketing, Neukundengewinnung und Analyse. Wir freuen uns über das Feedback und verstehen die Bedenken hinsichtlich der technologischen Komplexität und der Bereitschaftsübungen.
Was die Leistung der aktuellen Privacy Sandbox-Technologien betrifft, haben unsere Testergebnisse gezeigt, dass die Teilnahme des Ökosystems ein entscheidender Faktor für die Leistung der Privacy Sandbox-Lösungen ist. Bei Tests mit geringen Mengen konnten die Marktdynamik und die Anreize für die Nutzung der Technologien in großem Umfang nicht reproduziert werden.

Registrierung und Bestätigung

In diesem Quartal wurde kein Feedback erhalten.

Relevante Inhalte und Werbung anzeigen

Themen

Feedback-Thema Zusammenfassung Chrome Response
Leistungs- und Nützlichkeitsinteresse an der Topics API mit Verbesserungen Das Feedback von Stakeholdern auf der Kaufseite deutet darauf hin, dass die Topics API ein wertvolles Signal ist und zu CPM-Daten (Cost-per-Impression) führt, die für Werbetreibendenkampagnen mit denen für Zielgruppen von Drittanbietern vergleichbar sind. Einige Publisher betrachten das Signal der Topics API als qualitativ hochwertiger als Standard-Signale aus dem offenen Web. Aufgrund dieses Feedbacks zur Nützlichkeit der Topics API fordern Stakeholder Verbesserungen, z. B. eine höhere Genauigkeit und Konsistenz der Taxonomie sowie eine Erweiterung der Publisher-Steuerelemente, um eine breitere Akzeptanz zu erreichen. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Nützlichkeit für
verschiedene Arten von
Stakeholdern		 Da für die Themenklassifizierung derzeit nur der Hostname der Seite verwendet wird, um die entsprechenden Themen zu definieren, werden auf großen Websites mit vielfältigen Inhalten allgemeine Themen beigetragen, während auf kleinen Websites Nischenthemen mit mehr Werbewert beigetragen werden. Unsere Antwort ähnelt der der vorherigen Quartale:
Wie bei 3PCs gibt es einen Unterschied im Wert der Informationen, die von verschiedenen Websites beigetragen werden. Websites mit Nischeninteresse sind in Bezug auf ihren Wertbeitrag inkonsistent: Nicht alle Websites mit Nischeninteresse haben kommerziell wertvolle Inhalte und tragen daher weniger zum Wert bei. Dies sind die Websites, die von der Topics API profitieren. Wir haben die Möglichkeit von Klassifizierungen auf Seitenebene anstelle von Websiteebene in Betracht gezogen. Eine solche Klassifizierung birgt jedoch eine Reihe erheblicher Datenschutz- und Sicherheitsbedenken.
Thementaxonomie nicht detailliert genug Die Topics API bietet nicht genügend Granularität für Nachrichtenverlage mit verschiedenen Inhaltsbereichen innerhalb einer einzelnen Domain. Das kann die Nützlichkeit der API für die Anzeigenausrichtung einschränken. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Verbesserung des Klassifikators Publishern wird erlaubt, Chrome Berechtigungen zu erteilen, um Themen basierend auf Seiteninhalten (z.B. Kopfzeile, Textkörper) zu klassifizieren. Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback hier.
Richtlinie Anfrage nach Klarstellung der Richtlinien zur Verwendung der Topics API in Verbindung mit Informationen von Drittanbietern Es gibt keine Schwierigkeiten bei der Verwendung der Topics API und von Drittanbieter-Cookies, da die Topics API eine Teilmenge der Funktionen von Drittanbieter-Cookies bietet.
Header „Observe-Browse-Topics“ Anfrage nach Klärung der Implementierung des Headers „Observe-Browse-Topics“, insbesondere ob die kontinuierliche Rückgabe des Headers Probleme verursachen würde. Wenn Sie den Observe-Browse-Topics: ?1-Header kontinuierlich zurückgeben, führt das nicht zu technischen Problemen.
Der Browser verarbeitet dieses Signal effizient und vermerkt lediglich, dass der Seitenbesuch für die Themenberechnung infrage kommt, ohne dass es zu Duplikaten oder Fehlern kommt. Das ist zwar nicht auf jeder Seite erforderlich, aber es ist eine gültige und einfache Strategie, es als Standardheader in allen Dokumenten der obersten Ebene zu senden.
Taxonomiekategorien Fordern Sie an, dass die aktuelle Thementaxonomie mit neuen Themen aktualisiert wird. Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von Entwicklern hier.
Nullwerte Anfrage nach Anleitung zur Verbesserung der Leistung der Topics API und zum Verständnis der Gründe für die Nullantworten, z. B. Filterung oder Sensibilität. Zur Klarstellung: null- oder leere Antworten von der Topics API sind eine erwartete Datenschutzfunktion und kein Fehler.
Eine null-Antwort kann folgende Ursachen haben:
• Datenschutzregeln:Eine zufällige null-Wahrscheinlichkeit von 5% oder weil Ihr Script den Nutzer auf Websites zu diesem Thema nicht „beobachtet“ hat.
• Nutzerstatus:Unzureichender Browserverlauf, Verwendung des Inkognitomodus oder der Nutzer hat die Einstellungen für die Anzeigendaten in Chrome deaktiviert.
• Technische Fehler:Auf Publisher-Websites muss der Observe-Browse-Topics: ?1-Header gesendet werden. Für alle aufrufenden iFrames ist die Berechtigung allow="Browse-topics" erforderlich.
Verwenden Sie zur Untersuchung die chrome://topics-internals-Fehlerbehebungsseite, um zu sehen, welche Themen Ihr Browser berechnet hat und warum.
Die Datenschutzfunktionen verhindern zwar eine Auslieferungsrate von 100 %, Sie können die Leistung jedoch verbessern, indem Sie
• mit Publishern zusammenarbeiten: Sorgen Sie dafür, dass Ihre Partner den Observe-Browse-Topics: ?1-Header auf ihren Websites richtig senden.
• Code überprüfen:Wenn Sie iFrames verwenden, prüfen Sie, ob die allow="Browse-topics"-Richtlinie vorhanden ist.

Protected Audience API

Feedback-Thema Zusammenfassung Chrome Response
PA API-Einführung durch Kosten und Komplexität behindert Unternehmen, die die Protected Audience API (PA API) eingeführt haben, geben ihr weniger Priorität oder machen die Integrationen rückgängig. Als Gründe werden Betriebskosten, mangelnde Nachfrage von Werbetreibenden und ein geringes Inventarvolumen von Anzeigenplattformen genannt.
Einige Rückmeldungen enthielten Vorteile des Potenzials der PA API, z. B. die Möglichkeit, dauerhafte Zielgruppen zu erstellen und aufgrund einer hohen Abgleichsrate eine höhere Reichweite zu erzielen.		 Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Plattformübergreifende Funktionen Plattformübergreifende Funktionen sollten durch die Nutzung der PA API auf allen Plattformen unterstützt werden, um bessere Retargeting- und Zielgruppenausrichtungsfunktionen zu ermöglichen. Google sollte dafür sorgen, dass in Chrome registrierte Interessengruppen beim Ausliefern von Anzeigen in nativen Umgebungen oder in WebViews zugänglich sind und dass in Android registrierte Interessengruppen in Chrome-Auktionen verfügbar sind. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
directFromSellerSignals Durch die Begrenzung der in der kontextbezogenen Auktion verfügbaren Informationen werden Auktionsteilnehmer immer über den Google-Anzeigenserver weitergeleitet. Ein Publisher muss zuerst alle seine Exchange-Partner und dann Google Ad Manager (GAM) aufrufen, um die kontextbezogene Auktion auszuführen und schließlich GAM zu ermöglichen, IG-Auktionen aufzurufen. Ohne das Ergebnis der kontextbezogenen Auktion in Echtzeit zu kennen, kann kein Mitbewerber eine Entscheidung auf höchster Ebene fair treffen.

Die Funktion „directFromSellerSignals“ in der PA API bietet möglicherweise keine ausreichende Transparenz in Bezug auf Auktionsinformationen, was den Zugriff auf erforderliche Daten erschweren kann. Google sollte „directFromSellerSignals“ entweder entfernen oder so aktualisieren, dass damit nicht der Mindestpreis der Anzeigenauktion des Ad-Servers verborgen werden kann. Der kontextbezogene Preis könnte beispielsweise über ein transparentes, unveränderliches, signiertes Feld an Chrome übergeben werden, auf das alle Auktionsteilnehmer (und der Publisher) zugreifen und das sie überprüfen können.		 Unsere Antwort ist gegenüber den vorherigen Quartalen unverändert:
Antwort von Chrome:
Informationen, die an runAdAuction() übergeben werden, stammen nicht vom Verkäufer, es sei denn, der Verkäufer ruft runAdAuction() über seinen eigenen iFrame auf. Bei einer Auktion mit mehreren Verkäufern ist es nicht möglich, dass alle Verkäufer den Frame erstellen, der runAdAuction() aufruft. Mit „directFromSellerSignals“ wurde dieses Problem behoben, indem Inhalte aus einem Subressourcen-Bundle geladen wurden, das vom Ursprung eines Verkäufers geladen wurde. So wird sichergestellt, dass die Authentizität und Integrität von Informationen, die aus den Verkäuferauktionskonfigurationen in eine Auktion übertragen werden, nicht manipuliert werden können. Wenn Publisher die PA API verwenden möchten, um Informationen zu den Daten zu erhalten, die ihre Technologieanbieter in PA-Auktionen übergeben, können sie diese Technologieanbieter nach dieser Funktion fragen.
Antwort von Google Ad Manager:
Wir legen seit Jahren großen Wert auf faire Auktionen. Dazu gehört auch unser Versprechen, dass kein Preis aus einer der nicht garantierten Anzeigenquellen eines Publishers, einschließlich der Preise für nicht garantierte Werbebuchungen, an einen anderen Käufer weitergegeben wird, bevor dieser in der Auktion ein Gebot abgibt. Dieses Versprechen haben wir später in unseren Zusagen an die französische Wettbewerbsbehörde noch einmal bekräftigt.
Bei Protected Audience-Auktionen möchten wir unser Versprechen einhalten, indem wir „directFromSellerSignals“ nutzen und das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion in Auktionen mit mehreren Verkäufern nicht an andere Auktionsteilnehmer weitergeben. Wie in diesem Update erläutert, geben wir den Preis der kontextbezogenen Auktion auch nicht an unsere eigene Komponentenauktion weiter.
Berichte Anfrage zum Hinzufügen einer Analyse-/Berichtseinheit, um eine zentrale Berichterstellung zu ermöglichen. Wir diskutieren diese Anfrage hier und freuen uns über zusätzliches Feedback.
k-Anonymität für buyerReportingId Gebote können anhand der k-Anonymität der „buyerReportingId“ verworfen werden, um die Zielgruppenauswahl und die Berichterstellungspflichten gegenüber Drittanbieterdaten zu erleichtern. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Verbesserte Fehlerbehebung im generateBid-Script Anfordern eines Mechanismus, mit dem die spezifische Phase oder der „Breakpoint“ im generateBid-Skript schnell identifiziert werden kann, an dem der Prozess fehlschlägt. Wir wissen, dass Echtzeitmessungen als Mechanismus zum Festlegen von Breakpoints für On-Device-Auktionen verwendet werden sollen. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs in Zukunft spielen werden, angesichts der Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Auswahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Event-Listener zum Überwachen des Status von „runAdAuction“ Vorschlag, der Funktion „navigator.runAdAuction“ der PA API Unterstützung für Event-Listener hinzuzufügen, um das Monitoring des Anzeigenauktionslebenszyklus zu verbessern. Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus dem Ökosystem hier.
API-Verwendung Bitte erläutern Sie, wie die PA API und die Attribution Reporting API (ARA) Webwerbe-Anwendungsfälle ohne Drittanbieter-Cookies unterstützen können, insbesondere für Nutzer, die Drittanbieter-Cookies, aber nicht Privacy Sandbox-APIs deaktiviert haben, und in Szenarien mit fehlgeschlagenen Cookie-Synchronisierungen und WebView. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Latenz Die Latenz, die mit der PA API verbunden ist, kann die Akzeptanz behindern, da Publisher die PA API möglicherweise deaktivieren, wenn die Latenz zu hoch ist. In den letzten Quartalen wurden mehrere Verbesserungen an der On-Device-Latenz vorgenommen. Die Entwicklung und Skalierung von Gebots- und Auktionsdiensten (Bidding and Auction, B&A) wird nach Bedarf fortgesetzt. Unser Leitfaden zu Best Practices für die Latenz wurde aktualisiert und enthält jetzt weitere Informationen dazu, wie Sie diese Funktionen nutzen können. Wir arbeiten auch an neuen Verbesserungen der Latenz, von denen einige hier eingesehen werden können.
Logging-Verhalten in B&A (Test im Vergleich zur Produktion) Klarstellung der Unterschiede beim Logging-Verhalten zwischen Test- und Produktionsmodus für B&A-Dienste. Insbesondere die Verfügbarkeit von Cloud-Logs und die Auswirkungen des Produktionsmodus auf die Protokollierung. Zuerst ist es wichtig, zwischen Produktions- und Nichtproduktions-Builds und dem separaten Parameter TEST_MODE zu unterscheiden, der lediglich einen fest codierten Testverschlüsselungsschlüssel aktiviert. Die folgende Erklärung konzentriert sich auf die Build-Typen.
In nicht produktiven Builds bieten B&A-Server eine konfigurierbare Ausführlichkeitsstufe für das Logging. Diese detaillierten Logs werden in die Standard-Streams stdout/stderr geschrieben. In Google Cloud sind sie über die native Logging-Schnittstelle zugänglich und in Amazon Web Services finden Sie sie in den Logs der angehängten Konsole.
Bei Prod-Builds ist das Logging-Verhalten eingeschränkter. Die Ausführlichkeitsstufe ist festgelegt und kann nicht geändert werden. Einige nicht datenschutzrelevante Logs, z. B. Serverstartmeldungen und die meisten Absturzfehler, werden weiterhin in stdout/stderr ausgegeben. Anfragespezifische Logs sind über diesen Kanal jedoch nicht verfügbar. Die einzigen Protokolle pro Anfrage aus einem Produktionsbuild sind für Anfragen, die ein Debugging-Token mit Einwilligung enthalten. Diese werden ausschließlich über OpenTelemetry exportiert. Es ist wichtig, die Debugging-Funktion mit Einwilligung nur sparsam zu verwenden, da starker Traffic die Serverleistung beeinträchtigen und zu Fehlern bei der Statusprüfung führen kann.
Alle Messwerte werden über OpenTelemetry exportiert. Nicht datenschutzrelevante Messwerte werden immer unverändert exportiert, ohne dass sie mit Rauschen versehen werden. Umgekehrt werden datenschutzrelevante Messwerte immer mit Rauschen versehen, wenn sie von einem Server exportiert werden, der im Produktionsmodus ausgeführt wird. Die spezifische Telemetriekonfiguration bestimmt, ob diese datenschutzrelevanten Messwerte verrauscht, unverrauscht oder beides exportiert werden.
Vollständigen Seitenpfad in vertrauenswürdige Gebotssignale für Markensicherheit aufnehmen Anfrage nach einer Aktualisierung der PA API, damit im Abrufvorgang für „trustedBiddingSignals“ zusätzlich zum Hostnamen auch der vollständige URL-Pfad der Seite der obersten Ebene enthalten ist.
Der primäre Anwendungsfall besteht darin, differenziertere Einstellungen für die Markensicherheit zu ermöglichen. Werbetreibende müssen oft verhindern, dass Anzeigen in bestimmten Bereichen einer Domain (z.B. nachrichtenseite.de/politik) ausgeliefert werden, während sie mit der Domain im Allgemeinen zufrieden sind. Da diese Blockierlisten Millionen von Einträgen enthalten können, müssen sie serverseitig ausgewertet werden. Die aktuelle Spezifikation, bei der nur der Hostname gesendet wird, macht es dem trustedBiddingSignals-Server unmöglich, diese erforderliche Pfadebene zu bewerten, was die Möglichkeiten zur Markensicherheit einschränkt.		 Wir diskutieren dieses Problem derzeit hier. Zuvor gab es bereits ausführliche Diskussionen, die hier nachgelesen werden können. Wir freuen uns über weiteres Feedback.
Wir möchten jedoch klarstellen, dass wir diese Informationen nur dann hinzufügen, wenn der Abruf von „trustedBiddingSignals“ an einen Server erfolgt, der in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt wird.

Geschützte Auktion (B&A-Dienste)

Feedback-Thema Zusammenfassung Chrome Response
Verfügbarkeit von Tests Informationen zur Verfügbarkeit von Key/Value (KV) v2 für Tests in Chrome- und B&A-Umgebungen. KV v2 ist sowohl in B&A als auch in Chrome verfügbar. Weitere Informationen
KV-Server-Implementierung Anfrage nach Klärung der Verwendung des KV-Servers, insbesondere in Bezug auf die Zuordnung von Creative-Render-URLs zu Anfragedaten, die Notwendigkeit der Koordination zwischen SSPs und DSPs bei der Definition von Parametern in der Render-URL und die Verfügbarkeit von Dokumentation, in der die erforderliche Koordination und Datenspeicherung im KV-Modus beschrieben werden. Der KV-Dienst verwendet die renderURL als Schlüssel. Wenn die URL neu ist, wird sie gespeichert. Wenn sie vorhanden ist, wird ihr Wert zur Verwendung in „scoreAd“ zurückgegeben. Das Rückgabeformat hängt von der Einrichtung ab: Bei „Bring Your Own Server“ (BYOS) ist jeder Wert zulässig, während für den Trusted KV-Dienst eine benutzerdefinierte Funktion erforderlich ist.
Die Abstimmung mit DSPs ist zwar nicht immer erforderlich, aber für Funktionen wie den Makroersatz (z.B. ${AD_WIDTH}) in der renderURL, wodurch eine dynamische Anpassung und Überprüfung von Anzeigen möglich ist.
Wir empfehlen, mit einem einfachen Test mit einer DSP zu beginnen, um den erforderlichen Koordinierungsgrad zu ermitteln. Wir aktualisieren derzeit auch unsere KV-Dokumentation und werden sie öffentlich freigeben, sobald sie verfügbar ist.
BYOS für B&A Warum bietet B&A keinen BYOS-Modus an, der dem BYOS-Modus von KV ähnelt? B&A erfordert eine TEE, was ein BYOS-Modell verhindert, da es hochsensible Datenkombinationen verarbeitet, die die Durchsetzung von Datenschutzmechanismen erfordern, wie unten erläutert.
Für DSPs:
Bei B&A-Prozessen wird der Kontext des Publishers (möglicherweise die vollständige URL, wenn sie vom Verkäufer explizit über „auctionSignals“ / „perBuyerSignals“ gesendet wird) mit detaillierten Nutzer-IG-Daten kombiniert. Die TEE ist unerlässlich, um diese Kombination sicher zu verarbeiten und eine potenzielle Re-Identifizierung von Nutzern zu verhindern. Bei KV BYOS kann die vollständige URL nicht gesendet werden.
Für SSPs:
Allein die Kombination der teilnehmenden Interessengruppen (und ihrer DSP-Inhaber) in einer Auktion kann eine identifizierende Signatur generieren. Hier kommt die Chaffing-Lösung ins Spiel, für die ein TEE erforderlich ist.
Die sichere Verarbeitung dieser kombinierten sensiblen Signale und die Durchsetzung von Datenschutzmechanismen erfordern daher die kontrollierte, bestätigte Umgebung einer TEE.

Digitale Anzeigen analysieren

Attribution Reporting (und andere APIs)

Feedback-Thema Zusammenfassung Chrome Response
Richtlinie zu Lärm Die Implementierung von ARA war für einige Marktteilnehmer von Vorteil und Google sollte weiterhin Berichte auf Ereignisebene bereitstellen. Google sollte in Szenarien, in denen sowohl ARA als auch 3PCs verfügbar sind, eine Lockerung der Richtlinie zu Geräuschen in Betracht ziehen. Leistungsbezogene Werbetreibende verwenden zunehmend die aktuelle Implementierung des Felds „value“ des ARA-Flex-Events. Eine weniger restriktive Rauschrichtlinie würde dazu beitragen, Verzögerungen und ungenaue Berichte zu reduzieren. Dieser Mechanismus ist ein grundlegender Bestandteil des ARA-Designs, das den Datenschutz der Nutzer schützen soll, indem es individuelles Tracking verhindert. Wir berücksichtigen das Feedback zu den Herausforderungen bei der Berichterstellung, die durch Rauschen verursacht werden. Wir prüfen weiterhin, welche Rolle die Privacy Sandbox-APIs in Zukunft spielen werden, sowie mögliche zukünftige Verbesserungen. Dabei berücksichtigen wir die Ankündigung von Google vom April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Roadmap und Langzeitsupport Anfordern einer Produkt-Roadmap für ARA sowie einer Bestätigung der langfristigen Investitionen und des Supports angesichts der Ankündigung, keinen Mechanismus zur Auswahl durch Nutzer für 3PC einzuführen. Das Privacy Sandbox-Team arbeitet mit dem Ökosystem zusammen, um die zukünftige Rolle der Privacy Sandbox-APIs zu verstehen und mögliche zukünftige Investitionen zu bewerten.
Umgebungsübergreifende Analyse (App-zu-Web) Anfrage nach einer Lösung, bei der ARA verwendet wird, um die umgebungsübergreifende Analyse zu ermöglichen. Dies bietet einen saubereren und zuverlässigeren Datenfluss und verbessert die Möglichkeit, Nutzerinteraktionen auf verschiedenen Plattformen zu verknüpfen. App-to-Web auf demselben Gerät wird bereits von ARA unterstützt. Weitere Informationen zur Lösung für die App- und Webanalyse und hier
Browserübergreifende Attribution Ein einheitlicher, browserübergreifender Ansatz für ARA würde die Möglichkeit, den ROI im offenen Web zu messen, erheblich verbessern und eine stabile Alternative vor potenziellen regulatorischen Änderungen bieten. Chrome sollte mit dem Safari-Team an einer solchen Lösung zusammenarbeiten. Wir arbeiten bereits mit anderen Browseranbietern in den Gruppen PATCG und PATWG innerhalb des W3C an einer interoperablen API. Da diese Arbeit vorläufig ist, können Stakeholder unseren Fortschritt hier einsehen.
Geräteübergreifende/Offline-Analyse Die fehlende Unterstützung der geräteübergreifenden Conversion-Analyse in ARA ist eine erhebliche Einschränkung. Die Messung von Online-zu-Offline-Conversions ist ebenfalls sehr wichtig und der Browser könnte eine Rolle bei der Zusammenarbeit mit Messanbietern spielen. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Multi-Touchpoint-Attribution Anfrage, Werbetreibenden zu erlauben, Privacy Sandbox-Daten als unvoreingenommene „Ground Truth“ zu verwenden, um ihre vorhandenen Attributionsmodelle zu validieren und zu optimieren. Dies kann erreicht werden, indem die vom Browser bereitgestellten Daten von ARA als zuverlässiges Abgleichssignal verwendet werden, um eine Baseline zu erstellen. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Analyse von Zugriffen ohne Einwilligung/mit Opt-out Eine datenschutzfreundliche Lösung wie Interoperable Private Attribution würde Analysen für Traffic ohne Einwilligung ermöglichen. So lässt sich die Kampagnenleistung besser nachvollziehen, da auch Daten von Nutzern berücksichtigt werden, die das Tracking deaktiviert haben. Damit wird eine große Lücke in der Analyse geschlossen, die durch die Einwilligungspflicht entsteht. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Server-zu-Server-Attribution Anfrage, Anzeigentechnologien mit komplexer serverseitiger Infrastruktur flexibler in ARA einzubinden, um Anwendungsfälle zu berücksichtigen, die sich rein clientseitig nur schwer verwalten lassen, ohne den Datenschutz der Nutzer zu beeinträchtigen. Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.
Registrierung mehrerer Domains Wir bitten um Klarstellung zu Einschränkungen und Vorbehalten bei der Registrierung mehrerer Domains mit ARA, insbesondere in Bezug auf den Aggregationsdienst und die Cross-Origin-Attribution. Im Folgenden finden Sie die wichtigsten Einschränkungen bei der Verwendung von ARA mit mehreren Domains:
• Die Attribution ist auf einen einzelnen Ursprung beschränkt. Sie können einen Klick aus einer Ihrer Domains nicht mit einer Conversion in einer anderen Domain abgleichen. Die Zuordnung wird sowohl für die Quelle als auch für den Trigger in einer Sandbox mit demselben Ursprung ausgeführt.
• Der Aggregationsdienst unterstützt kein Batching mit mehreren Ursprüngen. Berichte unterschiedlicher Herkunft müssen separat verarbeitet werden. Wir arbeiten an Möglichkeiten, dies in Zukunft zu unterstützen.
Kurz gesagt: Mehrere Domains können unter einer Einheit registriert werden, aber alle ARA-Funktionen wie Attribution und Aggregation müssen derzeit auf Ursprungsebene verarbeitet werden.

Zusammenfassungsdienst

In diesem Quartal wurde kein Feedback erhalten.

Private Aggregation API

Feedback-Thema Zusammenfassung Chrome Response
Grenzwerte und Geräuschpegel Bedenken hinsichtlich der Einschränkungen für die Größe von Aggregationsschlüsseln und Aggregationswerten in der Private Aggregation API. Die Größen für Aggregationsschlüssel und ‑werte wurden so gewählt, dass eine hohe Granularität erreicht wird, ohne dass Netzwerk- und Speicherkosten zu hoch sind. Wir empfehlen außerdem, Hashing zu verwenden, wenn Sie Schlüssel zuweisen, um die Flexibilität zu maximieren.
Es gibt zwar auch andere Faktoren, die Nutzerdaten schützen, aber das Hinzufügen von Rauschen ist ein wichtiger Bestandteil der Datenschutzfunktionen der Private Aggregation API.
Wir berücksichtigen das Feedback und werden die entsprechenden Parameter weiterhin prüfen. Dabei werden wir auch die Rolle der Privacy Sandbox-APIs in Zukunft berücksichtigen, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl bei Drittanbieter-Cookies in Chrome zu lassen, beibehalten wird.
Datenschutz und Nützlichkeit Bei der Privacy Sandbox wird der Datenschutz möglicherweise über den Nutzen gestellt, was die Einführung behindern könnte. Vorschlag, die Datenfreigabe mit Einwilligung der Nutzer zu ermöglichen, um die Analyse und die Personalisierung von Anzeigen zu verbessern. Die Größen für Aggregationsschlüssel und ‑werte wurden so gewählt, dass eine hohe Granularität erreicht wird, ohne dass Netzwerk- und Speicherkosten zu hoch sind. Wir empfehlen außerdem, Hashing zu verwenden, wenn Sie Schlüssel zuweisen, um die Flexibilität zu maximieren.
Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, angesichts der Ankündigung von Google vom April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.

Verdecktes Tracking einschränken

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

Feedback-Thema Zusammenfassung Chrome Response
Spamerkennung Wenn die erste Anfrage einer Website, die ein System zur Spamerkennung verwendet, auf Client-Hinweisen basiert, kann das Tracking- oder Erkennungssystem die Anfrage möglicherweise nicht identifizieren oder richtig kategorisieren. Anwendungsfälle, die auf den Zugriff auf User-Agent-Client-Hints (UA-CH) bei der ersten Anfrage angewiesen sind, sollten kritische Client-Hints verwenden.
API-Feedback Erwägen Sie, Sec-CH-USA-Wow64 einzustellen, da es für das moderne Web nicht mehr relevant ist. Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback hier. Wir haben auch Feedback erhalten, dass es nützlich wäre, wow64 über Windows hinaus zu erweitern.

IP-Schutz (früher Gnatcatcher)

Feedback-Thema Zusammenfassung Chrome Response
Steuerelemente Anfrage für den Ein/Aus-Schalter für den IP-Schutz für Websites, die selektiv außerhalb des Inkognitomodus verwendet werden sollen. Vielen Dank für das Feedback. Hier können Sie uns weiteres Feedback zu diesem Problem geben.
Fehlverhalten Wird die Identifizierung von Tätern verhindert, wenn die Polizei die Offenlegung von IP-Adressen für Plattform-Fehlverhalten anfordert, weil Probabilistic Reveal Tokens (PRTs) einen NULL-Wert ergeben? Wenn eine Domain ausschließlich zur Erkennung von Betrug und Missbrauch verwendet wird, ist sie wahrscheinlich nicht in der Liste der maskierten Domains (Masked Domain List, MDL) enthalten und daher nicht von IP-Schutz betroffen. Daher wären für diese Domains keine PRTs erforderlich.
Wenn eine Domain in der MDL enthalten ist, sind PRTs derzeit die einzige Möglichkeit, die ursprüngliche IP-Adresse für eine Proxyanfrage zu ermitteln. Da PRTs speziell für die Unterstützung von aggregierten Analysen und nicht für die individuelle Identifizierung entwickelt wurden, enthalten sie in den meisten Fällen keine IP-Adresse. Wir gehen davon aus, dass die Auswirkungen in dem beschriebenen Szenario begrenzt sein werden, da der IP-Schutz nur im Kontext von Drittanbietern gilt. Das bedeutet, dass Publisher weiterhin nicht über Proxys geleitete IP-Adressen für First-Party-Interaktionen erhalten, z. B. wenn Nutzer die Website einer Onlineplattform besuchen.
Schutz vor Betrug Was sind die Besonderheiten der Betrugsschutzmaßnahmen von Google für den IP-Schutz, einschließlich Details zur Ratenbegrenzung des Zugriffs auf Proxys und zur Ausstellung von Authentifizierungstokens, und was sind die spezifischen Anwendungsfälle für PRTs? Wir bestätigen, dass Ratenbegrenzungen und Authentifizierungstokens in IP-Schutz dazu dienen, zu verhindern, dass Bots durch übermäßigen Zugriff auf Proxys Anzeigenbetrug begehen. Weitere Informationen finden Sie in der Strategie zur Betrugs- und Spambekämpfung. Weitere Anwendungsfälle für PRTs finden Sie in der Dokumentation zur Erläuterung von PRTs.
Inkognitomodus Ist der IP-Schutz im Inkognitomodus noch für das dritte Quartal geplant? Derzeit gibt es keine Änderungen am Zeitplan für die Einführung von IP-Schutz im Inkognitomodus im 3. Quartal.

Eindämmung von Bounce-Tracking

Feedback-Thema Zusammenfassung Chrome Response
API-Feedback Chrome sollte den Cookie-/Speicherzugriff blockieren, anstatt ihn zu partitionieren, wenn BTM (Bounce Tracking Mitigations) angewendet werden. Als Grund werden unbeabsichtigtes Verhalten und Verwirrung durch die „Partitionierungsmethode“ von Safari angeführt. Wir begrüßen diesen Vorschlag. Derzeit ist bei BTM keine Cookie-/Speicherpartitionierung vorgesehen. Stattdessen werden die Daten nach einer Kulanzfrist gelöscht. Sollte es später Designs für BTM geben, die sofortige Maßnahmen in Bezug auf Cookies erfordern, werden wir das Blockieren von Cookies dem Partitionieren vorziehen.

Websiteübergreifende Datenschutzgrenzen stärken

In diesem Quartal wurde kein Feedback erhalten.

Fenced Frames API

In diesem Quartal wurde kein Feedback erhalten.

Shared Storage API

Feedback-Thema Zusammenfassung Chrome Response
API-Funktionsanfrage Anfrage zum Anhängen von Anzeigenaufrufen und ‑klicks im freigegebenen Speicher Wir berücksichtigen dieses Feedback bei der Bewertung der Rolle, die die Privacy Sandbox-APIs künftig spielen werden, insbesondere im Hinblick auf die Ankündigung von Google im April 2025, dass der aktuelle Ansatz, Nutzern die Wahl von Drittanbieter-Cookies in Chrome zu ermöglichen, beibehalten wird.

CHIPS

Feedback-Thema Zusammenfassung Chrome Response
Frage zur API Anfrage nach Klärung, wie die 3PC-Steuerelemente von Chrome mit CHIPS interagieren, insbesondere ob nicht partitionierte Cookies in partitionierte Cookies umgewandelt werden, wenn 3PCs deaktiviert sind, und ob partitionierte Cookies aktiv bleiben. Nicht partitionierte Cookies werden in einem Drittanbieterkontext nicht gespeichert, abgerufen oder gesendet, wenn 3PCs deaktiviert sind. Partitionierte Cookies werden jedoch weiterhin im Drittanbieterkontext gespeichert, abgerufen und gesendet, da ihre Funktionalität nicht durch Browsereinstellungen beeinträchtigt wird, mit denen 3PCs deaktiviert werden.
Datenschutzrechtliche Bedenken Bedenken, dass eine eingebettete Partei mit einer dauerhaften Kennung, z. B. für Single Sign-On, sowohl der einbettenden als auch der eingebetteten Partei ermöglichen könnte, eine globale digitale Kennung zu erhalten, selbst wenn partitionierte Cookies verwendet werden. Eine eingebettete Partei kann zwar eine dauerhafte Kennung haben, aber wenn diese Kennung in einem partitionierten Cookie gespeichert wird, ist sie nur auf der Website zugänglich, auf der das Cookie durch die Einbettung gesetzt wurde. Für die websiteübergreifende Verknüpfung dieser Kennung ist eine Anmeldung erforderlich. Dadurch kann bereits eine Kennung in Form eines Authentifizierungstokens ausgetauscht werden, auch ohne partitionierte Cookies.

FedCM

Feedback-Thema Zusammenfassung Chrome Response
API-Verwendung Die stille Vermittlung schlägt für Nutzer mit mehreren Konten ohne spezifischen Fehler fehl. Das Verhalten bei der stillen Vermittlung ist so vorgesehen, da es für einen ganz bestimmten Fall mit nur einem verfügbaren Konto gedacht ist. Wir empfehlen stattdessen die Verwendung der optionalen Vermittlung, bei der FedCM auf die Präsentation einer Kontoauswahl für den Nutzer zurückgreift, wenn die stille Vermittlung nicht möglich ist.
API-Verwendung navigator.credentials.get gibt allgemeine Fehler zurück, sodass keine spezifischen Ablehnungsgründe wie das Schließen durch den Nutzer oder Wartezeiten erfasst werden können. Dass Entwickler nicht unterscheiden können, ob der Nutzer das FedCM-Dialogfeld geschlossen hat, ein Netzwerkfehler aufgetreten ist oder FedCM sich in einer „Abkühlphase“ befindet, weil der Nutzer das Dialogfeld zuvor geschlossen hat, ist ebenfalls ein Feature, das die Privatsphäre des Nutzers schützen soll. Die Befürchtung ist, dass Websites mit einer solchen Funktion den Anmeldestatus des Nutzers bei verschiedenen Identitätsanbietern (Identity Providers, IdPs) ableiten könnten.
Anmelden Es wurde ein inkonsistentes Verhalten bei der Kontoauswahl beobachtet, wenn mehrere Konten angemeldet sind. Es ist unklar, ob die zeitweise Unfähigkeit, ein bestimmtes Konto in einem Szenario mit mehreren angemeldeten Konten auszuwählen, ein zeitweiser Fehler in FedCM oder ein Problem mit dem Testsystem ist. Wir arbeiten mit dem Melder zusammen, um dieses Problem zu beheben, und haben ihn um weitere Details gebeten, damit wir das Problem besser nachvollziehen können.
API-Verwendung Wenn der Nutzer das Dialogfeld während der Autorisierung mit FedCM schließt, wird die Tatsache, dass er sich im Cooldown-Status befindet, nicht über einen abfangbaren Fehler gemeldet. Ja, das wäre der Fall und es würde der generische Fehlercode ausgegeben, um die Privatsphäre der Nutzer zu schützen.
API-Verwendung Warum wird FedCM nach einer erfolgreichen automatischen Reauthentifizierung für 10 Minuten in den Ruhemodus versetzt? Da die automatische Reauthentifizierung ohne eine vom Nutzer initiierte Aktion erfolgt, benötigt der Nutzer, wenn er zur Website zurückkehren, sich aber mit einem anderen Konto anmelden möchte, einen Zeitraum, in dem FedCM ihn nicht automatisch reauthentifiziert. Während des „Ruhezeitraums“ haben Nutzer die Möglichkeit, sich manuell mit einem anderen Konto anzumelden. In diesem Blogpost finden Sie weitere Informationen zu dieser „ruhigen Phase“.
Einfaches FedCM Bedenken, dass der Vorschlag für Lightweight FedCM zusätzliche Komplexität für Identitätsanbieter mit sich bringt, da zwei inkompatible Implementierungen (FedCM und Lightweight FedCM) unterstützt werden müssen. Lightweight FedCM ist mit dem herkömmlichen FedCM kompatibel. Identitätsanbieter können die Implementierungsmethode auswählen, die sie verwenden möchten, und müssen nicht beide unterstützen.
Lightweight FedCM ist ein Push-Mechanismus für FedCM. Wenn ein Identitätsanbieter diese Funktion verwendet, kann er die Kontoinformationen an den Browser senden, wenn sich der Nutzer anmeldet. Wenn eine vertrauende Partei FedCM aufruft, wird das Konto dann aus dem Browser anstelle des Kontenendpunkts des Identitätsanbieters abgerufen.
Einfaches FedCM Bedenken hinsichtlich der Offenlegung personenbezogener Nutzerdaten wie Name, E-Mail-Adresse und Profilbild gegenüber dem RP im Lightweight FedCM-Vorschlag. Der Vorschlag für Lightweight FedCM wurde seit Erhalt dieses Feedbacks aktualisiert, um den Namen, die E-Mail-Adresse und das Profilbild aus der Methodenantwort zu entfernen.
Einfaches FedCM Die Verwaltung mehrerer angemeldeter Konten scheint im Lightweight FedCM-Vorschlag zu starr zu sein. Der Vorschlag unterstützt derzeit keine individuellen Sitzungsdauern oder differenzierten Anmeldestatus pro Konto. Das Ablaufdatum ist derzeit an den IdP im credentials-Objekt gebunden. Wir haben das Ablaufdatum pro Konto als offene Frage notiert und werden dieses Feedback bei zukünftigen Entwicklungen berücksichtigen.
Einfaches FedCM Die Unterscheidung zwischen „angemeldet“ und „zur Auswahl verfügbar“ ist nicht klar definiert, was sich auf die Nutzerfreundlichkeit des Lightweight FedCM-Vorschlags auswirken könnte. Derzeit wird in der FedCM-Benutzeroberfläche nicht unterstützt, ob ein Konto angemeldet oder abgemeldet ist. Abgemeldete Konten sollten nicht aufgeführt werden.
Wenn ein Konto abgemeldet und aufgeführt ist und ein Nutzer das Konto auswählt, in dem er nicht aktiv angemeldet ist, kann die Continuation API verwendet werden, um den Nutzer wieder anzumelden.
API-Verwendung Inkonsistenz zwischen dem Feld given_name in getUserInfo und seiner Verwendung in der FedCM-Benutzeroberfläche. Dieses Problem wurde hier mit Mozilla besprochen, um zu klären, wie given_name in getUserInfo behandelt werden soll.
API-Verwendung Nicht alle Felder, die in der Benutzeroberfläche von IdentityProviderAccount verwendet werden, werden für getUserInfo bereitgestellt, insbesondere tel und username. Das deutet darauf hin, dass eine Synchronisierung erforderlich ist. Die Diskussion mit Mozilla und anderen Mitgliedern der FedID Community Group zum Abgleich der Felder aus IdentityProviderAccount, die an getUserInfo. gesendet werden, schreitet voran.
Enterprise FedCM Anfrage für FedCM-Unterstützung für Enterprise-IdP-Anwendungsfälle. Das Hauptproblem ist die Notwendigkeit eines vertrauenswürdigen Mechanismus für IdPs, um Browsern zu signalisieren, dass Administratoren der Nutzung bestimmter RPs durch den Nutzer vorab zugestimmt haben. Dieser Mechanismus darf nicht von Web-Trackern nachgeahmt und/oder missbraucht werden. Dies wurde in der FedID CG-Sitzung am 22. April besprochen (Notizen der Sitzung). Kombinationen aus Browsererweiterungen und Unternehmensrichtlinien (für verwaltete Geräte) wurden als mögliche Lösungen vorgeschlagen. Hier können Sie uns zusätzliches Feedback zu diesem Problem geben.

Spam und Betrug bekämpfen

Private State Token API (und andere APIs)

In diesem Quartal wurde kein Feedback erhalten.