Feedbackbericht – 3. Quartal 2022

Vierteljährlicher Bericht für das 3. Quartal 2022 mit einer Zusammenfassung des Feedbacks aus der Community zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google bereit erklärt, vierteljährliche 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, Fledge 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 spezifische API/Technologie

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 2. Quartal berichtet) Nützlichkeit für verschiedene Arten von Stakeholdern	Bedenken, dass die Privacy Sandbox-Technologien größere Entwickler bevorzugen und dass Nischenwebsites (kleinere Websites) einen höheren Beitrag leisten als generische (größere) Websites.	Update im 3. Quartal: Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verfälscht wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende unabhängig von ihrer Größe berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird. Im Zuge der Tests der Privacy Sandbox ist eine der wichtigsten Fragen, die wir bewerten, die Leistung der neuen Technologien für verschiedene Arten von Interessenvertretern. Feedback ist dabei von entscheidender Bedeutung, insbesondere spezifisches und umsetzbares Feedback, das uns helfen kann, die technischen Designs weiter zu verbessern. Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen, in dem Marktteilnehmer mehr Informationen erhalten und die vorgeschlagenen Ansätze kommentiert werden können.
(Auch im 2. Quartal berichtet) Dokumentationsanfragen	Anfragen nach weiteren Ressourcen zur Verwaltung von Tests, Analysen und Implementierungen	Update im 3. Quartal: Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden, und werden in den kommenden Wochen und Monaten weitere Informationen bereitstellen, damit Entwickler besser nachvollziehen können, wie sie von den neuen Technologien profitieren können. Außerdem haben wir öffentliche Sprechstunden für Entwickler abgehalten, bei denen Best Practices und Demos vorgestellt wurden. Außerdem gab es Fragerunden mit Produkt- und Entwicklerteams, um Live-Diskussionen und -Fragen zu ermöglichen.
Browserübergreifende Unterstützung	Andere Browseranbieter, die die Privacy Sandbox APIs verwenden	Andere Browser-Anbieter wie Apple, Mozilla und Microsoft nehmen aktiv an den öffentlichen Foren teil, in denen Datenschutzprinzipien und browserbasierte Ansätze diskutiert werden. Die gemeinsamen Diskussionen in Foren wie das letzte jährliche W3C-TPAC-Meeting und die fortlaufenden W3C PATCG-Foren, in denen wir Anzeichen für eine Konvergenz erkennen, freuen uns sehr.
Plattformunterschiede	Beantragen Sie die Angleichung der Funktionen im Web und in Android so weit wie möglich, um den Ressourcenaufwand für die Umstellung zu reduzieren.	Wir arbeiten intensiv daran, unsere Ansätze für Chrome und Android aufeinander abzustimmen, um Verwirrung/Fragmentierung innerhalb der Branche zu vermeiden. Wenn wir Unterschiede in unserem Ansatz verfolgen, ist das hauptsächlich auf notwendige technische Unterschiede zwischen den Plattformen für das Web und für mobile Apps zurückzuführen, die von den Entwicklern bereits berücksichtigt werden.
Ressourcen zum Testen der Privacy Sandbox APIs	Schwierigkeiten beim Zuordnen Ressourcen zum Testen der Privacy Sandbox APIs angesichts des aktuellen wirtschaftlichen Gegenwinds.	Google verbessert kontinuierlich die Dokumentation und den Support für Tester, um deren Komplexität zu vereinfachen und die Einführung der APIs zu erleichtern. Dazu gehören API-spezifische Mailinglisten, offene Sprechstunden und laufende Updates auf developers.chrome.com.
Sandbox API-Deaktivierungssignal	Anfrage zur Übermittlung des Signals „Nutzer hat die Sandbox APIs deaktiviert“, das von Anzeigentechnologien und Websites verwendet werden darf.	Es gibt schon viele Fälle, in denen Websites auf Nutzereinstellungen reagieren, z. B. das „Deaktivieren von Drittanbieter-Cookies“, indem sie den Nutzer dazu drängen, seine Einstellungen zu ändern. Manchmal wird auch der Zugriff auf die Website blockiert, es sei denn, er hat dies getan. Ein Deaktivierungssignal kann auch als zusätzliches Signal für das Fingerprinting verwendet werden. Derzeit hat Google nicht die Absicht, ein Widerspruchssignal bereitzustellen.
(Auch im 2. Quartal berichtet) Präzisere Zeitpläne	Klarere, detailliertere Veröffentlichungspläne	Update im 3. Quartal: Wie im Abschnitt „Änderungen als Reaktion auf Feedback“ unten erläutert, hat Google den Zeitplan der Privacy Sandbox im Juli aktualisiert, um dem Markt mehr Zeit für vorläufige Tests und Feedback zu geben. Außerdem hat Google mehr Zeit für Tests, sobald die Privacy Sandbox APIs vollständig eingeführt sind, bevor Drittanbieter-Cookies eingestellt werden.
(Auch im 2. Quartal berichtet) Fristen für die Einstellung von Drittanbieter-Cookies	Anfragen zur Vermeidung weiterer Verzögerungen bei der Einstellung von Drittanbieter-Cookies	Update im 3. Quartal: Im Juli haben wir für Chrome einen aktualisierten Zeitplan für die Einstellung von Drittanbieter-Cookies angekündigt. Damit möchten wir verantwortungsbewusst handeln, wenn man bedenkt, dass die Technologien komplex sind und ihre Bedeutung für die Plattform so wichtig ist. Das Feedback von Regulierungsbehörden und der Branche wurde vor dieser Änderung berücksichtigt und wir arbeiten weiterhin eng mit allen Stakeholdern zusammen.
Eigene Cookies	Werden auch Einschränkungen für eigene Cookies vorgeschlagen? Falls ja, haben wir Bedenken in Bezug auf die langfristige Stabilität, das Risiko weiterer unvorhersehbarer Browseränderungen und damit verschwendete Entwicklungsarbeit jetzt.	Wir haben keine Einschränkungen für eigene Cookies berücksichtigt. Der Schwerpunkt der Privacy Sandbox liegt auf der Einstellung von Drittanbieter-Cookies.

Relevante Inhalte und Werbung zeigen

Themen

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 2. Quartal berichtet) Nützlichkeit für verschiedene Arten von Stakeholdern	Es gibt Bedenken hinsichtlich der Nützlichkeit von Websites, die sich nach dem Grad des Traffics oder der Spezialisierung ihres Contents richten.	Update im 3. Quartal: Die Nützlichkeit der API wird durch Tests erforscht. Wie in Paragraf 17.c.ii der Vereinbarungen vorgesehen, gibt Google die Ergebnisse solcher Tests an die CMA weiter. Chrome geht davon aus, dass sich die Taxonomie und andere Parameter basierend auf den Testergebnissen weiterentwickeln werden. Für die Weiterentwicklung der Taxonomie oder der Parameter sind keine abwärtsinkompatiblen Änderungen erforderlich. Außerdem geht Chrome davon aus, dass sich das Feedback auch nach der Einstellung von Drittanbieter-Cookies auf die Weiterentwicklung der Topics API auswirken wird.
Datenschutzbestimmungen	Anfrage zum Entfernen der Filteranforderung für Themen pro Aufrufer.	Basierend auf dem Feedback von Datenschutz-KOLs, Datenschutzbeauftragten, Sicherheitsexperten, Gruppen für digitale Rechte und anderen Akteuren im System hat Chrome dieses Design gewählt, um nur denjenigen Zugriff auf Informationen zu gewähren, die sonst einen solchen Zugriff hatten. Zu den Gründen zählten unter anderem die Beschränkung des inkrementellen plattformübergreifenden Datenlecks, die Gewährleistung von Transparenz und Erklärbarkeit, die Einführung eines einfach zu implementierenden und beschreibenden Ansatzes sowie die Begrenzung des Risikos von Fingerprinting. Publisher und Drittanbieter, die die Topics API erhalten, können selbst entscheiden, welche Informationen sie an die Parteien auf ihrer Website weitergeben möchten. Falls Dritte diese Informationen weitergeben, empfiehlt Chrome diese, den Nutzern gegenüber transparent zu sein und ihnen Kontrollen zu bieten.
Falsch kategorisierte Websites	Websites sind dem falschen Thema zugeordnet, was zu einer ungenauen Anzeigenausrichtung führen kann.	Websites werden mithilfe einer Kombination aus einer von Menschen zusammengestellten Liste mit den beliebtesten Websites und einem ML-Modell auf dem Gerät klassifiziert. Chrome prüft weiterhin, welche Websites zur Klassifizierung von Themen beitragen können. Jegliche Verbesserungen des Nutzens müssen gegen die Risiken in Bezug auf Datenschutz und Missbrauch abgewogen werden. Zu den Risiken gehören beispielsweise: Websites, bei denen die eigene Kennzeichnung verwendet wird, um verschiedene (und möglicherweise sensible) Bedeutungen in Themen zu codieren Websites, die ihre Themen aus finanziellen Gründen falsch darstellen Websites, die Themen angreifen, um ihre Nützlichkeit für andere zu senken (z. B. Spamming von Nutzerthemen mit bedeutungslosem Rauschen) Diese Komponenten sind über chrome://topics-internals oder dieses Colab verfügbar. Im Rahmen der Tests gehen wir davon aus, dass sich die Klassifizierung mit der Zeit verbessern wird. Wir freuen uns über Feedback zu Beispielen für Websites, die möglicherweise falsch kategorisiert wurden.
Zugriffsanforderungen	Die aktuelle Topics-Anforderung für eine DOM-Entität auf der Seite als Skript oder iFrame für den Zugriff kann zu unerwünschtem Verhalten von Spielern im Anzeigensystem führen.	Wir haben eine Änderung in der Erläuterung zu GitHub zusammengeführt. Wir beabsichtigen, Topics in HTTP-Headern zu unterstützen.
Thementaxonomie nicht detailliert genug	Aktuelle Klassifizierungen für Themen sind zu weit gefasst und enthalten keine detaillierteren Themen wie z. B. regionale Themen.	Verbesserungen an der Taxonomie sind fortlaufende Bemühungen und wir erwarten, dass sich die Taxonomie durch Tests und Eingaben weiterentwickeln wird. Wir sind aktiv auf der Suche nach Feedback zur Taxonomie, die für die Plattform am nützlichsten wäre. Bei der Entscheidung, ob Sie die Anzahl der Themen erweitern oder detailliertere Themen einbeziehen sollten, sind einige Aspekte zu berücksichtigen: 1) mögliche Auswirkungen auf den Datenschutz (z.B. kann mehr Themen ein Fingerprinting-Risiko darstellen) und 2) die Möglichkeit, zuvor beobachtete Themen abzurufen (z.B. mit mehr Themen ist die Wahrscheinlichkeit geringer, dass ein AdTech das ausgewählte Thema in der Vergangenheit gesehen hat). Google versucht auch, im Rahmen der bestehenden Filteranforderungen die Möglichkeit des Aufrufers zu maximieren, zuvor beobachtete Themen abzurufen. Dabei soll sowohl der Nutzen als auch der Datenschutz gewährleistet werden.
Maximal zulässige Anzahl von Themen	Drei Themen pro Website sind zu wenig Informationen, um für Werbetreibende Anzeigen zu schalten.	Das Feedback aus der Community, insbesondere die Testergebnisse aus unseren Ursprungstests, wird die Weiterentwicklung der API weiterhin beeinflussen. Es ist zu beachten, dass die Topics API andere Signale wie Kontextinformationen ergänzen soll, damit dem Besucher passende Werbung präsentiert wird. So stehen dem Werbetreibenden über die Themen hinaus noch mehr Informationen zur Verfügung.
(Auch im 2. Quartal berichtet) Steuerelemente und Sicherheit für Nutzer	Bestimmte Themen können als Anhaltspunkte für sensible Gruppen dienen und Nutzer benötigen mehr Kontrollen, um negative Ergebnisse zu verhindern.	Update im 3. Quartal: Themen stellen einen bedeutenden Schritt nach vorn für mehr Kontrolle und Transparenz dar. Nutzer können Themen deaktivieren, die ihnen zugewiesenen Themen überprüfen, Themen entfernen und sehen, welche Unternehmen mit ihren Themen auf einer bestimmten Seite interagieren. Außerdem haben Nutzer die Möglichkeit, ihre Themen zu löschen, indem sie ihren Browserverlauf löschen, aus dem Themen abgeleitet werden. Diese Einstellungen sind derzeit im Chrome-Browser auf Geräteebene implementiert. Wir begrüßen weitere Diskussionen über fortgeschrittene Nutzersteuerungsmöglichkeiten, wie sie von den Entwicklern vorgeschlagen werden. Wir müssen jedoch sicherstellen, dass neue Ergänzungen gut auf die geäußerten Bedenken reagieren und nicht zu kleinteiligen Änderungen führen.
Auswirkungen auf die SEO	Publisher, die die Hostnamen ihrer Website anpassen, um die Topics API besser widerzuspiegeln, kann sich negativ auf die SEO auswirken.	Wir raten Websites davon ab, ihre Hostnamen nur zugunsten der Topics API zu ändern. Es stimmt, dass eine Website die Themen beeinflussen kann, die ihnen zugewiesen sind. Die Vorteile für Publisher sind jedoch bestenfalls unklar und es würde den Wert von Topics für die gesamte Plattform untergraben, wenn Websites versuchen, das Klassifizierungsmodell zu „spielen“. Die Themenzuweisungen werden ebenfalls nicht festgelegt. Wir gehen davon aus, dass sich die Taxonomie auch durch Tests und Eingaben weiterentwickeln wird. Im Zusammenhang mit diesen Tests ermutigen wir Feedback, einschließlich Beispielen für Websites, die möglicherweise falsch kategorisiert wurden.
Betrug und Missbrauch	Bieten Sie dem Käufer die Möglichkeit, zu prüfen, ob das Thema, das er sieht, auch tatsächlich vom Browser generiert wurde.	Wir freuen uns über den Vorschlag, einen Mechanismus für AdTech-Käufer zu unterstützen, mit dem die Themen, die von Verkäufern in programmatischen Werbeauktionen weitergegeben werden, überprüft werden können. Wir ermutigen alle dazu, sich an der Diskussion zu beteiligen. Während wir uns derzeit auf andere Verbesserungen mit höherer Priorität konzentrieren, sind wir uns bewusst, dass dies eine wichtige Ergänzung des Designs in Zukunft sein könnte.
Betrug und Missbrauch	Sie ermöglichen die öffentliche Überprüfung von Parteien, die rechtmäßige Nutzer von Topics-Daten sind, und zwar auf die gleiche Weise, wie sie öffentlich gepostet und überprüft werden können.	Wir schätzen den Vorschlag und sind uns einig, dass die Verantwortung der Öffentlichkeit ein wichtiges Instrument ist, um die Ziele der Privacy Sandbox zu erreichen. Topics API-Aufrufe sind grundsätzlich öffentlich, da jeder eine Website besuchen und die Aufrufe einer Domain an die JavaScript API beobachten kann. Einzelpersonen und Organisationen können daher die entsprechende Aktivität einsehen und beurteilen, auf welchen Websites Topics wie verwendet wird. Wir sind der Meinung, dass dies ein besserer Ansatz ist, als die „Rechtmäßigkeit“ einer Website als Teil der Funktionalität der Topics API selbst zu beurteilen.
Auswirkungen auf eigene Signale	Topics-Signale können sehr wertvoll sein und werden daher andere selbst erhobene interessenbezogene Signale abgewertet.	Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist, und Topics wurde entwickelt, um genau diesen Anwendungsfall zu unterstützen. Wie oben beschrieben, haben andere Stakeholder des Ökosystems Bedenken geäußert, dass die Topics API möglicherweise nicht nützlich genug ist, um einen Mehrwert zu bieten. In jedem Fall sind Verbesserungen an der Taxonomie ein fortlaufender Prozess und wir erwarten, dass sich die Taxonomie durch Tests und Eingaben weiterentwickeln wird.

FLEDGE

Feedback-Design	Zusammenfassung	Chrome-Antwort
FLEDGE-Auktion	Wie können SSPs Daten formatieren, die an Google Ads gesendet werden, um in einer FLEDGE-Auktion zu bieten?	Unternehmen, die an den Tests teilnehmen, werden gebeten, Dokumentationen über ihre Testpläne zu veröffentlichen und gegebenenfalls zusammenzuarbeiten. Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen. Der CMA soll Marktteilnehmern, die die Tests durchführen möchten, weitere Informationen sowie die Gelegenheit bieten, die vorgeschlagenen Ansätze zu kommentieren. Das Ad Manager-Team hat hier eine Dokumentation für Verkäufer veröffentlicht, die FLEDGE bei Publishern testen möchten, die Ad Manager als ihren Ad-Server verwenden. Hier finden Sie weitere technische Details.
FLEDGE in verschachtelten Fenced Frames	Fenced Frames ermöglichen weniger restriktive Tests und schränken in einer undefinierten Zukunft mehr ein. Dieser unbekannte Zeitplan stellt eine Herausforderung für das System dar.	Unternehmen können FLEDGE noch heute mit Fenced Frames testen. Um die Onboarding-Option zu vereinfachen, können Unternehmen zuerst FLEDGE implementieren. Nach der Implementierung von FLEDGE können sie Fenced Frames mit ihrem FLEDGE-Design testen.
Richtlinie zur Datenverarbeitung	Wie lauten die Datenverarbeitungsrichtlinien für Interessengruppen / FLEDGE?	Im FLEDGE-Design bleiben alle Daten, die in Interessengruppen gespeichert sind oder zu Personen in welchen Interessengruppen, auf dem Gerät gespeichert. Keine dieser Daten wird an einen Google-Server gesendet. Einige Datenschutzmaßnahmen, die Chrome für FLEDGE plant, umfassen die Interaktion mit einem von Google betriebenen k-Anonymitätsserver. Diese Interaktion wird sorgfältig so gestaltet, dass keine Informationen über Nutzer weitergegeben werden und dass sie in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt werden, um die Gleichheit der Informationen im gesamten Anzeigensystem zu gewährleisten. \ Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch Selbstausübung des eigenen Unternehmens verzerrt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird.
Altersbeschränkungen	Wie sorgt Chrome dafür, dass über FLEDGE erstellte Zielgruppen den Altersbeschränkungen entsprechen?	Publisher und Werbetreibende sind am besten in der Lage zu beurteilen, ob die Zielgruppen, die sie mit FLEDGE erstellen, den anwendbaren Gesetzen entsprechen. Zum weiteren Schutz der Nutzer werden die Privacy Sandbox APIs für in Chrome angemeldete Nutzer nicht aktiviert, wenn das mit ihrem Konto verknüpfte Alter noch nicht 18 Jahre alt ist. Das gilt auch während der Testphase. Bei nicht angemeldeten Nutzern erfasst Chrome keine Profilsignale, die es dem Browser ermöglichen, das Nutzeralter abzuleiten.
FLEDGE-Schlüssel/Wert-Dienste	Mehr Klarheit darüber, was der FLEDGE-Dienst für Schlüssel/Wert-Paare zulässt, z. B. die Anzahl der Schlüssel und wie oft diese aktualisiert werden können.	Unternehmen, die FLEDGE verwenden, können so viele Schlüssel haben, wie in den RAM passen. Weitere Informationen Wir arbeiten daran, Daten schneller zu ändern, und freuen uns über Vorschläge für sämtliche Anforderungen.
Testen	Schwieriges Testen von FLEDGE mit Google Ads	In der Google Ads-Onboarding-Dokumentation erfahren Sie, wie Sie am Ursprungstest teilnehmen und ihn testen können.
Bidding and Auktion Services API	Wie sieht die Strategie von Google für die Bidding and Auktion Services API aus? Wird es bei Geräteauktionen über oder unter den FLEDGE-Werten für den Chrome-Browser priorisiert?	Wir halten uns weiterhin an das aktuelle FLEDGE-basierte On-Device-Gebotsdesign. Die Gebots- und Auktionsdienste wurden vorgeschlagen, um mögliche Lösungen für bestimmte Anwendungsfälle zu finden, bei denen die Rechenleistung oder Netzwerkgeschwindigkeit des Geräts begrenzt sein kann.
Zusammengefasste Berichte	Anfrage zur Unterstützung aggregierter Berichte basierend auf allen für „generateBid“ verfügbaren Signalen	Weitere Informationen dazu werden wir in Kürze veröffentlichen.
Kontextbezogene Anzeigen	Kontextbezogene Anzeigen mit FLEDGE bereitstellen	Wir haben diese Option in Betracht gezogen und würden aus den in dieser Diskussion beschriebenen Gründen derzeit nicht empfehlen, FLEDGE für kontextbezogene Anzeigen zu verwenden.
Tests in der Praxis	Anleitung zum Isolieren von FLEDGE von Drittanbieter-Cookies für reale Tests.	Wir untersuchen derzeit Möglichkeiten, Testpopulationen bereitzustellen. Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen, in dem Marktteilnehmer mehr Informationen erhalten und die vorgeschlagenen Ansätze kommentiert werden können.
FLEDGE und Attribution Reporting API testen	Wie implementieren Sie die Attribution Reporting API am besten mit FLEDGE? Ist es sinnvoll, FLEDGE und Attribution getrennt oder zusammen zu testen?	Langfristig werden wir sowohl das Testen von FLEDGE als auch der Attribution Reporting API als integrierte Lösung unterstützen. Wir empfehlen Entwicklern jedoch, die Attribution Reporting API zuerst eigenständig und dann mit FLEDGE zu testen, wenn die Integration abgeschlossen ist.
Sichtbarkeit von Gebotspreisen	Anfrage zur Verschleierung von Gebotspreisen	Es ist möglich, Haltepunkte in „generateBid()“ oder „scoreAd()“ festzulegen, um auf Gebotswerte aus den Entwicklertools zuzugreifen. Das Chrome-Team hat den in diesem Feedback zu FLEDGE angegebenen engen Angriffsvektor berücksichtigt. Bei den Sicherheits- und Datenschutzmodellen von Chrome wird jedoch davon ausgegangen, dass Nutzer die Informationen auf ihrem eigenen Gerät in vollem Umfang nutzen können. Daher gibt es keine Möglichkeit, Gebotsdaten wie gewünscht auszublenden.
Dokumentationsanfragen	Dokumentation und Beispiele für Tests in einer Live-Umgebung.	Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden, und werden in den kommenden Wochen und Monaten weitere Informationen bereitstellen, damit Entwickler besser nachvollziehen können, wie sie von den neuen Technologien profitieren können. Außerdem haben wir öffentliche externe Sprechstunden für Entwickler veranstaltet, um Best Practices und Demos sowie Fragerunden mit Produkt- und Technikexperten zu teilen, um Live-Diskussionen und -Fragen zu ermöglichen.
Private Aggregation API	Möchten Sie weitere Informationen zur Private Aggregation API anfordern?	Es gibt eine öffentliche Erläuterung mit den neuesten Informationen, die wir derzeit zur Verfügung stellen können. Weitere Informationen werden bereitgestellt, wenn sich diese API in der Entwicklung befindet und Anwendungsfälle definiert sind.
Datenlatenz	Werden die Daten des FLEDGE-Schlüssel/Wert-Servers in Echtzeit abgerufen?	Bevor aktualisierte Daten für Abfragen vom Server zurückgegeben werden können, ist eine geringe Veralterung von nur wenigen Minuten und nicht mehreren Stunden zu erwarten, wie in einem offenen GitHub-Problem erläutert. Wir freuen uns auch über Entwicklerfeedback.
Gebots- und Auktionsdienste	Werden Gebotspreise für den Nutzer ausgeblendet, wenn Bidding und Auktionsdienste (B&A) verwendet werden?	Beim serverseitigen Ansatz für B&A ist der individuelle Gebotspreis für den Nutzer nicht sichtbar, da die Gebotsanfrage vom SSP-Auktionsdienst direkt an den DSP-Auktionsdienst gesendet wird und daher im Browser nicht mehr verfügbar ist. Der Preis des erfolgreichen Gebots ist für den Browser jedoch weiterhin sichtbar. Weitere Informationen zu Anfragen zur Verschleierung von Gebotspreisen finden Sie oben.
Gebots- und Auktionsdienste	Wie lässt sich ein Load-Balancing für Gebots- und Auktionsdienste vornehmen?	Derzeit haben wir keine Hinweise zum Load-Balancing, aber dies ist aus Leistungs- und Datenschutzperspektive wichtig. Weitere Einzelheiten folgen zu einem späteren Zeitpunkt.
FLEDGE-Limits	Beantragen Sie eine Erhöhung des JoinAdInterestGroup-Limits für die Dauer von 30 Tagen auf 90 Tage.	Wir sind der Meinung, dass die 30-tägige Datenaufbewahrung mit den anderen Privacy Sandbox-Werbe-APIs übereinstimmt, z. B. dem 30-Tage-Limit in Attribution Reporting und dem dreiwöchigen Rückblick bei der Topics API. Dieser Zeitrahmen berücksichtigt sowohl die Anforderungen der Anzeigentechnologie als auch die Erwartungen der Nutzer in Bezug auf den Datenschutz. Wir würden uns aber über weiteres Feedback freuen, während wir das Problem hier weiter besprechen.
Freigegebener Speicher in FLEDGE	Ist es möglich, die Shared Storage API in FLEDGE zu verwenden?	Wir beabsichtigen, die Shared Storage API in FLEDGE künftig zu unterstützen, und arbeiten daran, diese in einem bevorstehenden Ursprungstest verfügbar zu machen.
Häufigkeitssteuerung nach Klicks	Ist es möglich, Frequency Capping nach Klicks (nicht nach Gewinnen) in FLEDGE zu verwenden?	FLEDGE gibt jedoch an, dass ein Fenced Frame navigator.leaveAdInterestGroup() (ohne Parameter) aufrufen kann, um die Interessengruppe zu verlassen, die die Auslieferung der Anzeige ausgelöst hat. Dieser Aufruf könnte beim ersten Empfang eines Klicks erfolgen, um zukünftige Gebote zu verhindern. Dies ist eine Form des Frequency Cappings. Diese Lösung würde sich derzeit nicht für eine Begrenzung nach mehr als einem Klick eignen.
FLEDGE in verschachtelten Fenced Frames	Klicks auf Anzeigen mit Fenced Frame können nicht erfasst werden, wenn sie auf einem verschachtelten Fenced Frame erfolgen.	Hier finden Sie einen Vorschlag zur Behebung des Problems.
Messwerte ermitteln	Sie benötigen Informationen zum Erfassen von Latenzdaten für Bieter in einer FLEDGE-Auktion.	Wir arbeiten daran, bald ein Dokument zur Leistungsmessung zu veröffentlichen.
Berichte	Wie werden FLEDGE-Berichte verarbeitet?	FLEDGE-Berichte zu Gewinnen, Auktionsergebnissen und Ereignissen (z. B. zu Klicks) sind über FLEDGE APIs wie reportResult() verfügbar. Bei Berichten mit Anzeigen-Conversions ist die Einbindung in die Attribution Reporting API unabhängig von FLEDGE. Es werden jedoch laufend Gespräche über mögliche Ansätze geführt. Mit der Private Aggregation API können auch aus den isolierten Ausführungsumgebungen Berichte zu Auktionsergebnissen erstellt werden. Weitere Informationen
Größe der Interessengruppe	Gibt es eine Möglichkeit für Anzeigentechnologie-Anbieter, die Größe einer Interessengruppe (d.h. die Anzahl der Nutzer in der Gruppe) zu überprüfen?	Die Mitgliedschaft in Interessengruppen wird vom Browser auf dem Gerät des Nutzers gespeichert und nicht an den Browseranbieter oder andere weitergegeben. Allerdings kann der Inhaber einer Interessengruppe theoretisch jeden Aufruf an navigator.joininterestgroup(...) erfassen. Die Erfassung dieses Anrufs garantiert nicht die genaue Größe einer IG, da Nutzer eine Gruppe jederzeit verlassen können. Der Inhaber erhält jedoch eine Obergrenze und eine ungefähre Schätzung.
Leistung	Wird bei jeder Auktion ein Bidding-JS-/WebAssembly-Code kompiliert?	Bidding-JS-/WebAssembly-Code wird bei jeder Auktion einmal kompiliert.
Leistung	Was ist der Umfang von biddingDurationMsec?	BiddingDurationMsec beinhaltet die Kompilierung der Skriptzeit. Nicht enthalten sind die Download-Zeit, Wasm-Kompilierungszeit, Netzwerkzeit, Abrufzeit vom Schlüsselwert-Server oder Daten, die der JS-Kompilierung vorausgehen.
Anpassbare	Ist es möglich, adComponent so zu aktualisieren, dass sie an den User angepasst ist?	adComponent kann aktualisiert werden, wenn Interessengruppen aktualisiert werden. Dies geschieht entweder durch den Aufrufer beim Anrufen von "joinInterestGroup" oder wenn Chrome einen Aufruf an dailyUpdateURL startet. Auf diese Weise kann der Aufrufer die adComponent auf Grundlage des Wissens des Nutzers auf der aktuellen Website bzw. basierend auf k-anonymen Informationen aktualisieren. Den ursprünglichen Vorschlag einer Turtledove auf Produktebene finden Sie hier, der eine Analyse von RTB House zur Auswirkung auf die wichtigsten Messwerte für den Anwendungsfall der Empfehlung enthält.
Interessengruppe	Kann ein Inhaber einer Interessengruppe bestimmte Nutzer unter bestimmten Bedingungen entfernen?	Die Mitgliedschaft in einer Interessengruppe wird nur im Browser des Nutzers gespeichert und kann nur auf dessen Seite entfernt werden, z.B. durch Löschen der Websitedaten. Allerdings kann ein Inhaber einer Interessengruppe die Methode navigator.leaveAdInterestGroup() (mit einer bestimmten Bedingungslogik) aufrufen, wenn der Nutzer zu einer Seite zurückkehrt, die der Kontrolle des Inhabers der Interessengruppe unterliegt.
Leistung	Wie kann die Leistung von „generateBid“ gemessen werden?	Die Kompilierungs- und Ausführungszeit kann mit biddingDurationMsec gemessen werden. Die Downloadzeit kann über chrome://net-export gemessen werden. In aktuellen Versionen von Chrome wird die Kompilierungs- und Ausführungszeit auf dem Tab „Leistung“ der Entwicklertools angezeigt.
Häufigkeit der Aktualisierung von Interessengruppen	Wie häufig wird die Interessengruppe von den Browsern aktualisiert?	Interessengruppen, die in den letzten 24 Stunden nicht aktualisiert wurden, werden in Chrome aktualisiert, wenn navigator.updateAdInterestGroups() aufgerufen wird oder wenn sie an einer Auktion teilnehmen konnten. Weitere Informationen
Anbieter von Aggregationsdiensten	Wann werden andere Cloud-Anbieter vom Aggregation Service unterstützt?	Derzeit gibt es kein Update zu den genauen Zeiten, aber wir werden dies später bekannt geben. Aktuell erfüllt nur AWS die Sicherheitsanforderungen des Aggregationsdienstes.
Zeitplan für FLEDGE-Tests	Wie lange wird FLEDGE in BYOS getestet? Bleibt ausreichend Zeit, um vom BYOS-Modell zum TEE-basierten Modell zu wechseln?	Damit dem System genügend Zeit für Tests bleibt, gehen wir davon aus, dass die Verwendung der TEEs erst kurz nach der Einstellung von Drittanbieter-Cookies erforderlich ist. Wir werden Entwickler rechtzeitig informieren, bevor diese Umstellung erfolgt, damit sie mit dem Testen und der Akzeptanz beginnen können. Derzeit gibt es keine weiteren Neuigkeiten, aber wir werden sie bekannt geben, sobald dies der Fall ist. Die neuesten Informationen findest du hier.
Datengrößenlimit	Wie groß ist die maximale Datengröße für Wasm in der Bidding-Funktion?	Wie hier beschrieben darf die Aktualisierung von Interessengruppen nicht zu einer Interessengruppe führen, die größer als 50 KB ist, aber die maximale Datengröße für Wasm wurde noch nicht definiert. Daher würden wir uns über Feedback zu diesem Thema freuen.
Auktionssignale	Wird es eine standardisierte Datenstruktur für AuktionSignals geben?	Dies wurde noch nicht definiert, wir sind jedoch offen für Feedback.
AdTech-Server abfragen	Ist es möglich, AdTech-Serverdaten in Echtzeit von einem K/V-Server abzurufen?	Nein, der K/V-Server wird in einem Vertrauensmodell ausgeführt, das „Kein Netzwerk-, Laufwerkszugriff, Timer oder Logging“ erzwingt, um die Offenlegung von Nutzerdaten zu vermeiden. Weitere Informationen zum Vertrauensmodell
Häufigkeit der Aktualisierung von adComponents	Das Feld „adComponents“ kann derzeit nicht anhand des Browserverlaufs des Nutzers aktualisiert werden (derzeit nur in IG-Einstellung)	Die Privacy Sandbox soll die Anforderungen der Webcommunity ohne websiteübergreifendes Tracking erfüllen, d. h. den Zugriff auf den Browserverlauf verhindern. Wir empfehlen, Alternativen wie Topics zu verwenden.
Auktionsergebnisse	Gibt es eine Möglichkeit für Anzeigentechnologie-Anbieter, die Gewinnraten bei Auktionen zu ermitteln?	Das Auktionsergebnis wird gemeldet, indem die Funktionen reportResult() und reportWin() im Auktionscode des Verkäufers bzw. des gewinnenden Käufers aufgerufen werden. Beide können also Protokolldaten und Berichte zum Auktionsergebnis erstellen.
(Auch im 2. Quartal berichtet) Unterstützung für die Ausrichtung auf auszuschließende Interessengruppen	Eine API zur Unterstützung der Ausrichtung auf negative Interessengruppen: Anzeigen werden nur geschaltet, wenn ein Nutzer nicht zu einer Interessengruppe gehört.	Update im 3. Quartal: Wir haben einen neuen Vorschlag veröffentlicht und würden gerne Feedback dazu einholen.

Digitale Anzeigen analysieren

Attribution Reporting (und andere APIs)

Feedback-Design	Zusammenfassung	Chrome-Antwort
OT-Anforderungen	Entfernen Sie die Einschränkungen der Berechtigungsrichtlinie während / nur für das OT.	Bitte sehen Sie sich auch unsere angekündigten Änderungen an der Richtlinie für Berechtigungen beim Testen an. Die Bedenken der Stakeholder, auf die sich diese Änderung auswirkt, besteht darin, dass DSPs die API auf einer größeren Anzahl von ursprungsübergreifenden iFrames testen können. Ursprünglich mussten DSPs sich mit Publishern/SSPs abstimmen, um sicherzustellen, dass die richtige Berechtigungsrichtlinie festgelegt wurde, um die API in ursprungsübergreifenden iFrames zu testen. Nach dieser Änderung können DSPs die API jetzt standardmäßig aufrufen und SSPs/Publisher können die API bei Bedarf während des Ursprungstests deaktivieren.
Geräusche	Geben Sie an, dass das Rauschen zu hoch ist, was den Nutzen der Berichterstellung beeinträchtigt.	Wir erfreuen uns über Feedback bezüglich des Rauschens. Anhand dieses Feedbacks können wir bestimmen, wie bestimmte rauschenbezogene Parameter festgelegt werden. Wir arbeiten daran, weitere Ressourcen, Tools und andere Dokumente zu veröffentlichen, um Testern dabei zu helfen.
Domainübergreifende Conversions	Wie erfassen Sie domainübergreifende Conversions, z. B. mit zwei oder mehr Zielen?	Wir werden diese Frage aktuell diskutieren und Feedback einholen.
Anforderungen für die Fehlerbehebung	Möchten Sie Entwicklern erlauben, das verbleibende Datenschutzbudget bei der Bereitstellung / Tests für einen zusammenfassenden Bericht zu prüfen?	Sie können diese Funktionsanfrage hier verfolgen.
API-Nutzungsrichtlinien	Feedback zu Richtlinien, die auf der Grundlage von Einschränkungen für Dinge wie Fingerprinting eine bestimmte API verwenden können	Das ist eine sehr interessante Idee, die wir gerne mit anderen Browser-Anbietern und dem Web-Ökosystem im weiteren Sinne besprechen würden.
Ablaufeinstellung im Conversion-Bericht	Anfrage zur Unterstützung des Berichtsfilters / Ablaufs von weniger als 24 Stunden.	Stundenbasierte Ablaufzeiten sind ein Grund für Datenschutzprobleme, da Anzeigentechnologie so genau wissen kann, zu welcher Uhrzeit ein Nutzer die Website des Werbetreibenden besucht. Dank der Ablaufzeit auf Tagesebene können Anzeigentechnologie-Anbieter ungültige Impressionen herausfiltern, ohne zu ermitteln, zu welcher Uhrzeit der Nutzer die Website besucht hat.
Ablauf des OT-Tokens	Anfrage zur Verlängerung der Gültigkeit der vorhandenen OT-Tokens, um den operativen Aufwand zu reduzieren.	Wir sind uns bewusst, dass Tokens verlängert werden müssen, und arbeiten daran, dies für Entwickler einfacher zu machen, und informieren sie entsprechend.
Regionaler Support	Der Aggregationsdienst unterstützt derzeit nicht alle Regionen.	Dies ist eine aktuelle Einschränkung der Betaversion. Wir gehen davon aus, dass im Laufe der Tests weitere Regionen unterstützt werden, aber es gibt noch keinen genauen Zeitplan dafür.
Verzögerung bei Berichten auf Ereignisebene	Die Verzögerung von 2 bis 30 Tagen bei Berichten auf Ereignisebene kann für bestimmte Anwendungsfälle zu lang sein.	Hier finden Sie einen Vorschlag, nach dem Anzeigentechnologie-Anbieter steuern können, wann Berichte auf Ereignisebene bis zum Ablaufdatum gesendet werden. Die Standardeinstellung beträgt 30 Tage, Sie können aber auch einen kürzeren Zeitraum festlegen.
(Auch im 2. Quartal berichtet) Multi-Touchpoint-Attribution	Multi-Touchpoint-Attribution zulassen, z. B. geräteübergreifend oder appübergreifend	Update im 3. Quartal: Aktuelle Methoden der Multi-Touchpoint-Attribution erfordern eine deterministische Verknüpfung der Impressionen (und damit der Identität) eines Nutzers über verschiedene Websites hinweg. Daher entspricht diese Funktion in ihrer aktuellen Form nicht den Zielen der Privacy Sandbox, die wichtige Anwendungsfälle für Werbung ohne websiteübergreifendes Tracking unterstützen soll.
Zeitplan für die Einbindung von FLEDGE und Attributionsberichten	Wie sieht der Zeitplan für die Einbindung von FLEDGE und der Attribution Reporting API aus?	Aktuell gibt es keine Neuigkeiten dazu, aber wir werden weitere Informationen veröffentlichen, sobald wir einen festen Termin festlegen können.
Mehrere Triggertypen	Anfrage nach mehr Flexibilität bei der Trigger-Registrierung.	Wir haben ein Deduplizierungssystem für die Aggregate API vorgeschlagen, das Anzeigentechnologie-Anbietern mehr Flexibilität bei der Steuerung der Berichte auf Ereignisebene und der zusammengefassten Berichte bietet.
Messwerte ermitteln	Fordern Sie Messdaten an, die belegen, ob das Inventar eine gute Leistung erzielt.	Wir freuen uns über das Feedback und bitten Sie um weitere Klarheit über die Anwendungsfälle für diese Anfrage.
Conversion-Ablauf	Anfrage zur Unterstützung des Ablaufs von Conversions im Trigger-Tag statt nur im Quell-Tag.	Wir freuen uns über das Feedback und bitten Sie um weitere Klarheit über die Anwendungsfälle für diese Anfrage.
Batch-Berichte	Fordern Sie zusätzliche Analysen in Batchberichten an.	Wir freuen uns über Ihr Feedback, während wir weiter über die Auswirkungen auf den Aggregationsdienst nachdenken. Wir würden gerne erfahren, wie AdTech das Zusammenfassen von Berichten und die erwartete Häufigkeit in Betracht ziehen wird. Außerdem würden wir uns über Feedback dazu freuen, wie sich die Batch-Strategie im Laufe des Jahres ändert.
Epsilon	Wann wird der Wert von Epsilon bestimmt?	Wir arbeiten aktiv mit Testern der Plattform zusammen, um den Epsilon-Wert festzulegen und seine Implementierung in Google Analytics abzuschließen. Der Wert ist öffentlich sichtbar, zusammen mit der Diskussion, die zur Entscheidung geführt hat. Wenn Sie Feedback haben, posten Sie es bitte in diesem GH-Problem.

Verdecktes Tracking begrenzen

Reduzierung des User-Agents

Feedback-Design	Zusammenfassung	Chrome-Antwort
Bereitstellungsabhängigkeiten	Bereitstellungsabhängigkeiten des Structured User-Agents (SUA) beheben	Wir haben „Phase 4“, eine kleinere Versionsreduzierung, für alle Chrome-Nutzer ab Version 101 eingeführt. Weitere Informationen
Testen	Verlängern des Ursprungstests zur User-Agent-Reduction – von Meta anfordern.	Wir haben den Ursprungstest verlängert und die Berechtigung erhalten, Traffic-Limits zu entfernen, um größere Websites zu berücksichtigen. Die gelockerten Traffic-Limits gelten für alle Websites, egal ob groß oder klein.

User-Agent-Client-Hints

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 2. Quartal berichtet) Betrug und Missbrauchsbekämpfung	Bestimmte Funktionen, die über UA-CH verloren gehen können: Klickweiterleitungs-Tracker und betrügerische Klicks.	Update im 3. Quartal: Wir haben positives Feedback von Unternehmen erhalten, die uns mitteilen, dass sie keine nachteiligen Auswirkungen auf ihre Pipelines zur Betrugsbekämpfung festgestellt haben (Ergebnisse hier und hier). Das Team untersucht diese potenziellen Probleme weiterhin mit Stakeholdern, um Betrug zu verhindern und Analysen durchzuführen.
Berechtigungsrichtlinie	Wird die Berechtigungsrichtlinie im Cache gespeichert?	Die Berechtigungsrichtlinie wird nicht im Cache gespeichert, wie in diesem GitHub-Problem beschrieben.

Gnatcatcher (WIP)

Feedback-Design	Zusammenfassung	Chrome-Antwort
Anwendungsfälle für die Standortbestimmung	Gnatcatcher kann verhindern, dass legitime Anwendungsfälle für die Standortbestimmung in Zukunft funktionieren, z. B. die Personalisierung von Inhalten auf Grundlage der Standortbestimmung.	Wir arbeiten mit verschiedenen Interessenvertretern zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle von IP-Adressen unterstützt.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedback-Design	Zusammenfassung	Chrome-Antwort
Richtlinie	Bedenken, dass der FPS nicht mit den Bestimmungen der CMA zu den anwendbaren Datenschutzvorschriften vereinbar ist, da die DSGVO die Anzahl der Websites in einem Satz nicht begrenzt, während der Anbieter eine Beschränkung von drei Websites vorsieht.	Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verfälscht wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung, Publisher und Werbetreibende sowie die Auswirkungen auf den Datenschutz und die Einhaltung der Datenschutzprinzipien gemäß den anwendbaren Datenschutzvorschriften berücksichtigt werden. Aus den geäußerten Bedenken geht keine Auskunft über eine Inkompatibilität mit der DSGVO hervor. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird. Weitere Informationen finden Sie unten im Abschnitt „Änderungen als Reaktion auf Feedback“.
Dokumentation	Fordern Sie zusätzliche Beispiele an und aktualisieren Sie vorhandene erklärende Erklärungen.	Die Beispiele in unseren Erklärungen werden gerade überprüft. Bei Bedarf werden sie verdeutlicht oder entfernt.
Teilen von Präferenzen	Vorschlag, Präferenzen für Gruppen derselben Gruppe festzulegen.	Wir freuen uns über Feedback und diskutieren die Idee hier aktiv.
Durchsetzung der Richtlinien	Transparente Durchsetzungsprozesse bergen das Risiko eines Missbrauchs durch böswillige Akteure.	Wir wissen das Feedback zu schätzen und sind aktiv im Austausch mit Stakeholdern auf GitHub (unter Berücksichtigung der Punkte, die in diesem Thema erwähnt wurden, und in anderen Foren berücksichtigen), um dieses Risiko zu bewerten und mögliche Risikominderungen zu ermitteln.
Gemeinsame Eigentumsrechte	Vorschlag für eine maschinenlesbare Erklärung für gemeinsame Eigentumsrechte	Wir freuen uns über Beiträge zu unserem Vorschlag.
Subdomains-Eigentumsrechte	Sollten verschiedene Subdomains mit unterschiedlichen Datenverantwortlichen, unterschiedlichen Datenschutzerklärungen oder verschiedenen Rechtspersönlichkeiten zum selben First-Party-Set gehören?	Basierend auf dem Feedback planen wir, den gängigen Anwendungsfall für eTLD zu entfernen.
Missbrauchsminderung	Bitte um weitere Details zu den Maßnahmen zur Missbrauchsbekämpfung.	Das Verfahren wird derzeit geprüft. Weitere Einzelheiten geben wir in den kommenden Monaten bekannt.
Möglicher Angriffsvektor	Ein irreführendes Set für leicht auffindbare Seiten könnte verwendet werden, um Traffic auf andere Seiten zu lenken, die in betrügerischer Absicht als unabhängig dargestellt werden.	Wir sammeln aktiv Beiträge aus der Öffentlichkeit und suchen nach Möglichkeiten, dieses Problem anzugehen.
Validierung festlegen	Validierung des Satzes über allgemeine Richtlinien, für die eingewilligt wurde	Verschiedene Mitglieder der Community für Webstandards und die allgemeine Plattform haben darauf hingewiesen, dass dies nicht umsetzbar ist.
Domain limit	Anfrage zur Erweiterung der Anzahl verknüpfter Domains.	Wir diskutieren derzeit aktiv über das Domainlimit bei der Framerate und würden uns über Feedback von der Community zur Anzahl der verknüpften Domains freuen, die sie für ihre Anwendungsfälle benötigen.
Interaktion mit Teilmengendienst	Bedenken in Bezug auf den Dienst und die zugehörige Teilmengeninteraktion.	Wir schätzen das Feedback und werden prüfen, ob dies in den zukünftigen Spezifikationen genauer wird.
(Auch im 2. Quartal berichtet) Verbesserter Datenschutz	Zu viele Websites in derselben Gruppe können ähnliche Ergebnisse erzielen wie Drittanbieter-Cookies.	Update im 3. Quartal: Im neuesten Vorschlag wird eine Beschränkung auf drei Domains für die zugehörige Untergruppe vorgeschlagen, die keine ccTLDs und Dienstdomains umfasst. Chrome interagiert aktiv mit der Plattform, um festzustellen, ob dieses Limit angemessen ist.
(Auch im 2. Quartal berichtet) Allgemeine Anforderung der Datenschutzerklärung	Es ist nicht möglich, für alle Produkte und Rechtsprechungen eine gemeinsame Datenschutzerklärung zu verwenden.	Update im 3. Quartal: Eine gemeinsame Datenschutzerklärung ist nicht mehr erforderlich, um zum selben Datenpool gehören zu können.

Fenced Frames-API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Warum ein neues Element anstelle von Attributen in iFrames?	Frage bezüglich des Angebots „Fenced Frame“ anstelle von vorhandenen iFrame-Angeboten.	Wir freuen uns über Ihr Feedback und sind offen für neue Ideen, wie wir den aktuellen Stand der Dinge wie hier beschrieben angleichen können.
Schnittmengenbeobachter in abgegrenzten Frames	Fragen zur Sichtbarkeit von Informationen in einem Fenced Frame	Dies ist eine aktive Diskussion und der Kommentarzeitraum in diesem Dokument und auf GitHub. Wir begrüßen es, wenn Partner Anwendungsfälle mit uns teilen, damit wir besser nachvollziehen können, wie wir Sie unterstützen können.
Videoinventar und natives Inventar unterstützen	Wird für Fenced Frames Videoinventar und natives Inventar unterstützt?	Im Hinblick auf die Videowiedergabefunktionen unterscheiden sich Fenced Frames nicht von iFrames und deshalb wird sie in keiner öffentlichen Dokumentation explizit erwähnt. Sollten Sie Probleme mit Videoanzeigen feststellen, senden Sie uns Feedback, damit wir die Angelegenheit weiter untersuchen können.
Web-Bundles	Wird die Anzeigenbereitstellung und das Rendering durch Websets in Zukunft mit Fenced Frame x FLEDGE eine Anforderung sein?	Das langfristige Ziel ist die Unterstützung von Web Bundles zum Rendern von Anzeigeninhalten in einem abgegrenzten Frame. Die aktuelle Implementierung von FLEDGE unterstützt dies jedoch nicht und erfordert das Rendern einer HTML-Ressource, die aus renderUrl abgerufen wurde.
Asset-Abmessungen	Anfrage für render_url, um ein Makro für die Höhe und Breite der Anzeigenfläche zu unterstützen, damit wir mit einem Creative der passenden Größe antworten können	Dieses Thema wird hier aktiv diskutiert.

Shared Storage API

Feedback-Design	Zusammenfassung	Chrome-Antwort
FLEDGE-Integration	Wie werden freigegebener Speicher und FLEDGE integriert?	Obwohl wir dies derzeit nicht verfolgen, möchten wir diese Idee untersuchen, um die Wahrung des Datenschutzes sicherzustellen. Wir empfehlen interessierte Parteien, Vorschläge für mögliche Anwendungsfälle einzureichen, die dieser Vorschlag im GitHub-Repository für gemeinsam genutzten Speicher oder im GitHub-Repository für FLEDGE unterstützt. .
Datenaufbewahrung	Das Leeren des freigegebenen Speichers reduziert den Nutzen. Wurden als Alternative eine Verlängerung der Aufbewahrungsdauer oder die Möglichkeit zum Löschen einzelner Schlüssel/Wert-Paare in Betracht gezogen?	Wir sind immer auf der Suche nach einem Gleichgewicht zwischen Datenschutz und Nutzen. Wir freuen uns über Feedback zu Anpassungen und empfehlen unseren Partnern, beim Testen des gemeinsamen Speicherplatzes mehr Feedback und Details zu geben.
Negatives Signal	Negatives Signal von Mozilla in Bezug auf den Vorschlag für freigegebenen Speicher.	Wir danken Mozilla für die sorgfältige Prüfung unseres Vorschlags. Wir planen, in naher Zukunft auf ihr Feedback zu reagieren.

CHIPS

Feedback-Design	Zusammenfassung	Chrome-Antwort
Partitionierte Anforderung	Für das Attribut „Partitioniert“ bei eigenen Cookies muss eine explizite Verhaltensanforderung hinzugefügt werden.	Wir haben das in einem Gespräch über die PrivacyCG besprochen und uns auf das GitHub-Problem gewarnt. Wir arbeiten weiterhin mit Browsern, Entwicklern und der Datenschutz-Community zusammen, um uns auf ein bestimmtes Verhalten einigen und es spezifizieren zu können.
Authentifizierte Einbettungen	CHIPS können den aktuellen SSO-Anmeldevorgang aufgrund der unterschiedlichen Partitionierung beeinträchtigen, die sich auf authentifizierte Einbettungen auswirkt.	Der Anwendungsfall für authentifizierte Einbettungen ist uns bekannt und wir arbeiten bereits an Lösungen.
Cookie-Partitionslimit	Bedenken, dass die derzeitige Beschränkung von 10 Cookies für bestimmte Anwendungsfälle möglicherweise nicht ausreicht.	Wir entfernen von der Beschränkung der Anzahl an Cookies auf eine Speicherbeschränkung von 12 KB. So können wir Bedenken hinsichtlich der Cookie-Begrenzung ausräumen und gleichzeitig gewährleisten, dass die Leistung und der Speicherbedarf des Browsers nicht beeinträchtigt werden.
Zeitplan für Ursprungstests	Erweitern Sie UT nach dem Entfernen der Begrenzungsanforderung für Hostnamen.	Aufgrund von Feedback aus der Umgebung haben wir die Frist für den Ursprungstest verlängert.
Testeinschränkungen in Chrome	CHIPS-Testmöglichkeit in Firefox aufgrund aktueller Beschränkungen in Chrome	Die Implementierung in Firefox unterscheidet sich nur geringfügig, Chrome hat eine niedrigere Cookie-Grenze und CHIPS ist ein Opt-in-Mechanismus, aber Firefox ist standardmäßig partitioniert.
(Auch im 2. Quartal berichtet) Authentifizierte Einbettungen	Wird der Anmeldestatus mit CHIPS beibehalten?	Update im 3. Quartal: Der Anmeldestatus wird derzeit nicht beibehalten, ist aber nicht der vorgesehene Anwendungsfall für CHIPS. Der Anwendungsfall für authentifizierte Einbettungen ist uns bekannt und wir arbeiten bereits an Lösungen.

FedCM

Feedback-Design	Zusammenfassung	Chrome-Antwort
(Auch im 2. Quartal berichtet) Potenzielle Angriffsvektoren	Potenzielle Angriffsvektoren durch Linkdekoration und Timing-Angriffe.	Update im 3. Quartal: Wir haben mit Mozilla zusammengearbeitet, um ein gemeinsames Verständnis dafür zu entwickeln, wie das Problem beim Timing-Angriff angegangen werden kann. Die Details dazu finden Sie hier. Wir erstellen nun einen Prototyp für diese architektonische Änderung und planen, in den nächsten Quartalen Tests durchzuführen.
Identitätsanbieter	Kontoauswahl: Einzelner Identitätsanbieter. Anfrage zum Zulassen mehrerer Identitätsanbieter.	Wir haben mit Browseranbietern und der FedID CG zusammengearbeitet, um die Möglichkeit zu schaffen, mehrere Identitätsanbieter zuzulassen, und sind zu einer Formulierung gekommen, die sich lohnen könnte. Eine Beschreibung des Vorschlags finden Sie hier. In den nächsten Quartalen werden voraussichtlich Prototypen entwickelt und Tests durchgeführt.
Bekannte Probleme mit Föderation	Anfrage zur Aufzählung von Fällen, in denen bei der Föderation Probleme mit der Einstellung von Drittanbieter-Cookies auftreten können.	Die FedID-CG hat ein Arbeitselement, mit dem hier und hier aufgezählt wird, wie die Föderation aufbregt. Das Unternehmen erstellt außerdem eine Entscheidungsmatrix, um Fehler bei Web Platform APIs abzubilden.
Nounce parameter	Könnte der Parameter „Nounce“ sich auf den Anmeldevorgang auswirken?	Dies kann als websiteübergreifendes Tracking betrachtet werden, aber wir sammeln noch Informationen und analysieren, wie solche Fälle zu behandeln sind.
Nutzereinwilligung	Verknüpfung verschiedener vertrauender Parteien (RPs) und Nutzereinwilligung für jeden Ursprung.	Mit dieser Spezifikation kann nicht gesteuert werden, wie Quellen innerhalb derselben Domain Cookies gemeinsam nutzen. Die Spezifikation lässt das IDtoken vom IdP-Ursprung zum RP-Ursprung zu. Es liegt jedoch an der RP, zu entscheiden, ob der Anmeldestatus des Nutzers in einem Cookie gespeichert werden soll, das an diesen einzelnen Ursprung gesperrt ist, oder in einem Cookie, das für Ursprünge innerhalb derselben Domain freigegeben ist.
IdP-Konto Übertragbarkeit	Nutzeroption, IdPs zu migrieren, wenn sie sich für die Übertragung zwischen zwei IdPs entscheiden	Das scheint etwas zu tun, das der Nutzer direkt auf der Anmeldeseite seines neuen IdPs tun müsste, nicht über die FedCM API.
Konto löschen	IdP-Widerruf für die Kontolöschung beim IdP	Für diese Funktionsanfrage können wir jetzt Feedback geben und sie wird derzeit geprüft.
UI-Anspruch	Behauptungen über browserspezifische Aspekte der Benutzeroberfläche	Weitere Informationen hierzu finden Sie unter Pull-Anfrage.
Prüfung auf IdP-Empfehlung	Der IdP prüft die Referrer-URL von RP.	Der Spezifikation wurde eine obligatorische Prüfung der IdP-Verweis-URLs hinzugefügt. Siehe Pull-Anfrage.
Anmeldung	Anfrage für eine Anpassung der Anmeldevorgänge an die RP-Einstellungen.	Wir freuen uns über Ihre Idee und besprechen intensiv.

Spam und Betrug bekämpfen

Trust Tokens API

Feedback-Design	Zusammenfassung	Chrome-Antwort
Betrug und Missbrauch	Tools, um sicherzustellen, dass ein Bot einen Aussteller nicht dazu verleitet hat, ihm ein Token zu geben, dass ein Bot kein Token übernommen hat, das einem echten Nutzer ausgestellt wurde, und um zu verhindern, dass Bots schädliche Tokens ausgeben?	Bots können zwar Tokens von einem Aussteller erhalten, Aussteller werden jedoch dazu angehalten, die Häufigkeit von Tokens und robusten Methoden für die Ausstellung von Tokens und die Aktualisierung ihrer Ausstellungslogik einzuschränken, wenn böswillige Akteure versuchen, sie zu umgehen. Aussteller ohne eine ausreichende Logik für die Ausgabe von Tokens werden im System wahrscheinlich weniger vertrauenswürdig sein, da Websites auf zuverlässigere Aussteller setzen.
Betrug und Missbrauch	Gibt es eine Möglichkeit für den Einlösen von Trust Tokens, anzugeben, dass er nur Trust Tokens von bestimmten Entitäten akzeptiert?	Ja, das ist möglich. Die Funktionsweise wird im Abschnitt Einlösung von Trust Tokens beschrieben.
Betrug und Missbrauch	Gibt es eine Möglichkeit für den Aussteller von Trust Tokens, eine Liste der Einlösungsstellen zu erstellen und anderen das Einlösen von Tokens nicht zu gestatten?	Derzeit nicht, aber das Team untersucht diesen Anwendungsfall.
Zeitplan	Wann wird die Trust Token API allgemein verfügbar sein?	Sobald wir einen genauen Zeitplan festlegen können, werden wir weitere Informationen öffentlich bekannt geben.
(Auch im 2. Quartal berichtet) Wartungsaufwand	Es ist nicht klar, wie lange Protokollversionen unterstützt werden.	Update im 3. Quartal: In den APIs wird zusätzlicher Support für mehrere gleichzeitige Versionen hinzugefügt, um einen reibungslosen Übergang zwischen Versionen zu ermöglichen. Die Fristen für den Support bzw. die Einstellung befinden sich jedoch noch in der Entwicklung.