Feedbackbericht – 2. Quartal 2023

Quartalsbericht für das 2. Quartal 2023 mit einer Zusammenfassung des Feedbacks zum Privacy Sandbox-Vorschlag und zur Antwort von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google verpflichtet, vierteljährlich öffentliche Berichte zum Prozess der Stakeholder-Beteiligung an seinen Privacy Sandbox-Vorschlägen zu veröffentlichen (siehe Paragraf 12 und Paragraf 17(c)(ii) der Verpflichtungen). Für die Feedbackberichte werden die Rückmeldungen aggregiert, die das Chrome-Team aus den verschiedenen Quellen erhält, die in der Feedbackübersicht aufgeführt sind, darunter: GitHub-Probleme, das Feedbackformular, das unter privacysandbox.com verfügbar ist, Besprechungen mit Branchenvertretern und Foren für Webstandards. Wir freuen uns über das Feedback, das wir aus der Community erhalten haben, und suchen aktiv nach Möglichkeiten, die Erkenntnisse in Designentscheidungen einfließen zu lassen.

Feedbackthemen werden nach Häufigkeit pro API sortiert. Dazu wird die Menge des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, zusammengefasst und in absteigender Reihenfolge nach Menge sortiert. Die häufigsten Feedbackthemen wurden anhand von Diskussionsthemen aus öffentlichen Treffen (W3C, PatCG, IETF), direktem Feedback, GitHub und häufig gestellten Fragen identifiziert, die über die internen Teams von Google und öffentliche Formulare aufkamen.

Insbesondere wurden die Protokolle der Sitzungen von Webstandards-Organisationen überprüft. Für direktes Feedback wurden die Aufzeichnungen von persönlichen Stakeholder-Sitzungen von Google, E-Mails, die von einzelnen Entwicklern empfangen wurden, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Google koordinierte dann die an diesen verschiedenen Outreach-Aktivitäten beteiligten Teams, um die relative Verbreitung der Themen in Bezug auf die einzelnen APIs zu ermitteln.

Die Erläuterungen zu den Antworten von Chrome auf Feedback wurden anhand veröffentlichter FAQs, tatsächlicher Antworten auf von Stakeholdern angesprochene Probleme und einer speziell für diese öffentliche Berichterstattung festgelegten Position entwickelt. Entsprechend dem aktuellen Schwerpunkt der Entwicklung und Tests haben wir vor allem Fragen und Feedback zu den APIs Topics, Protected Audience und Attribution Reporting erhalten.

Für Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingegangen ist, wurde möglicherweise noch keine Chrome-Antwort berücksichtigt.

CHIPS
Cookies mit unabhängigem partitionierten 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
NSZ
Origin-Testversion
PatCG
Private Advertising Technology Community Group
RP
Vertrauende 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
Willful IP Blindness

Allgemeines Feedback, keine bestimmte API/Technologie

Feedbackthema Zusammenfassung Chrome-Antwort
Data Governance und rechtliche Compliance Leitfäden für die Branche zur Verwendung der Privacy Sandbox unter Einhaltung der rechtlichen Bestimmungen Wie bei jeder neuen Technologie ist jedes Unternehmen dafür verantwortlich, dass die Nutzung der Privacy Sandbox gesetzeskonform ist. Google kann anderen keine Rechtsberatung anbieten. Wir sind uns jedoch bewusst, dass dies ein wichtiger Bereich für das Ökosystem ist. Für jede API haben wir umfangreiche technische Dokumentationen veröffentlicht, die die Grundlage für die erforderlichen rechtlichen Bewertungen bilden sollten. Wir arbeiten daran, zusätzliche Materialien zur Verfügung zu stellen, die Unternehmen bei der Einhaltung der behördlichen Anforderungen unterstützen.
Vorschlag für quantitative Tests für die CMA Weitere Informationen zum quantitativen Testvorschlag der CMA Wir arbeiten mit der CMA zusammen, um Tests zu entwickeln, die Aufschluss über die Auswirkungen der Einstellung von Drittanbieter-Cookies und der Einführung der Privacy Sandbox-Vorschläge auf das Werbe-Ökosystem geben. Im April veröffentlichte die CMA allgemeine Informationen dazu, was während des Testzeitraums zu erwarten ist. Im Juni folgte eine detaillierte Anleitung. Wir empfehlen Ihnen, Fragen oder Feedback zum Vorschlag der CMA zu quantitativen Tests direkt an die CMA zu richten.
Von Chrome unterstützte Testmodi Weitere Informationen und Erläuterungen zu den Testzeitplänen Am 18. Mai haben wir einen Blogpost veröffentlicht, in dem weitere Informationen zu den beiden Modi für von Chrome unterstützte Tests enthalten sind. Diese Details sind noch nicht endgültig. Im Laufe des 3. Quartals 2023 veröffentlichen wir weitere Informationen zur Implementierung.
Partitionierter Speicher Wird bei Chrome-gestützten Tests partitionierter Speicher verwendet? Die Speicherpartitionierung wird vor dem Test zur Einstellung von Drittanbieter-Cookies für alle Nutzer eingeführt. Daher wird sie für alle Verzweigungen des Tests aktiviert. Websites haben während dieser Zeit die Möglichkeit, einen Testlauf zur Einstellung zu aktivieren, um nicht partitionierten Speicherplatz zurückzugewinnen.
Produktionssupport Wie werden technische Probleme und Eskalierungen im Zusammenhang mit der Privacy Sandbox in Chrome unterstützt? Google bietet verschiedene Kanäle, über die Anzeigenfachleute Probleme melden und erforderliche Eskalierungen ermöglichen können.
Weitere Informationen zu den öffentlichen und privaten Foren für Feedback und Eskalierung finden Sie in unserer Feedbackübersicht.
Zeitplan für die Registrierung Der aktuelle Zeitraum für die Registrierung ist zu kurz. Wir prüfen derzeit den Termin für die Durchsetzung und würden uns gerne von Ihnen darüber informieren lassen, welcher Zeitplan besser geeignet wäre.
D-U-N-S-Nummer Weitere Informationen zur D-U-N-S-Nummer für die Registrierung und Zertifizierung Die Anforderungen für den Erhalt einer D-U-N-S-Nummer finden Teilnehmer auf der Website von Dun & Bradstreet. Die Anforderungen variieren je nach Markt. Teilnehmer sollten daher die Website des Marktes, an dem sie interessiert sind, besuchen. Im Allgemeinen müssen Teilnehmer jedoch grundlegende Informationen zu ihrem Unternehmen angeben, z. B. den Namen des Unternehmens, die Adresse und die Kontaktdaten des Inhabers oder Managers. Die Teilnehmer werden möglicherweise auch aufgefordert, Finanzinformationen anzugeben, z. B. den Jahresumsatz des Unternehmens. Sobald der Antrag vollständig ist, wird er von D&B geprüft und eine D-U-N-S-Nummer ausgestellt, wenn der Antrag genehmigt wird.
Von der Ursprungstestphase zur allgemeinen Verfügbarkeit Hat die Umstellung von Origin-Tests auf die allgemeine Verfügbarkeit Auswirkungen auf aktuelle Origin-Tester? Ab Juli können Tester allgemein auf die Relevanz- und Mess-APIs zugreifen. Dadurch gibt es eine Überschneidung zwischen der Verfügbarkeit der Testversion und der allgemeinen Verfügbarkeit.
AdExchanger-Studie Weitere Informationen zur Umfragemethodik Die Befragten wurden gebeten, die Synchronisierungsraten und den Umsatz für ihre Unternehmen zu schätzen. Die Methode, mit der die Teilnehmer ihre individuellen Fragen beantworteten, war ihnen selbst überlassen.
Parameterwerte Wie werden Parameterwerte wie Geräuschpegel, Anonymitätsgrenzwerte und Datenschutzbudget bestimmt? In dieser GitHub-Erläuterung werden die allgemeineren Prinzipien der Privacy Sandbox APIs beschrieben. Viele Werte werden noch finalisiert und wir freuen uns über Feedback zu diesem Thema.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema Zusammenfassung Chrome-Antwort
Datenschutz Studien zur Datenschutzfreundlichkeit der Topics API Wir sind aktiv in der Forschungscommunity und präsentieren unsere Forschung zu den Datenschutzeigenschaften der Topics API in Artikeln, Berichten und Workshoppräsentationen. Wir freuen uns, dass sich immer mehr externe Mitglieder der Forschungscommunity mit diesem Thema beschäftigen.

Die Topics API schützt Nutzer vor allgemeinem Tracking im Web, da es zu aufwendig wird, Nutzer in großem Umfang zu tracken. Diese Studien zeigen, dass wir dies mit der Topics API erfolgreich tun. Topics ist datenschutzfreundlicher als Drittanbieter-Cookies und schützt die Nutzer, während die von ihnen besuchten Websites unterstützt werden.
Die Thementaxonomie ist nicht detailliert genug Die Taxonomie für allgemeine Themen umfasst keine detaillierteren Themen, einschließlich regionaler. Als Reaktion auf vorheriges Feedback aus dem Werbesystem haben wir am 15. Juni einen Blogpost veröffentlicht, in dem eine neue aktualisierte Taxonomie beschrieben wird, die zahlreiche Verbesserungen auf Grundlage des Feedbacks aus dem Werbesystem enthält. Im Rahmen unserer Arbeit an der überarbeiteten Taxonomie haben wir mit mehreren Unternehmen aus dem gesamten Werbesystem zusammengearbeitet, darunter Raptive (früher CafeMedia) und Criteo. In der aktualisierten Taxonomie wurden Kategorien entfernt, die unserer Meinung nach weniger nützlich sind, und durch Kategorien ersetzt, die besser zu den Interessen von Werbetreibenden passen. Wir behalten uns jedoch vor, potenziell sensible Themen weiterhin auszuschließen.

Wir empfehlen allen Nutzern, die neueste Taxonomie zu prüfen und Feedback zu den Änderungen zu geben.
Aktualisierung von Taxonomie und Klassifikator Weitere Informationen zur Taxonomie und zum Release-Zyklus von Topics-Klassifikatoren sowie dazu, wie sich Unternehmen auf solche Updates vorbereiten können. Wie in unserem aktuellen Blogpost erwähnt, gehen wir davon aus, dass sich die Taxonomie im Laufe der Zeit weiterentwickeln wird und die Verwaltung der Taxonomie schließlich an eine externe Partei übertragen wird, die Stakeholder aus der gesamten Branche vertritt. Wir haben den Plan zur Einführung auch in der Gruppe topics-announce geteilt.
Auswirkungen auf Signale mit selbst erhobenen Daten Die Erhöhung der Anzahl der Themen bei der letzten Aktualisierung der Taxonomie kann sehr wertvoll sein und andere interessebasierte Signale aus selbst erhobenen Daten dadurch entwerten. Im Bericht zu Q1 2023 gab die CMA an: „Uns ist bekannt, dass Google seine vorgeschlagene neue Taxonomie mit mehreren Marktteilnehmern in der gesamten AdTech-Lieferkette besprochen hat. Einige große Publisher haben angegeben, dass eine größere Nützlichkeit von Themen den Wettbewerbsdruck auf ihre Lösungen auf der Grundlage selbst erhobener Daten erhöhen würde. Unsere vorläufige Einschätzung ist jedoch, dass eine größere Nützlichkeit insgesamt für den Wettbewerb besser ist – insbesondere für die Fähigkeit kleinerer Publisher, ihr Inventar nach der Einstellung von Drittanbieter-Cookies weiter zu monetarisieren.“ Unserer Meinung nach stimmt dieser Kommentar der CMA mit unserer überein.
Nützlichkeit für verschiedene Arten von Stakeholdern Anbieter von Anzeigentechnologien, die als SSPs und DSPs fungieren, können erhebliche Vorteile gegenüber anderen Akteuren im Werbesystem haben. Unsere Antwort hat sich gegenüber den vorherigen Quartalen nicht geändert:

„Google hat sich gegenüber der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu entwerfen und umzusetzen, dass der Wettbewerb nicht durch eine Bevorzugung des eigenen Geschäfts von Google verzerrt wird. Außerdem werden die Auswirkungen auf den Wettbewerb in der digitalen Werbung sowie auf Publisher und Werbetreibende unabhängig von ihrer Größe berücksichtigt. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen entspricht. Im Laufe der Tests der Privacy Sandbox werden wir unter anderem prüfen, wie sich die neuen Technologien für verschiedene Arten von Stakeholdern schlagen. Feedback ist in dieser Hinsicht entscheidend, insbesondere spezifisches und umsetzbares Feedback, das uns dabei helfen kann, die technischen Designs weiter zu verbessern. Wir haben mit der CMA zusammengearbeitet, um unseren Ansatz für quantitative Tests zu entwickeln. Wir unterstützen die CMA bei der Veröffentlichung einer Mitteilung zum Testdesign, um Marktteilnehmern mehr Informationen zur Verfügung zu stellen und ihnen die Möglichkeit zu geben, sich zu den vorgeschlagenen Ansätzen zu äußern.“
Abgeleitete Themen Führt die Segmentfragmentierung dazu, dass untergeordnete Themen nie an die Spitze kommen, wenn die Häufigkeit von Browseraufrufen als Auswahlkriterium für Themen verwendet wird? In Chrome werden derzeit andere Rankingmethoden evaluiert und andere Signale untersucht, die das Ranking verbessern könnten. Wir werden das Ökosystem rechtzeitig über unsere überarbeiteten Pläne informieren.
Vertraulichkeit Ziel der Topics API sollte es sein, dafür zu sorgen, dass Nutzerinformationen, die über die Topics API abgerufen oder abgeleitet werden, weniger personenidentifizierbar sind als das, was mit den heutigen Tracking-Methoden abgeleitet werden könnte. Wir sind der Meinung, dass die Topics API deutlich datenschutzfreundlicher ist als aktuelle Technologien, die erneute Identifizierung von Nutzern deutlich einschränkt und sensible Themen ausschließt. Wir sind uns bewusst, dass Themen mit selbst erhobenen Daten in Beziehung gesetzt oder kombiniert werden können, um sensible Kategorien zu erstellen. Wir sind jedoch der Meinung, dass die Topics API ein Schritt in Richtung mehr Datenschutz für Nutzer ist. Wir werden die API daher kontinuierlich verbessern.
Taxonomiestruktur ID, Versionierung und andere Metadatenstruktur zur Topics-Taxonomie hinzufügen Derzeit wird in der API-Antwort die Taxonomie-ID enthalten. Da wir uns auf eine langfristige Verwaltung zubewegen, ist es sinnvoll, das Topics-Objekt zu überprüfen und bei Bedarf zusätzliche Metadaten zur Versionierung hinzuzufügen.
Steuerelemente für Publisher Publisher sollten mitbestimmen können, unter welchen Themen ihre Websites klassifiziert werden. Eine falsche Klassifizierung von Websites kann das Topics-Signal insgesamt etwas weniger nützlich machen. Die fälschlicherweise klassifizierten Websites sind davon aber nicht mehr oder weniger betroffen als andere Websites. Das liegt daran, dass die Kontextinformationen einer Website immer für Auktionen auf der Website verfügbar sind. So können auch bei einer Falschklassifizierung vergleichbare Informationen zum richtigen Thema bereitgestellt werden. Hier können Sie uns Feedback zu diesem Thema geben.

Wenn Verlage und Webpublisher ihre Klassifizierung selbst steuern können, birgt das Risiken. Websites können ihre Websites absichtlich falsch klassifizieren, was die Nutzung für alle Nutzer einschränkt, oder vertrauliche Inhalte in weniger gängigen Themen codieren, was den Datenschutz der Nutzer beeinträchtigt.
Chrome-Erweiterungen Chrome-Erweiterungen erlauben, Themen zu verwalten und zu filtern, ähnlich wie bei aktuellen Erweiterungen zur Cookie-Verwaltung Das sollte bereits möglich sein, wie auf GitHub erläutert. Wir freuen uns aber über zusätzliches Feedback aus der Community.
Umstellung auf allgemeine Verfügbarkeit Hat die Umstellung von Ursprungstests auf die allgemeine Verfügbarkeit Auswirkungen auf die Topics API? Für Nutzer, die von der Origin-Testversion zur allgemeinen Verfügbarkeit wechseln, gehen keine Daten verloren.
Datenschutz Hostnamen können private Informationen enthalten, die von der Topics API offengelegt werden können. Wir haben eine Reihe von Maßnahmen ergriffen, um die Privatsphäre zu schützen, wie hier beschrieben.
Betrug und Missbrauch Manipulation von Themen durch betrügerische Zugriffe verhindern Hier finden Sie weitere Informationen zu Abhilfemaßnahmen.
Themenklassifikator Können Websiteinhaber die Klassifizierung ihrer Website ändern lassen? Wir sind gespannt auf Ihre Meinung zu diesem Thema und freuen uns über Ihr Feedback.
Websites von Anbietern von Topics Bestimmte Websites, auf denen Inhalte zu vielen Themen gehostet werden, als „Websites von Anbietern mit speziellen Themen“ kennzeichnen und Klassifikatoren anhand der Tags auf den Webseiten trainieren. Hier diskutieren wir den Vorschlag und freuen uns über zusätzliches Feedback.

Protected Audience API (früher FLEDGE)

Feedbackthema Zusammenfassung Chrome-Antwort
Anpassung an Traffic Leistungsauswirkungen der SSP-gestützten Filterung zur Optimierung der Last von Abfragen pro Sekunde (Queries per Second, QPS) Wir haben uns intensiv mit der Verkehrssteuerung beschäftigt und empfehlen SSPs, Caching zu nutzen.
Testvolumen Es ist schwierig, Protected Audience zu testen, da SSPs und DSPs Schwierigkeiten haben, große Trafficvolumina zu erzielen. Wir arbeiten ständig mit SSP- und DSP-Partnern zusammen, um geschützte Zielgruppen einzuführen und zu testen. Die allgemeine Verfügbarkeit hat begonnen und wir sind zuversichtlich, dass der Prozentsatz der Zugriffe mit aktivierter PA für Partner attraktiver wird.
Komplexität Die Implementierung von Protected Audience-Lösungen erfordert erheblichen Aufwand und Kosten. Wir sind uns bewusst, dass die Einführung neuer Technologien, einschließlich der Privacy Sandbox, schwierig ist. Das Privacy Sandbox-Team arbeitet eng mit einer Vielzahl von Stakeholdern zusammen, um sie zu informieren und bei ihren Bemühungen zu unterstützen. Außerdem werden kontinuierlich weitere Beschleuniger zur Unterstützung der Einführung im Ökosystem geprüft.
Vertrauenswürdige Ausführungsumgebungen Unterstützung für vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) in nicht öffentlichen Cloud-Umgebungen Wir prüfen zwar, ob wir auch andere Optionen als cloudbasierte Lösungen unterstützen können, aber derzeit ist es aufgrund der Sicherheitseinschränkungen von On-Premise-Lösungen nicht möglich, On-Premise-TEEs zu unterstützen. Dies würde eine zeitaufwendige Bewertung für die Privacy Sandbox erfordern. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der erheblichen Herausforderungen, die On-Premise-Implementierungen mit sich bringen, sind wir der Ansicht, dass die Cloud-basierten Implementierungen weiter ausgebaut und verbessert werden sollten (z.B. Unterstützung von GCP zusätzlich zu AWS). Wir freuen uns jedoch über zusätzliches Feedback dazu, warum eine solche Anforderung notwendig ist.
Kostenstruktur Der Vorschlag für Gebots- und Auktionsdienste erhöht die Kosten und Komplexität für Ad Techs im Vergleich zu clientseitigen Modellen. Wir entwickeln derzeit einen Leitfaden zur Schätzung der Kosten für die Unterstützung von Gebots- und Auktionsabläufen auf dem Bidding & Auction-Server. Diese Kosten werden mit der Nutzung von Anzeigentechnologien in Beziehung gesetzt, um eines der Ziele unserer Designs zu erreichen.
K-Anon-Zeitleisten Wann werden die geplanten Einschränkungen für die k-Anonymität für „renderUrl“ erzwungen? Wir arbeiten an einer Erläuterung der Zeitleiste für die Durchsetzung, die wir bald veröffentlichen werden.
Einschränkungen für runAdAuction Kann Chrome runAdAuction so einschränken, dass es nur über die Startseite aufgerufen werden kann? Unser Design unterstützt zwar vollständig, dass runAdAuction von der Startseite aus aufgerufen werden kann, wir sind jedoch der Meinung, dass es für Publisher schädlicher wäre, wenn es nur von der obersten Domain aus aufgerufen werden kann.

Wir haben von der Branche insbesondere gehört, dass die Privacy Sandbox die Belastung für Publisher und Werbetreibende minimieren muss. Dieses Feedback entspricht dem allgemeinen Prinzip der Webentwicklung, dass Websiteinhaber Tools von Drittanbietern zur Verwaltung ihrer Websites verwenden können. Ziel der Privacy Sandbox ist es, ein gesundes Werbesystem zu fördern, ohne vorschreiben zu müssen, wie Publisher und Anzeigentechnologien funktionieren.

Indem wir Publishern die Möglichkeit geben, zu entscheiden, wie und wer runAdAuction auf ihrer Website aufruft, bieten wir ihnen Flexibilität, den für ihre Anforderungen am besten geeigneten Weg zu finden.
Unterstützung bei der Implementierung Kann Chrome eine Open-Source-Implementierung von Auktionen mit mehreren Verkäufern erstellen oder dazu beitragen? Ziel der Privacy Sandbox ist es, datenschutzfreundliche Technologien zu entwickeln, die nicht auf Drittanbieter-Cookies oder anderen websiteübergreifenden Kennungen basieren. Wir möchten eine solide Plattform für digitale Werbung bieten,

In unserem GitHub-Repository haben wir eine Anleitung zur Funktionsweise der APIs veröffentlicht. Wir sind offen für Lösungen, die gemeinsam mit der Branche entwickelt werden.

Wir planen keine bestimmte Implementierung, da es unsere Hauptaufgabe ist, Plattformtechnologien zu entwickeln und nicht Strategien für die Verwendung dieser Technologien vorzuschreiben. Mit unseren Technologien können Anbieter von Anzeigentechnologien ihre Kunden bestmöglich bedienen und dabei die Datenschutzanforderungen für Verbraucher erfüllen.
Mehrfachkundenauktionen Wird Chrome den Austausch eines „kontextbezogenen“ Gewinners mit Komponentenauktionen erzwingen? Die Protected Audience API soll es den Parteien ermöglichen, die die Auktion mit mehreren Verkäufern initiieren, Informationen an die Komponentenauktion weiterzugeben (Hinweis: nur vor Beginn der Auktion).

Wir sehen jedoch keine Möglichkeit für den Browser, zu unterscheiden, ob eine Information ein kontextuell relevantes Element ist oder nicht. Daher können wir das Blockieren oder Erforderlichmachen bestimmter Informationen nicht erzwingen.
Nutzereinstellung für das Tracking mit Einwilligung Adtech-Anfrage an die Partner-Abteilung, wie die Nutzereinwilligung korrekt erfasst werden kann Unsere Antwort enthält auch das, was wir in Frage 1 gesagt haben:
„Bei bestimmten Anzeigen ist der relevante AdTech-Anbieter am besten in der Lage, Einstellungen dafür vorzunehmen, welche Creatives ausgeliefert oder wie sie ausgewählt werden.“

Wir haben während des WICG-Treffens zum Thema „Protected Audience“ im Mai eine Reihe von Szenarien im Zusammenhang mit diesem Problem besprochen. Wir freuen uns über zusätzliches Feedback und Diskussionen zu diesem Thema.
Benutzerdefinierte Zielgruppen Werden Anwendungsfälle für SSPs im Zusammenhang mit dem Erstellen benutzerdefinierter Zielgruppen von der Protected Audience API unterstützt? Mit der Protected Audience API können SSPs und andere Anbieter von Anzeigentechnologien benutzerdefinierte Zielgruppen erstellen und verwalten. Weitere Informationen dazu, wie eine SSP in die PA API eingebunden werden kann, werden derzeit entwickelt und für SSPs und andere Anbieter von Anzeigentechnologien zur Verfügung gestellt.
Formate Wird Video von der Protected Audience API unterstützt? Videoanzeigen werden auf zwei Arten ausgeliefert: als VAST-XML oder HTML (eine Out-Stream-Anzeige, die letztendlich auch VAST-XML in einen Videoplayer laden kann). Käufer können beide Formate über eine Render-URL zurückgeben. Die VAST-Spezifikation wurde vor Kurzem aktualisiert, um die Attribution Reporting API zu unterstützen. Betreiber von Websites, auf denen Videoanzeigen ausgeliefert werden, müssen sich auf die Auslieferung von Anzeigen über die Protected Audience API vorbereiten. Das bedeutet, dass Placement-Tags die URL aus einem Protected Audience-Frame an einen Videoplayer übergeben können. Wir arbeiten daran, die Anforderungen an Videos mit abgegrenzten Frames zu erfüllen, bevor sie frühestens 2026 eingeführt werden.
Taktung Wie funktioniert der Anwendungsfall für die Auslieferungssteuerung mit der Protected Audience API? Vielen Dank für dein Feedback. Wir würden uns freuen, wenn wir von mehr SSP-Partnern mehr Anfragen mit weiteren Details erhalten würden, da dies bisher hauptsächlich ein Problem für DSPs war.
Aktualisierungshäufigkeit Die Häufigkeit der Aufrufe von dailyUpdate (bis zu 1 pro Interessengruppe und Tag) reicht für bestimmte Anwendungsfälle möglicherweise nicht aus, z. B. für die Aktualisierung von Produktinformationen. Vielen Dank für dein Feedback. Es gibt andere Lösungen, mit denen Anbieter von Anzeigentechnologien Signale verwenden können, die in unterschiedlichen Abständen aktualisiert werden, z. B. K/V-Suchanfragen.
Qualitätskontrolle von Anzeigen Wie implementieren Publisher die Qualitätskontrolle für Anzeigen? Derzeit bietet die Protected Audience API Funktionen, mit denen Publisher ihre SSPs über bestimmte Einstellungen informieren können, die sie im Rahmen der Auktionskonfiguration vor dem Gebotsabgabeprozess festlegen können (d.h. Sperrlisten basierend auf Labels, die mit Anzeigen verknüpft sind). Wir freuen uns über Feedback zu zusätzlichen Funktionen, die das System möglicherweise benötigt.
Debugging Wann wird die Funktion forDebuggingOnly entfernt? Wir planen, forDebuggingOnly für Ereignisse vom Typ „Verlust“ einzustellen, sobald Drittanbieter-Cookies eingestellt werden. Wir planen, forDebuggingOnly für Ereignisse vom Typ „Gewinn“ frühestens 2026 einzustellen.
Geräteübergreifende Interessengruppen Vorschlag zur Aktivierung geräteübergreifender Interessengruppen für authentifizierte User-Agents Wir prüfen diesen Vorschlag, aber die hohe Spezifität des geräteübergreifenden Targetings wirft erhebliche Datenschutzbedenken auf, wie in diesem GitHub-Problem erläutert.
(Auch im 1. Quartal erfasst) Dynamisches Remarketing Ist dynamisches Remarketing nach der Einstellung von Drittanbieter-Cookies weiterhin mit der Protected Audience API möglich? Wir sind der Meinung, dass dieser Anwendungsfall mit Protected Audience möglich ist, wie hier erläutert.
Auf „Ähnliche Daten“ klicken Klickbezogene Daten zu browserSignals. hinzufügen Wir bitten um Klärung, wann der Klick erfolgt ist, damit wir eine vorläufige Position angeben können.
(Auch im 4. Quartal 2022 gemeldet) Benutzerdefinierte Funktionen in Protected Audience Wie werden benutzerdefinierte Funktionen (UDFs) in der Protected Audience API unterstützt? Dies sind Funktionen, die von Endnutzern programmiert werden können, um die Funktionalität der API zu erweitern. Der Anbieter von Anzeigentechnologien, der dieses Problem gemeldet hat, prüft noch, was er mit UDFs tun kann. Es gibt also noch kein umsetzbares Feedback, auf das wir reagieren können – zumindest nicht vor der allgemeinen Verfügbarkeit.
Währung Währungsbeträge dürfen nicht als Gleitkommazahlen dargestellt werden. Hier finden Sie weitere Informationen zu diesem Thema.
Anzeigenauswahl außerhalb der DSP Welche Rolle spielen Ad-Server in Protected Audience API-Auktionen? Uns ist bekannt, dass Ad-Server weiterhin Dienste zur Anzeigenauswahl nach der Gebotsabgabe und zur dynamischen Creative-Optimierung anbieten sollen. Wir führen derzeit eine detaillierte Lückenanalyse zwischen der aktuellen Protected Audience API und diesen Anforderungen durch.
GenerateBid Unterstützung für den Google Ads-Vorschlag, ab generateBid mehr als eine Anzeigenvorlage pro Anzeigeninteressegruppe zurückzugeben und diese Kandidaten in „scoreAd“ zu bewerten. Dies wird derzeit geprüft. Hier können Sie uns zusätzliches Feedback geben.
Auktionsauftrag Müssen Protected Audience API-Auktionen die letzten sein, die ausgeführt werden, damit sie das Ergebnis aller anderen Auktionen berücksichtigen können? Es gibt keine technische Anforderung, dass die Protected Audience API zuletzt ausgeführt werden muss.
Nicht vom Nutzer initiierte Navigation Nicht vom Nutzer initiierte Navigation anzeigen Wir prüfen diesen Antrag und besprechen ihn hier . Wir freuen uns über zusätzliches Feedback.
Caching Die SSP darf die perBuyerSignals einer bestimmten DSP nicht aus einem Cache erstellen, wenn sich der Nutzerstatus ändert. Uns ist bewusst, dass das Caching nicht für jeden Anwendungsfall von perBuyer-Signalen funktioniert. Wir prüfen derzeit weitere Optionen. Wir freuen uns über zusätzliches Feedback aus der Community dazu, ob Caching für ihre Anwendungsfälle geeignet wäre.
Attributionsberichte und Protected Audience Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? Integrationen für die Protected Audience API sind derzeit für beide Modi der Attribution Reporting API verfügbar (Berichte auf Ereignisebene und Zusammenfassungsberichte). Am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung der Protected Audience API und der Attribution Reporting API veröffentlicht. Weitere Informationen dazu finden Sie hier.
Serverendpunkt Ist der Serverendpunkt im Enddesign der Trusted Aggregation Server? Der Serverendpunkt ist ein von der Anzeigentechnologie verwalteter Endpunkt, der unabhängig von den vertrauenswürdigen Aggregationsservern ist, die für die Verarbeitung der erfassten und transformierten Berichte verwendet werden. Derzeit sind keine Änderungen am Berichtsendpunkt geplant. Das aktuelle Design soll dafür sorgen, dass die aggregierten Berichte selbst (mit verschlüsselten Nutzlasten) keine websiteübergreifenden Daten preisgeben. Ein vertrauenswürdiger Endpunkt sollte also nicht erforderlich sein. Eine weitere Komplikation ist, dass für verschiedene Anzeigentechnologien wahrscheinlich unterschiedliche Batching-Strategien erforderlich sind. Hier können Sie uns zusätzliches Feedback geben.
WebIDL Die aktuelle Protected Audience API-Spezifikation ist nicht mit der WebIDL-Spezifikation kompatibel. Wir prüfen dieses Feedback und besprechen das Problem hier.
Einwilligungsverwaltung Wie wird die Weitergabe von Einwilligungssignalen in der Protected Audience API verarbeitet? Kontextinformationen fallen nicht in den Geltungsbereich der Protected Audience API. Wir besprechen dieses Problem und freuen uns über zusätzliches Feedback.
Kontobasiertes Marketing Wären Anwendungsfälle für akzentuiertes Marketing möglich? Die Protected Audience API unterstützt eine Vielzahl von Anwendungsfällen für Zielgruppenmarketing. Wir arbeiten weiter daran, herauszufinden, wie die Protected Audience API diesen Anwendungsfall am besten unterstützen kann. Wir freuen uns über zusätzliches Feedback zu diesem Thema.
Komponentenauktion Was erhalten Teilnehmer an Komponentenauktionen? Bei den Komponentenauktionen werden keine Interessengruppen direkt bewertet, sondern die Anzeigen und Gebote, die eine DSP über die Funktion generateBid einreicht. Die Funktion generateBid() wird pro Interessengruppe ausgeführt. Die DSP gibt bei der Ausführung von „generateBid“ Folgendes zurück: 

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

Externe Beiträge Unterstützung externer Beiträge zur GitHub-Codebasis des Key/Value-Servers anfordern Wir arbeiten daran, unsere relevanten Prozesse zu aktualisieren, um externe Beiträge zum GitHub-Code zu unterstützen.
Größe der Interessengruppe Wie viele Schlüssel werden maximal von der IG unterstützt? Die aktuelle Obergrenze für die Größe einer IG beträgt 50 KB. Schlüssel werden dabei mitgezählt. Wir freuen uns auf weitere Diskussionen zur Größenbeschränkung.
Batching Wie kann die Anzahl der K/V-Serveraufrufe reduziert werden? Mit HTTP-Cache-Control-Headern können Sie die Anzahl der K/V-Aufrufe reduzieren. Sie können beispielsweise für Komponentenauktionen und Anzeigenflächen auf einer einzelnen Seite im Cache gespeichert werden.
Versionsverwaltung Unterstützung mehrerer Versionen von AdTech-Code Gebots- und Auktionsdienste unterstützen mehrere Versionen von AdTech-Code. In der Bidding and Auction API kann mit der SelectAd-Anfrage die Version des Codes angegeben werden, die für die Auktionsanfrage verwendet wird (d.h. für Gebote / Auktionen und auch für Berichte).
Shared Storage Unterstützung für das Schreiben in freigegebenen Speicher im Gebots- und Auktionsdienst. Derzeit wird der gemeinsame Speicher von Bidding- und Auktionsdiensten nicht unterstützt. Wir freuen uns aber über zusätzliches Feedback dazu, warum solche Anwendungsfälle für das System wichtig sind.
Web-zu-App Unterstützung der Freigabe von Interessengruppen zwischen Web und App. Der Web-zu-App-Wechsel ist derzeit nicht Teil der Bereitstellung der Protected Audience API in Chrome und Android. Wir würden uns aber gern von Ihnen darüber informieren lassen, wie wichtig dieser Anwendungsfall ist.
K-Anonymität Umgang mit Fallbacks für die k-Anonymität Wir besprechen das Problem und freuen uns über zusätzliches Feedback.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Alternative Konfigurationen für VTC-Berichte auf Ereignisebene Feedback zu alternativen Berichtskonfigurationen für VTC auf Ereignisebene Wir haben Feedback erhalten, dass die aktuellen Konfigurationen auf Ereignisebene nicht optimal sind. Wir würden uns daher über Feedback zu optimalen globalen Konfigurationen freuen. Wir freuen uns über weiteres Feedback zu diesem Thema. Weitere Informationen finden Sie in unserem Erläuterungsvideo zu flexiblen Ereignissen.
Flexible Konfigurationen auf Ereignisebene Wie ist der Status der flexiblen Konfigurationen auf Ereignisebene? Wir haben eine Dokumentation zur flexiblen Konfiguration auf Ereignisebene geteilt. Die Funktion befindet sich noch in der Vorschlagsphase und wir benötigen mehr Feedback dazu, ob sie für das Google-System wertvoll ist.
Flexible Konfigurationen auf Ereignisebene Wie können widersprüchliche Meldungen verschiedener Parteien in Einklang gebracht werden? Die meisten Berichtsszenarien werden mithilfe von zusammengefassten Berichten abgedeckt. Der flexible Konfigurationsvorschlag auf Ereignisebene bietet jedoch zusätzliche Flexibilität für Berichte auf Ereignisebene, die am häufigsten für Optimierungsfälle verwendet werden. Wir freuen uns über weitere Kommentare und Feedback zu diesem Szenario.
Quellenregistrierung Was passiert, wenn die Quellenregistrierung nach der Triggerregistrierung erfolgt? Wenn derzeit eine Quellenregistrierung nach der Triggerregistrierung erfolgt, können Quelle und Trigger nicht miteinander in Beziehung gesetzt werden. Das scheint ein Grenzfall zu sein. Wir freuen uns über zusätzliches Feedback zu diesem Problem und werden es beheben, wenn es sich um ein Szenario handelt, das viele Anbieter von Anzeigentechnologien betrifft.
Mit mehreren Werbeagenturen zusammenarbeiten Wie können DSPs die Attribution Reporting API verwenden, wenn ein Werbetreibender mit mehreren Werbeagenturen zusammenarbeitet? Die API unterstützt Weiterleitungen und kann daher auch verwendet werden, wenn ein Werbetreibender mit mehreren Werbeagenturen zusammenarbeitet. Außerdem gibt es einige Einschränkungen bei Weiterleitungen, um sicherzustellen, dass die API den Datenschutz verbessert. Außerdem haben wir eine mögliche Lösung mit der Shared Storage API für das spezifische Szenario identifiziert, das von der AdTech-Lösung angesprochen wurde. Wir freuen uns über weiteres Feedback zu diesem Szenario und werden es auf jeden Fall berücksichtigen.
Einschränkungen für Ziele Die automatische Aktualisierung von Anzeigen kann durch Zieleinschränkungen beeinträchtigt werden. Wir haben dieses Thema in der WICG-Videokonferenz am 1. Mai besprochen und würden gerne wissen, was ein angemessenes Limit wäre. Wir haben den Erläuterungen zu Attributionsberichten mit Berichten auf Ereignisebene hinzugefügt, dass der Browser die Anzahl der eTLD+1s für „Ziel“ einschränken kann, die von Quellwebsites vertreten werden. (siehe Pull-Request).
Attributionsberichte und Protected Audience Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? Integrationen für die Protected Audience API sind derzeit für beide Modi der Attribution Reporting API verfügbar (Berichte auf Ereignisebene und Zusammenfassungsberichte). Am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung der Protected Audience API und der Attribution Reporting API veröffentlicht. Weitere Informationen dazu finden Sie hier.
Flexible Konfigurationen auf Ereignisebene Best Practices für die Geräuschsimulation teilen, da die Parameter jetzt konfigurierbar sind Wir haben Code auf GitHub veröffentlicht, mit dem jeder den Informationsgewinn und die Auswirkungen von Rauschen für beliebige flexible Konfigurationen auf Ereignisebene bewerten kann. Wir würden uns über Feedback von allen Nutzern freuen, die den Code testen.
App- und webübergreifende Attributionsmessung Wann ist die App- und Web-Attribution verfügbar? Am 9. Mai haben wir einen Test für die App- und Web-Attributionsmessung über die Attribution Reporting API angekündigt. Die allgemeine Verfügbarkeit der APIs für Relevanz und Messung ist für Chrome 115 geplant. Die plattformübergreifende Attributionsmessung und die Web-Attributionsmessung sind derzeit nicht für Chrome 115 geplant.
Conversions deduplizieren Wie können unabhängige Analyselösungen mit der ARA abgeglichen werden? Wie bei der aktuellen Standardpraxis arbeiten Werbetreibende mit einem unabhängigen Analyseanbieter zusammen, um Duplikate in Conversion-Berichten zu entfernen. Wir haben Ressourcen zur Deduplizierung von Conversions für Berichte auf Ereignisebene veröffentlicht.
Datenverluste bei Datenbankaktualisierungen für Attributionsberichte Gehen Daten verloren, wenn Chrome die Datenbank für Attributionsberichte wie angekündigt aktualisiert? Ab Chrome 115 (stabile Version) aktivieren wir die Relevanz- und Mess-APIs standardmäßig für einen Teil der Chrome-Nutzer. Die allgemeine Verfügbarkeit wird nach und nach erhöht, während wir potenzielle Probleme im Blick behalten. Ziel ist es, bis zum 3. Quartal 2023 eine Verfügbarkeit von 100% über einen Zeitraum von mehreren Wochen zu erreichen. Das ist auch der Zeitpunkt, an dem der Test für die Herkunft von Relevanz- und Messwerten endet. Ab Juli können sich Tester für den Zugriff auf diese APIs registrieren, sobald sie allgemein verfügbar sind. Dadurch gibt es eine Überschneidung zwischen der Verfügbarkeit des ursprünglichen Tests und der allgemeinen Verfügbarkeit durch die Registrierung. Ihr Token für den Ursprungstest ist bis zum 19. September gültig. Wir empfehlen Ihnen jedoch, sich vor Ablauf für die APIs zu registrieren, damit Sie nahtlos vom Ursprungstest zur vollständigen Nutzung übergehen können, ohne laufende Tests zu unterbrechen.

Wie in dieser Mitteilung erwähnt, werden die Daten, die mit älteren Versionen (M113 und älter) registriert wurden, nach dem Update nicht migriert. Daher kann es zu Datenverlusten kommen. Dieser Datenverlust wird nicht in den Debug-Berichten angezeigt. Wir werden versuchen, Datenverluste von 114 auf 115 zu vermeiden.
Abrechnung Attributionsberichte für die Abrechnung nach Cost-per-Conversion verwenden Wie in diesem Artikel erläutert, ist die Attribution Reporting API aufgrund von Ungenauigkeiten in Berichten auf Ereignisebene und Zusammenfassungsberichten möglicherweise nicht für die Abrechnung nach Cost-per-Conversion geeignet. Wir möchten Sie ermutigen, Feedback zur Auswirkung der Attribution Reporting API auf verschiedene Abrechnungsmodelle auf GitHub zu geben.

Zusammenfassungsdienst

Feedbackthema Zusammenfassung Chrome-Antwort
Änderung bei der Verzögerung von Berichten, die zusammengefasst werden können Positive Reaktionen auf den Vorschlag, die Verzögerung bei aggregierten Berichten von [10–60 Min.] auf [0–10 Min.] zu verkürzen, basierend auf Feedback aus dem System Wir freuen uns über die positive Resonanz auf die vorgeschlagene Änderung und möchten Sie ermutigen, uns weiterhin Feedback zu unseren Vorschlägen zu geben.
Lokale Lösung Kann der Aggregationsdienst in lokalen Rechenzentren bereitgestellt werden? Wir prüfen zwar, ob wir auch andere Optionen als cloudbasierte Lösungen unterstützen können, aber derzeit ist es aufgrund der Sicherheitseinschränkungen von On-Premise-Lösungen nicht möglich, On-Premise-TEEs zu unterstützen. Dies würde eine zeitaufwendige Bewertung für die Privacy Sandbox erfordern. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der erheblichen Herausforderungen, die On-Premise-Implementierungen mit sich bringen, sind wir der Ansicht, dass die Cloud-basierten Implementierungen weiter ausgebaut und verbessert werden sollten (z.B. Unterstützung von GCP zusätzlich zu AWS). Wir freuen uns jedoch über zusätzliches Feedback dazu, warum eine solche Anforderung notwendig ist.
Berichte für verschiedene Zeiträume noch einmal verarbeiten Möglichkeit, Berichte für verschiedene Zeiträume noch einmal zu verarbeiten Wir haben ähnliche Anfragen erhalten, Batches in verschiedene Zeiträume aufzuteilen. Ein Vorschlag besteht darin, die freigegebene ID um ein von der Anzeigentechnologie definiertes Label zu erweitern, damit Berichte in verschiedene Batches aufgeteilt werden können. Wir befinden uns in der Anfangsphase der Bewertung dieses Prozesses und werden das System im Laufe der Entwicklung dieses Vorschlags aktualisieren.
Auswirkungen der vertrauenswürdigen Ausführungsumgebung auf den Datenschutz Positive Einstellung zu den Datenschutzaspekten vertrauenswürdiger Ausführungsumgebungen Wir freuen uns über die positiven Reaktionen aus der Branche auf unsere Vorschläge und begrüßen weiteres Feedback, während wir unsere Vorschläge weiter iterieren und entwickeln.
Nutzungsbedingungen Bis wann müssen die Nutzungsbedingungen für den Aggregationsdienst akzeptiert werden? Wir haben noch keinen Termin für die Akzeptanz der Nutzungsbedingungen festgelegt. Wir empfehlen Ihnen jedoch, die Nutzungsbedingungen so bald wie möglich zu akzeptieren, um Verzögerungen bei der Registrierung zu vermeiden. Wir empfehlen Unternehmen, sich bei Fragen an uns zu wenden.
Key Discovery Mit der Funktion zur Schlüsselerkennung können Tester zusammengefasste Berichte abfragen, ohne eine explizite Liste möglicher Tastenkombinationen zu benötigen. So können sie Zusammenfassungsberichte für die netzwerkübergreifende Attribution verarbeiten, um die Leistung und Genauigkeit zu verbessern. Wir prüfen derzeit mögliche Lösungen und Umgehungsmöglichkeiten und freuen uns über zusätzliches Feedback aus der Community.

Private Aggregation API

Feedbackthema Zusammenfassung Chrome-Antwort
Meldequelle Wie wird die Herkunft von Berichten definiert? Der Berichtsoriginator ist immer der Script-Originator des Aufrufers der privaten Aggregation.
128-Bit-Schlüsselraum Klarheit über die Einschränkung des 128-Bit-Schlüsselbereichs Wir werden diese Einschränkung des Schlüsselbereichs klarer formulieren und die Inkonsistenzen auf den Seiten beheben. Wir empfehlen, Hash-Strategien zu verwenden, um innerhalb dieses Schlüsselbereichs zu bleiben.
Maximaler Beitrag pro Bericht Das aktuelle Limit von 20 Beiträgen pro Bericht ist zu niedrig. Anstatt die maximale Anzahl von Beiträgen zu erhöhen, sind wir bereit, Berichte aufzuteilen, anstatt sie bei Erreichen des Limits zu kürzen. Wir werden das Ökosystem im Laufe der Entwicklung dieses Vorschlags einbinden.
Berichte zur Reichweite Sie möchten plattform- und geräteübergreifende Berichte zur Reichweite anfordern. Die Reichweite ist ein grundlegender Messwert für Markenwerbung. Werbetreibende stützen sich auf plattform- und geräteübergreifende Näherungen für Berichte zu Reichweite und Häufigkeit, um ihre Kampagnen zu analysieren und Ausgaben zuzuordnen. Bei Reichweitenmodellen werden Drittanbieter-Cookies als Signal für die Analyse von Anzeigen verwendet, die in Umgebungen von Drittanbietern ausgeliefert werden. Daher haben Anbieter von Anzeigentechnologien eine alternative Lösung gefordert, sobald Drittanbieter-Cookies eingestellt werden.
 Das Privacy Sandbox-Team prüft derzeit Funktionen, die nach der Einstellung von Drittanbieter-Cookies die plattformübergreifende Reichweite unterstützen.
Wir freuen uns über weiteres Feedback aus der Community.

Verdecktes Tracking einschränken

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

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch im 1. Quartal 2023 gemeldet) Hinweise zu zusätzlichen Formfaktoren Anfrage für User-Agent-Client-Hints (UA-CH), um zusätzliche Formfaktoren wie Fernseher und VR zu berücksichtigen Wir arbeiten noch an einigen wichtigen Designentscheidungen (z. B. ob wir einen einzelnen Wert wie „Fernseher“ oder eine Liste der Formfaktorfunktionen angeben sollen), sind aber weiterhin daran interessiert, einen Prototyp dieser Idee zu erstellen.
Datenschutzbudget Einschränkungen des Datenschutzbudgets können dazu führen, dass UA-CH-Anfragen nicht deterministisch werden, wenn zu viele Anfragen gesendet werden. Wir haben derzeit keine neuen Informationen zum Vorschlag für das Datenschutzbudget. Wir haben uns jedoch verpflichtet, Anfragen für UA-Clienthinweise nicht einzuschränken, bevor Drittanbieter-Cookies eingestellt wurden.
Websitekompatibilität Websites verwenden die UA-CH-Marke, um den Zugriff bestimmter Browser auf Websites einzuschränken. Es gibt gute Gründe für eine Markenliste. Einer davon ist die Kompatibilität. Eine UA kann mehrere Marken haben, um diese Probleme zu umgehen.

IP-Schutz (früher Gnatcatcher)

Feedbackthema Zusammenfassung Chrome-Antwort
Betrug und Missbrauch Wie können Unternehmen mit dem IP-Schutz Maßnahmen zur Betrugsprävention einrichten? Wir sind uns der Bedeutung von Anwendungsfällen zur Betrugsprävention und der möglichen Auswirkungen auf diese Anwendungsfälle bewusst. Weitere Informationen zur Unterstützung von Betrugsprävention werden wir im Laufe des Sommers veröffentlichen. Wir möchten von Ihnen wissen, wie wir die Bekämpfung von Betrug noch besser unterstützen können.
GeoIP Weitere Informationen zum Zeitplan für Tests und Bereitstellung von GeoIP Google Chrome hat vor Kurzem neue Informationen zu unseren GeoIP-Plänen veröffentlicht. Im 3. Quartal werden wir weitere Informationen zum Zeitplan der Einführung veröffentlichen. Wir gehen davon aus, dass wir den IP-Schutz zunächst als optionale Funktion für einen kleinen Prozentsatz des Traffics einführen. Uns ist bewusst, dass dieser Vorschlag für Unternehmen einige erhebliche Änderungen mit sich bringen kann. Wir möchten dem gesamten System Zeit geben, sich anzupassen und Feedback zu geben, bevor die Funktion allgemein eingeführt wird.
Kontoauthentifizierung Wie funktioniert die Kontoauthentifizierung mit dem Proxyserver genau? Weitere Informationen zur Kontoauthentifizierung werden wir im Laufe des Sommers veröffentlichen. Einige erste Überlegungen haben wir bereits geteilt.

Eindämmung von Bounce-Tracking

Feedbackthema Zusammenfassung Chrome-Antwort
Testleitfaden Informationen zum Testen der Eindämmung von Bounce-Tracking Im Mai haben wir einen Blogpost mit weiteren Informationen zum Testen der Funktion veröffentlicht.
Dokumentation Klarheit im Vorschlag für das Bounce-Tracking Der aktuelle Vorschlag ist noch in Arbeit und wird von Chrome kontinuierlich aktualisiert, um Klarheit und Informationen für das Ökosystem zu schaffen. Wir arbeiten daran, weitere Details bereitzustellen, und freuen uns über zusätzliches Feedback.
Löschen von Cookies Werden durch die Funktion zur Minimierung von Klick- und Weiterleitungsabbrüchen alle Cookies in einer Domain gelöscht? Bei der Bounce-Tracking-Minimierung (BTM) werden der gesamte Speicher und der gesamte Cache gelöscht, wie hier beschrieben.
Eindämmung von Bounce-Tracking umgehen Die Klassifizierung von Ausstiegs-Trackern kann durch Weiterleitungen mit Pop-ups oder neuen Tabs umgangen werden. Die Spezifikation für die Funktion zum Eindämmen von Bounce-Tracking befindet sich noch in der Entwicklungsphase. Bisher haben wir uns hauptsächlich auf Weiterleitungen im selben Tab konzentriert. Wir planen jedoch, in Zukunft auch an Pop-up-Abläufen zu arbeiten. Hier können Sie uns zusätzliches Feedback geben.

Datenschutzbudget

Feedbackthema Zusammenfassung Chrome-Antwort
Ausrichtung auf Umgebung Das Datenschutzbudget kann sich auf Anwendungsfälle für das Targeting aufgrund der Nähe auswirken. Wir haben Feedback zu diesem Thema erhalten und würden gerne mehr über die potenziellen Auswirkungen des Ökosystems erfahren.

Websiteübergreifende Datenschutzgrenzen stärken

First-Party-Sets

Feedbackthema Zusammenfassung Chrome-Antwort
(Auch in vorherigen Quartalen erfasst) Domainlimit Mehr verknüpfte Domains beantragen In Chrome wird die richtige numerische Grenze für die zugehörige Teilmenge ermittelt, die für die identifizierten Anwendungsfälle ein ausgewogenes Verhältnis zwischen Datenschutz und Nutzen bietet. Schon zu Beginn hat Chrome mitgeteilt, dass die genaue Anzahl der zugehörigen Untergruppe noch nicht festgelegt ist.
Anwendungsfall für eingebettete Inhalte Unterstützung für eingebettete Anwendungsfälle, für die eigene Sets, CHIPs und freigegebener Speicher erforderlich sind Das Chrome-Team hat das Feedback zu diesem Anwendungsfall erhalten und prüft es. Wir freuen uns über zusätzliches Feedback.
Repository-Verwaltung Informationen zu Richtlinien zum Entfernen von selbst erhobenen Datensätzen aus dem GitHub-Repository bei Abweichungen oder Vernachlässigung Das Feedback zu diesem Anwendungsfall wurde an das Chrome-Team weitergeleitet. Das Team untersucht das Problem und freut sich über zusätzliches Feedback.
Nutzer informieren Chrome sollte die Nutzerfreundlichkeit und das Verständnis von First-Party-Sets verbessern, um die Akzeptanz zu erhöhen. Chrome möchte Nutzer über First-Party-Sets informieren und hat dazu einen Hilfeartikel veröffentlicht, der über die Chrome-Benutzeroberfläche verlinkt ist. Wir arbeiten auch weiterhin daran, herauszufinden, wie wir Nutzer im passenden Kontext am besten informieren können.
Post 3PCD Drittanbieter-Cookies bleiben auch nach der Einstellung von Drittanbieter-Cookies in einem Set mit selbst erhobenen Daten erhalten. Mit requestStorageAccess und requestStorageAccessFor werden Drittanbieter-Cookies zwar wieder für bestimmte, klar definierte Anwendungsfälle verfügbar gemacht, sie müssen aber jetzt von der Website aktiv aufgerufen werden, anstatt wie derzeit in Chrome standardmäßig verfügbar zu sein.

Für diese Aufrufe innerhalb eines einzelnen Sets ist keine Nutzergenehmigung erforderlich. Nutzer können dies jedoch verhindern, indem sie dieses Verhalten in den Einstellungen deaktivieren.

Weitere Informationen finden Nutzer im Hilfeartikel, der über die Chrome-Benutzeroberfläche verlinkt ist. Wir planen, den bestehenden Entwicklerleitfaden zu erweitern, sobald die FPS auf 100 % ansteigen.
Einreichung von First-Party-Sets Benennen Sie die erforderliche .well-known/first-party-set um, sodass sie die Erweiterung „.json“ enthält. Wir haben diese Änderung vorgenommen, damit bestimmte Webhosting-Tarife unterstützt werden.
IANA-Registrierung first_party_sets.JSON muss bei der IANA registriert sein. Wir prüfen den Vorschlag und freuen uns über zusätzliches Feedback.

Fenced Frames API

Feedbackthema Zusammenfassung Chrome-Antwort
Anzeigenblockierung Umzäunte Frames können es Werbeblockern erleichtern, Anzeigen zu blockieren. Erweiterungen können mit eingegrenzten Frames ähnlich wie mit iFrames interagieren. Die tatsächliche URL, zu der der eingezäunte Frame weitergeleitet werden soll, ist auch für Erweiterungen sichtbar. Daher können sie wie bei Iframes URL-Übereinstimmungsregeln für das Blockieren anwenden. Wenn Sie alle eingegrenzten Frames einfach bedingungslos blockieren, funktionieren möglicherweise andere Anwendungsfälle von eingegrenzten Frames nicht mehr.

Shared Storage API

Feedbackthema Zusammenfassung Chrome-Antwort
Breitere Akzeptanz Der gemeinsame Speicher sollte ein branchenweiter Standard sein, der plattformübergreifend verfügbar ist. Wir nehmen dieses Feedback gerne entgegen. Das Chrome-Team nimmt weiterhin aktiv an W3C-Foren teil, um den Vorschlag zu unterstützen, Feedback einzuholen und die Akzeptanz zu fördern.
Ausgabegatter Die Ausgabe-Gatter für freigegebenen Speicher sind zu eingeschränkt. Wir berücksichtigen dieses Feedback und freuen uns über weitere Informationen dazu, warum die Ausgabetore zu begrenzt sind.
Gesetzliche Vorschriften Wie wird bei Shared Storage die Einhaltung von Vorschriften wie Datenaufbewahrungsrichtlinien sichergestellt? Der freigegebene Speicher bietet die Flexibilität, Logik zur Steuerung der Lebensdauer und des Ablaufdatums gespeicherter Daten zu implementieren und anzupassen. Anbieter von Anzeigentechnologien können Daten im gemeinsamen Speicher anhand von Schreibzeitstempeln aktualisieren oder löschen.
A/B Testing Wie können A/B-Tests für die Shared Storage API und die Protected Audience API durchgeführt werden? Wir arbeiten daran, weitere Informationen zu diesem Thema zu veröffentlichen.
Limit für den gemeinsam genutzten Speicher Was passiert, wenn das Limit für freigegebenen Speicherplatz erreicht wird? Ist das Limit erreicht, werden keine weiteren Eingaben gespeichert.
Mehrfacher Zugriff beimselben Seitenaufbau Was passiert, wenn beim Laden derselben Seite mehrmals auf den freigegebenen Speicher zugegriffen wird? Am besten eignet sich dafür die window.sharedStorage.append(key, value)-Funktion. Anstatt den Wert für jede Anzeige zu aktualisieren, was bei mehreren Anzeigen zu Kollisionen führen kann. Die APPEND-Funktion fügt den neuen Wert einfach an das Ende des vorhandenen Werts an.
iFrame-Funktionen Unterstützt Shared Storage bestimmte iFrame-Funktionen, die nach der Einstellung von Drittanbieter-Cookies nicht mehr funktionieren? Nach der Einstellung von Drittanbieter-Cookies wird der lokale Speicher in iFrames nach der Website der obersten Ebene partitioniert, die iFrames selbst werden jedoch nicht blockiert. Die Daten im lokalen Speicher eines iframes können nicht auf mehreren Websites der obersten Ebene repliziert werden, der lokale Speicher kann aber weiterhin innerhalb des iframes verwendet werden.

CHIPs

Feedbackthema Zusammenfassung Chrome-Antwort
Partitionslimit 10 KiB pro partitionierter Website sind immer noch sehr viel und wir würden uns eine niedrigere Grenze wünschen. Firefox hat bereits eine positive Position bei CHIPS angegeben. Wenn Sie Unterstützung bei Webkit benötigen, empfehlen wir Ihnen, direkt über dieses GitHub-Problem Feedback zu Ihren Anwendungsfällen zu geben, in denen partitionierte Cookies gegenüber partitioniertem Speicher bevorzugt werden.
Authentifizierte Einbettungen CHIPs können sich auf den aktuellen Ablauf der SSO-Anmeldung auswirken, da eine andere Partitionierung die authentifizierten Einbettungen beeinflusst. Wir möchten die Storage Access API (mit Nutzeraufforderungen) nutzen, um den Anwendungsfall für authentifizierte Einbettungen zu unterstützen. Vor Kurzem haben wir einen Prototyp gesendet.
Richtlinien für die unbefristete Garantie Gelten Richtlinien zur potenziellen Lebensdauer auch für eigene Cookies? Derzeit ist es nicht geplant, Lebensdauerlimits für selbst erhobene Cookies einzuführen.

FedCM

Feedbackthema Zusammenfassung Chrome-Antwort
OAuth-Autorisierungsunterstützung Abstimmung bei der Autorisierung von OAuth-Bereichen, die nicht zum Profil gehören Wir suchen aktiv über die W3C FedID CG nach Input von der Web Identity-Community, wie die Autorisierung nach der Einstellung von Drittanbieter-Cookies über die grundlegende Authentifizierung hinaus unterstützt werden kann.
Unterstützung für SAML Anforderungen an die SAML-Unterstützung abstimmen Das Team sucht aktiv nach Feedback von Forschungs- und Bildungseinrichtungen zu den Anforderungen an die SAML-Unterstützung (zusätzlich zur OpenID Connect-Unterstützung) nach der Einstellung von Drittanbieter-Cookies.

Spam und Betrug bekämpfen

Private State Tokens API (und andere APIs)

Feedbackthema Zusammenfassung Chrome-Antwort
Neue Signale Mehrere Partner haben sich positiv dazu geäußert, browsergestützte Signale zur Geräteintegrität oder zum Nutzervertrauen zu untersuchen. Im Allgemeinen sind sie auch skeptisch, ob neue speziell entwickelte Signale ausreichen, um das aktuelle Niveau der Betrugserkennung beizubehalten. Wir freuen uns, gemeinsam mit der Anti-Betrugs- und Websicherheits-Community neue Vorschläge zu prüfen. Außerdem nehmen wir ihre Bedenken ernst und teilen sie. Genau aus diesem Grund war „der Kampf gegen Spam und Betrug“ ein zentraler Arbeitsstrang der Privacy Sandbox und wir legen weiterhin großen Wert auf die Wahrung der Websicherheit, während wir den Datenschutz für Nutzer verbessern.
Positives Feedback zu PST Mehrere Partner haben Interesse daran bekundet, PSTs für verschiedene Anwendungsfälle im Bereich Betrugsprävention oder Websicherheit zu testen oder zu verwenden. Wir freuen uns über die Unterstützung und das Interesse an neuen Lösungen, die PSTs nutzen. Auf der Entwicklerwebsite für Chrome finden Sie Ressourcen und Beispielcode. Wir freuen uns auch über weiteres Feedback.
Betrug und Missbrauch Leitfaden zur Verhinderung und Erkennung von Anzeigenbetrug bei der Analyse nach der Einstellung von Drittanbieter-Cookies, wenn keine Kennungen mehr verfügbar sind. Wir haben Tools wie Private-State-Tokens eingeführt, mit denen sich ein Teil der Signale wiederherstellen lässt, die durch Drittanbieter-Cookies zu Betrugspräventionszwecken verloren gegangen sind. Dabei werden jedoch neue Datenschutzeinstellungen verwendet. Wir investieren aktiv in neue Vorschläge zur Betrugs- und Missbrauchsprävention, um Funktionen bei anderen Änderungen an der Privacy Sandbox beizubehalten.
Preis für Informationen zum Aussteller und Ursprung Die Informationsrate zwischen Aussteller und Ursprung ist hoch genug, um einzelne Nutzer zu identifizieren. Wir haben die Spezifikation aktualisiert, um klarer zu formulieren, welche Nutzerdaten mithilfe von Private State Tokens übertragen werden können. Es können bis zu sechs öffentliche Schlüssel gleichzeitig verwendet werden, die einen „Status“ für einen bestimmten Nutzer darstellen können. Diese Schlüsselsätze können nur alle 60 Tage aktualisiert werden (außer in seltenen Fällen, in denen eine Notfallschlüsselrotation erforderlich ist). Das erschwert die Zusammenführung zusätzlicher Nutzerdaten im Laufe der Zeit. Bei jeder neuen Web-API muss ein Gleichgewicht zwischen Nützlichkeit und neuen Nutzerinformationen gefunden werden. Wir gehen davon aus, dass PSTs das richtige Gleichgewicht zwischen dem Schutz der Privatsphäre der Nutzer und der Unterstützung wichtiger Anwendungsfälle zur Betrugsprävention schaffen, die von der Einstellung von Drittanbieter-Cookies betroffen sind.
Integration abrufen Die fetch-Integration ist kompliziert und unnötig. Die Verwendung von fetch hat Vor- und Nachteile. Wir möchten die Web-Standardisierung vorantreiben, aber es wäre zu früh, diese Änderung vorzunehmen, bevor wir eine klarere Vorstellung davon haben, wie der Standard aussehen wird. Wenn und sobald ein Standard eingeführt wird, sind wir auch bestrebt, Webentwickler auf verantwortungsvolle Weise auf diesen Standard umzustellen.
Speicherstandort Schlüsselkonfigurationen für Private State Tokens sollten am selben Speicherort wie das PrivacyPass-Protokoll gespeichert werden. Während der Tests während des Origin-Tests haben Entwickler angegeben, dass sie die Flexibilität bevorzugen, ihre Schlüssel an allgemeinen URLs statt in einem .well-known-Verzeichnis zu speichern. Das Schlüsselbindungsformat in PrivacyPass eignet sich nicht besonders für eine Version, bei der die Schlüsselsätze einen impliziten Wert für „öffentliche Metadaten“ zulassen sollen. Wenn eine Variante von PrivacyPass mit öffentlichen Metadaten standardisiert wird (entweder als POPRF, partielle RSA-Blendung oder Schlüsselsätze), wechseln wir möglicherweise zu einer zukünftigen Version von PST, um dies zu unterstützen.
Header-Implementierung der API Fragen zur Header-Implementierung der API Sobald die API standardisiert ist und die Nutzung der API im Ökosystem ausgereift ist, können wir hoffentlich sowohl die standardmäßige Version dieser API ohne Header unterstützen als auch die Headerversion möglicherweise einstellen, wenn die Nutzung niedrig genug ist oder es genügend Entwicklertools/-support für standardmäßige Möglichkeiten zur Korrelation von Ausstellungs-/Einlösungsanfragen mit anderen Daten gibt. Hier finden Sie weitere Informationen zu dem Problem.
Anmeldung Ist es sinnvoll, dass Aussteller sich bei Browseranbietern registrieren müssen? Wir haben die Spezifikation aktualisiert, um den Registrierungsprozess für Aussteller von Private State Tokens zu beschreiben. Auch wenn es sich um ein eigenes Verfahren handelt, ähnelt es den Registrierungsplänen für den Rest der Privacy Sandbox-Arbeit, bei denen wir Aussteller bitten, eine öffentliche Erklärung dazu abzugeben, wie sie PSTs verwenden möchten, und die technischen Einschränkungen zu akzeptieren, die den Datenschutz der Nutzer schützen.