Feedbackbericht – Q3 2023

Vierteljährlicher Bericht für das 3. Quartal 2023, in dem das Feedback aus der Plattform zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome zusammengefasst wird.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google sich bereit erklärt, vierteljährlich Berichte über den Prozess der Einbeziehung der Stakeholder im Rahmen seiner Privacy Sandbox-Vorschläge zu veröffentlichen (siehe Abschnitte 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch eine Zusammenfassung des Feedbacks von Chrome aus den verschiedenen Quellen generiert, die in der Feedbackübersicht aufgeführt sind. Dazu gehören unter anderem: GitHub Issues, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Community und sucht aktiv nach Möglichkeiten, die gewonnenen Erkenntnisse in Designentscheidungen einfließen zu lassen.

Feedbackthemen sind nach Verbreitung pro API geordnet. Dazu wird eine Zusammenfassung des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, in absteigender Reihenfolge sortiert. Die gemeinsamen Feedbackthemen wurden ermittelt, indem Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen, die über interne Teams und öffentliche Formulare von Google gestellt wurden, überprüft wurden.

Genauer gesagt wurden die Gesprächsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, E-Mails, die von einzelnen Entwicklern eingegangen sind, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Anschließend koordinierte Google die Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, um die relative Verbreitung der Themen zu ermitteln, die in Bezug auf die einzelnen APIs entstehen.

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

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

Glossar der Akronyme

CHIPS

Cookies mit unabhängig partitioniertem Status

DSP

Demand-Side-Plattform

FedCM

Federated Credential Management

fps

First-Party-Sets

IAB

Interactive Advertising Bureau

IdP

Identitätsanbieter

IETF

Internet Engineering Task Force

IP-Adresse

Internet Protocol-Adresse

openRTB

Echtzeitgebote

ÜS

Ursprungstest

PatCG

Private Advertising Technology Community Group

RP

Verlassende Partei

SSP

Supply-Side-Plattform

TEE

Vertrauenswürdige Ausführungsumgebung

UA

User-Agent-String

UA-CH

User-Agent-Client-Hints

W3C

World Wide Web Consortium

WIPB

Vorsätzliche IP-Blindheit

Allgemeines Feedback, keine bestimmte API oder Technologie

Feedback-Design	Zusammenfassung	Chrome-Antwort
Systembereitschaft	SSPs äußerten Bedenken, dass Publisher nicht bereit sind und die erforderliche Bereitstellungsarbeit nicht übernehmen.	Die Privacy Sandbox konzentriert sich speziell auf die Aufklärung von Publishern. Dazu gehören spezielle Webinare und Meetings mit Publishern und SSPs, die die Bereitstellungsarbeit vorantreiben.
Einstellung von Drittanbieter-Cookies	Bedenken hinsichtlich der Einstellung von Drittanbieter-Cookies (3PCD) im 4. Quartal 2023 aufgrund von technischen Ausfällen in der Branche.	Der Zeitplan für die Privacy Sandbox wurde mit der CMA besprochen. Die Sequenzierung führt zu einer zweiten Hälfte des Jahres 2024. Privacy Sandbox wird detailliertere Informationen zur Sequenzierung der 3PCD-Leistung veröffentlichen. Im Rahmen der Vereinbarungen unterliegt 3PCD den Wettbewerbsbedenken der CMA.
Google Ad Manager	Google Ad Manager weigert sich, die API-Oberfläche verfügbar zu machen, was die Tests schwierig macht.	Antwort von Google Ad Manager:Aus den in dieser Antwort von Google Ad Manager erläuterten Gründen ist es bei den Plänen für die Einbindung der Protected Audience API in Google Ad Manager nicht der Fall, den Ad-Server von Google für Publisher ohne Kontrolle über die Auktion der obersten Ebene zu unterstützen.
Google Ad Manager	In Google Ad Manager ist ein geheimer Mindestpreis festgelegt, der nur für AdX- oder Open Bidding-SSPs sichtbar ist.	Aus der öffentlichen Dokumentation von Google Ad Manager geht hervor, dass der Gewinner der kontextbezogenen Auktion an die Gesamtbewertungslogik und nicht an die Komponentenauktionen übergeben wird, einschließlich AdX oder Open Bidding. Darüber hinaus steht in der Dokumentation zur obersten Bewertungslogik: "Ad Manager vergleicht das erfolgreiche Gebot jeder Komponentenauktion, einschließlich der Auktion der eigenen Ad Manager-Komponenten für Interessengruppengebote der Käufer, und der besten kontextbezogenen Anzeige, die über die dynamische Zuordnung ausgewählt wird, und liefert die Anzeige mit dem höchsten Gebot aus."
Google Ad Manager	Für Google Ads-Produkte gelten dieselben Regeln wie für Anzeigenprodukte von Drittanbietern.	Für Google Ads-Produkte gelten bereits dieselben Regeln wie für Drittanbieter.
Von Chrome unterstützte Tests	Fügen Sie Labels für Browser hinzu, die nicht in A oder B enthalten sind.	Wir erwägen derzeit nicht, dies zu tun, da unsere Untersuchungen ergeben haben, dass das Hinzufügen von Labels, die keine Tests sind, die Datenschutzbedenken in Bezug auf Traffic im Inkognitomodus erschweren kann.
Werbeagentur	Können Agenturen oder Unternehmen ohne JavaScript auf Websites Privacy Sandbox APIs verwenden?	Die Privacy Sandbox APIs können von allen aufgerufen werden. Wenn eine Agentur oder eine andere Person Technologien direkt auf den APIs erstellen möchte, die sie kann. Clientseitige APIs müssen genauso wie Cookies in den Client integriert werden. Viele APIs, wie Cookies, haben auch eine HTTP-Header-Schnittstelle. Mit Prebid können wir schon einmal clientseitige Integrationen in die APIs erstellen. Andere Unternehmen könnten das genauso machen.
Clientseitige Lösungen	Warum verwendet Google clientseitige Lösungen für die Privacy Sandbox, wenn ein Entwickler im Jahr 2012 zuvor Bedenken bezüglich der Skalierbarkeit solcher Lösungen geäußert hat?	Das Studienfach „Datenschutz verbessernde Technologie“ (PET) hat sich seit 2012 erheblich weiterentwickelt und damit auch kommerzielle Anwendungen. Den Kern der Privacy Sandbox bilden Kombinationen von PETs, die vor über einem Jahrzehnt nicht realisierbar waren. Darüber hinaus hat die persönliche Rechenleistung zugenommen, ebenso wie die Nutzererwartungen an Browser und die gesetzlichen Anforderungen an den Datenschutz.
Machine Learning	Wie wird die Privacy Sandbox von Google für maschinelles Lernen eingesetzt?	Maschinelles Lernen wird heutzutage größtenteils im Bereich der Anzeigentechnologie eingesetzt. Daran dürfte sich nichts ändern. Die Privacy Sandbox hindert Anzeigentechnologie-Unternehmen oder andere nicht daran, weiterhin maschinelles Lernen zu nutzen. Auch für die Privacy Sandbox müssen Unternehmen, die ihre APIs einbinden, maschinelles Lernen verwenden. Es ist zu erwarten, dass Unternehmen ihre Produkte und Dienste weiterhin so entwickeln, dass sie den Anforderungen ihrer Kunden entsprechen, unabhängig davon, ob dies maschinelles Lernen einschließt oder nicht. Alle maschinellen Lernalgorithmen, die Privacy Sandbox-Integratoren erstellen, sind ihnen selbstverständlich bekannt und werden ihnen somit nicht verborgen.
Datenüberprüfung	Wie können Unternehmen überprüfen, ob die Daten, die sie durch die Privacy Sandbox erhalten, korrekt sind und ist Google bereit, von einem Rechtssubjekt wie dem Media Ratings Council (MRC) überprüft zu werden?	Die Privacy Sandbox APIs basieren auf der Open-Source-Plattform von Chrome. Die Teile der APIs, die in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden sollen, sind ebenfalls Open-Source- und überprüfbar. Jeder, der den Code untersuchen möchte, auch MRC.
(Auch in vorherigen Quartalen gemeldet) Produktionssupport	Wie unterstützt Chrome die Privacy Sandbox bei technischen Problemen und Eskalierungen, die sich auf das System auswirken?	Google bietet verschiedene Kanäle, über die Anzeigentechnologie-Mitarbeiter technische Probleme melden und die zur Lösung dieser Probleme erforderlichen Eskalationen ermöglichen können. Darüber hinaus geht Chrome davon aus, einen Prozess zur Behebung technischer Probleme und Eskalierungen, die sich auf den Zustand des Systems auswirken, weiter zu entwickeln und zu skalieren. Chrome setzt sich dafür ein, Ressourcen für diese Bemühungen bereitzustellen. In unserem Entwicklerbeitrag findest du weitere Informationen zu den öffentlichen und privaten Foren für Feedback und Eskalationen.
Von Chrome unterstützte Testmodi	Weitere Informationen zu den zeitlichen Beschränkungen und genauen Implementierungen für die von Chrome unterstützten Testmodi.	Wir haben einen Blogpost zu Testmodi geteilt und arbeiten daran, bald weitere Informationen zu veröffentlichen. Wir sind Glückwunsch von Vorschlägen für die Größe der Testmoduslabels.
Integration in andere Branchenstandards	Werden die Privacy Sandbox APIs mit TCF 2.* und dem Einwilligungsmodus verbunden oder mit beiden?	Es ist nicht geplant, die Privacy Sandbox APIs direkt in Version 2 des TCF oder den Einwilligungsmodus zu integrieren. Unternehmen und Branchenverbände können jedoch ihre Produkte und Frameworks so anpassen, dass sie in Verbindung mit Privacy Sandbox APIs funktionieren. Bei Frameworks wie dem TCF muss jeder Teilnehmer beispielsweise seinen eigenen Complianceansatz auf Grundlage des empfangenen TCF-Signals und der zugehörigen TCF-Richtlinien festlegen. Wir erwarten, dass Unternehmen selbst entscheiden, wann und wie sie die verschiedenen Funktionen unserer Privacy Sandbox-Bausteine nutzen.

Registrierung und Bestätigung

Feedback-Design	Zusammenfassung	Chrome-Antwort
Einschränkung	Bei der Registrierung kann Google entscheiden, welches Unternehmen im System die Privacy Sandbox APIs verwenden darf.	Der Registrierungs- und Bestätigungsprozess umfasst im Wesentlichen die Verifizierung der Entität (z. B. wenn die Entität eine DUN-Nummer hat, einen Link zu einer Datenschutzerklärung angeben kann usw.) und macht die öffentliche Bestätigung zu einer Voraussetzung für den Aufruf der APIs. Entitäten, die die Registrierungsanforderungen erfolgreich erfüllen können, werden validiert. Unternehmen, die keine DUNs haben, bieten von Dun & Bradstreet einen beschleunigten, kostenlosen Prozess zum Erwerb eines DUN an. Ziel ist es, den Datenschutz der APIs durch die gerade genannten Maßnahmen zu verbessern und die Privacy Sandbox APIs für mehr Transparenz zu sorgen, damit interessierte Parteien besser nachvollziehen können, wer welche API verwendet und welche Attestierungen sie erstellen. Wir sind offen für weiteres Feedback aus der Branche zu diesem Thema, das bereits zur Gestaltung des Prozesses genutzt wurde.
Aufwand für erneute Registrierung	Die Bestätigungsdatei läuft alle zwölf Monate ab und Websites müssen sich neu registrieren.	Wir haben Feedback aus dem System erhalten und unseren Ansatz entsprechend angepasst. Das bedeutet, dass Dateien nicht mehr nach 12 Monaten oder nach einem festgelegten Zeitraum ablaufen. Wir aktualisieren unseren Entwicklerleitfaden zur Registrierung mit zusätzlichem Kontext.
Bestätigungsdatei	Wie wird die Bestätigungsdatei verwendet?	Alle Unternehmen, die APIs für Relevanz und Messung aufrufen, müssen bis zur Erzwingungsfrist die Attestierungsdatei auf ihre Website hochladen und für die Öffentlichkeit aufbewahren, solange sie die APIs weiterhin aufrufen möchten. Für Websites ist mit etwa einer Anfrage pro Stunde über die Privacy Sandbox zu rechnen. Andere potenzielle Entitäten können ebenfalls Anfragen stellen. Dies erfolgt über den eigenen Mechanismus des Registrierungssystems, um die Server registrierter Entitäten abzufragen und sicherzustellen, dass die Attestierungsdatei gültig ist. Bestätigungen werden in Transparenzberichte aufgenommen und sind für die Allgemeinheit sichtbar. Wir erwarten von Unternehmen, dass sie ihre eigenen Bescheinigungen einhalten, ebenso wie das übrige System und die relevanten Aufsichtsbehörden.
Registrierung	Erfolgt die Registrierung pro Website oder pro Ursprung?	Die Registrierung erfolgt auf Website-Ebene.

Relevante Inhalte und Werbung zeigen

Themen

Feedback-Design	Zusammenfassung	Chrome-Antwort
Leistung	Leistungsprobleme bei den Auswirkungen der Opt-in-Rate für die Topics API im Europäischen Wirtschaftsraum.	Wir empfehlen den betroffenen Beteiligten, sich bezüglich des Problems an die zuständige Datenschutzaufsichtsbehörde zu wenden. Sie sind am besten geeignet, um auf solche Bedenken einzugehen und zu beeinflussen, ob die Anwendung datenschutzfreundlicher Technologien durch Gesetze gefördert oder stattdessen wie Tracking behandelt werden, wobei die gleichen Ansätze für die Einwilligung erforderlich sind. Dies kann dazu führen, dass APIs wie die in der Privacy Sandbox nicht so häufig verfügbar sind.
Registrierung	Müssen sich nachgelagerte Bieter für die Topics API registrieren, um Topics-Signale von vorgelagerten SSPs zu verwenden?	Die nachgelagerten Empfänger von Themen, die über den ursprünglichen Aufrufer der Topics API hinausgehen, müssen nicht registriert werden. Es ist jedoch wahrscheinlich, dass sie für eine andere API-Nutzung registriert werden. Im Rahmen der Transparenzbemühungen des Programms wird programmatisch eine Liste der Privacy Sandbox-Anfragen bereitgestellt. So können interessierte Nutzer der Topics API bei Bedarf prüfen, ob der Empfänger, an den sie ein Thema senden, registriert ist.
Nach Themen filtern	Anfrage zum Anwenden der Filter eines anderen Aufrufers auf die Themen, die er auf der Seite abgerufen hat, um nur freizugeben, was Käufer abrufen können	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Community.
Ausschließen von Websites	Websites ausschließen, damit sie nicht zu den Topics eines Nutzers beitragen können.	Themen werden nicht standardmäßig aufgerufen. Dabei ist zu beachten, dass bei der Auswahl von Themen keine Seiteninhalte berücksichtigt werden und dass alle Themen so ausgewählt werden, dass sie nicht vertraulich sind. Eine Website kann auch über den folgenden Header für die Berechtigungsrichtlinie verhindern, dass ihre Website in die Berechnung des Themas einbezogen wird: Permissions-Policy: browsing-topics=()
Themenbeobachtung	Hiermit können Verlage und Webpublisher Chrome erlauben, Themen anhand des Seiteninhalts zu klassifizieren, z. B. „head“ oder „body“.	Früher hatten wir in Betracht gezogen, Websites anhand des Seiteninhalts nach Themen zu klassifizieren, und uns aufgrund von Datenschutz- und Sicherheitsbedenken dazu entschieden, die Website nicht weiterzuentwickeln. Dieser Vorschlag kann einige dieser Bedenken ausräumen, es ist jedoch unklar, in welchem Umfang. Aufgrund der bevorstehenden CMA-Testphase gehen wir davon aus, dass diese Änderung nicht vor der 3PCD erfolgt. Hier können wir gerne zusätzliches Feedback geben.
Themenbeobachtung	Hier können Sie detailliertere Berechtigungsrichtlinien für Publisher angeben.	Durch die Bereitstellung detaillierterer Berechtigungsrichtlinien für Publisher können Publisher-Websites den Nutzen der Topics API für das gesamte System negativ beeinflussen, ohne die Nützlichkeit der Topics API für die Website selbst zu beeinträchtigen. Ausführlichere Informationen zu diesem Thema finden Sie in der Richtlinie zu Updateberechtigungen zur Unterstützung separater Berechtigungen für das Abrufen und Beobachten des GitHub-Problems.
Medizinische und gesundheitsbezogene Themen	Warum deckt die Themen-Taxonomie keine Themen der Kategorien „Medizin“ und „Gesundheit“ ab?	Die Kategorien „Medizin“ und „Gesundheit“ gelten als sensibel und daher von der Taxonomie der Themen ausgeschlossen.
Themenabruf	Schnellere Methode für DSPs, um Topics ohne Header abzurufen.	Die Header-Methoden sind leistungsfähiger und kostengünstiger als das Erstellen eines ursprungsübergreifenden iFrames und ein document.browsingTopics()-Aufruf von dort. Für den Aufruf muss ein ursprungsübergreifender iFrame verwendet werden, da der Kontext der obersten Ebene zur Beobachtung eines Themas mit dem Kontext übereinstimmen muss, über den auf die Themen zugegriffen wird. Dies wurde hier ausführlich erläutert.
Themenabruf	Anfragen zur Unterstützung der Übergabe von Topics über Header bei Anfragen mit ursprungsübergreifenden Script-Tags.	Aus Sicherheitsgründen ist dies nicht möglich. Jedes Dokument und seine Ausführungsumgebung sind einem einzigen Ursprung zugeordnet, dem des Dokuments. Bei Unterressourcen von Drittanbietern, die in derselben Umgebung geladen und ausgeführt werden, wird davon ausgegangen, dass sie dem Ursprung des Dokuments gehören. So soll verhindert werden, dass Daten, die nicht eingewilligt haben, von einem Ursprung an einen anderen weitergegeben werden. Alternativ können Sie ein browsingTopics-Attribut für <script>-Tags angeben. Dies sollte aus Sicherheitsperspektive sauber sein und keine zusätzliche Latenz verursachen. Wir freuen uns immer über Feedback von Interessierten.
Bekanntheit	Steigern Sie das öffentliche Bewusstsein für die Topics API und deren Verwendung.	Wir haben uns mit dem Stakeholder zusammengetan, der dieses Feedback gegeben hat. Das Problem wurde auf GitHub gelöst. Wir werden auch in Zukunft das Verständnis der API im Ökosystems unterstützen und freuen uns auf die Meinungen anderer Stakeholder. Bis dahin empfehlen wir allen Interessenten, die mehr über die Topics API erfahren möchten, sich mit der Dokumentation im Chrome-Entwicklerhandbuch vertraut zu machen.
Meldung	Benachrichtigung zum Benachrichtigen des Nutzers, wenn seine Topics von einer Website beobachtet werden	Wir haben dieses Feedback auf GitHub umgesetzt. Weitere Informationen zu den Steuerelementen für Themen finden Nutzer in der Chrome-Hilfe.
Machine Learning	Wie kann ML verwendet werden, um Themen von Nutzern abzuleiten?	Wir besprechen dieses Problem und freuen uns auf zusätzliches Feedback.
Nützlichkeit für verschiedene Arten von Stakeholdern	Kleinere AdTech-Unternehmen können die Topics API möglicherweise nicht beobachten, weil sie von Browsern berechnet werden.	Das Thema wird nur für Anzeigentechnologie-Anbieter vergeben, die beobachtet haben, dass der Nutzer in den letzten drei Wochen eine Seite zu dem betreffenden Thema besucht hat. Wenn der Anzeigentechnologie-Nutzer die API in den letzten drei Wochen für diesen Nutzer auf einer Website zu diesem Thema nicht aufgerufen hat, ist der zurückgegebene Wert leer. Diese Funktion bedeutet, dass Anzeigentechnologien, deren Dienste von einer größeren Anzahl von Websiteinhabern verwendet werden und daher mehr Möglichkeiten haben, einen Websitebesuch eines bestimmten Nutzers zu beobachten, mehr Themen erhalten als andere Anzeigentechnologien. Diese Funktion ist für den Datenschutz der API unerlässlich, da sie die Verfügbarkeit von Informationen zu einem Nutzer auf die Parteien beschränkt, die dieselben zugrunde liegenden Informationen bereits einsehen können (derzeit über Drittanbieter-Cookies).
XHR-Anfrage	Wann wird die Aufnahme von Topics in XMLHttpRequest-Anfragen (XHR) eingestellt?	Wie von Chrome im August 2023 angekündigt, begann Chrome damit, die Unterstützung für XHR bei der Umstellung vom Ursprungstest auf die allgemeine Verfügbarkeit einzustellen. Wenn Sie die Topics API mit XHR verwendet haben, funktionieren Ihre Websites weiterhin. Die Themen werden lediglich nicht zu den XHR-Anfrageheadern hinzugefügt. Wir empfehlen, für Ihre Anfrage entweder zu fetch zu wechseln, das iFrame-Attribut zu verwenden oder die JavaScript API zum Abrufen von Themen zu verwenden. Fetch wird von allen modernen Browsern unterstützt, jedoch nicht von Internet Explorer oder Opera Mini.
Aktualisierungsprozess für Taxonomie und Klassifikator	Weitere Informationen zum Veröffentlichungsrhythmus der Topics-Taxonomie und zum Klassifikator und dazu, wie sich Unternehmen auf solche Aktualisierungen vorbereiten können	Unsere Antwort im Vergleich zum 2. Quartal bleibt unverändert: Wie im aktuellen Blogpost erwähnt, erwarten wir, dass sich die Taxonomie im Laufe der Zeit weiterentwickelt und dass die Governance der Taxonomie irgendwann an eine externe Partei übergehen wird, die Stakeholder aus der Branche vertritt. Den Anstiegsplan haben wir auch in der topics-announce Gruppe veröffentlicht.
Missbrauch	Möglicher Angriff über die Weiterleitungskette.	Wir prüfen das Problem und freuen uns über zusätzliches Feedback.
Inventartypen des Publishers	Welche Arten von Publisher-Inventar werden von Protected Audience- und Topics-Tests unterstützt?	Weder Protected Audience noch Topics sind im Hinblick auf die Inventartypen, für die sie verwendet werden können, grundsätzlich einschränkend.
Anlaufzeit	Es wird keine Anlaufzeit für neue Taxonomien empfohlen, um 100 % zu erreichen.	Nach dieser Feedbackanfrage aus der Community und der Diskussion während der PATCG-Meetings haben wir unseren Plan für die Einführung der neuen Taxonomie bekannt gegeben.

Protected Audience API (früher FLEDGE)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Top-Level-Auktionen	Der Publisher-Ad-Server von Google kann verwendet werden, ohne Google Ad Manager die Kontrolle über die Protected Audience API-Auktion auf oberster Ebene zu übertragen.	Antwort von Google Ad Manager: Die Pläne von Google Ad Manager für die Protected Audience API sehen aus folgenden Gründen keine Unterstützung des Google-Ad-Servers für Publisher ohne Kontrolle über die Protected Audience-Auktion auf oberster Ebene vor. Damit unsere Kunden auf dem Ad-Serving-Markt für Publisher richtig bedient werden können, muss der Ad-Server von Google für Publisher die Kontrolle über die Protected Audience-Auktion auf oberster Ebene behalten. Als Ad-Server für Publisher ist es unsere Aufgabe, Publishern Prognosen bereitzustellen, damit sie direkt verkaufte Kampagnen ohne Überbuchung aushandeln und ihre direkten Reservierungen optimal takten und bereitstellen können. 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 kann es passieren, dass Publisher ihr Inventar überverkaufen und so den Ruf ihres Unternehmens gefährden. Die Taktung ist ebenfalls von entscheidender Bedeutung, da die Nichterfüllung von Reservierungsverträgen mit Werbetreibenden auch die direkte Beziehung zwischen Publisher und Werbetreibenden gefährdet, was erhebliche Auswirkungen auf das Geschäft des Publishers haben kann. Kurz gesagt: Die Aktivität eines Publisher-Ad-Servers bezüglich der Durchführung der Protected Audience-Auktion auf oberster Ebene unterscheidet sich nicht von den anderen Aktivitäten des Ad-Servers des Publishers.
directFrom SellerSignals	directFrom SellerSignals wird in Google Ad Manager verhindert, dass der Publisher den Preis seiner kontextbezogenen Auktion sieht.	Chrome-Antwort: An runAdAuction() übergebene Informationen stammen nur dann vom Verkäufer, wenn der Verkäufer runAdAuction() über seinen eigenen iFrame aufruft. In 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 vom Ursprung eines Verkäufers geladen wurde. Dadurch wird sichergestellt, dass die Authentizität und Integrität der Informationen, die aus den Konfigurationen der Verkäuferauktionen an eine Auktion übergeben werden, nicht manipuliert werden können. Wenn Publisher die Protected Audience API verwenden möchten, um die Informationen zu ermitteln, die ihre Technologieanbieter an Protected Audience-Auktionen übergeben, 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 haben wir uns versprochen, dass keine Preise aus nicht garantierten Anzeigenquellen eines Publishers, einschließlich nicht garantierter Werbebuchungen, mit einem anderen Käufer geteilt werden, bevor dieser bei der Auktion ein Gebot abgibt. Dies haben wir später im Rahmen unserer Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bestätigt. Wir beabsichtigen, bei Protected Audience-Auktionen unser Versprechen zu halten, indem wir directFromSellerSignals nutzen und das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion mit mehreren Verkäufern nicht an andere Auktionsteilnehmer weitergeben. Zur Klarstellung: Auch der Preis der kontextbezogenen Auktion wird nicht mit der Auktion für eigene Komponenten geteilt, wie in der Aktualisierung Weitere Informationen zur Auktionsdynamik auf oberster Ebene erläutert.
Veröffentlichung von Informationen	Vertrauliche Geschäftslogik und Vertragsdetails können vom Browser offengelegt werden.	Die Person, die einen Webbrowser verwendet, kann alles sehen, was darin passiert. Wenn eine Anzeigenauktion im Browser stattfindet, ist es wahr, dass der Nutzer, dessen Browser der Browser ist, die Auktion beobachten kann und dabei auch sehen kann, wie viele verschiedene Parteien Gebote abgeben. Da ein Browser der User-Agent ist, halten wir es nicht für möglich oder wünschenswert, dies zu ändern. Diese Vorgänge sind jedoch nur für die Person sichtbar, die den Browser verwendet. Eine On-Device-Auktion, die mit der Protected Audience API ausgeführt wird, kann auf keinen Servern, auch nicht auf denen von Google, beobachtet werden.
PerBuyerExperiment GroupId	Mit dem aktuellen Wertebereich von PerBuyerExperiment GroupId können Käufer die Kontextdaten mit der vertrauenswürdigen Serveranfrage in Beziehung setzen.	Die Verwendung der Protected Audience API auf diese Weise entspricht nicht der obligatorischen Bestätigung der Privacy Sandbox, dass API-Nutzer nicht versuchen werden, die Privacy Sandbox-Schutzmaßnahmen zu umgehen. Die Anforderung, dass Schlüssel/Wert-Paar-Server in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden, bietet in Zukunft technischen Schutz vor diesem Angriff.
Richtlinie für denselben Ursprung	Lockern Sie die Richtlinie für denselben Ursprung, um Subdomains zuzulassen.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Plattform.
API-Versionsverwaltung	Anfrage zur Versionsverwaltung und Versionshinweise für Änderungen an der Protected Audience API.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Plattform.
Auktionen mit mehreren SSPs	Zulassen, dass Auktionssignale der obersten Ebene JSON-Zusammenführungen mit dem Komponentensignal auctionSignals ausführen.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Plattform.
Gebotslimit	Erhöhen Sie das Limit für die Anzahl der Anzeigenkomponenten, die in das Gebot aufgenommen werden, von 20 auf 40.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback dazu, warum dies hilfreich wäre.
(Auch in vorherigen Quartalen erfasst) Leistung von Protected Audience-Auktionen	Bericht von Testern, dass Protected Audience-Auktionen eine hohe Latenz haben.	Was die Latenz angeht, folgt die Protected Audience API im Allgemeinen dem bestehenden Standardparadigma. Sie erstellen Kontrollen, mit denen Verkäufer entscheiden können, wie viel Zeit und Ressourcen die Bieter benötigen, und sie entwickelt Tools, mit denen Käufer entscheiden können, wie sie die ihnen zur Verfügung stehenden Ressourcen am besten nutzen. Diese Kontrollen und Tools sind heute allgemein verfügbar, ihr volles Potenzial wird jedoch erst nach der Einführung durch Käufer und Verkäufer realisiert. Darüber hinaus arbeitet Chrome kontinuierlich an einer Reihe von Infrastrukturverbesserungen für die Auktionsgeschwindigkeit (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Wir bitten um Feedback zu beiden Hälften dieser Latenzbemühungen: neue Tools, die für Käufer und Verkäufer nützlich sein könnten, und Berichte über beobachtete Engpässe, die Chrome-Entwickler untersuchen sollten.
Filtern auf Käuferseite	Unterstützung für das Filtern auf Käuferseite basierend auf Interessengruppen hinzufügen.	Wir haben mehrere Möglichkeiten vorgeschlagen, wie SSPs und DSPs ihr Design entsprechend ändern können: Es wird ein Teil der Arbeit in den Schlüssel/Wert-Server der DSP verschoben. SSPs erstellen einige Kontextsignale und geben diese an DSPs weiter. SSPs, die Kontextsignale für DSPs im Cache speichern
Steuerung für Publisher-Interessengruppen	Unterstützung für Publisher, die die Verwendung von vom Publisher erstellten Interessengruppen delegieren möchten.	Wir haben mit vielen Parteien über dieses Ersuchen diskutiert. Wir sind der Meinung, dass alle Anwendungsfälle, die mit der "Delegation" der vom Publisher erstellten Interessengruppen verbunden sind, jetzt berücksichtigt werden können. Außerdem sollten wir zusätzlichen Support bereitstellen, damit einige Anwendungsfälle in Zukunft reibungsloser funktionieren.
(Auch in Q2 gemeldet) Vertrauenswürdige Ausführungsumgebungen	Unterstützung für vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) in nicht öffentlichen Cloudumgebungen.	Unsere Antwort ist ähnlich wie in früheren Quartalen: Wir arbeiten zwar kontinuierlich an der Unterstützung von Optionen, die über öffentliche cloudbasierte Lösungen hinausgehen, aber derzeit haben wir keine Pläne zur Unterstützung lokaler TEEs. Zu diesem Zeitpunkt sind wir angesichts der Sicherheitsanforderungen der Privacy Sandbox und der erheblichen Herausforderungen, die lokale Bereitstellungen mit sich bringen, 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 vorteilhaftsten ist. Wir freuen uns jedoch über zusätzliches Feedback dazu, warum eine solche Anforderung angesichts der Datenschutz- und Sicherheitseinschränkungen notwendig und durchführbar ist.
eine vertrauenswürdige Ausführungsumgebung	Komponenten im TEE-Bereitstellungspfad wie der Load-Balancer können den gesamten Traffic beobachten und Informationen zur IP-Adresse jeder Anfrage haben.	Derzeit wird die IP-Adresse bei Bidding und Auktionen sowie bei Protected Audience-Auktionen auf dem Gerät als Metadaten in Anfrageheadern an den Anzeigendienst des vertrauenswürdigen Verkäufers übergeben. Weitere Informationen finden Sie unter Metadatenweiterleitung. Langfristig planen wir, den Traffic von Anzeigentechnologien und Trackern über einen IP-Proxy weiterzuleiten, wodurch Komponenten daran gehindert werden, den gesamten Traffic im Bereitstellungspfad zu beobachten.
Gültigkeitsdauer (TTL)	Wird die Gültigkeitsdauer (TTL) festgelegt, bevor Dienste neue Schlüssel anfordern müssen, oder soll sie flexibel (oder dynamisch) sein?	Die TTL ist in der Regel statisch. Derzeit beträgt die öffentliche TTL 8 Tage und die Rotation erfolgt alle 7 Tage. Im Fall des Aggregationsdiensts ist sie auch für private Schlüssel gleich. Bei Bidding- und Auktionsdiensten werden private und öffentliche Schlüssel alle n Stunden über den Nicht-Anfragepfad abgerufen und im Arbeitsspeicher gespeichert, sodass nicht mehr als n Stunden zwischen den rotierenden Schlüsseln und den Servern, die diese Schlüssel erfassen, eine Verzögerung von mehr als n Stunden auftritt. Durch den 1-tägigen Puffer zwischen Schlüsselrotation und Ablauf wird sichergestellt, dass die Dienste auch dann weiter ausgeführt werden können, wenn die Schlüsselgenerierung fehlschlägt. Wir erwägen eine Verlängerung der TTL, um Ausfälle besser zu schützen. Im Falle eines Schlüssellecks planen wir, die Schlüsselgenerierung manuell zu erzwingen und Schlüssel früher zu entwerten. Beachten Sie, dass öffentliche Schlüssel auf den Clients derzeit für 24 Stunden im Cache gespeichert werden, um sicherzustellen, dass die Dienste bei einem Koordinatorausfall weiterhin funktionieren können.
Anpassung an Traffic	Traffic Shaping für Bidding und Auktionsdienste	Käufer können basierend auf selbst erhobenen Daten des Publishers oder Kontextdaten die Nachfrage nach Protected Audience-Auktionen angeben. Verkäufer können ähnliche Einstellungen auch auf dem Ad-Server oder Ad-Server-Server des Verkäufers vornehmen. Die Modelle können mit selbst erhobenen Daten und aggregierten Berichten aus Protected Audience-Auktionen trainiert werden. Anhand dieser Informationen können Verkäufer verhindern, dass Anfragen an Gebots- und Auktionsserver gesendet werden, wenn keine Nachfrage nach Protected Audience-Auktionen besteht. Wir sind der Meinung, dass dies eine effektive Möglichkeit sein kann, den Traffic zu beeinflussen.
Komponentenauktion	Welche Auktionssignale auf oberster Ebene werden an Komponentenverkäufer weitergegeben?	Käufer in einer Komponentenauktion erhalten nur Signale vom Komponentenanbieter. In Kürze werden wir noch weitere Informationen zum Gesamtablauf von kombinierten Auktionen mit Header Bidding und Protected Audience-Auktionen zur Verfügung stellen.
Video-Rendering	Unterstützung für das Video-Rendering mit Protected Audience und Fenced Frames	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 Durchsetzung von Fenced Frames auf 2026 zurückzustellen. Das bedeutet, wenn ein Partner jetzt Fenced Frames durchsetzen würde, würde die Unterstützung für Videos für diesen Partner fehlen.
Frequency Capping	(Auch in vorherigen Quartalen verfügbar) Häufigkeitseinstellungen pro Nutzer innerhalb einer Kampagne und Anzeigengruppe.	Unsere Antwort hat sich im Vergleich zu den vorherigen Berichten nicht geändert: Protected Audience unterstützt auch Frequency Capping für On-Device-Auktionen sowie Kontext- und Branding-Kampagnen. Freigegebener Speicher und websitespezifische Obergrenzen können auch für zusätzliche Steuerungsmöglichkeiten für das Frequency Capping verwendet werden.
Anzeigenvorgaben	Bietet Protected Audience eine Möglichkeit, Werbetreibendenwebsites die Sperrliste zu deaktivieren oder sie auf eine Sperrliste zu setzen oder alle Interessengruppen vom selben Inhaber zu belassen?	Nutzer haben mehrere Möglichkeiten, den Zugriff auf die Protected Audience API und andere Privacy Sandbox-Funktionen zu blockieren.
Richtlinie für denselben Ursprung für Quell-URL von Gebots- und Auktionsskripts	Lockern Sie die Anforderung, dass alle Felder, die URLs zum Laden von Skripts oder JSON angeben, den gleichen Ursprung haben müssen wie der Inhaber.	Wir prüfen diese Anfrage derzeit und freuen uns auf zusätzliches Feedback von uns.
forDebuggingOnly	Es besteht die Möglichkeit, dass forDebuggingOnly .reportAdAuctionWin missbraucht wird, wenn es nach 3PCD verbleibt.	In den letzten Jahren haben wir von unserem System Feedback zu Funktionslücken in Protected Audience erhalten, nachdem Drittanbieter-Cookies eingestellt wurden. Wir arbeiten an einem Plan, um diese nach der 3PCD zu unterstützen, ohne dabei die Ziele der Privacy Sandbox zu gefährden. Wir freuen uns über zusätzliche Vorschläge und Feedback zu fehlenden Funktionen, die das System sehen möchte.
Mehrere Interessengruppen	Mehrere Interessengruppen im selben Gebot verwenden	Dies wird derzeit in der Protected Audience API nicht unterstützt, da es zu einer Änderung des zugrunde liegenden Datenschutzmodells führen würde. Hier können wir gern weitere Diskussionen führen.
On-Device-Auktionen	Unterstützt Chrome unter Android Protected Audience-Auktionen auf dem Gerät?	Ja, On-Device-Auktionen werden in Chrome unter Android unterstützt.
(Bericht im 2. Quartal 2023) Klickbezogene Daten	Klickbezogene Daten zu browserSignals hinzufügen.	Wir werden diese Funktionsanfrage weiter prüfen und freuen uns über zusätzliches Feedback dazu, warum dies priorisiert werden sollte.
Vertrauenswürdige Ausführungsumgebungsanbieter	Gibt es wesentliche Unterschiede in den Angeboten der verschiedenen Cloud-Anbieter für vertrauenswürdige Ausführungsumgebung?	Uns sind keine wesentlichen Unterschiede bekannt. Wir empfehlen jedoch, die öffentlichen Bereitstellungsleitfäden zu lesen, um zu ermitteln, welche Lösung ihren Anforderungen am besten entspricht. Google Cloud AWS
(Erfasst in vorherigen Quartalen) Unterstützung für Ausrichtung auf auszuschließende Interessengruppen	Eine API zur Unterstützung der Ausrichtung auf auszuschließende Interessengruppen: Anzeigen werden nur ausgeliefert, wenn ein Nutzer nicht zu einer Interessengruppe gehört.	Wir sind dabei, diese Funktion zu implementieren, und diskutieren gerade diese Anfrage.
Verstoß gegen die Inhaltsrichtlinien	Funktionen unterstützen, mit denen Nutzer unzulässige Anzeigen melden können, die von der Protected Audience API in Fenced Frames ausgeliefert wurden.	Wir sind der Meinung, dass der bestehende Mechanismus zur Berichterstellung für Fenced Frame-Anzeigen gute Optionen für Anzeigentechnologie-Anbieter bietet, die von Nutzern einen Bericht über unerwünschte Anzeigen erstellen möchten. Dies würde die Berichterstellung für unzulässige Anzeigen in einer Weise zulassen, die im Vergleich zum heutigen Branchenstandard im Wesentlichen unverändert ist. Wir begrüßen zusätzliche Funktionsanfragen, wenn noch Lücken bestehen, z. B. in der Zeit nach der Entfernung von Drittanbieter-Cookies, aber bevor sich das Fenced Frame-Rendering weit verbreitet.
Berichterstellung über die Private Aggregation API	Wie können wir die Zeit berechnen, die ein Nutzer in dieser Interessengruppe verbracht hat?	In Chrome M116+ sollten Sie die Aktualität gemäß der Definition von pull/639 verwenden können.
Server für k-Anonymität	Weitere Informationen zum Server für k-Anonymität.	Weitere Informationen zu k-Anonymitätsservern finden Sie hier. Wir würden uns über zusätzliches Feedback freuen.
Dynamische Creative-URLs	Unterstützung für Creative-URLs ohne vorherige Deklaration bei gleichzeitiger Wahrung der k-Anonymität.	Wir besprechen diese Funktionsanfrage und freuen uns über zusätzliches Feedback dazu, warum dies priorisiert werden sollte.
k-Anonymität erforderlich	Wird die k-Anonymität bei Aktualisierungen von Interessengruppen wieder eingeführt?	Wir gehen nicht davon aus, dass sich die Position in diesem GitHub-Beitrag ändern wird. Wie in diesem Beitrag angekündigt, haben wir beschlossen, die k-Anonymitätsanforderung für die Aktualisierungen von Interessengruppen der Protected Audience API zu entfernen, die keine nennenswerten Auswirkungen auf den allgemeinen Datenschutz der API hat. Wir planen, zu einem späteren Zeitpunkt, an dem die entsprechenden Technologien weiter entwickelt, bereitgestellt und eingeführt werden, weitere mögliche direkte Schutzmaßnahmen in Betracht zu ziehen (z. B. Datenschutz für IP-Adressen oder einen vertrauenswürdigen Updateserver).
Betatest für Gebots- und Auktionsdienste	Wann beginnt der Betatest für Bidding und Auktionsdienste?	Wie im Zeitplan und Zeitplan angegeben, beginnt die erste Phase der Tests für Bidding und Auktionsdienste im November 2023.
Roadblocking	Anfrage zur Unterstützung der Creative-Koordination für Werbenetzwerke (SSP und DSP befinden sich im selben Unternehmen oder in denselben Properties)	Wir freuen uns über das Feedback zu diesem Anwendungsfall und möchten herausfinden, ob mehr Anzeigentechnologie-Anbieter an einer Unterstützung dieser Funktion interessiert sind. Wir freuen uns über zusätzliches Feedback.
Native Werbung	Fenced Frame-Unterstützung für native Werbung	Wir erwägen eine Unterstützung des Anwendungsfalls und erörtern mögliche Problemumgehungen und Lösungen.
k-Anonymität	Wie kann ich Anzeigen auf einer Interessengruppe maximieren, die die K-Anon-Grenzwerte erfüllen?	Wir haben einige taktische Richtlinien zu diesem Thema für Sie zusammengestellt.
POST-Unterstützung	Das Senden von Auktionsdaten über POST-Anfragen wird unterstützt.	Wir werten diese Funktionsanfrage derzeit aus und freuen uns über weitere Einreichungen von GitHub-Problemen darüber, warum dies priorisiert werden sollte.
Detaillierungsgrad der Berichte	Wie hoch ist der Detaillierungsgrad der Berichte für Fenced Frame-Anzeigen mit Anzeigen, die aus mehreren Teilen bestehen?	Das aktuelle Design lässt das Erfassen der Produkt-ID oder -Position nicht zu, da dies den Datenschutz für Nutzer gefährden könnte. Nur das reserved.top_navigation-Objekt kann aufgerufen werden. Es wird gesendet, wenn eine Nutzeraktivierung (z. B. ein Klick) auf den umzäunten Frame der Anzeigenkomponente erfolgt. Dies führt zu einer Navigation auf oberster Ebene.
Anzeigenauktion	Kann eine SSP, die an einer Komponentenauktion teilnimmt, selbst eine andere Komponentenauktion auslösen?	Ein componentSeller kann nicht auch componentAuctions enthalten. Mehrfachkundenauktionen haben nur zwei Ebenen: 1. Die Komponentenauktionen parallel. 2. Die Auktion der obersten Ebene, bei der die erfolgreiche Anzeige von jedem componentAuction teilnimmt.
Verfügbarkeit der Dienste für Gebote und Auktionen	Sind Gebote und Auktionen während der von Chrome unterstützten Testphase verfügbar?	Während der von Chrome unterstützten Testphase sind die Gebots- und Auktionsserver nicht verfügbar.
Gebotssignale	Zulassen, dass Browser Gebotssignale anfordern und löschen.	Wir besprechen diese Anfrage und freuen uns über zusätzliches Feedback dazu, warum dies priorisiert werden sollte.
generateBid()	userBiddingSignals von Interessengruppe kann bis updateURL aktualisiert werden.	Wir prüfen diesen Vorschlag und bitten um zusätzliches Feedback und Diskussionen.
Inventartypen des Publishers	Welche Arten von Publisher-Inventar werden von Protected Audience- und TOPICS-Tests unterstützt?	Weder Protected Audience noch Topics sind im Hinblick auf die Inventartypen, für die sie verwendet werden können, grundsätzlich einschränkend.
Server-zu-Server-Integration	Ist für Protected Audience eine direkte Integration zwischen SSP und DSP erforderlich?	Eine direkte Integration zwischen der SSP und der DSP ist nicht erforderlich, wenn die DSP keine Kontextsignale auf ihrem eigenen Server verarbeiten muss, um die verarbeiteten Informationen an ihre On-Device-Bidding-Funktion zu übergeben.
Ein bid_currency-Feld in B&A	Unterstützung für das Feld „bid_currency“ in Bidding und im Auktionsdienst.	bid_currency wird von B&A noch nicht unterstützt. Dies ist aber voraussichtlich bis Ende Januar 2024 möglich. Die Zeitachse finden Sie hier.
perBuyerSignals	Gibt es eine Größenbeschränkung für perBuyerSignals?	Für die Anzahl der Signale pro Käufer gibt es keine Begrenzung, aber das Senden zu vieler Daten kann sich nachteilig auf die Leistung des Browsers auswirken.
Websiteübergreifende Anwendungsfälle	Kann ich Protected Audience API-Interessengruppen auf mehreren Websites verwenden?	Protected Audience ist für solche Anwendungsfälle nicht vorgesehen, wie unter turtledove/issues/282 erläutert.
HTTP-Anfragen für Interessengruppen	Fügen Sie Interessengruppen-Blob in die HTTP-Header ein.	Wir sehen uns diese Anfrage an und freuen uns auf weiteres Feedback zu dieser Anfrage.
Qualitätskontrolle für Anzeigen	Verlust der Anzeigenqualitätskontrolle in Bezug auf websiteübergreifende Informationen	Wir sehen uns dieses Feedback an und freuen uns auf zusätzliches Feedback.
Chrome-Entwicklertools	Ausgehende Protected Audience-Netzwerkanfragen sollten auf dem Tab „Netzwerk“ der Chrome-Entwicklertools zu sehen sein.	Wir arbeiten daran, diese Funktion auf dem Tab „Network“ zu aktivieren, und freuen uns über zusätzliches Feedback dazu, warum dies priorisiert werden sollte.
eine vertrauenswürdige Ausführungsumgebung	Wann werden in der Erläuterung zum Monitoring der vertrauenswürdigen Ausführungsumgebung weitere Details dazu aufgeführt, welche Messwerte den Datenschutz beeinträchtigen (und in welchem Maße)?	Wir sind gerade dabei, die Erläuterung mit diesen Informationen zu aktualisieren. Die aktualisierte Erläuterung ist ab November 2023 verfügbar.
directFrom SellerSignals	Warum ist directFrom SellerSignals nicht als Web-Bundle verpackt?	Die Begründung für diese Entscheidung finden Sie hier.
Impressionsdelegierung	Gibt es eine praktikable Möglichkeit für die Delegierung von Impressionen, wenn das Ergebnis einer ausgewählten Interessengruppe eine weitere Targeting-Aktion ist?	Mehrere verschachtelte Auktionen sind aus zwei Gründen nicht mit unseren Datenschutzzielen kompatibel. Wenn der Gewinner einer Auktion in einem Fenced Frame gerendert wird, umfassen unsere Datenschutzziele für Protected Audience auch das resultierende Creative-Rendering ohne Kenntnis des Kontexts: Die URL der umgebenden Seite oder das eigene Cookie stellen eine Datenschutzverletzung dar. In dieser Umgebung ist eine verschachtelte Auktion nicht praktikabel. Zweitens besagt das Protected Audience-Modell, dass der Gewinner jeder Auktion auf Daten von nur einer zusätzlichen Website basieren soll. Verschachtelte Auktionen wären eine Möglichkeit, dies zu verstärken. So könnten Anzeigen auf der Grundlage eines Viele-Website-Profils ausgewählt werden.
Kriterium „Inaktive Daten“	Erläutern Sie das Kriterium "Inaktive Daten" im Vertrauensmodell des Schlüssel/Wert-Dienstes.	Daten im Key Value Service werden in den Arbeitsspeicher geladen und von dort bereitgestellt, anstatt ein Read-through-Caching durchzuführen.
Käuferdatensignal	Gibt es eine definierte Größenbeschränkung für die buyer_data-Signale, die von den DSPs empfangen werden?	Derzeit gibt es für den Browser keine Beschränkungen für buyer_data-Signale, die von DSPs empfangen werden.

Digitale Werbung analysieren

Attribution Reporting (und andere APIs)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Geräteübergreifend	Planen Sie die geräteübergreifende Unterstützung für die Attribution Reporting API ein.	Geräteübergreifende Lösungen bringen neben 3PC auch neue Datenschutzherausforderungen mit sich und bringen angesichts der Bandbreite an Geräten und Plattformen, die ein Nutzer möglicherweise verwendet, auch Herausforderungen bei der Technologieverteilung mit sich. Wir prüfen momentan mögliche Lösungen, konzentrieren uns jedoch auf die wichtigsten Anwendungsfälle, die derzeit von Attribution Reporting unterstützt werden, und planen nicht, eine geräteübergreifende Unterstützung einzuführen, bevor Drittanbieter-Cookies entfernt werden.
(Auch in vorherigen Quartalen gemeldet) Größe der Triggerdaten	Warum ist die Größe der Triggerdaten auf 3 Bit begrenzt?	Die Größe ist auf 3 Bit und 8 verschiedene Werte beschränkt, damit die Menge der website- und kontextübergreifenden Informationen zu einem Nutzer begrenzt ist. Wir begrüßen es, wenn Nutzer Feedback geben, ob die aktuelle Parametrisierung für die Berichterstellung auf Ereignisebene ausreicht.
Conversion-Trichter	Mehrere Domains melden, die bei einer Conversion verwendet wurden	Dieser Anwendungsfall ist durch das Hinzufügen mehrerer Ziele möglich. Wir freuen uns über zusätzliches Feedback.
Support für dieselbe Domain in unterschiedlichen Ländern	Funktioniert Attribution Reporting mit Websites, die dieselbe Domain, aber mehrere Länder-TLDs haben?	Dieses Problem wurde mit dem Stakeholder, der die Frage gestellt hat, besprochen und gelöst. Wenn Anzeigentechnologie-Anbieter mehrere Länder-TLDs verwenden müssen, sind mehrere Registrierungen erforderlich – eine für jede länderspezifische TLD.
Protected Audience API und Attributionsberichte	Können Anzeigentechnologie-Anbieter sowohl auf View-through-Conversions für Protected Audience-Auktionen als auch auf Klick-Conversions für Attribution Reporting zugreifen?	Ja, die Privacy Sandbox sollte sowohl VTCs als auch CTCs in Protected Audience unterstützen.
Verzögerungen bei Berichten mit zusammenfassenden Berichten	Reduzieren Sie Verzögerungen bei aggregierten Berichten weiter.	Wir haben kürzlich Feedback dazu erhalten und unsere Ideen hier geteilt. Wir freuen uns immer über zusätzliches Feedback aus der Community.
Verzögerungen bei Berichten mit zusammenfassenden Berichten	Verzögerungen durch die Einführung von Serververmittlung reduzieren	Wir prüfen diesen Vorschlag und freuen uns auf zusätzliches Feedback .
Verzögerungen bei Berichten auf Ereignisebene	Reduzieren Sie Verzögerungen bei Berichten auf Ereignisebene.	Mit dem vollständigen, flexiblen Angebot auf Ereignisebene, der unter Flexible Konfigurationen auf Ereignisebene beschrieben wird, können die Verzögerungen bei der Berichterstellung auf Ereignisebene unter Berücksichtigung von Störfaktoren auf eine Stunde reduziert werden.
Quelle für Berichte – Ursprung pro Quelle	Die Begrenzung der maximalen Quellen für Berichte pro Quelle verhindert, dass Anzeigentechnologie-Quellen für einen einzelnen Publisher-Ursprung registrieren.	Dies wurde mit dem Stakeholder besprochen, der das Problem gemeldet hat. Außerdem wird eine mögliche Lösung für die Verwendung eines Berichtsursprungs pro Berichtswebsite getestet, bevor andere mögliche Lösungen mit Weiterleitungen ausprobiert werden. Wir freuen uns auch über zusätzliches Feedback aus der Community zu diesem Limit.
Problemberichte	Wie können wir Fehler oder Probleme mit der Attribution Reporting API an Chrome melden?	Derzeit empfehlen wir AdTech-Experten, alle Attribution Reporting API-Fehler, die sie möglicherweise haben, auf GitHub als Problem zu melden. Wenn ein Problem in Zusammenhang mit Chrome auftritt, empfehlen wir, einen Chromium-Programmfehler zu erstellen. Links dazu, wie und wo du Probleme melden kannst, findest du unter Feedback geben und einbeziehen.
Deduplizierung	Wie können Conversions über verschiedene Pipelines und Geräte hinweg dedupliziert werden?	Die Deduplizierung über Geräte und Analysepipelines ist eine bekannte und aktuelle Herausforderung, vor der auch Anzeigentechnologie-Anbieter aktuell stehen. Mit der Attribution Reporting API können Anzeigentechnologie-Anbieter entscheiden, wann bestimmte Conversions registriert und bestimmte Metadaten hinzugefügt werden, um anzugeben, welche Messpipelines sie zum Erfassen der Conversions verwendet haben (mit anderen Worten, Teil des Aggregationsschlüssels), die mit anderen Messpipelines verglichen werden können. Wir freuen uns immer über zusätzliches Feedback zu diesem Thema.
Deduplizierung und Priorität	Fordern Sie vor der Deduplizierung an, zuerst Priorität zu erhalten.	Wir prüfen diese Anfrage und freuen uns auf zusätzliches Feedback.
Schutz vor Betrug	Es besteht das Risiko, dass Daten auf Ereignisebene von böswilligen Nutzern manipuliert werden.	Die Überprüfung von Berichten funktioniert nicht für die Berichterstellung auf Ereignisebene. Die Gründe hierfür finden Sie unter Warum werden Berichte auf Ereignisebene nicht unterstützt?.
Conversion-Typ	Wie kann ich in Attribution Reporting zwischen View-through und Navigation unterscheiden?	Wir haben die folgende integrierte Filteroption: source_type. Weitere Informationen

Aggregationsdienst

Feedback-Design	Zusammenfassung	Chrome-Antwort
Budgetausgleich	Einige Anzeigentechnologie-Anbieter fordern die Möglichkeit, Berichte noch einmal zu verarbeiten, wenn Fehler oder Löschungen von Berichten auftreten.	Das Team sucht nun nach Möglichkeiten, dieses Problem auf datenschutzfreundliche Weise zu lösen.
Websiteregistrierung	Mehrere AdTech-Unternehmen haben Unterstützung für die Verarbeitung mehrerer Ursprünge im selben Konto angefordert, um Anwendungsfälle wie die Aufteilung von Daten nach Geografie oder Werbetreibenden zu ermöglichen. Dieses Verhalten wird auch von Anzeigentechnologie-Anbietern erwartet, da die Client-API-Registrierung jetzt websitebasiert (und nicht ursprungsbasiert) ist. Durch die Migration vom Ursprung zur Websiteregistrierung wird der Onboarding-Prozess für AdTech optimiert, da er dem Anmeldeprozess für Kunden entspricht.	Wir werden für den Aggregation Service bald eine Migration von der Ursprungsregistrierung zur Websiteregistrierung starten und freuen uns auf Feedback von unserer Plattform.
Release- und Einstellungsplan	Veröffentlichungs- und Einstellungszeitplan für veröffentlichte Aggregation Service-Funktionen und -Patches Ziel des Plans ist es, Anzeigentechnologien einen Einblick in unsere Releaserichtlinien zu verschaffen, damit sie sich auf bevorstehende Releases und Einstellungen vorbereiten und dafür sorgen können, dass sie stabile und sichere Versionen von Diensten ausführen.	Wir haben vor Kurzem einen Vorschlag für den Release- und Einstellungsplan des Aggregation Service veröffentlicht und würden uns über zusätzliches Feedback freuen.
Koordinatoren	Was passiert, wenn die Koordinatoren den Aggregationsdienst ausfallen?	Beide Koordinatoren müssen vollständig verfügbar sein, damit das System ordnungsgemäß funktioniert. Kurze Nichtverfügbarkeit wird durch Wiederholungsversuche in unseren Clientbibliotheken ermöglicht. Bei einer längeren Nichtverfügbarkeit eines der beiden Koordinatoren schlagen Aggregationsjobs fehl. Jobs können neu gestartet werden, wenn das datenschutzorientierte Budget noch nicht aufgebraucht ist. Wenn ein Dienstfehler zu einer Budgetnutzung führte, ohne dass ein zusammenfassender Bericht in den Speicher für AdTech-Daten geschrieben wurde, empfehlen wir derzeit, Debug-Berichte zu verwenden, um Ergebnisse mit dem lokalen Testtool abzurufen. Wir arbeiten außerdem an Funktionen, mit denen sich im Falle von Fehlern das Budget ausgleichen lässt, damit Anzeigentechnologie-Mitarbeiter ihre Jobs noch einmal ausführen können.

Private Aggregation API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Blob-URL	Anfrage zur Unterstützung von Blob-URLs im freigegebenen Speicher.	In Chrome M116 werden jetzt Blob-URLs unterstützt.

Verdecktes Tracking begrenzen

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

Feedback-Design	Zusammenfassung	Chrome-Antwort
JavaScript API	Verfügbarkeit der User-Agent Client Hints JavaScript API	Es ist nicht geplant, diese Funktion zu entfernen, da sie unsere Kernlösung für Partner ist, die aktiv auf die Daten mit hoher Entropie zugreifen möchten, als in dem fixierten und reduzierten UA standardmäßig verfügbar sind.
Informationen zu Gerät und Formfaktor	Fähigkeit von Websites, Eingaben, Ausgaben und andere Informationen zu verstehen, die das Gerät, das die Website besucht, unterstützen kann.	Aufgrund des Feedbacks von Creatorn wird diese Anfrage unterstützt.

IP Protection (früher Gnatcatcher)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Berechtigter Drittanbieter-Traffic	Worauf bezieht sich in der Erläuterung „zulässiger Drittanbieter-Traffic“?	Wir wissen, wie wichtig diese Frage ist, und arbeiten aktiv daran, zu ermitteln, welcher Drittanbieter-Traffic infrage kommt und welcher nicht. Wir freuen uns über Feedback zu diesem Thema.
Netzwerk-Traffic-Audits	Unterstützung für Unternehmen bei der Durchführung von Netzwerk-Traffic-Audits für ihre Netzwerke.	Davon sind nur Drittanbieter-Traffic betroffen, der in eigene Websites eingebettet ist. Dadurch sollte die Menge des Traffics begrenzt sein, der gefiltert werden muss. Darüber hinaus möchten wir Nutzern die Möglichkeit geben, den IP-Schutz zu verwenden oder nicht. Für von Unternehmen gesteuerte Chromes wird es Unternehmensrichtlinien geben, um den IP-Schutz zu deaktivieren. Zum Schluss prüfen wir, welche Steuerelemente Netzwerkbetreibern zur Deaktivierung des IP-Schutzes (falls zutreffend) zur Verfügung stehen. Wir freuen uns über Feedback zu diesem Thema.
Zugriffssteuerung	Der IP-Schutz kann sich auf Webdienste auswirken, die IP-Adressen für die Zugriffssteuerung verwenden.	Wir wissen, wie wichtig der Schutz vor Betrug ist und welche Auswirkungen diese möglicherweise haben können. Wir bitten um Feedback aus der Umgebung, wie wir die Betrugsbekämpfung in Anwendungsfällen, die normalerweise auf IP-Adressen basieren, besser unterstützen können.
Kommunikation zwischen den 2-Hop-Proxys	So stellen Sie sicher, dass zwischen Proxys keine Informationen vorhanden sind.	Wir sind gerade dabei, die Proxy-Interaktionen zu entwerfen. Unser Ziel ist es, die Wahrscheinlichkeit eines solchen Informationsaustausches über geschäftliche, prozessbezogene oder technische Mittel zu minimieren.
Authentifizierungen von Drittanbietern	Unterstützung von Drittanbieter-Authentifizierungen	Wir planen, in Zukunft weitere Details zur Kontoauthentifizierung zu veröffentlichen. Hier sind jedoch bereits einige erste Überlegungen angestellt.
Tracker-Klassifizierung	Wie wird durch den IP-Schutz festgelegt, was einen Tracker und seine Varianten ausmacht?	Wir wissen, wie wichtig diese Frage ist, und arbeiten aktiv daran, zu ermitteln, welcher Drittanbieter-Traffic infrage kommt und welcher nicht. Wir freuen uns über Feedback zu diesem Thema.
Analysen	Der IP-Schutz kann die Genauigkeit von Analysediensten beeinträchtigen.	Wir möchten mehr über die Auswirkungen des IP-Schutzes erfahren und würden uns über zusätzliches Feedback und Beispiele aus der Umgebung freuen.
Proxy	Wie funktioniert die IP-Maske in diesem Fall, wenn ein Nutzer einen Proxy verwendet oder manuell einen Proxy definiert hat?	Wir möchten verstehen, welche Auswirkungen der IP-Schutz auf andere Proxys haben kann. Momentan gibt es keine Pläne, Informationen dazu zu veröffentlichen. Wir freuen uns über Feedback zu diesem Thema.
Premium-Angebot	Wird der IP-Schutz eine kostenpflichtige Funktion sein?	Der IP-Schutz wird Chrome-Nutzern als Teil der zentralen Browserumgebung zur Verfügung stehen. Es handelt sich nicht um eine kostenpflichtige Funktion.
Proxy server	Werden in Nutzersitzungen dieselben Proxyserver verwendet?	Eine HTTP/S-Verbindung verwendet ein einzelnes Paar von Proxys und stellt dem Ursprung eine einzelne maskierte IP-Adresse bereit. Darüber hinaus gibt es keine festen Einschränkungen dafür, dass verschiedene HTTP/S-Verbindungen dieselben Server verwenden müssen.
Plattform-Support	Auf welcher Plattform wird der IP-Schutz unterstützt?	Der IP-Schutz wird zuerst in Chrome für Android und Desktop verfügbar sein. Wir prüfen weiter, wie wir den Schutz auf andere Plattformen ausweiten können.
Deaktivieren	Können Nutzer den IP-Schutz deaktivieren?	Wir planen, Nutzern die Möglichkeit zu geben, ob sie IP-Schutz verwenden möchten oder nicht.
Anonymisierung	Welche Arten von Anfragen werden im Rahmen des IP-Schutzes anonymisiert?	HTTP/S- und DNS-Anfragen an zulässige Drittanbieterdomains werden über die Privacy-Proxys anonymisiert. In einer nachfolgenden Erklärung werden wir weitere Einzelheiten dazu erläutern, wie wir bestimmen, welche Domains aufgenommen werden. Der restliche Traffic (z. B. der Rest der DNS-Anfragen oder anderer HTTP/S-Traffic) ist davon nicht betroffen.
Datentransparenz	Auf Netzwerkadressen kann während des ersten Hops gemäß IP-Schutz zugegriffen werden.	Im Proxymodell mit zwei Hops sieht der erste Hop (gesteuert von Google) nur die IP-Adresse des Quellclients und eine Anfrage zur Verbindung mit dem zweiten Hop. Der zweite Hop (gesteuert von einem externen CDN) sieht hingegen nur ein Tupel im ersten Hop (Proxy-IP + Port) und Ziel-IP. Für die Antwort vom Ursprung kann der zweite Hop die Antwort an den mit der Anfrage verknüpften Proxy und Port des ersten Hops weiterleiten und muss nichts über die ursprüngliche Client-IP erfahren (und der erste Hop gibt nur die Antwort an den Client zurück, ohne etwas über die Ziel-IP-Adresse zu erfahren). Auf diese Weise lernt der erste Hop nur die Client-IP-Adresse und den zweiten Hop, während der zweite Hop nur die Ziel-IP-Adresse lernt.
WebView	Wird der IP-Schutz in Zukunft für Android WebView verfügbar sein?	Derzeit haben wir keine Pläne, Informationen dazu zu geben, aber wir möchten diesen Schutz so weit wie möglich anbieten.

Eindämmung von Bounce-Tracking

Feedback-Design	Zusammenfassung	Chrome-Antwort
Interaktions-Tracking	Wie werden Nutzerinteraktionen erfasst?	Mit Maßnahmen zur Eindämmung von Bounce-Tracking werden zwei Arten von Nutzerinteraktionen erfasst: Nutzeraktivierungen gemäß HTML-Spezifikation. Dabei handelt es sich um Klicks, Tastenbetätigungen, Touchscreen-Tippaktionen usw. Erfolgreiche webauth-Assertions. In diesen Fällen tippt ein Nutzer auf einen Sicherheitsschlüssel oder verwendet einen Passkey zur Authentifizierung. Diese Interaktionen werden mit der Website der obersten Ebene auf den Seiten verknüpft, auf denen sie stattfinden. Klickt ein Nutzer beispielsweise in einen eingebetteten iFrame, wird die Interaktion mit der Top-Level-Website und nicht mit der eingebetteten Website verknüpft. Die Interaktionen werden in einer Datenbank gespeichert, die die schemalose Anzahl+1 und den Zeitpunkt der Interaktion enthält. Interaktionen verhindern 45 Tage lang, dass die verknüpfte Domain vor dem Löschen des Bounce-Tracking-Einstufungsstatus gelöscht wird.
Ausnahmen auf der Zulassungsliste	Können Domains ausgenommen werden?	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.

Privacy Budget

In diesem Quartal gab es kein Feedback.

Websiteübergreifende Datenschutzgrenzen stärken

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

Feedback-Design	Zusammenfassung	Chrome-Antwort
Zentralisierter Ansatz	Bedenken hinsichtlich des zentralen Repository-Ansatzes für die Verwaltung von Gruppen ähnlicher Websites:	Ein öffentliches, leicht zugängliches Repository ist entscheidend für die Entwicklung von RWS, da es für Beiträge verantwortlich ist. Die Funktionalität von Drittanbieter-Cookies wird letztendlich durch die Verwendung der Storage Access API oder der rSAFor API bereitgestellt, wobei die RWS-Mitgliedschaft automatisch gewährten Zugriff gewährt (im Gegensatz zu Aufforderungen mit der Storage Access API). Wir sind der Meinung, dass ein Ansatz wie der RWS-Übermittlungsprozess eine geeignete Voraussetzung für den automatisch gewährten Zugriff auf Drittanbieter-Cookies ist.
JSON-Datei wird umbenannt	Muss aufgrund der Änderung des API-Namens der Name der gehosteten JSON-Datei geändert werden?	Ja, die Richtlinien für die Einreichung wurden geändert und die primäre Domain muss eine JSON-Datei unter /.well-known/related-website-set.json bereitstellen. Vorhandene Sätze in der RWS-Liste müssen nicht geändert werden. Wenn jedoch Änderungen an vorhandenen Sätzen gesendet werden, muss die JSON-Datei geändert werden.
(Auch in vorherigen Quartalen angegeben) Domainlimit	Anfrage zur Erweiterung der Anzahl verknüpfter Domains	Wie in einem Blogpost vom 31. August angekündigt, haben wir das Limit für verknüpfte Domains auf Grundlage des Feedbacks von unserem System auf fünf Domains erhöht. Wir haben uns entschieden, das Limit für verknüpfte Domains auf fünf Domains (plus eine primäre Domain) zu erhöhen, was am besten mit der Implementierung übereinstimmt, die von einem anderen großen Browser angeboten wird.
Drittanbieter-Cookies	Funktionieren Gruppen ähnlicher Websites nur, wenn Drittanbieter-Cookies deaktiviert sind?	Gruppen ähnlicher Websites funktionieren auch dann, wenn ein Nutzer Drittanbieter-Cookies nicht blockiert hat. Es gibt jedoch keine erkennbaren Auswirkungen, da die entsprechenden Cookies ohne Zugehörige Website-Sets und die Storage Access API verfügbar sind.
Seriöse Änderungen	Wie verhindert das Repository für Gruppen ähnlicher Websites, dass Nicht-Inhaber Sätze ändern?	Gemäß den Leitfäden zur Einreichung kann jeder eine PR auf GitHub einreichen, um die Datei first_party_sets.JSON zu bearbeiten. Wenn der PR genehmigt wurde (z. B. technische Prüfungen besteht usw.), wird er einmal pro Woche (Dienstag um 12:00 Uhr Eastern Time) manuell in Batches mit der kanonischen FPS-Liste zusammengeführt. Wenn ein böswilliger Akteur versucht, einen Satz zu ändern, der ihm nicht gehört, sollte dies kein Problem sein, da er die .well-known-Dateien nicht ändern kann und die Validierungen daher fehlschlagen.
Domaindiebstahl	Bei Domaindiebstahl können verwandte Domaindaten Unbefugten zugänglich gemacht werden.	Dies ist nicht möglich, wie im GitHub-Problem zu Protected Audience beschrieben.

Fenced Frames-API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Verstoß gegen die Inhaltsrichtlinien	Nutzern erlauben, verdächtige Anzeigen zu melden.	Das Melden verdächtiger Anzeigen wird durch Fenced Frames nicht verhindert. Nutzer können weiterhin mit der Anzeige interagieren und dem AdTech-Team verdächtige Anzeigen wie gewohnt melden.
Interaktion mit umliegenden Websites	Interaktionen mit der umgebenden oder übergeordneten Website zulassen.	Wir möchten verstehen, warum diese Anfrage notwendig ist, und würden uns über zusätzliches Feedback aus der Community freuen.
Native Werbung	Fenced Frame-Unterstützung für native Werbung	Wir erwägen, den Anwendungsfall zu unterstützen, und besprechen mögliche Umgehungen und Lösungen.

Shared Storage API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Domainübergreifend	Domainübergreifende Kommunikation für lokalen Speicher zulassen.	Dieser Anwendungsfall entspricht derzeit nicht den datenschutzfreundlichen Ausgabe-Gatters von Shared Storage. Wir freuen uns aber über zusätzlichen Kontext, wenn wir Vorschläge für nicht partitionierten Speicher entwickeln.
Blob-URL	Anfrage zur Unterstützung von Blob-URLs im freigegebenen Speicher.	In Chrome M116 werden jetzt Blob-URLs unterstützt.

Chips

In diesem Quartal gab es kein Feedback.

FedCM

Feedback-Design	Zusammenfassung	Chrome-Antwort
Drittanbieter-Cookies	Ist FedCM derzeit deaktiviert, wenn Nutzer in den Chrome-Einstellungen die Option „Cookies von Drittanbietern blockieren“ aktivieren?	Ja, FedCM ist derzeit deaktiviert. Für Tests empfehlen wir, zusätzlich chrome://flags/#fedcm- without-third-party-cookies zu aktivieren. Wir planen, FedCM ohne Drittanbieter-Cookies zu unterstützen.

Spam und Betrug bekämpfen

Private State Token API (und andere APIs)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Ablauf des Tokens	Geht das Token nach der Deinstallation von Google Chrome verloren oder wird es im Cache gespeichert?	Das Token geht verloren, wenn der Nutzer Google Chrome deinstalliert.
Token-Informationen	Wie können Aussteller dafür sorgen, dass ausgestellte Informationen im Private State Token privat bleiben?	Informationen werden im Token immer geheim gehalten und können von externen Parteien, die nicht über die Schlüssel verfügen, nicht entschlüsselt werden.
Fehler in Demo	Beim Ausführen der Demo für das Private State Token ist ein Fehler aufgetreten.	Wir haben die Demo aktualisiert. Sie sollte jetzt einwandfrei funktionieren.