Vierteljährlicher Bericht für das 2. Quartal 2023 mit einer Zusammenfassung des Feedbacks zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.
Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google sich bereit erklärt, vierteljährlich Berichte über den Prozess der Einbeziehung der Stakeholder im Rahmen seiner Privacy Sandbox-Vorschläge zu veröffentlichen (siehe Abschnitte 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch eine Zusammenfassung des Feedbacks von Chrome aus den verschiedenen Quellen generiert, die in der Feedbackübersicht aufgeführt sind. Dazu gehören unter anderem: GitHub Issues, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Community und sucht aktiv nach Möglichkeiten, die gewonnenen Erkenntnisse in Designentscheidungen einfließen zu lassen.
Feedbackthemen sind nach Verbreitung pro API geordnet. Dazu wird eine Zusammenfassung des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, in absteigender Reihenfolge sortiert. Die gemeinsamen Feedbackthemen wurden ermittelt, indem Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen, die über interne Teams und öffentliche Formulare von Google gestellt wurden, überprüft wurden.
Genauer gesagt wurden die Gesprächsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, E-Mails, die von einzelnen Entwicklern eingegangen sind, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Anschließend koordinierte Google die Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, um die relative Verbreitung der Themen zu ermitteln, die in Bezug auf die einzelnen APIs entstehen.
Die Erklärungen zu den Reaktionen von Chrome auf Feedback basieren auf veröffentlichten häufig gestellten Fragen, aus tatsächlichen Antworten auf von Stakeholdern geäußerte Probleme und aus der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts von Entwicklung und Tests wurden Fragen und Feedback insbesondere zu Topics, Protected Audience und Attribution Reporting APIs erhalten.
Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingeht, hat möglicherweise noch keine Antwort von Chrome als Antwort erhalten.
Glossar der Akronyme
- CHIPS
- Cookies mit unabhängig partitioniertem Status
- DSP
- Demand-Side-Plattform
- FedCM
- Federated Credential Management
- fps
- First-Party-Sets
- IAB
- Interactive Advertising Bureau
- IdP
- Identitätsanbieter
- IETF
- Internet Engineering Task Force
- IP-Adresse
- Internet Protocol-Adresse
- openRTB
- Echtzeitgebote
- ÜS
- Ursprungstest
- PatCG
- Private Advertising Technology Community Group
- RP
- Verlassende Partei
- SSP
- Supply-Side-Plattform
- TEE
- Vertrauenswürdige Ausführungsumgebung
- UA
- User-Agent-String
- UA-CH
- User-Agent-Client-Hints
- W3C
- World Wide Web Consortium
- WIPB
- Vorsätzliche IP-Blindheit
Allgemeines Feedback, keine spezifische API/Technologie
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Data Governance und Einhaltung gesetzlicher Vorschriften | Systemleitfäden zur Verwendung der Privacy Sandbox unter Berücksichtigung gesetzlicher Vorschriften | 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. Uns ist jedoch bewusst, dass dies ein wichtiger Interessenbereich für das Ökosystem ist. Für jede API haben wir umfangreiche technische Dokumentationen veröffentlicht, die die Grundlage für die notwendigen rechtlichen Prüfungen bilden sollen. Wir arbeiten außerdem daran, zusätzliche Materialien zur Verfügung zu stellen, um Unternehmen bei der Einhaltung gesetzlicher Vorschriften zu unterstützen. |
| CMA – Vorschlag für quantitative Tests | Weitere Informationen zum Vorschlag für quantitative Tests für die CMA | Gemeinsam mit der CMA entwickeln wir Tests, die einen Überblick über die Auswirkungen der Einstellung von Drittanbieter-Cookies und die Einführung der Privacy Sandbox-Vorschläge auf die Plattform geben. Im April veröffentlichte die CMA einen allgemeinen Leitfaden dazu, was während des Test- und Testzeitraum zu erwarten ist, gefolgt von detaillierten Leitlinien im Juni. Wir empfehlen Ihnen, Fragen oder Feedback zum Vorschlag der CMA zu Quantitative Tests direkt an die CMA zu senden. |
| Von Chrome unterstützte Testmodi | Weitere Informationen und Erläuterungen zu den Testzeitplänen | Am 18. Mai haben wir in einem Blogpost weitere Informationen zu den beiden von Chrome unterstützten Tests veröffentlicht. Diese Informationen sind noch nicht endgültig. Im Laufe des 3. Quartals 2023 veröffentlichen wir weitere Implementierungsanleitungen. |
| Partitionierter Speicher | Wird partitionierter Speicher bei von Chrome unterstützten Tests verwendet? | Die Speicherpartitionierung wird vor dem Test zur Einstellung von Drittanbieter-Cookies an alle Nutzer gesendet. Daher wird es für alle Verzweigungen des Tests aktiviert. Websites haben die Möglichkeit, einen Test zur Einstellung von Produkten und Diensten zu aktivieren, um nicht partitionierten Speicher in diesem Zeitraum zurückzuerhalten. |
| Produktionssupport | Wie werden bei Chrome technische Probleme und Eskalierungen bei der Privacy Sandbox unterstützt, die sich auf das System auswirken? | Google bietet verschiedene Kanäle, über die Anzeigentechnologie-Mitarbeiter Probleme melden und gegebenenfalls eskalieren können. In unserem Entwicklerbeitrag findest du weitere Informationen zu den öffentlichen und privaten Foren für Feedback und zur Eskalation. |
| Zeitplan für die Registrierung | Der aktuelle Zeitraum für die Registrierung ist zu kurz | Die Frist zur Umsetzung der Richtlinie wird derzeit noch geprüft und wir würden gerne wissen, welcher Zeitrahmen am besten geeignet ist. |
| D-U-N-S-Nummer | Weitere Informationen zur Anforderung der D-U-N-S-Nummer für die Registrierung und Bestätigung | Teilnehmer können die Voraussetzungen für den Erhalt einer D-U-N-S-Nummer auf der Dun & Bradstreet-Website nachlesen. Die Anforderungen variieren je nach Markt. Die Teilnehmer sollten daher auf der Website des jeweiligen Marktes nachsehen. Im Allgemeinen müssen Teilnehmer jedoch grundlegende Informationen zu ihrem Unternehmen angeben, wie den Namen des Unternehmens, die Adresse und die Kontaktdaten des Geschäftsinhabers oder Managers. Die Teilnehmer werden möglicherweise auch aufgefordert, finanzielle Informationen zur Verfügung zu stellen, beispielsweise den Jahresumsatz des Unternehmens. Sobald der Antrag vollständig ist, wird D&B ihn prüfen und eine D-U-N-S-Nummer ausstellen, wenn er genehmigt wird. |
| Übergang vom Ursprungstest zur allgemeinen Verfügbarkeit | Wirkt sich die Umstellung vom Ursprungstest zur allgemeinen Verfügbarkeit auf aktuelle Ursprungstesttester aus? | Ab Juli können Tester auf die allgemein verfügbaren APIs für Relevanz und Messung zugreifen. Dies führt zu einer Überschneidung zwischen der Verfügbarkeit von Ursprungstests und der allgemeinen Verfügbarkeit. |
| AdExchanger-Studie | Weitere Informationen zur Methodik der Umfrage | Bei der Umfrage wurden die Befragten gebeten, die Synchronisierungsraten und den Umsatz für ihr Unternehmen zu schätzen. Die Methodik der Teilnehmer lag bei der Beantwortung ihrer einzelnen Fragen. |
| Parameterwerte | Wie werden Parameterwerte wie der Geräuschpegel, die Anonymitätsschwellen und das Datenschutzbudget bestimmt? | In dieser Erläuterung zu GitHub werden die allgemeinen Prinzipien hinter den Privacy Sandbox APIs erläutert. Viele Werte sind noch in der Entwicklung und wir freuen uns über Feedback zu diesem Thema. |
Relevante Inhalte und Werbung zeigen
Themen
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Datenschutz | Studie zur Bewertung der Topics API zum Schutz der Privatsphäre | Wir sind aktiv in die Forschungs-Community eingebunden und präsentieren unsere Forschungsergebnisse zu den Datenschutzeigenschaften der Topics API in Artikeln, Berichten und Workshop-Präsentationen. Wir freuen uns, wenn mehr externe Mitglieder der Forschungs-Community sich mit diesem Bereich beschäftigen. Die Topics API schützt Nutzer vor allgemeinem Tracking im Web, da es zu schwierig ist, Nutzer in großem Umfang zu tracken. Diese Artikel zeigen, dass dies mit der Topics API erfolgreich ist. Sie ist privater als Drittanbieter-Cookies und schützt die Nutzer, während sie die Websites unterstützen, die sie gerne besuchen. |
| Thementaxonomie nicht detailliert genug | Die Taxonomie der breit gefassten Themen enthält keine detaillierteren Themen, einschließlich regionsspezifischer. | Als Reaktion auf früheres Feedback aus der Plattform haben wir am 15. Juni einen Blogpost veröffentlicht. Darin wird eine neue aktualisierte Taxonomie beschrieben, die zahlreiche Verbesserungen berücksichtigt, die auf dem Feedback aus der Plattform basieren. Im Rahmen unserer Arbeit an der überarbeiteten Taxonomie haben wir uns mit mehreren Unternehmen im Ökosystem wie Raptive (ehemals CafeMedia) und Criteo zusammengetan. Durch die aktualisierte Taxonomie werden Kategorien entfernt, von denen wir gehört haben, dass sie weniger nützlich sind. Stattdessen werden Kategorien verwendet, die den Interessen der Werbetreibenden besser entsprechen. Gleichzeitig werden potenziell sensible Themen weiterhin ausgeschlossen. Wir empfehlen, die neueste Taxonomie zu prüfen und Feedback zu den Änderungen zu geben. |
| Aktualisierungsprozess für Taxonomie und Klassifikator | Weitere Informationen zur Topics-Taxonomie und zum Veröffentlichungsrhythmus von Klassifikatoren sowie dazu, wie sich Unternehmen auf solche Aktualisierungen vorbereiten können | Wie in diesem Blogpost bereits erwähnt, gehen wir davon aus, dass sich die Taxonomie im Laufe der Zeit weiterentwickeln wird und dass eine externe Partei, die Stakeholder aus der Branche vertritt, letztendlich dazu übergehen wird, die Taxonomie zu verwalten. Den Plan für die weitere Entwicklung haben wir auch in der Gruppe topics-announce veröffentlicht. |
| Auswirkungen auf eigene Signale | Die gestiegene Anzahl von Themen im Rahmen des jüngsten Taxonomie-Updates kann sehr wertvoll sein. Daher werden andere selbst erhobene interessenbezogene Signale abgewertet. | Im Bericht für das 1. Quartal 2023 kommentierte die CMA: „Uns ist bewusst, dass Google die vorgeschlagene neue Taxonomie mit mehreren Marktteilnehmern in der AdTech-Lieferkette besprochen hat. Einige große Publisher haben angegeben, dass ein größerer Nutzen von Themen den Wettbewerbsdruck auf ihre Lösungen, die auf selbst erhobenen Daten basieren, erhöhen würde. Unsere vorläufige Ansicht ist jedoch, dass ein größerer Nutzen insgesamt besser für den Wettbewerb ist – insbesondere im Hinblick auf die Fähigkeit von kleineren Publishern, ihr Inventar nach der Einstellung von Drittanbieter-Cookies weiterhin zu monetarisieren.“ Unsere Auffassung entspricht dem Kommentar der CMA. |
| Nützlichkeit für verschiedene Arten von Stakeholdern | Anzeigentechnologien, die als SSPs und DSPs fungieren, haben unter Umständen erhebliche Vorteile gegenüber anderen Akteuren des Systems. | Unsere Antwort hat sich im Vergleich zu vorherigen Quartalen nicht geändert: „Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch das eigene Geschäft von Google verzerrt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb in der digitalen 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 bei der weiteren Verbesserung der technischen Designs helfen kann. 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.“ |
| Untergeordnete Themen | Die Kriterien für die Themenauswahl sind die Häufigkeit der Browserbesuche. Wird die Segmentierung dazu führen, dass untergeordnete Themen nie ganz oben aufsteigen? | Chrome wertet derzeit andere Ranking-Methoden aus und untersucht weitere Signale, die das Ranking verbessern können. Wir werden unsere überarbeiteten Pläne zu gegebener Zeit dem Ökosystem mitteilen. |
| Vertraulichkeit | Das Ziel der Topics API ist es, sicherzustellen, dass Nutzerinformationen, die über die Topics API abgerufen oder von ihr abgeleitet wurden, weniger vertraulich sind als solche, die mit den heutigen Tracking-Methoden abgeleitet werden könnten. | Wir sind der Meinung, dass die Topics API deutlich besser geschützt ist als aktuelle Technologien, die Re-Identifikation von Nutzern erheblich einschränkt und sensible Themen ausschließen soll. Uns ist bewusst, dass Themen mit selbst erhobenen Daten korreliert oder kombiniert werden können, um sensible Kategorien zu erstellen. Wir sind jedoch der Meinung, dass die Topics API einen Schritt zum Datenschutz für Nutzer darstellt, und wir sind bestrebt, die API weiter zu verbessern. |
| Taxonomiestruktur | ID, Versionsverwaltung und andere Metadatenstruktur zur Topics-Taxonomie hinzufügen | Die API-Antwort enthält derzeit die Taxonomie-ID. Auf dem Weg zu langfristiger Governance ist es sinnvoll, das Topics-Objekt zu überprüfen und bei Bedarf zusätzliche Metadaten zur Versionsverwaltung hinzuzufügen. |
| Steuerung durch den Publisher | Publisher sollten mitbestimmen, unter welchen Themen ihre Websites klassifiziert werden sollen. | Die falsche Klassifizierung von Websites kann dazu führen, dass das Topics-Signal insgesamt etwas weniger nützlich ist. Die falsch klassifizierten Websites werden dadurch aber genauso stark beeinträchtigt wie andere Websites. Das liegt daran, dass die Kontextinformationen einer Website immer für Auktionen auf der Website verfügbar sind. So erhalten Sie auch bei falscher Klassifizierung vergleichbare Informationen zum richtigen Thema. Wir freuen uns über Feedback zu diesem Thema. Es besteht ein Risiko, dass Publisher die Kontrolle über die Klassifizierung haben. Websites werden möglicherweise absichtlich falsch klassifiziert, um den Nutzen für alle zu reduzieren, oder sensible Bedeutungen in weniger häufigen Themen zu codieren, was den Datenschutz gefährdet. |
| Chrome-Erweiterungen | Zulassen, dass Chrome-Erweiterungen Themen verwalten und filtern, ähnlich wie die aktuellen Erweiterungen zur Cookie-Verwaltung | Dies sollte bereits möglich sein, wie auf GitHub besprochen, wir freuen uns aber über zusätzliches Feedback aus der Community. |
| Übergang zur allgemeinen Verfügbarkeit | Wirkt sich der Wechsel vom Ursprungstest zur allgemeinen Verfügbarkeit auf die Topics API aus? | Für Nutzer, die vom Ursprungstest 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. | Zum Schutz der Privatsphäre gibt es eine Reihe von Maßnahmen, wie hier beschrieben. |
| Betrug und Missbrauch | Manipulation von Topics durch betrügerische Besuche verhindern | Hier werden Maßnahmen zur Risikominimierung erläutert. |
| Themenklassifikator | Können Websites eine Änderung ihrer Topics-Klassifizierung anfordern? | Wir freuen uns über Feedback zu diesem Thema und freuen uns auf Feedback. |
| Websites von Themenanbietern | Kennzeichnen Sie bestimmte Websites, die Inhalte zu vielen Themen hosten, als „Websites von Anbietern spezieller Themen“ und trainieren Sie Klassifikatoren anhand der Tags auf den Webseiten. | Wir erörtern den Vorschlag und freuen uns über zusätzliches Feedback. |
Protected Audience API (früher FLEDGE)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Anpassung an Traffic | Auswirkungen der SSP-gesteuerten Filterung auf die Leistung, um die Anzahl der Abfragen pro Sekunde zu optimieren | Wir haben uns intensiv mit der Trafficmuster beschäftigt. Daher empfehlen wir SSPs, das Caching zu nutzen. |
| Testvolumen | Das Testen von Protected Audience ist schwierig, da SSPs und DSPs Schwierigkeiten damit haben, hohe Trafficvolumen zu erhalten. | 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 prozentuale Anteil der Zugriffe, bei denen personalisierte Anzeigen aktiviert sind, für Partner einen besseren Test bieten wird. |
| Komplexität | Die Implementierung von Protected Audience-Lösungen ist mit einem erheblichen Aufwand und erheblichen Kosten verbunden. | Uns ist bewusst, dass die Implementierung neuer Technologien wie der Privacy Sandbox schwierig ist. Das Privacy Sandbox-Team arbeitet eng mit einer Vielzahl von Interessenvertretern zusammen, um ihre Bemühungen zu informieren und zu unterstützen, und evaluiert kontinuierlich andere Beschleunigungsmittel, um die Akzeptanz der Plattform zu unterstützen. |
| Vertrauenswürdige Ausführungsumgebungen | Unterstützung für vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) in nicht öffentlichen Cloudumgebungen | Wir erforschen möglicherweise weitere Optionen, die über Cloud-basierte Lösungen hinausgehen. Derzeit ist es jedoch nicht möglich, lokale TEEs zu unterstützen. Grund dafür sind Einschränkungen der lokalen Sicherheit, die eine zeitaufwendige Bewertung der Privacy Sandbox erfordern würden. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, sind wir davon überzeugt, dass die weitere Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z.B. die Unterstützung von Google Cloud zusätzlich zu AWS) für das System von größtem Vorteil ist. Wir freuen uns aber über zusätzliches Feedback dazu, warum eine solche Anforderung erforderlich ist. |
| Kostenstruktur | Angebote für Gebote und Auktionsdienste erhöhen die Kosten und die Komplexität für Anzeigentechnologie-Anbieter im Vergleich zu clientseitigen Modellen. | Wir arbeiten derzeit an einem Leitfaden zur Schätzung der Kosten für die Unterstützung von Gebots- und Auktionsworkflows auf dem Gebots- und Auktionsserver, der mit der Nutzung von Anzeigentechnologien in Zusammenhang steht und eines der Ziele unserer Designs erfüllt. |
| K-Anon-Zeitachsen | Wann werden die geplanten Einschränkungen der k-Anonymität für „renderUrl“ erzwungen? | Wir arbeiten an einer Erläuterung des Zeitplans für die Durchsetzung, den wir bald veröffentlichen werden. |
| RunAdAuction-Einschränkungen | Kann Chrome die Funktion "runAdAuction" so einschränken, dass sie nur von der obersten Seite aus aufgerufen werden kann? |
Unser Design unterstützt runAdAuction vollständig, damit es von der obersten Seite aus aufrufbar ist. Wir sind jedoch der Meinung, dass es für Publisher nachteiliger wäre, wenn es nur von der Top-Domain aufrufbar wäre.Wir haben insbesondere aus der Branche 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 zum Ausführen ihrer Websites verwenden können. Ziel der Privacy Sandbox ist es, ein funktionierendes System zu fördern, ohne die Funktionsweise von Publishern und Anzeigentechnologien vorschreiben zu müssen. Publisher legen fest, wie und wer runAdAuction auf ihrer Website aufruft, und bieten ihnen so die Flexibilität, den besten Weg für ihre Anforderungen zu finden. |
| Unterstützung bei der Implementierung | Kann Chrome eine Open-Source-Implementierung einer Mehrfachkundenauktion erstellen oder daran mitwirken? | Im Rahmen der Privacy Sandbox werden datenschutzfreundliche Technologien entwickelt, die nicht auf Drittanbieter-Cookies oder anderen websiteübergreifenden Kennungen angewiesen sind. Wir möchten eine gut funktionierende Werbeplattform schaffen, ohne vorschreiben zu müssen, wie Anzeigentechnologien funktionieren. Wir haben in unserem GitHub-Repository Informationen zur Funktionsweise der APIs veröffentlicht und sind offen für die Entwicklung von Lösungen in der Branche. Wir planen keine spezifische Implementierung. Unsere Kernaufgabe besteht darin, Plattformtechnologien zu entwickeln und keine Strategien für den Einsatz dieser Technologien vorzuschreiben. Mit unseren Technologien können Unternehmen im Bereich Anzeigentechnologie die richtigen Datenschutzbestimmungen für ihre Kunden festlegen. |
| Mehrfachkundenauktionen | Erzwingt Chrome die Freigabe eines kontextbezogenen Gewinners für Komponentenauktionen? | Die Protected Audience API bietet Parteien, die eine Auktion mit mehreren Verkäufern initiieren, die Möglichkeit, Informationen an die Komponentenauktion weiterzugeben (Hinweis: nur vor der Initiierung der Auktion). Der Browser hat jedoch keine Möglichkeit zu unterscheiden, ob eine Information kontextbezogen ist oder nicht. Daher können wir die Blockierung oder das Verlangen bestimmter Informationen nicht erzwingen. |
| Nutzerpräferenz für das Tracking von Einwilligungen | AdTech fragt PA, wie das Tracking der Nutzereinwilligung richtig implementiert werden kann | Unsere Antwort enthält das, was wir in Frage 1 gesagt haben: „Bei bestimmten Anzeigen ist die geeignete Anzeigentechnologie am besten geeignet, um Kontrolle darüber zu haben, welche Creatives ausgeliefert werden und wie sie ausgewählt werden.“ Bei der Protected Audience Meeting im Mai haben wir verschiedene Szenarien im Zusammenhang mit diesem Problem besprochen. Wir würden uns über zusätzliches Feedback und weitere Diskussionen zu diesem Thema freuen. |
| Benutzerdefinierte Zielgruppen | Werden SSP-Anwendungsfälle zum Erstellen benutzerdefinierter Zielgruppen von der Protected Audience API unterstützt? | Mit der Protected Audience API können SSPs und andere Anzeigentechnologie-Anbieter benutzerdefinierte Zielgruppen besitzen und verwalten. Weitere Informationen dazu, wie eine SSP in die PA API integriert werden kann, wird derzeit entwickelt. Sie werden SSPs und anderen Anzeigentechnologie-Anbietern zur Unterstützung ihrer Integration zur Verfügung gestellt. |
| Formate | Werden Videos von der Protected Audience API unterstützt? | Videoanzeigen werden auf zwei Arten ausgeliefert: als VAST-XML oder HTML. Das ist eine Out-Stream-Anzeige, die letztlich auch VAST-XML in einen Videoplayer laden kann. Käufer können beide Formate über eine renderURL zurückgeben. Die VAST-Spezifikation wurde vor Kurzem aktualisiert, damit die Attribution Reporting API unterstützt wird. Websites, auf denen Videoanzeigen ausgeliefert werden, müssen auf die Art und Weise vorbereitet sein, wie Anzeigen über die Protected Audience API ausgeliefert werden. Dazu muss die URL eines Protected Audience-iFrames über Placement-Tags an einen Videoplayer übergeben werden. Für Fenced Frames arbeiten wir daran, die Anforderungen an Videos zu erfüllen, bevor fenced Frames vor 2026 erforderlich sind. |
| Taktung | Wie funktioniert die Budgetabstufung in Verbindung mit der Protected Audience API? | Vielen Dank für dein Feedback. Wir sind daran interessiert, weitere Fälle dieser Anfrage mit weiteren Details von mehr SSP-Partnern zu erhalten, da dies bisher hauptsächlich ein DSP-Bedenken war. |
| Aktualisierungshäufigkeit | Für bestimmte Anwendungsfälle wie das Aktualisieren von Produktinformationen ist die Häufigkeit von Anrufen über dailyUpdate (bis zu einer pro Interessengruppe und Tag) unter Umständen nicht ausreichend. |
Vielen Dank für dein Feedback. Es gibt andere Lösungen, mit denen Anzeigentechnologie-Anbieter Signale verwenden können, die in unterschiedlichen Rhythmen aktualisiert werden, z. B. K/V-Lookups. |
| Kontrolle der Anzeigenqualität | Wie implementieren Publisher die Anzeigenqualitätskontrolle? | Heute bietet die Protected Audience API Publishern die Möglichkeit, ihre Sell-Side-Plattformen über bestimmte Einstellungen zu informieren, die sie im Rahmen der Auktionskonfiguration für Vorabgebote einrichten können (z.B. Sperrlisten basierend auf den mit Anzeigen verknüpften Labels). Wir freuen uns über Feedback zu zusätzlichen Funktionen, die diese Plattform möglicherweise erfordert. |
| Debugging | Wann wird die forDebuggingOnly-Funktion entfernt? |
Wir planen, forDebuggingOnly aufgrund von Verlusten durch die Einstellung von Drittanbieter-Cookies einzustellen. Wir planen, forDebuggingOnly für die Siegerevents frühestens 2026 einzustellen. |
| Geräteübergreifende Interessengruppen | Angebot, geräteübergreifende Interessengruppen für authentifizierte User-Agents zu aktivieren | Wir prüfen diesen Vorschlag, aber die hohe Spezifität des geräteübergreifenden Targetings wirft erhebliche Bedenken im Hinblick auf den Datenschutz auf, wie in diesem GitHub-Problem erläutert. |
| (Auch im 1. Quartal berichtet) Dynamisches Remarketing | Ist dynamisches Remarketing mit der Protected Audience API auch nach der Einstellung von Drittanbieter-Cookies weiterhin möglich? | Wir sind der Meinung, dass dieser Anwendungsfall mithilfe von Protected Audience möglich ist, wie hier erläutert. |
| Auf zugehörige Daten klicken | Klickbezogene Daten zu browserSignals. hinzufügen |
Wir bitten derzeit um Erläuterungen zum Zeitpunkt des Klicks, um eine vorläufige Stellungnahme zu äußern. |
| (Auch im 4. Quartal 2022 berichtet) Benutzerdefinierte Funktionen in Protected Audience | Wie werden benutzerdefinierte Funktionen (User-Defined Functions, UDF) 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 AdTech, der dieses Problem gemeldet hat, sagte auch, dass er noch prüft, was mit UDF möglich ist, sodass es hier noch kein umsetzbares Feedback gibt, auf das wir reagieren können, zumindest nicht bis zur allgemeinen Verfügbarkeit. |
| Currency | Währungsbeträge dürfen nicht durch Gleitkommazahlen dargestellt werden. | Ausführlichere Informationen zu diesem Problem |
| Funktionen zur Anzeigenauswahl ohne DSP | Welche Rolle spielen Ad-Server bei Protect Audience API-Auktionen? | Wir wissen über die Anfragen an die Ad-Server, weiterhin Dienste für die Anzeigenauswahl nach der Gebotsabgabe bzw. für die Optimierung dynamischer Creatives anbieten zu können. Wir werten derzeit die detaillierte Analyse der Lücke zwischen der aktuellen Protected Audience API und diesen Anfragen aus. |
| GenerateBid | Unterstützung für das Google Ads-Angebot, mehr als eine mögliche Anzeige pro Anzeigengruppe von generateBid zurückzugeben und diese Kandidaten in "scoreAd" zu bewerten. |
Dies wird derzeit geprüft. Hier kannst du uns zusätzliches Feedback geben. |
| Auktionsauftrag | Müssen Protected Audience API-Auktionen die letzte durchgeführt werden, damit sie Input aus den Ergebnissen aller anderen Auktionen erhalten kann? | Es besteht keine technische Anforderung, dass die Protected Audience API als Letztes ausgeführt werden soll. |
| Nicht vom Nutzer gestartete Navigation | Nicht vom Nutzer initiierte Navigation freigeben | Wir prüfen diese Anfrage und besprechen sie hier . Wir würden uns über zusätzliches Feedback freuen. |
| Caching | SSP sollte keine proBuyerSignals-Datei einer bestimmten DSP aus einem Cache erstellen, wenn sich der Nutzerstatus ändert. | Uns ist bewusst, dass Caching nicht für jeden Anwendungsfall für Signale pro Käufer funktioniert, deshalb evaluieren wir weitere Optionen. Wir freuen uns über zusätzliches Feedback aus der Community darüber, ob Caching für ihre Anwendungsfälle geeignet ist. |
| Attribution Reporting und Protected Audience API | Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? | Integrationen sind derzeit für die Protected Audience API sowohl für Attribution Reporting API-Modi (auf Ereignisebene als auch in zusammenfassende Berichte) verfügbar. Am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung von Protected Audience API und Attribution Reporting veröffentlicht. Weitere Informationen |
| Serverendpunkt | Wird der Serverendpunkt im endgültigen Design der vertrauenswürdige Aggregationsserver sein? | Der Serverendpunkt ist ein Endpunkt für AdTech, der unabhängig von den vertrauenswürdigen Aggregationsservern ist, die zur Verarbeitung der erfassten und transformierten Berichte verwendet werden. Derzeit sind keine Änderungen für den Endpunkt der Berichterstellung geplant. Mit dem aktuellen Design soll sichergestellt werden, dass die aggregierbaren Berichte selbst (mit verschlüsselten Nutzlasten) keine websiteübergreifenden Daten weitergeben. Daher sollte kein vertrauenswürdiger Endpunkt erforderlich sein. Eine weitere Komplikation ist, dass verschiedene Anzeigentechnologien wahrscheinlich unterschiedliche Batch-Strategien haben werden. Hier kannst du uns zusätzliches Feedback geben. |
| WebIDL | Die aktuelle Protected Audience API-Spezifikation ist nicht mit der WebIDL-Spezifikation kompatibel. | Wir werten dieses Feedback aus und erörtern das Problem hier. |
| Einwilligungsverwaltung | Wie wird die Übergabe von Einwilligungssignalen in der Protected Audience API gehandhabt? | Kontextinformationen fallen nicht unter die Protected Audience API. Wir diskutieren dieses Problem und freuen uns über zusätzliches Feedback. |
| Kontobasiertes Marketing | Wäre kontobasiertes Marketing möglich? | Die Protected Audience API unterstützt eine Vielzahl von zielgruppenbasierten Marketinganwendungsfällen. Wir werden weiterhin nachvollziehen können, wie die Protected Audience API diesen speziellen Anwendungsfall am besten unterstützen kann, und würden gerne zusätzliches Feedback von unserer Plattform zu diesem Thema begrüßen. |
| Komponentenauktion | Was bewerten die Teilnehmer an der Komponentenauktion? | Die Komponentenauktionen bewerten Interessengruppen nicht direkt, sondern sie bewerten die Anzeigen und Gebote, die eine DSP über die generateBid-Funktion einreicht. Die Funktion generateBid() wird pro Interessengruppe ausgeführt. Die DSP gibt beim Ausführen von „generateBid“ Folgendes zurück:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Externe Beiträge | Anfrage zur Unterstützung externer Beiträge auf der GitHub-Codebasis des Schlüssel/Wert-Servers. | Wir möchten unsere relevanten Prozesse aktualisieren, um externe Beiträge zum GitHub-Code zu unterstützen. |
| Größe der Interessengruppe | Welche maximale Anzahl von Schlüsseln kann von IG unterstützt werden? | Das aktuelle Limit beträgt 50 KB für die Größe eines IG und Schlüssel zählen dazu. Wir freuen uns über weitere Diskussionen über die Größenbeschränkung. |
| Batching | Wie kann die Anzahl der K/V-Serveraufrufe reduziert werden? | Sie können HTTP-Cache-Control-Header verwenden, um die Anzahl der K/V-Aufrufe zu reduzieren. Sie können beispielsweise über Komponentenauktionen und Anzeigenflächen auf einer einzelnen Seite hinweg im Cache gespeichert werden. |
| Versionsverwaltung | Unterstützung mehrerer Versionen von AdTech-Code | Die Gebots- und Auktionsdienste unterstützen mehrere Versionen von AdTech-Code. In der Bidding and Auktion API kann die SelectAd-Anfrage die Version des Codes angeben, der für die Auktionsanfrage verwendet wird, d.h. für Gebote, Auktionen und auch Berichte. |
| Freigegebener Speicher | Unterstützung beim Schreiben an freigegebenen Speicher im Bidding- und Auktionsdienst. | Derzeit unterstützen Bidding und Auktionsdienste keinen freigegebenen Speicher. Wir würden uns jedoch über zusätzliches Feedback freuen, warum solche Anwendungsfälle für die Plattform so wichtig sind. |
| Web-zu-App | Das Teilen von Interessengruppen von Web zu App unterstützen. | Web-zu-App ist derzeit bei der Protected Audience API-Bereitstellung für Chrome und Android nicht abgedeckt. Wir würden jedoch gern wissen, wie wichtig dieser Anwendungsfall ist. |
| k-Anonymität | Umgang mit k-Anonymitäts-Fallbacks | Wir besprechen das Problem und freuen uns über zusätzliches Feedback. |
Digitale Anzeigen analysieren
Attribution Reporting (und andere APIs)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Alternative Konfigurationen für VTC-Berichte auf Ereignisebene | Feedback zu alternativen Konfigurationen für VTC-Berichte auf Ereignisebene | Einige Nutzer haben uns mitgeteilt, dass die aktuellen Konfigurationen auf Ereignisebene nicht optimal sind. Daher bitten wir um Feedback zu optimalen globalen Konfigurationen. Wir freuen uns über zusätzliches Feedback zu diesem Thema und sind der Meinung, dass auch unsere Erklärung auf flexibler Ereignisebene dabei hilft, dieses Problem zu lösen. |
| Flexible Konfigurationen auf Ereignisebene | Wie lautet der Status der Funktion für flexible Konfigurationen auf Ereignisebene? | Wir haben die Dokumentation zur flexiblen Konfiguration auf Ereignisebene freigegeben. Die Funktion befindet sich noch in der Entwurfsphase und wir bitten Sie um weiteres Feedback dazu, ob die Funktion für die Plattform nützlich sein wird. |
| Flexible Konfigurationen auf Ereignisebene | Wie können widersprüchliche Reports von verschiedenen Parteien abgeglichen werden? | Die meisten Berichterstellungsszenarien werden durch die Verwendung von aggregierten Berichten behandelt, während der flexible Konfigurationsvorschlag auf Ereignisebene speziell für zusätzliche Flexibilität für Berichte auf Ereignisebene vorgesehen ist, die am häufigsten für Optimierungsanwendungsfälle verwendet werden. Wir freuen uns über zusätzliche Kommentare oder Feedback zu diesem Szenario. |
| Quellenregistrierung | Was passiert, wenn die Quellregistrierung nach der Triggerregistrierung erfolgt? | Wenn eine Quellenregistrierung nach der Triggerregistrierung erfolgt, können Quelle und Trigger einander nicht zugeordnet werden. Dies scheint ein Grenzfallszenario zu sein. Wir freuen uns über zusätzliches Feedback zu diesem Problem und werden uns bemühen, dieses Problem zu lösen, mit dem viele Anzeigentechnologie-Anbieter konfrontiert zu sein scheinen. |
| Mit mehreren Werbeagenturen zusammenarbeiten | Wie können DSPs die Attribution Reporting API nutzen, wenn ein Werbetreibender mit mehreren Werbeagenturen zusammenarbeitet? | Die API unterstützt Weiterleitungen und kann daher auch dann verwendet werden, wenn ein Werbetreibender mit mehreren Werbeagenturen zusammenarbeitet. Außerdem gibt es in Bezug auf Weiterleitungen einige Einschränkungen, um den Datenschutz durch die API zu verbessern. Wir haben auch eine mögliche Problemumgehung gefunden, wenn Sie die Shared Storage API für das spezifische Szenario der Anzeigentechnologie verwenden. Wir freuen uns über zusätzliches Feedback zu diesem Szenario und werden es in Zukunft auf der Grundlage dieses Feedbacks umsetzen. |
| Ziellimits | Der Anwendungsfall für automatisch aktualisierte Anzeigen kann durch Ziellimits beeinträchtigt werden. | Wir haben dieses Problem in der WICG-Besprechung am 1. Mai besprochen und würden gerne von Ihnen wissen, welche Begrenzung angemessen wäre. Wir haben die Erklärung zu Attributionsberichten mit Berichten auf Ereignisebene hinzugefügt, die besagt, dass der Browser die Anzahl der „Ziel“-eTLD+1s beschränken kann, die durch Quellwebsites dargestellt werden. (siehe Pull-Anfrage). |
| Attribution Reporting und Protected Audience API | Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? | Integrationen sind derzeit für die Protected Audience API sowohl für Attribution Reporting API-Modi (auf Ereignisebene als auch in zusammenfassende Berichte) verfügbar. Am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung von Protected Audience API und Attribution Reporting veröffentlicht. Weitere Informationen |
| Flexible Konfigurationen auf Ereignisebene | Teilen Sie die Best Practices für die Rauschsimulation jetzt mit den konfigurierbaren Parametern. | Wir haben Code auf GitHub freigegeben, mit dem jeder den Informationszuwachs und die Störfaktoren für beliebige flexible Konfigurationen auf Ereignisebene bewerten kann. Wir freuen uns über Feedback von allen, die den Code testen möchten. |
| App- und Web-Attributionsmessung | Wann werden App- und Web-Attributionsanalysen verfügbar sein? | 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 in Chrome 115 ist zwar geplant, für die App- und Web-Attributionsmessung ist jedoch derzeit nicht geplant, dass sie in Chrome 115 allgemein verfügbar ist. |
| Conversions deduplizieren | Wie können unabhängige Analysetools mit ARA abgeglichen werden? | Wie bei der derzeitigen Praxis arbeiten Werbetreibende mit einem unabhängigen Drittanbieter für Messungen zusammen, um doppelte Conversion-Berichte zu deduplizieren. Informationen dazu, wie Sie Conversions deduplizieren, können für Berichte auf Ereignisebene verwendet werden. |
| Datenverlust bei Aktualisierungen der Attribution Reporting-Datenbank | Wird es zu Datenverlusten kommen, wenn Chrome wie angekündigt die Attribution Reporting Database aktualisiert? | Ab Chrome Stable 115 werden die APIs für Relevanz und Messung standardmäßig für einen Teil der Chrome-Nutzer aktiviert. Diese allgemeine Verfügbarkeit steigt, während wir das System auf potenzielle Probleme überprüfen. Ziel ist es, bis zum 3. Quartal 2023 über einen Zeitraum von Wochen eine Verfügbarkeit von 100% zu erreichen. Dies fällt mit dem Ende des Ursprungstests für Relevanz und Messung ein. Ab Juli können sich Tester für den allgemeinen Zugriff auf diese APIs registrieren. Dies führt zu einer Überschneidung zwischen der Verfügbarkeit von Ursprungstests 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 den Ursprungstest nahtlos beenden können, ohne laufende Tests zu unterbrechen. Wie in dieser Mitteilung erwähnt, werden die in älteren Versionen (M113 und früheren Versionen) registrierten Daten nach dem Update nicht migriert. Es kann daher zu einem Datenverlust kommen. Dieser Datenverlust wird in Berichten zur Fehlerbehebung nicht angezeigt. Wir versuchen, Datenverluste zwischen 114 und 115 zu vermeiden. |
| Abrechnung | Cost-per-Conversion-Abrechnung mithilfe von Attribution Reporting | Wie in diesem Artikel erwähnt, ist die Attribution Reporting API möglicherweise nicht für die Cost-per-Conversion-Abrechnung geeignet, da in Berichten auf Ereignisebene und in zusammengefassten Berichten zu viele Daten enthalten sind. Wir ermutigen die Spieler, uns Feedback zu den Auswirkungen der Attribution Reporting API auf GitHub zu geben. |
Aggregationsdienst
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Änderung der Verzögerung bei aggregierten Berichten | Positive Reaktionen auf den Vorschlag, die Verzögerung für Berichte vom Typ „Aggregierbar“ auf [10–60 Minuten] zu [0–10 Minuten] zu ändern | Wir freuen uns über die positiven Reaktionen auf die vorgeschlagene Änderung und ermutigen das Ökosystem, weiterhin Feedback zu unseren Vorschlägen zu geben. |
| Lokale Lösung | Kann der Aggregation Service in lokalen Rechenzentren bereitgestellt werden? | Wir erforschen möglicherweise weitere Optionen, die über Cloud-basierte Lösungen hinausgehen. Derzeit ist es jedoch nicht möglich, lokale TEEs zu unterstützen. Grund dafür sind Einschränkungen der lokalen Sicherheit, die eine zeitaufwendige Bewertung der Privacy Sandbox erfordern würden. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, sind wir davon überzeugt, dass die weitere Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z.B. die Unterstützung von Google Cloud zusätzlich zu AWS) für das System von größtem Vorteil ist. Wir freuen uns aber über zusätzliches Feedback dazu, warum eine solche Anforderung erforderlich ist. |
| Berichte für verschiedene Zeiträume erneut verarbeiten | Möglichkeit, Berichte für verschiedene Zeiträume noch einmal zu verarbeiten | Wir haben ähnliche Anfragen erhalten, Batches für verschiedene Zeiträume aufzuteilen. Ein Vorschlag besteht darin, die gemeinsame ID mit einem Anzeigentechnologie-Label zu erweitern, sodass Berichte in verschiedene Batches aufgeteilt werden können. Wir sind gerade dabei, diesen Prozess zu evaluieren, und werden die Plattform auf dem neuesten Stand halten, während sich der Vorschlag weiterentwickelt. |
| Auswirkungen der vertrauenswürdigen Ausführungsumgebung auf den Datenschutz | Positive Stimmung gegenüber den Auswirkungen von vertrauenswürdigen Ausführungsumgebungen | Wir freuen uns über die positiven Reaktionen auf unsere Vorschläge und freuen uns über weiteres Feedback im Rahmen unserer Weiterentwicklung und Optimierung. |
| Nutzungsbedingungen | Bis wann müssen die Nutzungsbedingungen des Aggregationsdienstes akzeptiert werden? | Auch wenn wir noch keine Frist für die Annahme der Nutzungsbedingungen festgelegt haben, empfehlen wir Unternehmen, diese so bald wie möglich zu akzeptieren, um Verzögerungen bei der Anmeldung zu vermeiden. Wir empfehlen Unternehmen, sich bei Fragen an uns zu wenden. |
| Schlüsselerkennung | Mit der Funktion zur zentralen Erkennung können Tester zusammengefasste Berichte abfragen, ohne die explizite Liste möglicher Tastenkombinationen zu benötigen, um zusammenfassende Berichte für die netzwerkübergreifende Attribution zu verarbeiten und so die Leistung und Genauigkeit zu verbessern. | Wir arbeiten momentan an Lösungen und Lösungen und freuen uns über zusätzliches Feedback. |
Private Aggregation API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Ursprung der Berichterstellung | Wie wird der Ursprung der Berichte definiert? | Die Berichtsquelle ist immer der Skriptursprung des Aufrufers der privaten Aggregation. |
| 128-Bit-Schlüsselraum | Klarheit bei der Beschränkung des 128-Bit-Schlüsselbereichs | Wir werden diese Schlüsselraumbeschränkung deutlicher machen und die Uneinheitlichkeiten zwischen den Seiten beheben. Wir empfehlen, Hash-Strategien zu verwenden, um innerhalb dieses Schlüsselraums 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, können wir Berichte auch aufteilen, statt sie zu kürzen. Bei der Weiterentwicklung dieses Vorschlags werden wir die Plattform aktiv einbeziehen. |
| Reichweitenberichte | Anfrage für plattform-/geräteübergreifende Berichte zur Reichweite Die Reichweite ist ein wesentlicher Messwert der Markenwerbung. Werbetreibende verlassen sich bei Berichten zu Reichweite und Häufigkeit auf plattform- und geräteübergreifende Näherungswerte, um ihre Kampagnen zu analysieren und die Ausgaben zuzuweisen. Bei Reichweitenmodellen werden Drittanbieter-Cookies als Signal für die Messung von Anzeigen verwendet, die in Drittanbieterumgebungen ausgeliefert werden. Daher haben Anzeigentechnologie-Anbieter eine alternative Lösung angefordert, nachdem Drittanbieter-Cookies eingestellt wurden. |
Das Privacy Sandbox-Team prüft Funktionen zur Unterstützung von Methoden für die domainübergreifende Reichweite nach der Einstellung von Drittanbieter-Cookies. Wir freuen uns immer über zusätzliches Feedback. |
Verdecktes Tracking begrenzen
Reduzierung des User-Agents/Client-Hints des User-Agents
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| (Auch im 1. Quartal 2023 gemeldet) Hinweise für zusätzliche Formfaktoren | Anforderung von User-Agent-Client-Hints (UA-CH) zur Bereitstellung zusätzlicher Formfaktoren wie TV, VR | Wir arbeiten noch an einigen wichtigen Designentscheidungen (ob wir einen einzelnen Wert wie „TV“ oder eine Liste von Formfaktorfunktionen bereitstellen möchten), bleib aber weiterhin daran interessiert, für diese Idee Prototypen zu entwickeln. |
| Privacy Budget | Privacy Budget-Einschränkungen können dazu führen, dass UA-CH-Anfragen nicht deterministisch werden, wenn zu viele Anfragen gesendet werden. | Derzeit gibt es keine neuen Änderungen am Privacy Budget-Vorschlag. Wir haben uns aber verpflichtet, Anfragen für UA-Client-Hinweise vor der Einstellung von Drittanbieter-Cookies nicht einzuschränken. |
| Website-Kompatibilität | Websites verwenden die Marke „UA-CH“, um den Zugriff bestimmter Browser auf Websites zu verhindern. | Es gibt zulässige Anwendungsfälle für Markenlisten, darunter die genaue Kompatibilität. Es ist kostenlos, mehrere Marken zu haben, um diese Probleme zu umgehen. |
IP Protection (früher Gnatcatcher)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Betrug und Missbrauch | Wie können Unternehmen mit IP-Schutz Maßnahmen zur Betrugsbekämpfung ergreifen? | Wir wissen, wie wichtig der Schutz vor Betrug ist und welche Auswirkungen das hat. Im Laufe des Sommers werden wir weitere Details zur Unterstützung zur Betrugsbekämpfung veröffentlichen. Wir bitten um Feedback dazu, wie wir den Schutz vor Betrug noch besser unterstützen können. |
| GeoIP | Weitere Informationen zum Zeitplan für Tests und die Bereitstellung von GeoIP | Chrome hat vor Kurzem neue Informationen zu unseren GeoIP-Plänen veröffentlicht. Wir planen, im 3. Quartal weitere Informationen zum Zeitplan für die Bereitstellung zu veröffentlichen. Wir gehen davon aus, dass wir den IP-Schutz anfangs für einen kleinen Prozentsatz des Traffics als Opt-in-Funktion einführen. Wir sind uns bewusst, dass dieser Vorschlag möglicherweise erhebliche Änderungen für Unternehmen mit sich bringt, und wir möchten dem 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? | Wir planen, im Laufe dieses Sommers weitere Details zur Kontoauthentifizierung zu veröffentlichen. Einige erste Schritte haben wir jedoch bereits angekündigt. |
Eindämmung von Bounce-Tracking
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Anleitung für Tests | Informationen zum Testen der Eindämmung von Bounce-Tracking | Im Mai haben wir einen Blogpost mit weiteren Informationen dazu veröffentlicht, wie Sie die Eindämmung von Bounce-Tracking testen können. |
| Dokumentation | Klarheit im Bounce-Tracking-Vorschlag | Der aktuelle Vorschlag ist noch in der Entwicklung und wird von Chrome kontinuierlich aktualisiert, um für mehr Klarheit und Informationen zu sorgen. Wir arbeiten daran, weitere Details zur Verfügung zu stellen, und freuen uns über jedes Feedback. |
| Löschen von Cookies | Werden durch die Eindämmung von Bounce-Tracking alle Cookies in einer Domain gelöscht? | Die Eindämmung von Bounce-Tracking (BTM) löscht den gesamten Speicher und den gesamten Cache, wie hier erläutert. |
| Umgehen der Eindämmung von Bounce-Tracking | Die Klassifizierung des Bounce-Trackers kann durch Weiterleitungen mit Pop-ups oder neuen Tabs umgangen werden. | Die Spezifikation zur Eindämmung von Bounce-Tracking ist noch in der Entwicklung. Bisher haben wir uns hauptsächlich mit Weiterleitungen auf denselben Tab beschäftigt. Wir planen jedoch, in Zukunft Pop-up-Abläufe zu integrieren. Hier kannst du uns zusätzliches Feedback geben. |
Privacy Budget
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Ausrichtung auf Umgebung | Das Privacy Budget kann sich auf Anwendungsfälle für das Umgebungs-Targeting auswirken. | Wir haben Feedback zu diesem Thema erhalten und würden gerne mehr über die möglichen Auswirkungen auf dieses Thema erfahren. |
Websiteübergreifende Datenschutzgrenzen stärken
First-Party-Sets
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| (Auch in vorherigen Quartalen angegeben) Domainlimit | Anfrage zur Erweiterung der Anzahl verknüpfter Domains | Chrome evaluiert derzeit ein entsprechendes numerisches Limit für die verknüpfte Teilmenge, mit dem ein ausgewogenes Verhältnis zwischen Datenschutz und Nutzen für die identifizierten Anwendungsfälle geschaffen wird. Von Anfang an hat Chrome mitgeteilt, dass die genaue Zahl für die verknüpfte Untergruppe noch nicht endgültig feststeht. |
| Eingebetteter Anwendungsfall | Unterstützung für eingebettete Anwendungsfälle, die First-Party-Sets, CHIPs und gemeinsamen Speicher erfordern | Chrome hat das Feedback zu diesem Anwendungsfall erhalten. Das Team wird es untersuchen und wir freuen uns über zusätzliches Feedback. |
| Repository-Verwaltung | Informationen zu Richtlinien zum Entfernen von First-Party-Sets aus dem GitHub-Repository, falls Diskrepanzen auftreten oder es vernachlässigt wird | Chrome hat das Feedback zu diesem Anwendungsfall erhalten. Das Team untersucht den Fall und freut sich über zusätzliches Feedback. |
| Nutzerschulung | Chrome sollte die Bekanntheit und das Verständnis von First-Party-Sets steigern, um die Akzeptanz zu erhöhen. | Das Ziel von Chrome ist es, Nutzer über First-Party-Sets aufzuklären. Zu diesem Zweck hat Chrome einen entsprechenden Hilfeartikel veröffentlicht, den Sie über die Chrome-Benutzeroberfläche aufrufen können. Chrome arbeitet auch weiterhin daran, Nutzer in den jeweiligen Kontexten am besten zu informieren. |
| Post-3PCD | Drittanbieter-Cookies bleiben in einem First-Party-Set auch nach der Einstellung von Drittanbieter-Cookies erhalten. | requestStorageAccess und requestStorageAccessFor stellen Drittanbieter-Cookies zwar wieder für spezifische, klar definierte Anwendungsfälle zur Verfügung, aber sie erfordern jetzt einen aktiven Aufruf durch die Website und sind nicht standardmäßig verfügbar, wie es derzeit bei Drittanbieter-Cookies (in Chrome) der Fall ist.Auch wenn dieser Aufruf innerhalb eines einzelnen Satzes keine Genehmigung durch den Nutzer erfordert, können Nutzer dies verhindern, indem sie diese Funktion in den Einstellungen deaktivieren. Weitere Informationen sind in diesem Hilfeartikel verfügbar, den Nutzer über die Chrome-Benutzeroberfläche aufrufen können. Wir planen, den bestehenden Entwicklerleitfaden zu erweitern, wenn die Framerate auf 100 % ansteigen soll. |
| Einreichung von First-Party-Sets | Benennen Sie die erforderliche .well-known/first-party-set um, sodass sie eine JSON-Erweiterung enthält. |
Wir haben diese Änderung vorgenommen, um sicherzustellen, dass bestimmte Webhosting-Tarife unterstützt werden. |
| IANA-Registrierung | first_party_sets.JSON muss bei IANA registriert sein |
Wir prüfen den Vorschlag und freuen uns über zusätzliches Feedback. |
Fenced Frames-API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Anzeigenblockierung | Mit Fenced Frames können Werbeblocker Anzeigen leichter blockieren. | Erweiterungen können mit Fenced Frames auf ähnliche Weise interagieren wie mit iFrames. Die tatsächliche URL, zu der der umzungene Frame navigiert ist, ist auch für Erweiterungen sichtbar. Daher können sie wie bei iFrames beliebige Regeln für die URL-Übereinstimmung für die Blockierung anwenden. Wenn Sie einfach alle abgegrenzten Frames bedingungslos blockieren, funktionieren mit Fenced Frames nicht werbebezogene Anwendungsfälle unter Umständen nicht mehr. |
Shared Storage API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Größere Akzeptanz | Der freigegebene Speicher sollte ein branchenüblicher Standard sein, der in allen Browsern verfügbar ist. | Wir freuen uns über Ihr Feedback und freuen uns über Ihr Feedback. Chrome nimmt weiterhin aktiv an den W3C-Foren teil, um den Vorschlag zu fördern, Feedback einzuholen und die Akzeptanz zu fördern. |
| Ausgabegatter | Ausgabegatter für freigegebenen Speicher sind zu begrenzt. | Wir sehen uns dieses Feedback an und freuen uns über weiteres Feedback aus dem System, warum die Ausgabegatter zu begrenzt sind. |
| Gesetzliche Vorschriften | Wie wird der gemeinsame Speicher mit der Einhaltung gesetzlicher Vorschriften gehandhabt, z. B. mit Richtlinien zur Datenaufbewahrung? | Freigegebener Speicher bietet die Flexibilität, Logik zu implementieren und anzupassen, um die Lebensdauer und den Ablauf gespeicherter Daten zu steuern. Anzeigentechnologie-Anbieter können Daten im freigegebenen Speicher basierend auf Schreibzeitstempeln aktualisieren oder löschen. |
| A/B Testing | Wie können A/B-Tests für gemeinsam genutzten Speicher und die Protected Audience API durchgeführt werden? | Wir arbeiten daran, weitere Informationen zu diesem Thema zu veröffentlichen, und hoffen, Ihnen in Zukunft weitere Details zur Verfügung stellen zu können. |
| Limit für gemeinsam genutzten Speicherplatz | Was passiert, wenn das Limit für den freigegebenen Speicherplatz erreicht ist? | Wenn das Limit erreicht ist, werden keine weiteren Eingaben gespeichert. |
| Mehrfachzugriff beim selben Seitenaufbau | Was passiert, wenn beim selben Seitenaufbau mehrmals auf freigegebener Speicher zugegriffen wird? | Am besten lässt sich dies mit der Funktion window.sharedStorage.append(key, value) beheben. Anstatt den Wert für jede Anzeige zu aktualisieren, kann dies zu Konflikten führen, wenn mehrere Anzeigen vorhanden sind. Die Anfügefunktion fügt einfach den neuen Wert am Ende des vorhandenen Werts hinzu. |
| iFrame-Funktionalität | Unterstützt freigegebener Speicher bestimmte iFrame-Funktionen, wenn diese nach der Einstellung von Drittanbieter-Cookies nicht mehr funktionieren? | Nach der Einstellung von Drittanbieter-Cookies wird der lokale Speicher in iFrames von der Website der obersten Ebene partitioniert, die iFrames selbst werden jedoch nicht blockiert. Die Daten im lokalen Speicher eines iFrames können nicht über mehrere Top-Level-Websites hinweg repliziert werden. Der lokale Speicher kann jedoch innerhalb des iFrames verwendet werden. |
Chips
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Partitionslimit | 10 KiB pro partitionierter Website ist immer noch ausreichend und würde gerne gesenkt werden. | Firefox hat bereits eine positive Position für CHIPS angegeben. Für den Webkit-Support empfehlen wir Entwicklern, dieses GitHub-Problem direkt an Apple zu senden. Es geht dabei um Anwendungsfälle, bei denen partitionierte Cookies gegenüber partitioniertem Speicher bevorzugt werden. |
| Authentifizierte Einbettungen | CHIPs können den aktuellen SSO-Anmeldevorgang aufgrund der unterschiedlichen Partitionierung beeinträchtigen, die sich auf authentifizierte Einbettungen auswirkt. | Wir haben vor, die Storage Access API (mit Nutzeraufforderungen) zu nutzen, um den Anwendungsfall für authentifizierte Einbettungen zu unterstützen. Vor Kurzem haben wir einen Intent-to-Prototyp gesendet. |
| Lebenslange Richtlinien | Gelten mögliche lebenslange Richtlinien für eigene Cookies? | Derzeit ist nicht geplant, eigene Cookies insgesamt zu begrenzen. |
FedCM
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Unterstützung für die OAuth-Autorisierung | Autorisierung von OAuth-Bereichen festlegen, die kein Profil sind | Wir bitten die Web Identity-Community über die FedID CG des W3C aktiv um Input zu den besten Möglichkeiten, die Autorisierung nach der Einstellung von Drittanbieter-Cookies über die Basisauthentifizierung hinaus zu unterstützen. |
| Unterstützung für SAML | Anforderungen für SAML-Support abstimmen | Das Team bittet nach der Einstellung von Drittanbieter-Cookies aktiv um Input aus Forschungs- und Bildungseinrichtungen zu SAML-Supportanforderungen (zusätzlich zum Support für OpenID-Connect). |
Spam und Betrug bekämpfen
Private State Token API (und andere APIs)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Neue Signale entdecken | Mehrere Partner haben eine positive Meinung dazu geäußert, browsergestützte Signale in Bezug auf Geräteintegrität oder Nutzervertrauen zu untersuchen. Im Allgemeinen sind sie auch vorsichtig, wenn neue zweckgebundene Signale ausreichen, um den aktuellen Stand der Betrugserkennung beizubehalten. | Wir freuen uns darauf, gemeinsam neue Vorschläge in der Community zum Schutz vor Betrug und Websicherheit zu entwickeln und ihre Bedenken zu äußern und zu teilen. Genau aus diesem Grund ist die Bekämpfung von Spam und Betrug ein zentraler Arbeitsablauf der Privacy Sandbox und der Grund, warum wir bei der Verbesserung des Datenschutzes weiter in den Schutz der Websicherheit investieren. |
| Positives Feedback zu PST | Mehrere Partner haben Interesse daran bekundet, PSTs für verschiedene Anwendungsfälle zur Betrugsbekämpfung oder Internetsicherheit zu testen oder zu nutzen. | Wir freuen uns über die Unterstützung und das Interesse an weiteren Entwicklungen für neue Lösungen, die PSTs verwenden. Ressourcen und Beispielcode finden Sie auf der Chrome-Entwicklerwebsite. Wir freuen uns immer über Feedback. |
| Betrug und Missbrauch | Leitfaden zur Vermeidung von Werbebetrug und zur Erkennung von Analysefunktionen, nachdem Drittanbieter-Cookies eingestellt wurden, wenn keine Kennungen mehr verfügbar sind. | Wir haben Tools wie Private State Tokens eingeführt, mit denen sich zum Schutz vor Betrug einen Teil der Signale wiederherstellen lässt, die durch Drittanbieter-Cookies verloren gegangen sind. Dabei wurden aber neue Datenschutzeinstellungen eingeführt. Wir investieren aktiv in neue Vorschläge zur Betrugs- und Missbrauchsbekämpfung, um die Funktionen auch bei anderen Privacy Sandbox-Änderungen aufrechtzuerhalten. |
| Informationsrate vom Aussteller zu Ursprungsort | Die Informationsrate zwischen Aussteller und Herkunftsort ist hoch genug, um einzelne Nutzer zu identifizieren. | Wir haben die Spezifikation aktualisiert, um deutlicher zu machen, welche Nutzerdaten mit Private State Tokens übertragen werden können. Standardmäßig 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 Rotation des Notfallschlüssels erforderlich ist). Dadurch wird das Potenzial, zusätzliche Nutzerdaten im Laufe der Zeit zusammenzuführen, verlangsamt. Bei jeder neuen Web-API ist ein ausgewogenes Verhältnis zwischen Nutzen und neuen Nutzerinformationen vorhanden. Wir gehen davon aus, dass PST-Dateien ein ausgewogenes Verhältnis zum Schutz der Nutzerdaten bieten und gleichzeitig wichtige Anwendungsfälle zur Betrugsbekämpfung ermöglichen, die von der Einstellung von Drittanbieter-Cookies betroffen sind. |
| Integration abrufen | Die Einbindung von fetch ist kompliziert und unnötig. |
Die Verwendung von fetch hat Vor- und Nachteile und wir würden eine weitere Standardisierung im Web anstreben. Wir sind jedoch der Meinung, dass es noch zu früh ist, diese Änderung vorzunehmen, bis wir uns ein genaueres Bild davon machen können, wie der Standard aussehen wird. Falls und wann sich ein Standard entwickelt, sind wir auch bestrebt, Webentwickler auf diesen Standard umzustellen. |
| Speicherort | Schlüsselkonfigurationen für Private State Tokens sollten am selben Ort wie das PrivacyPass-Protokoll gespeichert werden. | Während des Ursprungstests gaben Entwickler an, dass sie es bevorzugen, ihre Schlüssel flexibel unter allgemeinen URLs statt in einem .well-known-Verzeichnis zu speichern. Das Format der Schlüsselzusicherung in PrivacyPass eignet sich nicht besonders für eine Version, in der die Schlüsselsätze einen impliziten „öffentlichen Metadatenwert“ zulassen sollen. Wenn eine Variante des PrivacyPass-Abos mit öffentlichen Metadaten standardisiert wird (entweder als POPRF, partielles RSA-Blinding oder als Schlüsselsatz), können wir zu einer zukünftigen Version von PST wechseln, um dies zu unterstützen. |
| Header-Implementierung der API | Fragen zur Header-Implementierung der API | Wenn die API standardisiert wird und die Nutzung dieser API im Ökosystem weiter entwickelt wird, können wir hoffentlich entweder die Standard-Non-Header-Version dieser API unterstützen und möglicherweise die Header-Version einstellen, wenn die Nutzung niedrig genug ist, oder es genügend Entwickler-Tools/-Support für die standardmäßige Korrelation von Ausstellungs-/Einlösungsanfragen mit anderen Daten gibt. Wir besprechen das Problem hier. |
| Anmeldung | Ist die Registrierung von Ausstellern bei Browseranbietern praktikabel? | Wir haben die Spezifikation aktualisiert, um den Ausstellerregistrierungsprozess für Private State Tokens zu beschreiben. Es nutzt zwar einen eigenen Prozess, ähnelt aber den Registrierungsplänen für die restliche Privacy Sandbox, bei der wir Aussteller dazu auffordern, eine öffentliche Erklärung dazu abzugeben, wie sie PSTs verwenden möchten, und die technischen Einschränkungen zum Schutz der Nutzerdaten anerkennen. |