Diese Seite wurde von der Cloud Translation API übersetzt.

Feedbackbericht – Q4 2023

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

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google zugestimmt, vierteljährlich Berichte über den Prozess der Einbeziehung der Stakeholder für seine Privacy Sandbox-Vorschläge zur Verfügung zu stellen (siehe Paragraf 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch das Sammeln von Feedback generiert, das Chrome von den verschiedenen in der Feedbackübersicht aufgeführten Quellen erhalten hat. Dazu gehören unter anderem GitHub-Probleme, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Plattform und sucht aktiv nach Möglichkeiten, das Gelernte bei Designentscheidungen zu berücksichtigen.

Feedbackthemen sind nach der Häufigkeit pro API geordnet. Dazu wird das Feedback, das das Chrome-Team zu einem bestimmten Thema erhalten hat, aggregiert und in absteigender Reihenfolge nach Anzahl sortiert. Die gemeinsamen Feedbackthemen wurden durch Überprüfung der Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktem Feedback, GitHub und häufig gestellten Fragen identifiziert, die über interne Teams von Google und öffentliche Formulare von Google gestellt wurden.

Genauer gesagt wurden die Besprechungsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, die von einzelnen Entwicklern eingegangenen E-Mails, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Google hat sich dann zwischen den Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, koordiniert, um die relative Verbreitung der in den einzelnen APIs entstehenden Themen zu ermitteln.

Die Erklärungen zu den Reaktionen von Chrome auf das Feedback basieren auf veröffentlichten FAQs, auf tatsächlichen Antworten auf von Stakeholdern vorgebrachte Probleme und auf der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts bei Entwicklung und Tests wurden insbesondere Fragen und Feedback zu den APIs Topics, Protected Audience und Attribution Reporting erhalten.

Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingeht, hat möglicherweise noch keine Antwort von Chrome als Antwort erhalten.

Glossar der Akronyme

CHIPS: Cookies mit unabhängig partitioniertem Status
DSP: Demand-Side-Plattform
FedCM: Federated Credential Management
fps: First-Party-Sets
IAB: Interactive Advertising Bureau
IdP: Identitätsanbieter
IETF: Internet Engineering Task Force
IP-Adresse: Internet Protocol-Adresse
openRTB: Echtzeitgebote
ÜS: Ursprungstest
PatCG: Private Community für Werbetechnologie-Gruppe
RP: Verlassende Partei
SSP: Supply-Side-Plattform
TEE: Vertrauenswürdige Ausführungsumgebung
UA: User-Agent-String
UA-CH: User-Agent-Client-Hints
W3C: World Wide Web Consortium
In Arbeit: Willful IP Blindness

Allgemeines Feedback, keine bestimmte API oder Technologie

Feedback	Zusammenfassung	Chrome-Antwort
3PCD-Zeitachse	Stellen Sie weitere Informationen zur 3PCD-Zeitachse bereit.	Um Tests zu vereinfachen, hat Chrome ab dem 4. Januar 2024 für 1% der Nutzer den Zugang zu Drittanbieter-Apps standardmäßig eingeschränkt. Vorbehaltlich etwaiger verbleibender Bedenken der CMA plant Chrome, die Unterstützung für Drittanbieter-PCs ab dem 3. Quartal 2024 schrittweise einzustellen und bis zum Ende des Jahres 2024 fortzusetzen.
3PCD-Zeitachse	Auswirkungen auf den Zeitpunkt der 3PCD im 4. Quartal 2024, da er mit der Festtagssaison zusammenfällt und negative Auswirkungen auf Publisher haben könnte.	Es gibt keinen perfekten Zeitpunkt, um 3PCs einzustellen. Seit über einem Jahr ist klar ersichtlich, dass 3PCs in der zweiten Jahreshälfte 2024 eingestellt werden sollen. Unsere Verpflichtungen gegenüber der CMA, einschließlich des möglichen Zeitpunkts für einen Stillstand, haben sich nicht geändert. Uns ist bewusst, dass das 4. Quartal der zeitliche Aufwand entscheidend ist. Allerdings haben Änderungen am Zeitplan dazu geführt, dass Sie sich weniger auf die Branche vorbereiten konnten.
Chrome-Tests (Modus a/b)	Erfolgt die Testeinrichtung für Modus A und Modus B pro Instanz oder pro Chrome-Profil?	In der Dokumentation finden Sie eine Klarstellung dazu, dass sich der Chrome-Browser in diesem Kontext auf einen Chrome-Client bezieht, also auf eine Chrome-Installation auf einem Gerät. Jedes einzelne Nutzerdatenverzeichnis stellt einen eigenen Client dar.
Testzeitraum zur Einstellung	Teile weitere Informationen zum 3PCD-Testzeitraum.	Weitere Informationen zur 3PCD-Testversion finden Sie hier.
Testzeitraum zur Einstellung	Nicht genug Zeit, um vor Januar 2024 Tokens für den Testzeitraum für alle Websites bereitzustellen.	Wir nehmen zur Kenntnis, dass zwischen dem Beginn der Registrierung für den Test zur Einstellung der Funktion und dem Blockieren von 1% der Cookies im Rahmen des von Chrome unterstützten Testzeitraums eine kurze Zeitspanne liegt. Aus diesem Grund bietet Chrome teilnehmenden Ursprüngen einen Kulanzzeitraum, während sie daran arbeiten, Testtokens zur Einstellung bereitzustellen. Während des Kulanzzeitraums bis zum 1. April 2024 haben Ursprünge, die für den Einstellungstest registriert sind, Zugriff auf Drittanbieter-PCs in Chrome, auch wenn sie ihre Tokens noch nicht bereitgestellt haben. Dieser Kulanzzeitraum soll dazu dienen, Probleme mit der Webkompatibilität während der Übergangsphase zu vermeiden. Teilnehmende Ursprünge müssen vor Ablauf des Kulanzzeitraums Tokens zur Einstellung von Testversionen bereitstellen, damit sie nach Ablauf des Kulanzzeitraums weiterhin Zugriff auf Drittanbieter-PCs haben.
Chrome-Tests (Modus a/b)	Modus B ist für eine Stichprobe zu klein, um Leistungsabfälle genau zu messen.	Es muss ein ausgewogenes Verhältnis zwischen dem Prozentsatz des Traffics und dem Risiko von Auswirkungen auf Nutzer und Funktionalität im Web gefunden werden.
Steuerelemente testen	Nur die größten Publisher mit beträchtlichen Entwicklungsressourcen können die Leistung während der Tests beurteilen und diese an die CMA weiterleiten.	Publisher-Dienstanbieter teilen bereits Informationen öffentlich mit einem breiteren Ökosystem und gehen davon aus, dass sich dies auch im Zuge der Privacy Sandbox-Tests fortsetzen wird. Wir gehen auch davon aus, dass Unternehmen im Bereich Anzeigentechnologie, die auf den Privacy Sandbox APIs aufbauen, auch in Zukunft Funktionen entwickeln werden, die ihre Kundinnen und Kunden benötigen, z. B. auf Labels basierende Berichte.
Drittanbieterdaten	Bedenken hinsichtlich Datendrittunternehmen.	Es gibt verschiedene Arten von Datendrittunternehmen. Manche setzen möglicherweise verstärkt auf undurchsichtige Methoden des websiteübergreifenden Trackings. Andere setzen möglicherweise auf datenschutzfreundlichere Technologien und entwickeln neue Vorzüge für ihre Kunden. Wir hoffen, dass sich mehr Nutzer für Letzteres entscheiden und in die Richtung gehen, in die sowohl Nutzer als auch Regulierungsbehörden immer anspruchsvoller werden. Veränderungen schaffen Chancen für Entwicklung und Innovation.
Google Ad Manager	Wir benötigen weitere Google Ad Manager-Informationen dazu, wie Publisher die Privacy Sandbox testen können. Die Berichte reichen nicht aus, damit Publisher die Auswirkungen nachvollziehen können.	Antwort von Google Ad Manager: In der Google Ad Manager-Hilfe wird erläutert, wie Tests mit Labels für von Chrome unterstützte Tests durchgeführt werden. Ad Manager bietet Publishern derzeit Berichte zu Topics und Protected Audience. Zum Zeitpunkt der Erstellung dieses Feedbackberichts kann in Ad Manager Berichte zu Impressionen erstellt werden, die über die Protected Audience API erzielt wurden. Außerdem kann angegeben werden, ob Daten der Topics API in einer bestimmten Impression vorhanden waren. Publisher, die an ausgefeilteren Berichten wie einer Segmentierung von Berichten basierend auf den von Chrome unterstützten Labels interessiert sind, können die Labels direkt in Chrome lesen (mithilfe der Chrome-Dokumentation) und sie als Schlüssel/Wert-Paare in Anzeigenanfragen an Ad Manager und Berichte zu Schlüssel/Wert-Paaren übergeben, um Berichte zu den Labels zu erstellen.
Incentive testen	Werbetreibende befürchten, dass ausreichend Zeit zum Testen der Privacy Sandbox vorhanden ist und dass sich möglicherweise wesentliche Änderungen an der API ergeben.	Uns ist bewusst, dass manche Menschen mehr Zeit wünschen, aber wir haben wiederholt aus der Branche gehört, dass eine Verschiebung des Zeitplans wahrscheinlich zu weniger Vorbereitungen führen wird, nicht mehr. Der Zeitplan für die Einstellung von Drittanbieterlösungen hängt davon ab, ob alle noch bestehenden wettbewerbsrelevanten Belange der CMA berücksichtigt wurden. Wir empfehlen Ihnen aber, sich auf die 3PCD im Jahr 2024 vorzubereiten. Wie alle anderen Technologien werden auch Privacy Sandbox APIs weiter weiterentwickelt. Diese Entwicklung ist auf Fortschritte bei Technologien und dem Input des Ökosystems zurückzuführen. Wir werden auch in Zukunft verantwortlich dafür sein, Änderungen vorzunehmen, und sind nicht der Meinung, dass Änderungen in der Technologie die Nutzung auf unbestimmte Zeit behindern sollten.
Internetfähige Fernseher (CTV)	Lineare oder CTV-Videos sind nicht möglich.	Wir freuen uns darauf, weitere Anwendungsfälle für CTV zu untersuchen, sind aber nicht der Meinung, dass APIs für CTV-Geräte 3PCD in Chrome beeinträchtigen.
Ad-Server des Werbetreibenden	Google stellt offenbar die Anzeigenausrichtung auf DV360 um. Welcher Support wird für die Ad-Server von Werbetreibenden angeboten?	Antwort von Chrome: Die PA API wurde für die Ad-Server von Werbetreibenden entwickelt, um Anzeigen, die Nutzern mithilfe von iFrames / Fenced Frames und Beacon-Berichten präsentiert werden, auszuliefern und zu analysieren. Darüber hinaus arbeiten sie wie bisher mit vor- und nachgelagerten Parteien zusammen, um die Integration in den Bereitstellungsablauf vorzunehmen.
Google Ads-Datenmanager	Das kürzlich angekündigte „Google Ads Data Manager“ baut auf dem Kundenabgleich und erweiterten Conversions auf. Werbetreibende können damit ihre selbst erhobenen Kundendaten für Google freigeben, um alle Marketingfunktionen von Drittanbietern zu nutzen. Wie passt diese neue Funktion den Verpflichtungen von Google gegenüber der CMA?	Antwort von Google Ads: Mit Google Ads Data Manager können Sie selbst erhobene Daten aus Speichersystemen für Werbetreibende (Cloud-Systeme) hochladen, um sie für den Kundenabgleich (CM) und erweiterte Conversions (EC) zu verwenden. Das erleichtert kleine und mittlere Unternehmen mit weniger technischen Ressourcen die Arbeit. Google Ads Data Manager bietet keine neuen Funktionen für CM und EC in Bezug auf die Adressierbarkeit oder Messbarkeit von Anzeigen, die Inhaberinnen und Betreiberinnen von Google ODER Drittanbieter-Publisher sind. Die Werbeplattformen von Google haben denselben Zugriff auf die Funktionen der Privacy Sandbox-Technologien wie andere Anzeigentechnologie-Unternehmen.
Chrome-Einstellungen	Die interne Einstellungsseite von Chrome sollte weitere Informationen zur Größe von Cookies enthalten.	Die gewünschte Funktion ist bereits in den Chrome-Entwicklertools verfügbar. Wir freuen uns über zusätzliches Feedback dazu, warum diese Funktion auf der Seite „Einstellungen“ priorisiert werden sollte.
Heuristik	Welche Heuristiken setzen Chrome ein, um die Nutzerfreundlichkeit auch während der 3PCD-Umgebung aufrechtzuerhalten?	Sehen Sie sich unsere Antwort auf diese Frage auf GitHub an.
Browserversionen	Unterscheiden Sie sich zwischen stabilen und instabilen Chrome-Browsern?	Eine grobe Anpassung der Chrome-Hauptversion mit dem stabilen Releasezyklus wird funktionieren.
Compliance	Kann Chrome SOX-Berichte bereitstellen?	Chrome stellt keine SOX-bezogenen Berichte zur Verfügung. Die Privacy Sandbox APIs sind eine von vielen Web-APIs, die Chrome den von Nutzern besuchten Websites zur Verfügung stellt. Wie bei allen Web-APIs schließt der API-Aufrufer keine Vereinbarung mit Chrome zur Nutzung der Privacy Sandbox API ab. Der Zugriff hängt nur davon ab, ob der API-Aufrufer technische Anforderungen erfüllt und der Nutzer die entsprechenden Einstellungen aktiviert hat. Ist dies der Fall, bestimmt der API-Aufrufer allein, wie die API verwendet wird, z. B. welche Daten gespeichert, welche Gebote abgegeben und welche Berichte angefordert werden sollen usw.
Compliance	Die FAQs zur Einhaltung der Privacy Sandbox werden erweitert, um weitere Fragen zu beantworten.	Wir wissen das Feedback zu schätzen und planen, die FAQs weiter auszubauen.
Frage zu Chrome	Wirkt sich die Einstellung von Drittanbieter-Apps in Chrome auf die Verfügbarkeit von Drittanbieterprodukten in Android WebView (eingebetteter Browser) aus?	In dieser Phase der Einführung und Tests der 3PCD oder der Privacy Sandbox API ist WebView aktuell nicht verfügbar. Über die Aktivierung der übergreifenden App- und Web Attributionsmessung hinaus gehen wir davon aus.
Frage zur API	Wie können Klicks und Impressionen für gesponserte Produkte erfasst werden?	Dieser Anwendungsfall wird von der Attribution Reporting API abgedeckt.
Zeitplan	Warum hat sich der Zeitplan für 3PCD geändert?	Wir haben diese Gründe hier besprochen.
SSO für Chrome-Erweiterung	Lassen Sie den Anwendungsfall der Einmalanmeldung (SSO) zwischen einer Website und einer Chrome-Erweiterung nach 3PCD zu.	Wir diskutieren dieses Problem und freuen uns über Feedback zu weiteren Anwendungsfällen.
API-Nutzung	Kann Google eine Liste der Partner nennen, mit denen APIs getestet werden können?	Details zu Testern, die sich öffentlich identifiziert haben, sind auf GitHub für die folgenden APIs verfügbar: – Topics API – Protected Audience API – Attribution Reporting API – Freigegebener Speicher – CHIPs
Utiq-Initiative	Wie steht Chrome gegenüber der Utiq-Initiative?	Weitere Informationen dazu finden Sie hier.
Frage zu Chrome	Wie erkennt man Nutzer, die ohne Drittanbieter-PCs surfen?	Es gibt keine explizite Einstellung zur Erkennung von Drittanbieterblockierungen. Für einen allgemeinen Ansatz zur „Funktionserkennung“ empfehlen wir, die iFrame- bzw. websiteübergreifende Anfrage zu erstellen. Es empfiehlt sich dann, ein ähnliches Cookie für den erforderlichen Anwendungsfall zu setzen.
Frage zu Chrome	Ist das Surfen im Inkognitomodus dasselbe wie das Ausführen des Flag-Tests (Chrome mit dem Befehlszeilen-Flag „--test-third-party-cookie-phaseout“ starten)?	Der Inkognitomodus unterscheidet sich vom Flag. Das Flag blockiert nicht nur Drittanbieter, sondern ermöglicht auch die FedCM- und Drittanbieter-Speicherpartitionierung.
Frage zu Chrome	Weitere Informationen zu den erwarteten Auswirkungen von 3PCD auf die einzelnen Regionen/Länder, wenn 1% der Fall ist.	Die Kunden werden global zu den 1% nach dem Zufallsprinzip hinzugefügt, obwohl es regionale Abweichungen geben kann. Es kann beispielsweise Unterschiede bei der Verteilung der Geräte und der Chrome-Versionen geben.
Alternative Datenschutztechnologien	Alternative datenschutzfreundliche Technologien sollten zulässig sein, ein datenschutzfreundliches domainübergreifendes Tracking durchzuführen, um ein Datenmonopol in Chrome und Android zu verhindern.	Entwickler haben viele Gelegenheiten, datenschutzfreundliche Technologieangebote zusätzlich zu den von uns angebotenen Bausteinen und anderen Bausteinen der Privacy Sandbox zu entwickeln.
CookieGraph-Studie	Wie sieht Chrome die CookieGraph-Methode aus, die in diesem Dokument im Rahmen der Privacy Sandbox beschrieben wird?	Wir prüfen diesen Artikel und freuen uns auf zusätzliches Feedback.

Registrierung und Bestätigung

Feedback	Zusammenfassung	Chrome-Antwort
Registrierung ist eingeschränkt	Google hat spezifische Nutzungsbedingungen für Privacy Sandbox APIs eingeführt. Die Nutzungsbedingungen verhindern effektiv, dass Unternehmen, die darauf spezialisiert sind, Publisher bei der Erkennung von Einwilligungen von Besuchern zu unterstützen, Privacy Sandbox-Funktionen testen und/oder in ihre Identitätslösung einbinden. Durch die Nutzungsbedingungen wird die Nutzung der Privacy Sandbox auf unfaire Weise eingeschränkt.	Im Registrierungs- und Bescheinigungsprozess müssen die API-Nutzungsbedingungen nicht akzeptiert werden. Die Registrierung und Bescheinigung sollen stattdessen mehr Transparenz darüber ermöglichen, welche Entwickler die Privacy Sandbox APIs aufrufen und wie sie die auf sie zugreifenden Daten verwenden. Insbesondere ist die Bestätigung eine öffentliche Erklärung, dass der attestierende Entwickler die APIs nicht verwendet, um Nutzer auf Websites oder in Apps zu identifizieren, und dass er die Datenschutzmaßnahmen der APIs nicht auf andere Weise umgeht. Die Bescheinigung erfordert keine Zusicherungen hinsichtlich der Nutzung anderer Daten oder Technologien durch den Entwickler.
Privacy Sandbox-Anmeldung	Wie aktualisiere ich den Ansprechpartner / die E-Mail-Adresse für die Bescheinigung?	Die Informationen zur Anmeldung können mit dem Anmeldeformular aktualisiert werden. Weitere Informationen
Privacy Sandbox-Anmeldung	Können Sie Szenarien für Zugriffsabbruch erläutern, falls die Bescheinigung nicht verfügbar ist?	Für die Privacy Sandbox hat ein technischer Kontakt drei Wochen Zeit, die Bestätigungsdatei für die registrierte Website neu einzurichten, bevor einem registrierten Unternehmen der Zugriff auf die APIs für Messung und Relevanz verwehrt wird.
Privacy Sandbox-Anmeldung	Wie können wir die APIs in einer lokalen Umgebung mit Nicht-Produktionsendpunkten testen?	Wir haben diese Frage hier beantwortet.

Relevante Inhalte und Werbung präsentieren

Themen

Feedback	Zusammenfassung	Chrome-Antwort
Nützlichkeit für verschiedene Arten von Stakeholdern	Publisher sind besorgt über die Auswirkungen von Themen auf datengesteuerte Verkäufe. Größere Websites wird ein allgemeines Nachrichtenthema zugewiesen, ohne dass Daten einem bestimmten Verlag oder Webpublisher zugeordnet werden. Spezialisierte Publisher geben ihre Daten für begrenzte Informationen im Gegenzug weiter.	Uns ist bewusst, dass Websites mit Domains mit allgemeinem Interesse wahrscheinlich weniger detaillierte Themen liefern als Websites mit eher Nischeninteressen. Allerdings bieten nicht alle Nischenwebsites kommerziell wertvolle Themen. Diese Dynamik spiegelt auch den Status quo wider: dass einige Websites in auf Drittanbieter basierenden Anzeigenrelevanzsystemen einen höheren Mehrwert bieten als andere. Topics (und die Privacy Sandbox insgesamt) bietet Publishern mehr Kontrolle darüber, wie ihre Daten von den AdTech-Unternehmen genutzt werden, mit denen sie zusammenarbeiten. Außerdem sind die über die Topics API verfügbaren Informationen viel gröber als die vorhandenen Signale.
Ad-Server für Publisher	Publisher-Ad-Server, die dedizierte Ad-Server verwenden, können die Topics API möglicherweise nicht direkt beobachten.	Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Bestätigung	Attestierungsanforderung erweitern, um bekannte unerwünschte Folgen des kontextübergreifenden Informationstransfers zu umgehen.	Derzeit soll die Bescheinigung nicht diese umfassende Risikokategorie abdecken, sondern vielmehr den Missbrauch der API bekämpfen.
Volumen der Topics-Zugriffe	Die aktuelle Anzahl der erhaltenen Impressionen reicht für Tests nicht aus.	Wir wissen, dass Chrome Feedback zur Menge der im programmatischen System verfügbaren Topics API hat. Wir untersuchen mögliche Ursachen – sowohl innerhalb des Browsers als auch unter relevanten Testern. Falls erforderlich, prüft Chrome, welche potenziellen Änderungen am API-Design verfügbar sind, um die Abdeckungsrate zu erhöhen und Tests in großem Umfang zu ermöglichen, während gleichzeitig der Datenschutz gewährleistet ist.
API-Nutzung	Gibt es eine Ratenbegrenzung für die Topics API?	Es gibt einige Ratenbegrenzungen für Topics, um Missbrauch zu verhindern und die Nutzererfahrung im Web zu schützen. Weitere Informationen
V2-Taxonomie	IAB-Richtlinien bezüglich der Themendetails, die im offenen RTB-Protokoll enthalten sein sollen?	Ja, Richtlinien des IAB zur Einbeziehung von Topics in das Open RTB-Protokoll finden Sie hier.
Auswirkungen auf eigene Signale	Eine detaillierte Topics-Taxonomie Version 2 in Kombination mit einem Prozess, mit dem Sie den höchsten Wert dieser detaillierten Segmentierung (Top-Themen) erzielen, wird den Markt für Daten in der Werbung verzerren.	Unsere Antwort bleibt vom 3. Quartal unverändert: „Eine präzisere Topics-Taxonomie kann den Attraktivität für andere Lösungen indirekt beeinträchtigen, z. B. Lösungen, die auf selbst erhobenen Daten von Publishern oder auf Direct Deals basieren. Bei der Entwicklung der Topics API möchten wir vor allem dafür sorgen, dass interessenbezogene Werbung nach der 3PCD für alle Beteiligten so effektiv wie möglich unterstützt wird. Wir sind davon überzeugt, dass ein größerer Nutzen von Topics den Wettbewerb insgesamt verbessert und dem Ökosystem als Ganzes nützt.“
Testerliste	Wie werden Topics und die PA API bei Ihren Publishern eingesetzt?	Solche Informationen können wir nicht weitergeben. In der Liste der Tester können Publisher angeben, ob sie ihren Teststatus teilen möchten.
Themenauswahl	Zulassen, dass Nutzer proaktiv Themen auswählen, die sie interessieren?	Wir haben sicherlich darüber nachgedacht, Nutzern die Möglichkeit zu geben, proaktiv Themen hinzuzufügen. Eine kurzfristige Lösung ist nicht geplant, aber wir sind offen für neue Antworten.
Themenauswahl	Wenn ein AdTech-Anbieter Code zur Beobachtung von Themen auf einer Website hat, kann er dann wissen, welche Themen beobachtet werden könnten?	Ein Unternehmen für Anzeigentechnologie kann die mit einer Website verbundenen Themen ermitteln. Die API gibt diese Informationen nicht in Echtzeit weiter, da dies Latenzkosten verursachen kann.
V2-Taxonomie	Da Topics bis zu drei Topics zurückgeben kann, welches Verhalten erwartet Sie bei der Einführung von „Taxonomy v2“?	Die API gibt weiterhin bis zu drei Topics zurück und fügt die relevante Taxonomieversion für jedes Topic in die Antwort ein.
(Auch in vorherigen Quartalen berichtet) Beobachtung von Themen	Ermöglichen Sie Publishern, Chrome die Berechtigung zu erteilen, Themen anhand des Seiteninhalts zu kategorisieren (z. B. „head“ oder „body“).	Unsere Antwort bleibt im Vergleich zum 3. Quartal unverändert: „Bisher haben wir darüber nachgedacht, eine Klassifizierung von Websites anhand des Seiteninhalts nach Themen zu ermöglichen. Wir haben uns jedoch aus Datenschutz- und Sicherheitsbedenken entschieden, dies nicht zu tun. Dieser Vorschlag kann einige dieser Bedenken ausräumen, aber es ist unklar, in welchem Umfang. Aufgrund der bevorstehenden CMA-Testphase gehen wir davon aus, dass diese Änderung nicht vor 3PCD erfolgt. Wir freuen uns über zusätzliches Feedback.“
Themenauswahl	Wie werden Domains angesichts der Tatsache, dass sie allgemein sind, als Topics klassifiziert?	Wir verwenden den Hostnamen nur, um Websites Topics zu klassifizieren. Eine zu allgemein klassifizierte Website ist davon nicht betroffen. Dies liegt daran, dass die Kontextinformationen einer Website immer für Auktionen auf der Website verfügbar sind, wodurch spezifischere Informationen zum allgemeinen Thema bereitgestellt werden.
V2-Taxonomie	Sie wünschen sich eine bessere Abstimmung der Themen mit anderen Standards (z.B. IAB).	Wir würden gerne mehr darüber erfahren, warum sie sich eine engere Angleichung zwischen den Taxonomien von IAB und Topics erhofften. Welche Schritte muss er unternehmen, um die Topics API zu implementieren, und wie wirkt sich eine spezifischere Taxonomie auf diese Schritte aus? Wir planen, eine Zuordnung zwischen der Taxonomie für Inhalte und der IAB-Taxonomie für Inhalte zu veröffentlichen. Es wäre hilfreich zu verstehen, ob dadurch die Herausforderungen für Publisher angegangen werden können.
Datenspeicherung und -nutzung	Haben Sie weitere Informationen dazu, wie die Daten gespeichert und wohin sie übertragen werden?	Informationen zu Topics werden lokal auf dem Gerät eines Nutzers generiert und gespeichert. Auf Anfrage gibt die API bis zu drei Themen an Aufrufer zurück. Aus Sicht von Google sind Aufrufer dafür verantwortlich, bei der Verarbeitung und Speicherung von Topics-Informationen die lokalen Vorschriften einzuhalten. Außerdem müssen alle Aufrufer bestätigen, dass sie Topics nicht verwenden, um Nutzer websiteübergreifend zu identifizieren. Weitere Informationen finden Sie in den häufig gestellten Fragen zur Compliance in Bezug auf den Datenschutz.
V2-Taxonomie	Auswirkungen des Upgrades der Topics-Taxonomie und des Status des Browsers bei der Umstellung von Version 1 auf Version 2	Die aus der vorherigen Taxonomie abgeleiteten Themen sind weiterhin verfügbar und können von der Anzeigentechnologie abgerufen werden, bis sie verfallen (4 Wochen alt).
API-Beschreibung	Die Verwendung der Topics API ist irreführend.	Wir haben dieses Feedback an das UX-Team weitergeleitet.
Frage zur API	Wie werden Yahoo-Domains für die Topics API klassifiziert, wenn sie allgemein gehalten sind?	Wir verwenden den Hostnamen nur, um Websites Topics zu klassifizieren. Es ist wichtig zu verstehen, dass eine allgemein klassifizierte Website dadurch nicht geschädigt wird.
Die Verfügbarkeitsrate der Themen ist niedrig	Die Tester erhalten nur wenige Themen aus Google Ad Manager.	In Google Ad Manager wurden mehrere Optimierungen eingeführt, um die Abdeckung zu verbessern. Käufer sollten eine Steigerung der Abdeckung verzeichnen. Es gibt einige zu erwartende Faktoren, die die Abdeckung einschränken können, z.B. Nutzerpräferenzen, Beobachtungsanforderungen durch den Anrufer und möglicherweise einige Latenzen oder Zeitüberschreitungen.

Protected Audience API (früher FLEDGE)

Feedback	Zusammenfassung	Chrome-Antwort
Differenzierung	Unklarheiten darüber, wie SSPs bei der neuen Auktion von Mitbewerbern abheben	Wir haben von mehreren strategischen Plänen gehört, bei denen Protected Audience und/oder andere Privacy Sandbox APIs im Mittelpunkt stehen. Ein größerer Überblick: Die Reduzierung allgegenwärtiger websiteübergreifender Kennungen wird vonseiten der Verkäufer oft als positiver Schritt nicht nur in Bezug auf den Datenschutz, sondern auch in wirtschaftlicher Hinsicht angesehen. Für kleine und große Unternehmen, die diesen Wandel annehmen, werden Chancen auf neue Chancen geschaffen.
Anzeigen-Rendering	Chrome als einziger Weg zum Rendern von Anzeigen bremst Innovationen aus. Das Protected Audience-Rendering reduziert die Umsetzung der heutigen Standards für native Werbung.	Beim Rendern von Anzeigen in Browsern werden schon immer Browsertechnologien eingesetzt. Daran ändert sich nichts. Vielleicht ist dieses Problem spezifisch für Pläne, in Zukunft die Verwendung von Fenced Frames in Verbindung mit Protected Audience zu verlangen. Diese Pläne sind unter anderem deshalb „in der Zukunft“, weil wir möchten, dass die Fenced Frames-Technologie Innovationen vorantreibt und die Differenzierung beim Anzeigen-Rendering unterstützt. Interessierten Entwicklern und Unternehmen ist es Zeit, sich über die Entwicklung von Fenced Frames zu äußern, einschließlich der Unterstützung nativer Anzeigen.
Eingabe	Die Concern Protected Audience API (PA API) war fast fertig, als viele Anzeigentechnologie-Anbieter mit der Nutzung von Privacy Sandbox APIs begannen.	Die APIs werden auf Grundlage unserer Erkenntnisse aus der Nutzung sowie neuer Ideen, die sowohl innerhalb als auch außerhalb von Chrome entwickelt werden, weiterentwickelt. Die heute allgemein verfügbaren APIs für Relevanz und Messung sind stabil, aber das bedeutet nicht, dass die Entwicklung gestoppt wurde. Wir freuen uns über zusätzliches Feedback.
Auktionsdesign	Beim Protected Audience-Design wird die gesamte Logik für die Zielgruppenerstellung und die Anzeigenauswahl an die Buy-Side-Plattform übergeben. Damit ist es einer SSP nicht mehr möglich, Logik für die Zielgruppenerstellung und Anzeigenauswahl für Kampagnen anzubieten, die auf dieser Plattform ausgeführt werden.	Bei der Protected Audience API spielt es keine Rolle, wer Zielgruppen erstellt und wer auf Zielgruppen bietet. Eine SSP kann eine Interessengruppe erstellen, die sie für Gebote zur Verfügung stellt. Es ist auch möglich, dass eine Sell-Side-Plattform (SSP) eine Gebotslogik bereitstellt. Das scheint der Richtung zu entsprechen, in die viele SSPs direkt an Agenturen wenden. Auch wenn es immer Raum für weitere Anwendungsfälle gibt, sind die Grundlagen von Protected Audience so flexibel, dass sie viele verschiedene Ansätze zur Erstellung und Aktivierung von Zielgruppen unterstützen. Die Datenschutzmerkmale dieser Grundlagen bedeuten auch, dass Rohdaten auf Nutzerebene nicht zwischen Websites ausgetauscht werden.
Auktionsdesign	Wird die Protected Audience-Auktion den Bemühungen zur Optimierung des Supply Path (SPO) des Systems entgegenwirken, um die Gesamtzahl der Mittler zwischen einem Werbetreibenden und einem Publisher und/oder die Duplizierung einer bestimmten Opportunity zu reduzieren?	Nein. Eine erfolgreiche Anzeige in der Protected Audience API wird höchstens zwei Verkäuferentitäten (z.B. eine SSP und einen Ad-Server eines Publishers) und gar keine übergeben, wenn der Käufer eine direkte Integration mit dem Publisher erstellt. Die Entscheidung des Verlags oder Webpublishers bleibt bestehen, wenn dieselbe Anfrage über mehrere Vermittler dupliziert wird. Die Protected Audience API sollte weder in dieser Hinsicht noch Auswirkungen haben. Protected Audience-Auktionen finden außerhalb des heutigen Server-zu-Server-Echtzeitsystems statt, damit keine websiteübergreifenden Nutzerdaten offengelegt werden. Einige behaupten möglicherweise, dass hier eine Anzeigenanfrage dupliziert wird. Der Weg zu einem technisch nachweisbaren Datenschutz erfordert einige Kompromisse. Langfristig kann es jedoch vorkommen, dass Protected Audience verwendet wird, ohne auf herkömmliche serverseitige Auktionen zu verzichten. Dies könnte zu noch besser optimierten Quellpfaden führen.
Auktionsdesign	Die Protected Audience API wird auf ein Modell umgestellt, bei dem SSPs selten die „letzte“ Auktion auf der Seite sind, sondern vom API-Design zu diesem Modell gezwungen werden.	Wir sind anderer Meinung. Die ersten Implementierungen, die wir beobachtet haben, sorgen dafür, dass SSPs, die an Komponentenauktionen teilnehmen, die Ergebnisse von kontextbezogenen Auktionen schlagen können, die vor der Protected Audience-Auktion stattfinden. Die Ergebnisse von Auktionen der SSP-Komponenten in Protected Audience gelten als letzte, nachdem eine vollständige kontextbezogene Auktion ausgeführt wurde.
Auktionsdesign	Kontextbezogene Auktionen sind möglicherweise nur relevant, um Datensignale zur Auktionsmöglichkeit bereitzustellen, die bei Protected Audience-Auktionen berücksichtigt werden.	Wir gehen davon aus, dass kontextbezogene Auktionen aus verschiedenen Gründen relevant bleiben werden, z. B. für Deals, Kampagnen ohne eigene Zielgruppe und zahlreiche kontextbezogene Szenarien. Das ist auch nützlich, wenn keine IGs anwesend sind oder die Gebote in Protected Audience die Mindestpreise nicht erreichen oder die Anzeigenqualitätsregeln nicht einhalten.
Trafficmuster	DSPs arbeiten mit festen Abfragen pro Sekunde. Durch das Anpassen von Protected Audience-Auktionen wird der Nutzen der alten Infrastruktur verringert.	Eine Änderung im Hinblick auf Abfragen pro Sekunde bedeutet, dass viele Sell-Side-Plattformen websiteübergreifende IDs verwenden, um zu ermitteln, ob eine DSP eine Anfrage gesendet hat. Das gilt unabhängig davon, ob der Publisher eine Protected Audience-Auktion durchführen möchte oder nicht. Wir haben Trafficmuster mit vielen SSPs untersucht und Lösungen wie Caching und kontextbasiertes Filtern gefunden. Wir gehen davon aus, dass Entwickler im Laufe der Zeit die private Aggregation nutzen werden, um die DSP-Gebotseinstellungen besser zu verstehen und entsprechend zu filtern. Letztendlich wird eine Legacy-Infrastruktur, die auf websiteübergreifenden Kennungen basiert, nicht mehr nützlich sein.
Verfügbare Signale	Unklare über die gesamte Bandbreite an Signalen, die zur Verfügung stehen, wann Auktionen stattfinden und wie die Sequenzierung mit dem kontextbezogenen Auktionsverhalten Nachteile hat.	Im Allgemeinen können für Bieter Informationen aus der kontextbezogenen Auktion und einer Echtzeit-Schlüssel/Wert-Suche bereitgestellt werden, wenn ein IG erstellt wird. Für Scorers können Informationen bereitgestellt werden, wenn die Auktion konfiguriert ist. Dazu gehören Kontextinformationen zur Seite und zur kontextbezogenen Auktion sowie aus einer Echtzeit-Schlüssel/Wert-Suche für Anzeigen-Rendering-URLs.
(In vorherigen Quartalen erfasst) Video-Rendering	Unterstützung für das Video-Rendering mit Protected Audience und Fenced Frames.	Unsere Antwort hat sich im Vergleich zu den vorherigen Quartalen nicht geändert: „Die Protected Audience API unterstützt das Video-Rendering mit einem Mechanismus, der auf iFrames basiert. Wir haben jedoch noch keine Lösung entwickelt, die mit Fenced Frames kompatibel ist. Dies ist einer der Gründe, warum wir uns entschieden haben, die Erzwingung von Fenced Frames bis 2026 zurückzuziehen. Das heißt, wenn ein Partner sich jetzt für die Durchsetzung von Fenced Frames entscheidet, würde dieser Partner an der Unterstützung für Videos mangeln.“
Video-Rendering	Die PA API-Unterstützung für Videos in iFrames ist auf HTML5-Videos beschränkt und unterstützt nicht den weit verbreiteten VAST-Standard.	VAST-basierte Anzeigen lassen sich mit dem iFrame-Renderingmechanismus implementieren, der bereits in Protected Audience verfügbar ist. Wir wissen, dass dies aufseiten von Käufern, Verkäufern und Publisher-Anzeigenplattformen neue technische Entwicklungen erfordert, und wir werden weiterhin daran arbeiten, den Übergang von der bisherigen Funktionsweise von VAST zu erleichtern.
(Aus vorherigen Quartalen erfasst) Auktionen der obersten Ebene	Die Möglichkeit, den Ad-Server von Google für Publisher zu verwenden, ohne Google Ad Manager gleichzeitig die Kontrolle über die API-Auktion für PA-Anzeigen auf oberster Ebene zu geben.	Unsere Antwort hat sich im Vergleich zu vorherigen Quartalen nicht geändert: „Antwort von Google Ad Manager: Im Rahmen der Pläne von Google Ad Manager für die Protected Audience API wird der Ad-Server von Google-Publishern aus folgenden Gründen nicht ohne Kontrolle über die Protected Audience-Auktion der obersten Ebene unterstützt. Damit wir unseren Kunden auf dem Markt für die Anzeigenbereitstellung von Publishern gerecht werden können, muss der Ad-Server von Google die Kontrolle über die Protected Audience-Auktion der obersten Ebene behalten. Als Ad-Server eines Publishers besteht unsere Aufgabe darin, Publishern Prognosen bereitzustellen, damit diese direkt verkaufte Kampagnen ohne Überbuchung aushandeln können und ihre direkten Reservierungen optimal takten und durchführen. Dazu muss die letzte Auktion durchgeführt werden, um die gesamte mögliche direkte und indirekte Nachfrage zu vergleichen. Prognosen und Taktung sind Kernfunktionen, die Publisher von einem Ad-Server erwarten. Ohne genaue Prognosen können Publisher ihr Inventar am Ende überverkaufen, was den Ruf ihres Unternehmens gefährdet. Die Taktung ist ebenfalls von entscheidender Bedeutung, da die Tatsache, dass Reservierungsverträge mit Werbetreibenden nicht erfüllt werden können, ebenfalls Risiken für die direkte Beziehung zwischen Publisher und Werbetreibendem bergen, was erhebliche Auswirkungen auf das Geschäft eines Publishers haben könnte. Kurz gesagt: Die Aktivität eines Ad-Servers eines Publishers bezüglich der Durchführung der Protected Audience-Auktion der obersten Ebene unterscheidet sich nicht von den anderen Aktivitäten des Ad-Servers eines Publishers.“
(In vorherigen Quartalen erfasst) directFrom SellerSignals	Mit „directFromSellerSignals“ kann in Google Ad Manager verhindert werden, dass der Publisher den Preis der kontextbezogenen Auktion sieht.	Unsere Antwort hat sich im Vergleich zu vorherigen Quartalen nicht geändert: „Chrome-Antwort: An „runAdAuction()“ übergebene Informationen stammen nachweislich nicht vom Verkäufer, es sei denn, der Verkäufer ruft „runAdAuction()“ in seinem eigenen iFrame auf. Bei einer Auktion mit mehreren Verkäufern ist es unmöglich, dass alle Verkäufer den Frame erstellen, der runAdAuction() aufruft. directFromSellerSignals hat dieses Problem behoben, indem Inhalte aus einem Unterressourcen-Bundle geladen wurden, das aus dem Ursprung eines Verkäufers geladen wurde. So wird sichergestellt, dass die Authentizität und Integrität der Informationen, die über die Konfigurationen für Auktionen von Verkäufern an eine Auktion übergeben werden, nicht manipuliert werden können. Wenn Publisher die Protected Audience API verwenden möchten, um Informationen zu ermitteln, die ihre Technologieanbieter an Protected Audience-Auktionen weitergeben, können sie diese Technologieanbieter um diese Funktion bitten. Antwort von Google Ad Manager: Wir legen seit Jahren großen Wert auf Fairness bei Auktionen. Unter anderem wird versichert, dass keine Preise aus nicht garantierten Anzeigenquellen eines Publishers (einschließlich nicht garantierter Preise für Werbebuchungen) mit einem anderen Käufer geteilt werden, bevor er in der Auktion bietet. Dies haben wir später in unseren Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bestätigt. Wir beabsichtigen, bei Protected Audience-Auktionen unser Versprechen zu halten, indem wir „directFromSellerSignals“ nutzen. Wir möchten die Gebote von Auktionsteilnehmern vor Abschluss der Auktion nicht an andere Auktionsteilnehmer weitergeben. Wie in diesem Update erläutert, teilen wir den Preis der kontextbezogenen Auktion auch nicht mit unseren eigenen Auktionen für Komponenten."
(In vorherigen Quartalen erfasst) K-Anonymitätswert	Wie wird der Wert „K“ für „k-anon“ festgelegt und wann wird er veröffentlicht?	Der Wert für die k-Anonymität wurde im Dezember 2023 veröffentlicht. Nach Beginn des 3PCD-Prozesses erhöhen wir den k-Anonymitätsschwellenwert auf den endgültigen Wert von 50 (k=50) und legen den Aktualisierungszeitraum auf 1 Stunde (p=1) fest. Der K-Anonymitätswert von 50 wurde als optimale Balance zwischen Nutzen und Datenschutz bewertet. Dieser Wert reicht aus, um einfache Bot-Angriffe abzuwehren und den Differential Privacy zu wahren. Gleichzeitig ist er so niedrig, dass die API weiterhin für die vorgesehenen Anwendungsfälle nützlich ist.
(In vorherigen Quartalen erfasst) forDebuggingOnly	Möglichkeit, dass forDebuggingOnly.reportAdAuctionWin missbraucht wird, wenn es nach 3PCD bleibt.	Unser Vorschlag zur langfristigen Unterstützung der Fehlerbehebung bei Anwendungsfällen haben wir hier veröffentlicht. Wir freuen uns über zusätzliches Feedback zum Vorschlag.
(In vorherigen Quartalen erfasst) Richtlinie für denselben Ursprung	Anfrage zur Lockerung der Richtlinie für denselben Ursprung, um Subdomains zuzulassen.	Diese Anfrage wird derzeit geprüft und wir haben darüber hier gesprochen.
(In früheren Quartalen erfasst) Größe der Anzeigenkomponente	Erhöhen Sie die Anzahl der Anzeigenkomponenten von 20 auf 40.	Wir haben diese Anfrage während des WICG-Gesprächs vom 4. Oktober und in diesem GitHub-Problem besprochen und planen, das Problem bis Ende des 1. Quartals 2024 zu beheben.
(In vorherigen Quartalen erfasst) Ablauf des Serverschlüssels für Schlüssel/Wert-Paare	Diskussion über das Entfernen von Serverschlüsseln nach Ablauf der entsprechenden IGs.	Die Verwaltung von TTL sollte außerhalb von TEE durchgeführt werden, um die Komplexität zu verringern. Wir freuen uns aber über zusätzliches Feedback.
Trigger für Interessengruppen	Kann ein einzelner IG innerhalb einer einzelnen Auktion (Komponente) mehrere „generateBids“ auslösen?	Jedes Mal, wenn der Browser die FunktiongenerateBid() eines IG aufruft, darf dieser IG einen Gebotswert zurückgeben. Es ist z.B. möglich, dass eine Werbetreibende bei einer Auktion mit mehreren Verkäufern mehrmals aufgerufen wird, und zwar jedes Mal in einer der Komponentenauktionen. Der Inhaber des IG muss nicht explizit etwas tun, um dieses Verhalten zu aktivieren bzw. zu unterstützen.
Fragen zur Compliance	In welchem Umfang wird über den Chrome-Browser eines Nutzers eine Einwilligung eingeholt?	Weitere Informationen finden Sie in den FAQs zur datenschutzbezogenen Compliance unter „Wie wird die Privacy Sandbox in Bezug auf die datenschutzbezogene Compliance in Chrome angegangen?“.
Auktionen mit mehreren Tags	Auktionen mit mehreren Tags berücksichtigen	Wir sehen uns diese Anfrage gerade an und freuen uns über zusätzliches Feedback.
Verfügbarkeit des IP-Schutzes	Welche Auswirkungen hat es auf den Zeitplan von Protected Audience-Funktionen wie Fence Frame-Erzwingung und die Entfernung oder Entfernung von Berichten auf Ereignisebene, wenn der IP-Schutz nicht bis zu den angekündigten Terminen bereit ist?	Wie hier erwähnt, sind wir der Meinung, dass der Zeitplan von Protected Audience mit den Zeitplänen anderer Datenschutzfunktionen verknüpft werden sollte.
modelingSignals	Anforderung eines neuen Felds zusätzlich zu „modelingSignals“, das nur Display- und Klickinformationen codieren kann.	Wir sind uns der damit verbundenen Vorteile bewusst und prüfen die Anfrage derzeit. Wir freuen uns über zusätzliches Feedback.
Auszuschließende Interessenten	Wäre es möglich, dass normale IGs einen negativen IG-Namen angeben können?	Laut dieser Erläuterung ist dies derzeit nicht möglich. Wir freuen uns aber über zusätzliches Feedback, warum dies eine Anforderung ist.
API-Nutzung	Zusammengefassten Bericht aufgenerateBid()-Ebene generieren und	Die private Aggregation kann innerhalb von „generateBid“ aufgerufen werden.
Makros	Leiten Sie Signale von proKäufersignals über Makros in iFrames an Drittanbieter weiter.	Wir werden diesen Anwendungsfall hier besprechen und freuen uns über zusätzliches Feedback.
API-Nutzung	Wird „scoreAd()“ trotzdem aufgerufen, wenn beim Abrufen der vertrauenswürdigen Bewertungssignale ein Fehler zurückgegeben wird?	ScoreAd() sollte weiterhin ausgeführt werden, wenn der Abrufaufruf nicht erfolgreich war.
API-Nutzung	metadata.shard_num wird in riegeli-Dateien für Delta-/Snapshot-Dateien geschrieben.	Wir fügen gerade Unterstützung für shard_num hinzu, um die Blockierung aufzuheben. Riegeli wird nicht so gut angenommen wie das Beispiel Avro, aber es wird nicht aufgegeben. Da es bei TEE viel mehr Einschränkungen und Aufwand gibt, haben wir Kompromisse gemacht, um die Leistung der Nutzerfreundlichkeit in den Vordergrund zu stellen. Wir erwägen die Bereitstellung eines gRPC-Dienstes, um Dateien aus Anfragen zu erstellen. Möglicherweise bewerten wir auch andere Formate wie Avro im Hinblick auf ihre Auswirkungen auf die Leistung.
API-Tests	Wie unterstützen die PA API und die Measurement APIs inkrementelle Tests?	Die Privacy Sandbox bietet keine Möglichkeit, die Steigerung der Conversions vor einer Auktion kontrafaktisch zu messen. Sie können auch gemeinsam genutzten Speicher und private Zusammenfassungen verwenden, die kontrafaktischen Änderungen werden aber erst nach der Auktion angewendet.
API-Nutzung	Wirkt sich die Verwendung von BiddingWasmHelperURL für tägliche Updates auf den Grenzwert für die k-Anonymität aus?	Da die k-Anonymität bei IG-Updates nicht mehr berücksichtigt wird, kann biddingWasmHelperURL aktualisiert werden, ohne den Grenzwert zu beeinträchtigen.
API-Nutzung	Können wir Fehlerbenachrichtigungen für die PA API erhalten?	Wir freuen uns über Feedback dazu, welche Art von Fehlerbenachrichtigung sie benötigen, um Probleme mit der PA API zu beheben.
Anzeigengrößen	Anzeigengrößen sind weder in der Auktion noch in Berichten sichtbar.	Wir befassen uns mit dem Problem mit dieser Pull-Anfrage.
API-Nutzung	Wird der aktualisierte IG-Endpunkt für das IG aufgerufen, wenn es nicht an dieser Auktion teilnimmt?	Ja. Die „updateURL“ wird für alle IGs eines bestimmten Inhabers aufgerufen, auch wenn sie bei dieser bestimmten Auktion kein Gebot abgegeben haben. Es gelten lediglich die folgenden Voraussetzungen: – Der Inhaber muss an einer bestimmten Auktion teilnehmen, d. h., er muss in der Auktionskonfiguration als Käufer angegeben sein. – Die Interessengruppe des Inhabers darf in den letzten 24 Stunden nicht aktualisiert worden sein.
Prebid in PA API	Welche Version von Prebid.js wird für die Testphase benötigt?	Gemäß unserer technischen Dokumentation sollte die Version mindestens 8.9.0 sein.
Aktivierung selbst erhobener Daten in der PA API	Wie können sie ihre eigenen Daten für die Definition und Nutzung von Google-Produkten nutzen?	Für diese Aufgabe können Sie die Optionen „Delegierung von Berechtigungen“ und „auszuschließende Interessengruppen“ verwenden.
PA API und serverseitiges Tagging	Wie funktioniert die PA API mit serverseitigem Tagging?	Das Basis-Tag im Browser des Nutzers muss den API-Aufruf an die übrigen Tags auf der Serverseite weiterleiten, damit der Aufruf registriert werden kann.
Chrome-Tests (Modus a/b)	Wird erwartet, dass Sell-Side-Plattformen (SSP) diese Labels auch in RTB-Gebotsanfragen übergeben und wenn ja, wie?	Ja. Es wird erwartet, dass die Labels von der SSP an die DSP übergeben werden. Entitäten sollten auf das Label zugreifen und den Wert unverändert über diese Geräteerweiterung mit Partnern teilen.
Datenspeicherung und -nutzung	Haben Sie weitere Informationen dazu, wie die Daten gespeichert und wohin sie übertragen werden?	Wir werden keine rechtlichen Ratschläge geben, sondern eher unseren Ansatz/allgemeine Überlegungen zur Datenspeicherung, Aufbewahrung und anderen Datenschutzfragen. Weitere Informationen
API-Sicherheit	Bedenken hinsichtlich schädlichem clientseitigem Code, der den Rückgabewert der Funktion „generateBid()“ manipulieren würde.	Wir haben das Problem hier besprochen und ein Teil des Feedbacks wurde in den Vorschlag für die private Aggregation einfließen.
Benutzerdefiniertes Ziel	Wissen Sie bei „reportEvent“-Aufrufen von benutzerdefinierten Zielen, ob ein Ursprung für benutzerdefinierte Berichte (nicht für den Käufer oder für den Verkäufer), der als Teil einer IG in „AllowedReportingOrigins“ vorregistriert wurde, von der DSP in „reportWin“ mit „registerAdBeacon“ deklariert werden muss?	Nein, sie muss nicht noch einmal in „reportWin“ registriert werden. Sie kann direkt in „reportEvent“ verwendet werden, wie hier beschrieben.
API-Einschränkungen	IG-Größe während der Erstellung und Aktualisierung.	Die Updategröße wurde auf 1 MB aktualisiert, was der neuen Obergrenze von 1 MB (von 50 KB) für die Erstellung von IG-Dateien entspricht.
Einschränkungen für K-anon	K-anon für Anzeigen mit verschiedenen Größen.	Im Dezember 2023 haben wir den Wert für die k-Anonymität veröffentlicht. Dieser besagt, dass die Anzeigengröße „irgendwann nach 2025“ überprüft wird. Es gibt keine Möglichkeit, Größe auszuschließen, da es sich um einen websiteübergreifenden Tracking-Vektor handeln kann, wie im WICG-Gespräch am 11. Oktober beschrieben.
API-Sicherheit	Kann ein böswilliger Spieler den Hostnamen einer Seite fälschen?	Die API unterstützt einen Unterschlüssel, der auf den Hostnamen des Publishers festgelegt ist. Da der Browser den Schlüssel einstellt, erscheint es schwierig, diesen Mechanismus zu umgehen.
API-Nutzung	ForDebuggingOnly-Funktionen sollten nicht für die Produktion empfohlen werden.	Wir sind dabei, dem Ökosystem zu betonen, dass die forDebuggingOnly-Funktionen sich überhaupt nicht für die Fehlerbehebung nach 3PCD eignen.
Weitere Debugging-Tools erforderlich	ForDebuggingOnly reicht nicht aus, um Probleme zu verstehen, die vor „scoreAd()“ auftreten können.	Wir sammeln derzeit mehr Feedback zu dieser Lücke und freuen uns über weitere Anregungen.
Dauerhaftes Deaktivieren von Interessengruppen	Anfrage, damit Nutzer der Erstellung spezieller Google-Produkte dauerhaft widersprechen können.	Unsere Strategie war es, Nutzer nicht auf IG-Ebene deaktivieren zu lassen, da die Semantik für sie nach dem Stand der Dinge nicht nachvollziehbar ist.
Dokumentation verbessern	Verwenden Sie für den Parameter „ renderUrls“ in der Spezifikation und in der Erläuterung dieselbe Groß- und Kleinschreibung.	Wir wissen Ihr Feedback zu schätzen und werden die Dokumente bald aktualisieren.
Unterstützung für Protected Audience-Deals	Fordern Sie weitere Optionen für Unterstützung bei Protected Audience-Deals an.	Das Chrome-Team prüft derzeit, was wir tun können, um dies durch 3PCD zu unterstützen.
Makros	Makro-Unterstützung erforderlich, um die Größe von IGs unter der maximalen IG-Größe zu halten.	In einer kürzlich erfolgten Aktualisierung der Erläuterung wurde diese Anfrage teilweise berücksichtigt.
ReportLoss API auf Ereignisebene	Anfrage für die ReportLoss API auf Ereignisebene	Berichte zu Verlusten auf Ereignisebene stellen zwar ein erhebliches Datenschutzrisiko dar, aber wir sind der Meinung, dass die grundlegenden Ziele dieser Anfrage stattdessen mit entsprechenden Änderungen an der Private Aggregation API erreicht werden können. Wir freuen uns über weiteres Feedback.
API-Nutzung	Wie verhalten sich forDebuggingOnly-Methoden, wenn kein Gebotswert größer als 0 ist?	Wenn der Wert <= 0 ist, ist das ein automatischer Verlust. Also wird „reportAdAuctionloss“ aufgerufen.
Standardisierung	Keine Übereinstimmung zwischen Nutzern des Eingabe-/Ausgabewerts der Funktion „generateBid()“ der PA API.	Wir empfehlen allen Partnern, dieses oder ähnliche Probleme beim IAB Tech Lab zu melden. Diese Gruppe arbeitet speziell an Branchenstandards für APIs wie Protected Audience.
API-Sicherheit	Welche Daten von unseren IGs kann Google sehen?	Die k-Anonymität stützt sich auf einen starken Datenschutz, um zu verhindern, dass sensible Nutzerdaten an Dritte, auch an Google, weitergegeben werden. Google entwickelt auch eine Drittanbieterimplementierung (Fastly) dieser Ebene, um dieses Risiko zu minimieren.
Chrome-Tests (Modus a/b)	Können eingeschränkte Nutzer vom Test ausgeschlossen werden?	Wir legen den Status der k-Anonymität in Berichten offen, wie hier erläutert.
Markensicherheit	Unterstützung von Markensicherheits-Anwendungsfällen, bei denen Anzeigen je nach der Liste der blockierten Websites oder Keywords nicht ausgeliefert werden	Solche Anwendungsfälle für die Markensicherheit sollten mit der PA API bereits möglich sein. Für eine Werbekampagne, die auf bestimmte Domains ausgerichtet ist, kann die Domain-Sperrliste entweder im IG selbst gespeichert werden. Möglicherweise wird ein Bloom-Filter verwendet, wenn die einzelnen Einträge zu viel Platz beanspruchen würden. Oder sie können die Zulassungs- oder Ablehnungsentscheidung von ihrem Schlüsselwert-Server mithilfe einer UDF zurückgeben, die anhand der Kombination aus dem Schlüssel, der die Werbekampagne identifiziert, und dem Domainnamen, der in der Schlüsselwertanforderung enthalten ist, nach der Antwort sucht. Mit der Protected Audience API können sowohl die SSP als auch die DSP alle Informationen zum Seitenkontext an die Auktion weitergeben. Dies kann beispielsweise eine Liste sensibler Themen oder Keywords auf der Seite sein. Die Gebotslogik der DSP kann diese Informationen mit gespeicherten Informationen darüber vergleichen, wo die Anzeige nicht erscheinen soll, und gegebenenfalls ein Gebot abgeben. Wir freuen uns über Feedback zu bestimmten Anwendungsfällen, die ihrer Meinung nach nicht möglich sind.
Delegierung von Berechtigungen	Wie funktioniert das Delegieren von Berechtigungen?	Eine Dokumentation zur Berechtigungsdelegierung finden Sie hier.
Batchanfragen	Verwende für einige PA API-URLs die POST-Anfrage, um die Batch-Anfrage zu unterstützen.	Wir freuen uns über Ihren Vorschlag und freuen uns über zusätzliches Feedback, das Sie hier einreichen können.
API verbessern	Felder, die wahrscheinlich nicht verwendet werden sollten (z. B. X-fledge-Bidding-signals-format-version)	Wir besprechen das Problem und freuen uns über zusätzliches Feedback hier.
API verbessern	Anfrage zur Weitergabe der DSGVO-Einwilligung an einen Drittanbieter für die Anzeigenbereitstellung und ‐analyse.	Diese Funktion wird mit der verworfenen ReplaceInURN-Makroersetzungs-API unterstützt, wie hier erläutert.
Dynamische Creatives optimieren	Wie unterstützt Protected Audience die Optimierung dynamischer Creatives?	Dieser Anwendungsfall und mögliche Lösungen werden hier erörtert.
API verbessern	Anfrage für die URL der Anzeigenbereitstellung durch Drittanbieter, mit der der IG-Kontext abgerufen werden kann, primär der IG-Name, der dem IG entspricht, das die Auktion gewonnen hat.	Solche Anfragen können das Tracking-Risiko für Nutzer erhöhen. Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier.
API-Sicherheit	Sie befürchten, dass aufgrund der Größe von „IG blob“ Informationen über die ausgewählten IGs offengelegt werden.	Wie im Abschnitt zum Datenschutz in der Chrome B&A API-Erklärung erwähnt, hängt die Blob-Größe nicht von den Eingaben in navigator.getInterestGroupAdAuctionData() ab. Es werden nur alle IGs auf dem Gerät zusammengefasst. Dadurch wird sichergestellt, dass die Blob-Größe auf einer Seite relativ einheitlich ist, und das Risiko von websiteübergreifenden Informationen wird eingeschränkt. Genau aus diesem Grund haben wir es auf diese Weise entwickelt.
Chrome-Tests (Modus a/b)	Welche Haltung halten die anderen Sell-Side-Plattformen (SSPs), wenn es darum geht, Cookies zu setzen und von Chrome unterstützte Tests auszuführen?	Wir haben bislang keine wesentlichen Bedenken gehört (obwohl andere diese Situation zur Kenntnis genommen haben). Wir freuen uns aber über Feedback, wenn es sich um ein erhebliches Problem handelt.
Support für A/B Testing	Fordern Sie Support für A/B-Tests an die PA API an.	Wir haben diese Anfrage in der WICG-Besprechung im November besprochen und freuen uns über zusätzliches Feedback.
Anzeigengrößen	Wer wählt die Größe für eine Protected Audience-Auktion aus?	Diese Frage wird in diesen FAQs beantwortet.
API verbessern	Anfrage zum Konfigurieren des Diensts für Schlüssel/Wert-Paare, um den Pfad /bidding-signals/v1/getvalues zu akzeptieren	Wir haben dieser Pull-Anfrage Supportpfadpräfixe hinzugefügt.
API-Nutzung	Wie kann ein Publisher die IG mit seinem Code erstellen, wenn er Teil des Werbetreibendenstamms sein soll, damit der Werbetreibende darauf bieten kann?	Die Antworten müssen von einem AdTech-Partner stammen, also von einem DSP oder SSP, der an Protected Audience-Auktionen teilnehmen möchte und die Möglichkeit bietet, diese Zielgruppen aus einer externen Quelle zu beziehen. Wir haben dieses Problem in diesem GitHub-Problem ausführlicher behandelt.
API verbessern	Anfrage zur Verknüpfung auszuschließender Interessengruppen mit Anzeigen in „Einzuschließender Interessengruppen“.	Wir prüfen diese Anfrage und haben hier einen Vorschlag zur Unterstützung vorgelegt.
Anzahl der Shards	Supportanfrage zur Weitergabe von „shard_num support“ in Metadaten.	Aufgrund dieses Feedbacks haben wir Unterstützung für „shard_num“ hinzugefügt.
API-Nutzung	Anfrage zur Schätzung des Aufwands für Schlüssel im K/V-Server.	Wir haben Ihre Meinung geteilt und freuen uns über zusätzliches Feedback hier.
k-Anonymität	Anfrage zur Klarstellung und Verbesserung des Detaillierungsgrads von k-Anonymitäts-Zählern	Weitere Informationen zum Detaillierungsgrad der k-Anonymitäts-Zähler finden Sie hier.
Debugging	Anfrage zur Verbesserung der PA API-Debugging-Funktionen nach den kürzlich vorgeschlagenen Änderungen an forDebuggingOnly.	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
Anzeigengröße	Anfrage für die Größe der Anzeigenfläche als zusätzliches BTS-Signal.	Wir haben einen Vorschlag zur Unterstützung dieser Anfrage veröffentlicht. Hier können Sie uns zusätzliches Feedback geben.
API-Sicherheit	Ist es möglich, die Nutzung von „runAdAuction()“ basierend auf einem Ursprung einzuschränken?	Eine ausführliche Antwort finden Sie hier.
IG-Lifetime	Anfrage zur Verlängerung der Lebensdauer von IGs von 30 auf 90 Tage.	Wir prüfen die Anfrage und freuen uns über zusätzliches Feedback.
API-Nutzung	Ist es möglich, eine Protected Audience-Auktion parallel zu Header Bidding und dem Ad-Server-Aufruf des Publishers durchzuführen?	Wir besprechen diese Anfrage derzeit und freuen uns über zusätzliches Feedback hier.
Debugging	Anfrage nach besserem Support für Chrome PA API-Debugging-Erweiterungen über die Entwicklertools.	Wir stellen gern weitere Tools zur Fehlerbehebung bereit. Zusätzliche Vorschläge finden Sie hier.
API-Nutzung	Verlustbenachrichtigungen werden nicht ausgelöst, wenn keine Gebote von Komponentenverkäufern es zum Bestseller werden.	Die Begründung finden Sie hier.
API verbessern	Anfrage zur Unterstützung von TextEncoder im Worklet für Protected Audience-Gebote.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier.
API-Nutzung	Netzwerkaufrufe und die ausgeführte Logik im Client können den Hauptthread blockieren und Probleme bei der JS-Ausführung verursachen, die sich auf die SEO auswirken können.	Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier.
API-Nutzung	Können DSPs ihren aktuellen serverseitigen Gebotstrichter verwenden, um die Anzeigenkandidaten als Teil von „perBuyerSignal“ zur Verwendung in On-Device-Auktionen zu bewerten und zu senden?	Wir besprechen diese Frage derzeit und freuen uns über zusätzliches Feedback hier.
Daten zu Gebotsmöglichkeiten erweitern	Anfrage zur Erweiterung der vom Browser an die SSP übergebenen Daten zu Gebotsempfehlungen mit einer Liste eindeutiger Ursprungsdomains der aktiven IGs im Browser.	Wir besprechen diese Anfrage derzeit und freuen uns über zusätzliches Feedback hier.
Echtzeitgebote	Anfrage für zwei neue Hooks für „auktionskonfiguration“ und die Anpassung der Antwort „generateBid“ in ORTB.	Wir prüfen das Problem und freuen uns über zusätzliches Feedback.
Vorheriger Sieg	Anfrage für IG zum Definieren eines prevWinsTransformer, der die vorherigen Siege des IG annimmt und einen seriellen Ding ausgibt.	Wir prüfen das Problem und freuen uns über zusätzliches Feedback.
Inhaltstypen	Strategie zur Weiterentwicklung von Inhaltstypen, z.B. von JSON zu CBOR.	Wir prüfen das Problem und freuen uns über zusätzliches Feedback.
Prebid in der Protected Audience API	Anfrage für eine Beispielseite eines Publishers, auf der Prebid verwendet wird, um einen End-to-End-Ablauf für Protected Audience-Auktionen durchzuführen.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback aus der Plattform, warum dies priorisiert werden sollte. Einige Nutzer haben außerdem Beispielseiten von Publishern erstellt, die anderen im System zur Demo zur Verfügung stehen.

Geschützte Auktionsdienste

Feedback	Zusammenfassung	Chrome-Antwort
Vertrauenswürdige Ausführungsumgebungen	Ist die Ausführung von vertrauenswürdigen Ausführungsumgebungen in öffentlichen Clouds kostspieliger als in lokalen AdTech-Rechenzentren?	Unser aktuelles TEE-Sicherheitsmodell profitiert von Implementierungen in öffentlichen Clouds. Insbesondere schützen die aktuellen hardwarebasierten TEEs nicht vor allen physischen Angriffen. Unsere bestehenden unterstützten Anbieter öffentlicher Clouds, AWS und GCP, haben Maßnahmen zur Minderung von physischen Zugriffsrisiken entwickelt und implementiert, auch durch Mitarbeiter. Weiter unten finden Sie weitere Informationen zum lokalen Support. Nach Angaben von Anzeigentechnologie-Anbietern sind Cloud-Dienste teurer als lokale Rechenzentren für AdTech. Obwohl wir diese Aussagen nicht bewerten können, freuen wir uns über zusätzliches Feedback zu den Kosten und prüfen weiterhin, wie wir unseren TEE-Support erweitern können.
(Aus vorherigen Quartalen erfasst) Tee vor Ort	Welche Anforderungen muss man erfüllen, um TEE-Anbieter zu werden?	Unsere Antwort ist ähnlich wie in den vorherigen Quartalen: „Wir suchen weiterhin nach Optionen, die über öffentliche cloudbasierte Lösungen hinausgehen, und prüfen, welche Bereitstellungen aus Sicherheitsperspektive akzeptabel sind. Derzeit haben wir jedoch keine Pläne, lokale TEEs zu unterstützen. Derzeit sind wir angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, der Meinung, dass es für das System von größtem Nutzen ist, die cloudbasierten Bereitstellungen weiter auszubauen und zu verbessern. Wir freuen uns jedoch über zusätzliches Feedback dazu, warum eine solche Anforderung angesichts der Datenschutz- und Sicherheitseinschränkungen notwendig und durchführbar ist.“
Einschränkungen des Schlüssel/Wert-Servers	Einschränkungen von Schlüsseln pro Auktion und Server	Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier.
Einschränkungen für K-anon	Bestätigung, dass die K-Anonymität in Zukunft für K/V-Schlüssel nicht erzwungen wird.	Derzeit gibt es keine Pläne, K/V-Server bei Schlüsseln von K/V-Serveranfragen durchzusetzen, da wir K/V-Server künftig in TEE migrieren möchten.
K/V-Dienst entwickeln	Steht Google vorgefertigte Artefakte für den K/V-Dienst zur Verfügung?	Derzeit haben wir keine vordefinierten Artefakte für den Schlüssel/Wert-Server der Protected Audience API. Wir können sie jedoch zur Verfügung stellen, wenn eine starke Nachfrage aus dem System zu hören ist.
Beispiel-Support in B&A	Anfrage zum unterstützenden Feld „experimentGroupId“ im Gebots- und Auktionscode und an den Schlüsselwert-Dienst von BuyerFrontEnd	B&A unterstützt „experimentGroupId“ derzeit nicht, soll aber mit Beta 2 eingeführt werden (derzeit für Februar 2024 geplant). Weitere Informationen finden Sie hier.
API-Nutzung	Die Anfragezusammenführung über HTTP kann helfen, sich vor Angreifern auf dem Pfad zu schützen, aber der Betreiber des TEE merkt sich die Größe.	Wir besprechen diese Anfrage derzeit und freuen uns über zusätzliches Feedback hier.
Dokumentation verbessern	Aus der Spezifikation geht nicht klar hervor, wie der k-v-Server adressiert wird.	Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier.
API-Nutzung	Welchen Zweck haben "Ad-Auction-Result" (Anzeigenauktionsergebnis) und "adAuctionHeaders"?	Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Dokumentation verbessern	Es ist unklar, ob das V2-Design in FLEDGE.md übernommen wurde.	Unter FLEDGE.md wird erläutert, wie Chrome Anfragen an BYOS-KV sendet. Das v2-Protokolldesign ist auf TEE-KV beschränkt und wird derzeit nicht von Chrome unterstützt.

Analyse digitaler Anzeigen

Attribution Reporting (und andere APIs)

Feedback	Zusammenfassung	Chrome-Antwort
Umgebungsübergreifende Messung	Wie wird Chrome die umgebungsübergreifende Messung in der Übergangsphase unterstützen, in der Drittanbieter aus Chrome Mobile entfernt wurden, die Privacy Sandbox für Android aber noch nicht verfügbar ist?	Für Android arbeiten wir daran, die Abdeckung für PSB/ARA zu erweitern. Die Attribution Reporting API (ARA) ist für Android 13 und 14 verfügbar. Die Einführung auf Android 11 und 12 soll im Laufe des Jahres beginnen. Dies kann sich jedoch noch ändern. Eine Erweiterung auf Android 10 oder niedriger ist nicht möglich. Wir gehen jedoch davon aus, dass der Prozentsatz der Android-Geräte mit Android 10 oder niedriger bei 3PCD niedriger sein wird und im Laufe der Zeit mit dem Upgrade von Nutzern voraussichtlich abnimmt. Wir freuen uns über zusätzliches Feedback von der Community zu dieser Anfrage.
Wird gefiltert	„Conversions“ aus der Creative-Überprüfung herausfiltern	Wir haben diesen Stakeholder kontaktiert, um seine Anfrage besser zu verstehen, und freuen uns über zusätzliches Feedback aus dem Ökosystem zu diesem Thema.
Ad-Server von Drittanbietern	Wie funktionieren PA API und ARA mit Ad-Server-Tags von Drittanbietern?	Ähnlich wie bei Pixeln mit Impressions- und Klick-Tags kann ein Ad-Server entweder selbst die Quelle festlegen und Registrierungen für ARA auslösen (auch bei Protected Audience-Auktionen) oder Weiterleitungen einrichten, um die Quelle zu übergeben und zu akzeptieren und Registrierungen für ARA auszulösen.
DCM	Unterstützung von "attributionsrc" durch DCM und Ad-Server eines Drittanbieters.	Es handelt sich um ein DCM-Problem, das vom DCM-Team in diesem GitHub-Problem behoben wurde.
Hierarchischer Aggregationsschlüssel	Muss das gesamte Beitragsbudget in all diese hierarchischen Schlüssel aufgeteilt werden?	Wir haben diesen Stakeholder besprochen und ihm eine Antwort gegeben. Bei Verwendung einer hierarchischen Schlüsselstruktur muss die AdTech-Technologie berücksichtigen, dass das Beitragsbudget auf alle Schlüssel für eine Impression aufgeteilt wird.
Verschiedene Subdomains verwenden	Attributionsberichte so einrichten, dass sie mit Quellen und Triggern zusammenarbeiten, die auf verschiedenen Subdomains, aber mit derselben eTLD+1 registriert sind?	Wir haben diese Frage mit dem Stakeholder besprochen und die folgenden Lösungen vorgeschlagen. Sie können entweder die URL-Einrichtung so ändern, dass für Quelle und Trigger derselbe Berichtursprung gilt, oder sie können vor der Registrierung von ihrer aktuellen URL zu einer gemeinsamen URL weiterleiten. Wir freuen uns über zusätzliches Feedback, falls die vorgeschlagenen Lösungen für den jeweiligen Anwendungsfall nicht funktionieren.
(Auch in vorherigen Quartalen gemeldet) Produktionssupport	Welche Servicelevels stehen Partnern zur Verfügung, die ARA verwenden?	Unsere Antwort hat sich im Vergleich zu vorherigen Quartalen nicht geändert: „Google bietet eine Reihe von Kanälen, über die AdTech-Teams technische Probleme melden und die zur Lösung dieser Probleme erforderlichen Eskalierungen ermöglichen können. Darüber hinaus plant Chrome, Prozesse zur Behebung technischer Probleme und Eskalierungen, die sich auf die Integrität der Umgebung auswirken, weiter auszubauen und zu skalieren. Chrome ist bestrebt, Ressourcen für diese Bemühungen bereitzustellen. In unserem Entwicklerbeitrag finden Sie weitere Informationen zu den öffentlichen und privaten Foren für Feedback und Eskalationen.“
(Auch in vorherigen Quartalen aufgeführt) Zeitachse	Wird Google zu Beginn der quantitativen CMA-Tests „Phase 2 (Full Flexible Event-Level)“ bereitstellen?	Phase 2 (vollständig flexible Ereignisebene) wird voraussichtlich im 1. Quartal 2024 in Chrome verfügbar sein. Sie können den Status hier einsehen.
(Auch in vorherigen Quartalen erfasst) Conversion-Trichter	Mehrere Domains erfassen, die bei der Conversion verwendet wurden	Dieser Anwendungsfall ist möglich, da mehrere Ziele hinzugefügt wurden. Wir freuen uns über zusätzliches Feedback.
Labels für Berichtstests	Können Tester mithilfe der Berichtsfunktionen angeben, zu welcher Gruppe der Nutzer (Chrome-Browser) gehört (Modus A/B)?	Wir arbeiten an der Veröffentlichung eines Leitfadens für die Erfassung von Chrome-Testlabels in ARA.
Dokumentation	Laut der Dokumentation für Attribution-Reporting-Register-Source wird der Ablauf auf den nächsten Tag gerundet. Wie wird er gerundet?	Wird auf den nächsten Tag gerundet, werden 1,5 Tage auf 2 Tage gerundet.
Verschiedene Subdomains verwenden	Anfrage zum Empfang von Attribution Reporting API-Berichten in einer anderen Subdomain als Quelle und Auslösung der Registrierung	Das ist nicht möglich. HTTP-Weiterleitungen können angewendet werden, es ist jedoch keine entsprechende Einrichtung erforderlich. Wir freuen uns über zusätzliches Feedback aus der Community darüber, warum diese Anfrage hilfreich ist.
Verzögerung bei der Berichterstellung auf Ereignisebene	Sieben Tage für Attribution und Berichterstellung. Aufgrund der Verzögerung bei der Berichterstellung auf Ereignisebene kann es jedoch länger als acht Tage dauern, bis alle Berichte erstellt sind.	Wir nehmen das Feedback ernst und freuen uns über zusätzliche Rückmeldungen aus der Branche dazu, ob diese Verzögerung bei der Berichterstellung auf Ereignisebene ein Problem ist oder nicht, insbesondere im Hinblick auf die Umstellung von festen auf flexible Zeitfenster für Ereignisberichte.
Conversion-Trigger	Mit Conversion-Triggern, die zwischen dem Ende des ersten „event_report_window“ (1 h) und der Ablaufzeit (1 Tag) auftreten, werden keine Berichte generiert.	Wir haben eine flexible Konfiguration auf Ereignisebene eingeführt, die von festen zu flexiblen Fenstern für Ereignisberichte übergeht.
Geräusche	Enthalten Berichte auf Ereignisebene eine verrauschte Fälschung, wie in der GitHub-Erklärung beschrieben?	Ja. Rauschen wird auf Berichte auf Ereignisebene angewendet und ist repräsentativ für alle möglichen Ausgabestatus, einschließlich verschiedener „trigger_data“, und es wird gar nichts gemeldet, wenn ein Trigger aufgetreten ist, oder es werden möglicherweise mehrere falsche Berichte für das Ereignis gemeldet. Der Wert für „Rauschen in %“ ist Open Source und kann durch flexible Konfigurationen auf Ereignisebene flexibel gestaltet werden.
Wird gefiltert	Das Filtern mit der Attribution Reporting API würde trotzdem das Beitragsbudget verbrauchen, auch wenn der Aggregationsschlüssel nicht aufgezeichnet wird.	Das funktioniert wie beabsichtigt, da aggregatable_trigger_data nur das Filtern nach den Triggerschlüsselelementen selbst und nicht nach den Werten / Schlüsseln unterstützt. Filter der obersten Ebene unterstützen das Filtern der Schlüssel selbst. Dies wird jedoch für Ereignis und Aggregat freigegeben, daher ist es hier nicht anwendbar. Falls ein Filterung nach Schlüsseln erforderlich ist, freuen wir uns über zusätzliches Feedback aus unserer Community.
Speicherlimit	Anfrage zur Einführung eines Speicherlimits, bei der auch der Ursprung der Berichterstellung berücksichtigt wird.	Ab M120 wird dieses Limit von 1.024 auf 4.096 erhöht. Wir freuen uns über zusätzliches Feedback aus der Community.
Direkte Attribution	Wie erhalte ich Messwerte für Situationen, in denen ein Nutzer einen Werbetreibenden direkt besucht, ohne einen Publisher zu durchlaufen, da dies beim standardmäßigen Attributionsbericht nicht berücksichtigt wird?	ARA dient lediglich der Wiederherstellung websiteübergreifender Informationen (d.h. der Zusammenführung von Informationen über Publisher-/Werbetreibenden-Websites). Wenn keine websiteübergreifenden Informationen erforderlich sind, ist die ARA nicht hilfreich. Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier.
Berichtszeitraum	Rufen Sie „schedule_report_time“ von einem Zeitserver ab, anstatt die Zeit des lokalen Computers zu verwenden.	Derzeit planen wir nicht, einen Zeitserver zu verwenden, und es gab noch nicht viel Nachfrage von AdTech. Wir würden gerne zusätzliches Feedback von der Branche dazu erhalten, ob diese Funktion nützlich wäre.

Aggregationsdienst

Feedback	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen gemeldet) Lokale Lösung	Kann der Aggregation Service in lokalen Rechenzentren bereitgestellt werden?	Wir erforschen derzeit mögliche Optionen, die über cloudbasierte Lösungen hinausgehen, aber aufgrund lokaler Sicherheitseinschränkungen, die eine zeitaufwendige Evaluierung der Privacy Sandbox erfordern würden, ist es derzeit nicht möglich, lokale TEEs zu unterstützen. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, sind wir davon überzeugt, dass die weitere Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z.B. die Unterstützung von Google Cloud zusätzlich zu AWS) für das System am vorteilhaftesten ist. Wir freuen uns aber über zusätzliches Feedback dazu, warum eine solche Anforderung erforderlich ist.
Enklave	Wie wird die Enklave von der Aggregation Service API gehandhabt, wenn sie nicht aktiv ist oder plötzlich einen Fehler erhält?	Wir verwenden Wiederholungsversuche, wenn die Enklave beim Start fehlschlägt, und Autoscaling, um neue Instanzen aufzurufen, wenn eine Instanz als fehlerhaft eingestuft wird. AdTechs können Fehler auch mithilfe von Logs untersuchen. Zum Beheben von Enklave-Fehlern in AWS können Anzeigentechnologie-Anbieter den Status ihrer EC2-Instanz prüfen, indem sie sich im AWS Console Manager anmelden. Anzeigentechnologie-Anbieter können sich auch in der Nitro Enclave-Hostinstanz anmelden und den Enclave-Status mit dem Tool „nitro-cli“ prüfen. Wenn Fehler auftreten, können sie die Logs über die AWS-Befehlszeile ansehen und weitere Untersuchungen anstellen. Zum Beheben von Enklave-Fehlern auf der GCP können AdTech-Unternehmen den Status ihrer Instanz über die Cloud Console prüfen. Sie können auch den Befehl list-errors-command verwenden, um nach Fehlern zu suchen.
Verschiedene Subdomains verwenden	Anfrage zum Registrieren mehrerer (Sub-)Domains, um mehrere Instanzen von Aggregationsdiensten sowohl in Entwicklungs- als auch in Produktionsumgebungen zu verwenden.	Die Websiteregistrierung wurde eingeführt, sodass Anzeigentechnologie-Anbieter mehrere Subdomains derselben Website in einem AWS-Konto oder GCP-Projekt registrieren können. Außerdem können sie dieselbe Domain in mehreren AWS-Konten oder GCP-Projekten registrieren. Wir freuen uns über Feedback von unserer Community.
Datenschutzbudget	Wie lassen sich Probleme im Zusammenhang mit der Ausschöpfung des Datenschutzbudgets besser beheben?	Derzeit arbeiten wir an Lösungen, um mehr Details zum aufgebrauchten Budget bereitzustellen und um unsere Dokumentation zu verbessern, um Strategien zu skizzieren, mit denen AdTech-Unternehmen das Auftreten dieses Fehlers minimieren können. Wir aktualisieren die GitHub-Seite zum Aggregationsdienst, sobald wir einen Vorschlag haben.
Epsilon-Wert	Anfrage zur Erhöhung des Epsilon-Werts	Der Epsilon-Wert des Aggregation Service wird in einem Bereich von bis zu 64 beibehalten, um Tests und Feedback zu verschiedenen Parametern während der 3PCD zu erleichtern. Wir informieren das System im Voraus, bevor die Werte für den Epsilon-Bereich aktualisiert werden.
Binärprogramme	Veröffentlichen Sie einen umfassenderen Satz an Binärprogrammen für Aggregation Service-Releases.	Wir prüfen diese Anfrage und freuen uns auf zusätzliches Feedback.
API-Nutzung	Weitergabe von Daten an Koordinatoren in Anbetracht der Nutzungsbedingungen für Koordinatoren	Wir möchten diese Angelegenheit klären und würden uns über zusätzliches Feedback freuen.

Private Aggregation API

Feedback	Zusammenfassung	Chrome-Antwort
Debugging	Aktiviere zusätzliche Optionen für das Debugging während Modus-B-Tests.	Wie in diesem GitHub-Problem beschrieben, wird der Debug-Modus in Modus B künftig zugelassen. Diese Berechtigung ändert sich ab dem 31. Januar in M121-Beta bei 50% des Traffics von Modus B. Wir informieren Sie vor der Umstellung auf die stabile Version.

Verdecktes Tracking einschränken

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

Feedback	Zusammenfassung	Chrome-Antwort
ChromeOS	Support von User-Agent-Client Hints für die Bit-Leistung von Chrome OS.	Eine Antwort auf diese Anfrage finden Sie hier.

IP Protection (früher Gnatcatcher)

Feedback	Zusammenfassung	Chrome-Antwort
Missbrauch	Google kann die Browserdaten von Nutzern unter Umständen durch IP-Schutz einsehen.	Der IP-Schutz leitet Traffic über zwei Proxys, von denen einer von Google und der andere von einem anderen Unternehmen betrieben wird. Dadurch wird sichergestellt, dass Google keine Browserdaten sehen kann. Sämtlicher Datenverkehr zwischen Chrome und den Proxys wird verschlüsselt, sodass der Google-Proxy keine Informationen darüber hat, welche Websites durchsucht werden. Außerdem verwendet das System blinde Authentifizierungstokens, um den Zugriff auf Nutzerkennungen an den Proxys zu minimieren. Der Google-Proxy sieht nur, dass ein unbekannter Client mit einer bestimmten IP-Adresse das Proxysystem verwendet. Es sind keine Informationen zu besuchten Websites oder geladenen Anzeigen verfügbar.
Unterstützung für den monitorlosen Modus	Wie werden Bots verwaltet, die Plug-ins und den monitorlosen Modus verwenden?	Die Eindämmung des Missbrauchs des IP-Schutzes hat für das Team höchste Priorität. Wir haben diese Szenarien sorgfältig geprüft (und auch viele andere potenzielle Bedrohungen) und arbeiten an Optionen, mit denen die Wahrscheinlichkeit von Missbrauch und Betrug verringert werden kann. Derzeit können wir keine weiteren Angaben machen, werden diese aber in naher Zukunft bereitstellen und freuen uns auf die Fortsetzung der Diskussion.
Vorhandene Proxys	Wie funktioniert der IP-Schutz mit bestehenden Proxy-Einstellungen in Chrome?	Bestehende Proxykonfigurationen werden weiterhin unterstützt. Nutzer können ihre eigenen benutzerdefinierten Proxys wie zuvor konfigurieren.
Missbrauch melden	Wie wird Missbrauch gemeldet?	In naher Zukunft werden wir weitere Details dazu bekannt geben. Wir planen jedoch, eine Funktion für Organisationen und Nutzer einzurichten, über die Meldungen und Hinweise auf Missbrauch gemeldet werden können.
Vorschriften	Wie wird der Schutz von IP-Adressen lokalen Gesetzen und Bestimmungen entsprechen?	Google verpflichtet sich zur Einhaltung lokaler Gesetze und Bestimmungen. Das Umgehen solcher länderspezifischen Sperrungen ist möglicherweise nicht zulässig. Diese Funktion ist nicht zur Umgehung gedacht.
Funktionen einschränken	Blockiert der IP-Schutz unsere Cyberabwehr?	Unser Ziel ist es, Nutzer vor der Verfolgung ihrer IP-Adressen im Web zu schützen und gleichzeitig die Störung des normalen Serverbetriebs zu minimieren. Dazu gehört auch die Verwendung von IP-Adressen zur Verhinderung von Missbrauch. Derzeit können wir keine weiteren Angaben machen, werden diese aber in naher Zukunft bereitstellen und freuen uns auf die Fortsetzung der Diskussion.
Zeitplan	Wenn dies bis Ende 2024 umgesetzt werden soll, wird es fast unmöglich sein, sich darauf vorzubereiten.	Chrome führt den IP-Schutz zuerst als Opt-in-Einstellung für Nutzer in bestimmten Regionen ein. Wir wissen, dass dies eine erhebliche Veränderung für die Art und Weise haben kann, wie einige Unternehmen auf IP-Adressen angewiesen sind, und wir versuchen, Störungen während der Anpassung des Systems zu minimieren. Der IP-Schutz wird frühestens 2025 auf die Standardeinstellung umgestellt.
API-Nutzung	Können Nutzer beim ersten Öffnen von Chrome den IP-Schutz aktivieren?	Wir planen, Nutzern die Wahl zu lassen, ob sie IP-Schutz verwenden möchten oder nicht. Die Mechanismen zur Präsentation dieser Option für Nutzende befinden sich noch in der Entwicklungsphase.
API-Nutzung	Wie viele Daten werden protokolliert und wie lange werden sie aufbewahrt?	Weitere Einzelheiten geben wir bekannt, aber wir planen, nur minimale Datenmengen zu protokollieren.
Negatives Feedback	Nutzer können VPNs nutzen, wenn sie diese bevorzugen. PS APIs sind nicht erforderlich.	Der IP-Schutz dient dazu, die Nutzung von IP-Adressen für websiteübergreifendes Tracking zu verhindern. Er ist nicht als VPN-Dienst gedacht.
API-Sicherheit	Wie verhindere ich, dass Erstanbieter auf IP-Adressen zugreifen und Informationen über den Parameter des Headers weiterleiten?	Wir konzentrieren uns zunächst auf Drittanbieter, da wir sehen, dass dies die größte Wirkung hat. Wir werden die Plattform weiterhin beobachten, um festzustellen, ob wir unseren Ansatz weiterentwickeln müssen, um eine groß angelegte Umgehung zu verhindern.
API-Nutzung	Bestätigung erforderlich, wenn das Verständnis der API-Nutzung korrekt ist.	Beim IP-Schutz wird ein listenbasierter Ansatz verwendet, um zu ermitteln, welcher Traffic von Drittanbietern durch die Proxys geleitet wird. Ursprünge, die auf der Liste stehen, auf die aber in einem Erstanbieterkontext zugegriffen wird, werden für diese Verbindungen nicht über diesen Dienst weitergeleitet. Wenn beispielsweise ein Analyseunternehmen auf der Domainliste steht und ein Nutzer direkt auf die Website gelangt, kann diese Website weiterhin die IP-Adresse des Nutzers anstelle der über den Proxy bereitgestellten IP-Adresse erfassen. Wenn diese Domain auf der Liste jedoch eine Netzwerkanfrage im Kontext eines Drittanbieters sendet, wird die Verbindung weitergeleitet und die ursprüngliche IP-Adresse des Nutzers ist für die Website nicht sichtbar. Unser großes Ziel ist es, websiteübergreifendes Tracking von Nutzern im Web zu verhindern. Wir arbeiten an einigen Details, bevor wir weitere Informationen darüber teilen, auf welche Drittanbieterdomains wir uns zuerst konzentrieren wollen.
VPN	Sie haben Bedenken, dass der Vorschlag von Google für andere VPN-Anbieter nachteilig sein könnte.	Der IP-Schutz dient dazu, die Nutzung von IP-Adressen für websiteübergreifendes Tracking zu verhindern. Er ist nicht als VPN-Dienst gedacht.
Zeitplan	Wie sieht der zeitliche Ablauf des IP-Schutzes aus?	Der IP-Schutz wird anfangs aktiviert. So haben die Nutzer die Kontrolle über ihre Datenschutzentscheidungen und Google kann das Nutzerverhalten in geringerem Umfang im Blick behalten. Der IP-Schutz wird stufenweise eingeführt und wird frühestens 2025 zur Standardeinstellung wechseln. Wie bei allen unseren Vorschlägen zum Datenschutz möchten wir sicherstellen, dass wir kontinuierlich dazulernen und wissen, dass auch regionale Aspekte berücksichtigt werden können. Wir nutzen einen listenbasierten Ansatz, sodass nur Domains auf der Liste im Zusammenhang mit Drittanbietern betroffen sind. Uns ist bewusst, dass diese Vorschläge bei legitimen Anwendungsfällen unerwünschte Störungen verursachen können. Daher konzentrieren wir uns nur auf die Skripts und Domains, die für das Tracking von Nutzern gedacht sind.
Funktionen einschränken	Die IP-Adressen des Nutzers können nicht mehr in WHOIS nachgeschlagen werden.	Wir sind der Meinung, dass die IP-Adresse eine stabile Kennung ist, deren Verwendung Auswirkungen auf den Datenschutz für Nutzer haben kann, einschließlich der Verwendung von mit ihr verknüpften Metadaten wie ASN. Mit dem IP-Schutz möchten wir ein ausgewogenes Verhältnis zwischen Datenschutz und Nutzerfreundlichkeit im Web erreichen, beispielsweise bei der Standortbestimmung von IP-Adressen. Wenn diese Metadaten für Ihren Anwendungsfall nicht ausreichen, können wir das gern näher besprechen.
HTTP-Referrer-URL	Wird der ursprüngliche HTTP-Referrer beibehalten?	Es ist nicht geplant, den Verweis-Header im Rahmen des IP-Schutzes zu ändern, wie hier beschrieben.
Open Source	Sind die Quellcodes von IP Protection Open Source?	Der Großteil der hier genannten Software ist Open-Source-Software im Rahmen der Chromium- und Envoy-Proxy-Projekte. Einige Komponenten sind jedoch Closed-Source.

Eindämmung von Bounce-Tracking

Feedback	Zusammenfassung	Chrome-Antwort
Speicher löschen	Werden durch Bounce Tracking Mitigation (BTM) gemeinsamen Speicher und Attribution Reporting-Speicher gelöscht?	Wir hatten nicht die Absicht, den Privacy Sandbox API-Speicher (ARA, PA API, freigegebener Speicher, private Aggregation, Topics) zu löschen. BTM sollte nur Speichertypen löschen, die Datenschutzrisiken bergen, wenn der Zugriff im Zusammenhang mit Dritten erfolgt. Es wird bereits eine Fehlerbehebung durchgeführt.
API-Nutzung	Welche Chrome-Version wird BTM aktiviert? Wird das Weiterleitungs-/Absprung-Tracking nach 10 Sekunden von BTM als Bounce-Tracking betrachtet oder nicht?	In M116 wurde BTM für alle Nutzer mit blockierten Drittanbieter-PCs eingeführt. Derzeit gilt eine Weiterleitung nach 10 Sekunden nicht als Absprung.
Anwendungsfall: Anmeldung	Anmeldestatus über mehrere Domains hinweg automatisch synchronisieren/beibehalten, ohne dass es durch Tracking-ähnliches Verhalten beeinträchtigt wird?	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback von der Community.
Nutzerpfad	Derzeit führt BTM zu komplizierten User Journeys.	Wir diskutieren das Problem hier und teilen unsere Gedanken dazu mit.
Storage Access API	BTM in Chromium berücksichtigt Drittanbieterberechtigungen für die Storage Access API (SAA).	Wir haben dieses Problem mit Teilnehmern des Ökosystems beim TPAC 2023 besprochen und freuen uns über zusätzliches Feedback.
Auswirkungen auf Anzeigenberichte	Das Eindämmen von Bounce-Tracking kann dazu führen, dass kleinere Unternehmen im Werbesystem andere Privacy Sandbox-APIs wie ARA für die Anzeigenanwendung nutzen.	Mit den Maßnahmen zur Eindämmung von Bounce-Tracking soll eine Umgehung von 3PCD verhindert werden. ARA ist eine von vielen alternativen Analyselösungen, die Unternehmen nach der 3PCD anbieten, aber kein Unternehmen muss sie verwenden.

Datenschutzbudget

In diesem Quartal gab es kein Feedback.

Websiteübergreifende Datenschutzgrenzen stärken

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

Feedback	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen aufgeführt) Domainlimit für Gruppen ähnlicher Websites	Anfrage zur Erweiterung der Anzahl verknüpfter Domains.	Wir gehen derzeit nicht davon aus, dass der numerische Grenzwert erhöht wird. Der Grenzwert wurde basierend auf Datenschutzaspekten für Nutzer, dem Feedback von Stakeholdern des W3C und der Berücksichtigung vergleichbarer Implementierungen in anderen Browsern festgelegt. Weitere Informationen finden Sie in unseren Blogposts (1, 2). Wir empfehlen Ihnen, Anwendungsfälle zu untersuchen, bei denen der websiteübergreifende Zugriff auf Cookies über das numerische Limit hinausgeht, und ziehen Sie unsere Hinweise zu Anwendungsfällen für Identitäten, authentifizierten Einbettungen und Anwendungsfällen für Werbung in Betracht.
Umfang des Cookie-Zugriffs	Bedenken, dass alle Domains in einer RWS den Lese- und Schreibzugriff für alle Cookies aller Domains gewähren werden.	Die Mitgliedschaft in einer RWS-Website führt nicht dazu, dass Mitglieder auf die Cookies der anderen zugreifen können. Stattdessen würde dies Mitgliedern ermöglichen, auf ihre eigenen Cookies zuzugreifen, wenn sie auf anderen Same-RWS-Websites eingebettet sind (nach einem Storage Access API-Aufruf).
(Auch in vorherigen Quartalen gemeldet) Einbindung von RWS und CHIPS	Anfrage zur Integration von RWS und CHIPS, um Anwendungsfälle wie A/B-Tests zu unterstützen	Anwendungsfälle und Anfragen für diese Funktion finden Sie hier. Vorerst wägen wir die Notwendigkeit dieser Funktion gegen die Risiken der browserübergreifenden Interoperabilität ab.
API-Nutzung	Was passiert, wenn ein Nutzer Websites manuell lokal aus seinen Chrome-Einstellungen entfernt?	Wir haben derzeit keine Möglichkeit, eine Website manuell aus einer Gruppe zu löschen. Der Nutzer kann stattdessen die Funktion „Ähnliche Websites“ mit der Ein/Aus-Schaltfläche unter „Drittanbieter-Cookies blockieren“ oder „Alle Drittanbieter-Cookies blockieren“ in den neuen Einstellungen für den Schutz vor Tracking deaktivieren.
Domainübergreifende Kommunikation	Ist mit RWS eine domainübergreifende Kommunikation möglich?	Wir führen derzeit einen Ursprungstest durch, um den Zugriff auf einige Arten von nicht partitioniertem Speicher (einschließlich localStorage und Broadcast Channel) über die Storage Access API auszuweiten, die diese Kommunikation ermöglichen. Diese Funktion ist in allen unterstützten Konfigurationen der Storage Access API für dieselbe RWS- und auch auf Nicht-RWS-Websites verfügbar. Weitere Informationen finden Sie in diesem Blogpost.
requestStorageAccessFor	Kann „document.requestStorageAccessFor(origin)“ ein Promise zurückgeben, das mit den websiteübergreifenden Cookies des Ursprungs aufgelöst wird?	Das ist nicht möglich. Da der Aufruf vom Ursprung der obersten Ebene aus erfolgt (der sich von dem als Argument übergebenen Ursprung unterscheidet), würde dies gegen die Richtlinie für denselben Ursprung verstoßen.

Fenced Frames-API

Feedback	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen verfügbar) Native Advertising	Fenced Frame-Unterstützung für native Werbung	Wir haben bereits mitgeteilt, dass in Zukunft einige Technologien der Privacy Sandbox erforderlich sein werden, um den Datenschutz weiter zu stärken. Für die Protected Audience API müssen Sie beispielsweise ab 2026 Fenced Frames für das Anzeigen-Rendering verwenden und keine Berichte auf Ereignisebene erstellen. Wir haben für jede dieser zukünftigen Anforderungen ein frühes Datum als Datum genannt, damit die Branche Klarheit über die beabsichtigte Weiterentwicklung der APIs hat. Durch diese zusätzliche Zeit können wir in Zusammenarbeit mit der Branche weiter an der Entwicklung und Implementierung eines Supports für eine breitere Palette kritischer Anwendungsfälle arbeiten. Beispielsweise werden wir Fenced Frames weiterentwickeln, als es ab 2026 erforderlich ist, um Video- und native Anzeigen mit der Protected Audience API weiterhin zu unterstützen. Gemäß unseren Verpflichtungen wird die CMA zu solchen Änderungen konsultiert und wir werden weiterhin Feedback aus dem Ökosystem berücksichtigen, bevor wir diese Vorgaben umsetzen.
Größenunterschied zwischen den Plattformen	Gibt an, dass die Größe des im Fenced Frame angezeigten Contents auf Computern und Smartphones unterschiedlich aussieht.	Wir sehen uns das Problem an und freuen uns über zusätzliches Feedback hier.
Anzeigenkomponente rendern	Beispielcodes für das Rendern von adComponents in Fenced Frame angeben?	Wir arbeiten an einer Dokumentation zur Verwendung von navigator.adAuctionComponents(numComponents) innerhalb des Fenced Frame, um eine aus mehreren Teilen bestehende Anzeige darzustellen.
API verbessern	Stellen Sie mehr Signale für FencedFrames bereit (verbessern Sie z.B. die Markensicherheit).	Wir freuen uns über Ihren Vorschlag und freuen uns über zusätzliches Feedback, das Sie hier einreichen können.

Shared Storage API

Feedback	Zusammenfassung	Chrome-Antwort
Anwendungsfall: Missbrauch und Betrug verhindern	Möglichkeit der Verwendung von freigegebenem Speicher für Betrug oder Anomalieerkennung.	Wir haben hier über diese Möglichkeit gesprochen und würden uns über zusätzliches Feedback freuen.
Frequency Capping	Es muss eine Möglichkeit für websiteübergreifendes Frequency Capping außerhalb der PA API bereitgestellt werden.	Wir wissen das Feedback zu schätzen, dass das websiteübergreifende Frequency Capping außerhalb der PA API ein wertvoller Anwendungsfall ist. Derzeit konzentriert sich die Privacy Sandbox weiterhin auf die aktuellen APIs für 3PCD. Wir freuen uns aber über zusätzliches Feedback aus der Community zu diesem Anwendungsfall hier.

Chips

Feedback	Zusammenfassung	Chrome-Antwort
Pop-up/Weiterleitungen	Wie werden CHIPs die eingebettete Authentifizierung mit Pop-ups und Weiterleitungen unterstützen?	wir haben vor Kurzem einige Richtlinien zur Überprüfung der Auswirkungen der Einstellung von Drittanbietern auf Ihren Anmelde-Workflow veröffentlicht und hier zusätzliches Feedback erhalten.
Partitionslimit	Das Gesamtlimit pro Website und Partition auf 1 KiB reduzieren.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier. Wir werden das Feedback im Zuge der Einführung von 3PCD im Blick behalten und Entwickler, die CHIPs einführen, Feedback geben.
Migration von Cookies	Empfohlener Prozess für die Migration einer Webanwendung, um Cookies als partitioniert auszugeben, wobei laufende Cookies/Sitzungen nicht unterbrochen werden?	In unserer Antwort haben wir ein potenzielles Migrationsschema vorgeschlagen. Der Entwickler konnte jedoch eine alternative Lösung entwickeln, die für seine Konfiguration besser funktionierte.
API-Nutzung	Ist der Zugriff auf partitionierten Speicher deaktiviert, wenn ein Nutzer der Einstellung für APIs zum Datenschutz bei Anzeigen nicht zustimmt?	Partitionierter Speicher und partitionierte Cookies (CHIPs) sind auch dann aktiviert, wenn ein Nutzer der Einstellung der APIs für Anzeigen beim Datenschutz nicht zustimmt, da sie keine websiteübergreifende Übertragung von Informationen ermöglichen. Im Allgemeinen unterliegt die websiteübergreifende Übertragung von Informationen Beschränkungen, Prüfungen oder Nutzer-Opt-in, aber diese gelten derzeit nicht für CHIPS.
API-Nutzung	Was ist der Grund dafür, dass nicht partitionierte Cookies schließlich blockiert werden, anstatt sie nur „im Hintergrund“ zu partitionieren?	Kurz- und mittelfristig ist dies nicht möglich, wie hier erläutert.

FedCM

Feedback	Zusammenfassung	Chrome-Antwort
API-Nutzung	„well-known file“ kann in der Entwicklungsumgebung nicht für eTLD+1 bereitgestellt werden.	Wir haben Chrome Canary aktualisiert, sodass das Abrufen der bekannten wie hier beschrieben übersprungen wird.
API-Nutzung	Gibt es bestimmte Anforderungen an Nutzerinteraktionen, die für die Anforderung von Anmeldeberechtigungen durch Dritte oder die Verwendung von FedCM definiert sind?	Es gibt keine speziellen Anforderungen an Nutzerinteraktionen, wie hier beschrieben.
API-Sicherheit	Gibt es Pläne für einen Ablauf, mit dem der Client FedCM initiieren kann, aber im Wesentlichen die Tokens vom IdP an ein Back-End-System des RP übertragen werden?	Wir sprechen über dieses Thema und freuen uns über zusätzliches Feedback hier.
Aktivieren	Erlauben Sie dem IdP, dem Empfang der Client-ID des RP zu zustimmen, damit Nutzer entscheiden können, ob sie dem IdP vertrauen oder nicht.	Wir besprechen diese Anfrage derzeit und freuen uns über zusätzliches Feedback hier.
API-Nutzung	Anforderung weiterer Dokumente zu FedCM.	Dieses Feedback nehmen wir zur Kenntnis und werden die Dokumentation im Rahmen der Weiterentwicklung der API weiter verbessern.

So bekämpfen Sie Spam und Betrug

Private State Token API (und andere APIs)

Feedback	Zusammenfassung	Chrome-Antwort
Dokumentation	Fordern Sie einen detaillierten Entwicklerleitfaden zu Private State Tokens an, der Ihnen beim Testen hilft.	Im 4. Quartal 2023 haben wir einen Entwicklerleitfaden für Private State Tokens veröffentlicht.
Alters-/Geschlechtsüberprüfung	Schwierige Überprüfung nach Alter und Geschlecht der Zielgruppen nach 3PCD.	Private State Tokens sind derzeit nicht für die Überprüfung von Alter und Geschlecht vorgesehen. Wir möchten den Anwendungsfall und die Umsetzung noch besser verstehen und würden uns über zusätzliches Feedback freuen.