Vierteljährlicher Bericht für das 2. Quartal 2023 mit einer Zusammenfassung des Feedbacks zu den Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.
Im Rahmen seines Engagements gegenüber der CMA hat sich Google bereit erklärt, vierteljährliche Berichte zum Einbeziehung der Stakeholder im Rahmen der Privacy Sandbox (siehe Abschnitt 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Berichte über die Privacy Sandbox werden durch Zusammenfassungen von Feedback von Chrome aus verschiedenen Quellen, wie im Abschnitt Feedback Übersicht, einschließlich, aber nicht beschränkt auf: GitHub Probleme, das Feedbackformular auf privacysandbox.com, Branchenbesprechungen und Foren zu Webstandards. Wir freuen uns über Ihr Feedback zu Chrome aus dem Ökosystem und sucht aktiv nach Möglichkeiten, das Gelernte Designentscheidungen treffen.
Feedbackthemen werden pro API nach Verbreitung sortiert. Hierzu wird ein Zusammenfassung der Rückmeldungen, die das Chrome-Team zu einem nach Thema sortiert und in absteigender Reihenfolge nach der Menge sortiert. Das allgemeine Feedback Themen wurden identifiziert, indem die Themen aus öffentlichen Versammlungen überprüft wurden. (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen über die internen Teams von Google und über öffentliche Formulare präsent.
Genauer gesagt: Besprechungsprotokolle für Besprechungen von Standard-Webgremien und für direktes Feedback die Aufzeichnungen von persönlichen Gesprächen mit Stakeholdern von Google, E-Mails, die einzelne Entwickler, der API-Mailingliste oder der Öffentlichkeit erhalten haben Feedbackformular berücksichtigt wurden. Anschließend koordiniert Google die Teams die an diesen verschiedenen Aktivitäten beteiligt sind, um die relative Häufigkeit der Themen, die sich in Bezug auf die einzelnen APIs ergeben.
Die Erläuterungen zu den Reaktionen von Chrome auf Feedback wurden aus einem häufig gestellte Fragen, tatsächliche Antworten auf von Stakeholdern vorgebrachte Probleme und die Bestimmung für diese öffentliche Berichtsaufgabe zu nutzen. Rückblick auf den aktuellen Fokus von Entwicklung und Tests, Fragen und Feedback insbesondere in Bezug auf Topics, Protected Audience und Attribution APIs zur Berichterstellung
Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingegangen ist, hat möglicherweise noch keinen als Chrome-Antwort angesehen werden.
Glossar der Abkürzungen
- CHIPS
- Cookies mit unabhängigem partitionierten Status
- DSP
- Demand-Side-Plattform
- FedCM
- Föderierte Anmeldedatenverwaltung
- FPS
- First-Party-Sets
- IAB
- Interactive Advertising Bureau
- IDP
- Identitätsanbieter
- IETF
- Internet Engineering Task Force
- IP-Adresse
- Internet Protocol-Adresse
- openRTB
- Echtzeitgebote
- NSZ
- 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
- Willful IP Blindness
Allgemeines Feedback, keine spezifische API/Technologie
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Data Governance und Einhaltung gesetzlicher Vorschriften | Leitlinien für die Nutzung der Privacy Sandbox unter Einhaltung gesetzlicher Vorschriften. | Wie bei jeder neuen Technologie ist jedes Unternehmen dafür verantwortlich, dass bei der Nutzung der Privacy Sandbox alle Gesetze eingehalten werden. Google kann anderen keine Rechtsberatung anbieten. Uns ist jedoch bewusst, dass dies für das Ökosystem von größter Bedeutung ist. Für jedes API haben wir eine umfassende technische Dokumentation veröffentlicht, die als Grundlage für die notwendigen rechtlichen Bewertungen dienen sollte. Wir arbeiten daran, zusätzliche Materialien zur Unterstützung der zur Einhaltung gesetzlicher Auflagen. |
| Vorschlag für quantitative Tests der CMA | Weitere Informationen zum Vorschlag für quantitative Tests der CMA | Wir entwickeln gemeinsam mit der CMA Tests, die Aufschluss über die Auswirkungen der Einstellung von Drittanbieter-Cookies und die Einführung der Privacy Sandbox-Vorschläge auf das System geben. Im April veröffentlichte die CMA allgemeine Leitlinien dazu, was während der Test- und Testphase zu erwarten ist. Im Juni folgten dann eine detaillierte Anleitung. Fragen oder Feedback zum Vorschlag der CMA für quantitative Tests sollten direkt an die CMA weitergeleitet werden. |
| Von Chrome unterstützte Testmodi | Weitere Informationen und Erläuterungen zu den Testplänen | am 18. Mai haben wir einen Blogpost veröffentlicht, in dem wir weitere Informationen zu den beiden von Chrome unterstützten Testmodi vorgestellt haben. Diese Angaben sind noch nicht endgültig. Im 3. Quartal 2023 werden wir weitere Informationen zur Implementierung veröffentlichen. |
| Partitionierter Speicher | Wird partitionierter Speicher bei Chrome-gestützten Tests verwendet? | Die Speicherpartitionierung wird allen Nutzern vor dem Test zur Einstellung von Drittanbieter-Cookies zur Verfügung gestellt. Daher wird er für alle Verzweigungen des Tests aktiviert. In diesem Zeitraum können Websites einen Test zur Einstellung aktivieren, um nicht partitionierten Speicher wiederherzustellen. |
| Produktionssupport | Wie werden in Chrome technische Probleme und Eskalierungen der Privacy Sandbox behoben, die sich auf das System auswirken? | Google bietet verschiedene Kanäle, über die Anzeigentechnologie-Anbieter Probleme melden und notwendige Eskalierungen ermöglichen können. In unserem Entwicklerbeitrag finden Sie weitere Informationen über die öffentlichen und privaten Foren für Feedback und Eskalation. |
| Zeitplan für die Registrierung | Der aktuelle Zeitraum für die Registrierung ist zu kurz | Wir werten die Frist noch aus und würden gern von der Community wissen, welcher Zeitplan besser wäre. |
| D-U-N-S-Nummer | Weitere Informationen zur Anforderung der D-U-N-S-Nummer für die Registrierung und Bestätigung | Teilnehmer finden die Voraussetzungen für den Erhalt einer D-U-N-S-Nummer auf der Website von Dun & Bradstreet. Die Anforderungen variieren je nach Markt. Daher sollten die Teilnehmenden auf der Website für den spezifischen Markt nachdenken, für den sie sich interessieren. Im Allgemeinen müssen die 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 können auch nach finanziellen Informationen wie dem Jahresumsatz des Unternehmens gefragt werden. Sobald der Antrag vollständig ist, wird D&B ihn prüfen und eine D-U-N-S-Nummer ausstellen, wenn er genehmigt wird. |
| Vom Ursprungstest auf General Availability umstellen | Wirkt sich die Umstellung vom Ursprungstest auf die allgemeine Verfügbarkeit auf aktuelle Ursprungstesttester aus? | Ab Juli können Tester auf die APIs für Relevanz und Messung allgemein verfügbar sein. Dadurch entsteht eine Überschneidung zwischen der Verfügbarkeit des Ursprungstests und der allgemeinen Verfügbarkeit. |
| AdExchanger-Studie | Weitere Informationen zur Methodik der Umfrage | In der Umfrage wurden die Befragten gebeten, die Synchronisierungsraten und den Umsatz für ihr Unternehmen zu schätzen. Befragte Methodik zur Beantwortung der individuellen Fragen selbst überlassen. |
| Parameterwerte | Wie werden Parameterwerte wie Rauschpegel, Anonymitätsgrenzwerte und Datenschutzbudget festgelegt? | In dieser Erläuterung auf GitHub werden die allgemeineren Prinzipien hinter den Privacy Sandbox APIs erläutert. Viele Werte sind noch in der endgültigen Fassung und wir freuen uns über Feedback zu diesem Thema. |
Relevante Inhalte und Anzeigen
Themen
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Datenschutz | Studie zur Wahrung des Datenschutzes mit der Topics API | Wir engagieren uns aktiv in der Forschungscommunity und präsentieren unsere Forschungsergebnisse zu den Datenschutzeigenschaften der Topics API in Artikeln, Berichten und Workshop-Präsentationen. Wir freuen uns, dass sich mehr externe Mitglieder der Forschungs-Community in diesem Bereich beteiligen. Die Topics API schützt Nutzer vor allgemeinem Tracking im Web, da es zu schwierig ist, Nutzer in großem Umfang zu erfassen. Diese Artikel zeigen, dass wir dies mit der Topics API erfolgreich umsetzen. Sie ist datenschutzfreundlicher als Drittanbieter-Cookies und schützt Nutzer, während sie gleichzeitig die von ihnen besuchten Websites unterstützen. |
| Taxonomie der Themen nicht detailliert genug | Die Taxonomie der allgemeinen Themen umfasst keine detaillierteren Themen, einschließlich der Region. | Als Reaktion auf früheres Feedback haben wir am 15. Juni einen Blogpost veröffentlicht, in dem wir eine neue aktualisierte Taxonomie beschreiben, die aufgrund des Feedbacks aus dem Ökosystem zahlreiche Verbesserungen enthält. Im Rahmen unserer Arbeit an der überarbeiteten Taxonomie arbeiten wir mit mehreren Unternehmen der Branche zusammen, darunter Raptive (ehemals CafeMedia) und Criteo. Im Rahmen der aktualisierten Taxonomie werden Kategorien entfernt, die unserer Meinung nach weniger nützlich sind. Stattdessen werden Kategorien entfernt, die den Interessen der Werbetreibenden besser entsprechen. Wir arbeiten weiterhin daran, potenziell sensible Themen auszuschließen. Wir empfehlen allen Nutzern, sich die neueste Taxonomie anzusehen und Feedback zu den Änderungen zu geben. |
| Aktualisierungsprozess für Taxonomie und Klassifikator | Weitere Informationen zum Veröffentlichungsrhythmus von Thementaxonomie und -klassifikator und dazu, wie sich Unternehmen auf solche Aktualisierungen vorbereiten können. | Wie in unserem letzten Blogpost bereits mitgeteilt, gehen wir davon aus, dass sich die Taxonomie im Laufe der Zeit weiterentwickelt und die Verwaltung der Taxonomie schließlich auf eine externe Partei umgestellt wird, die Stakeholder aus der gesamten Branche vertritt. Den Erhöhungsplan haben wir auch in der Gruppe topics-announce veröffentlicht. |
| Auswirkungen auf eigene Signale | Die Zunahme der Anzahl der Themen in der kürzlich veröffentlichten Taxonomie könnte sehr nützlich sein und dazu führen, dass andere interessenbezogene Signale von selbst erhobenen Daten abgeschafft werden. | Im Bericht zum 1. Quartal 2023 sagte die CMA: „Uns ist bewusst, dass Google seine vorgeschlagene neue Taxonomie mit mehreren Marktteilnehmern in der gesamten Anzeigentechnologie-Lieferkette diskutiert hat. Einige große Publisher gaben an, dass ein größerer Nutzen von Themen den Wettbewerbsdruck auf ihre Lösungen, die auf selbst erhobenen Daten basieren, erhöhen würde. Wir sind jedoch vorerst davon überzeugt, dass ein größerer Nutzen für den Wettbewerb insgesamt besser ist – insbesondere für die Möglichkeit, dass kleinere Publisher ihr Inventar nach der Einstellung von Drittanbieter-Cookies weiter monetarisieren können.“ Unsere Sichtweise entspricht diesem Kommentar der CMA. |
| Nützlichkeit für verschiedene Arten von Stakeholdern | AdTechs, die als SSPs und DSPs fungieren, können erhebliche Vorteile gegenüber anderen Systemunternehmen 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 gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verzerrt wird, dass das eigene Unternehmen von Google bevorzugt wird. Dabei werden die Auswirkungen auf den Wettbewerb bei 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 nachkommt. Im Verlauf der Tests der Privacy Sandbox wird eine der wichtigsten Fragen, die wir bewerten, danach fragen, wie die neuen Technologien für verschiedene Arten von Stakeholdern abschneiden. In dieser Hinsicht ist Feedback entscheidend, insbesondere konkretes und umsetzbares Feedback, das uns helfen kann, die technischen Designs weiter zu verbessern. Wir haben mit der CMA zusammengearbeitet, um unseren Ansatz für quantitative Tests zu entwickeln, und unterstützen die Veröffentlichung eines Hinweises zum Testdesign, um den Marktteilnehmern mehr Informationen und die Möglichkeit zu geben, die vorgeschlagenen Ansätze zu kommentieren.“ |
| Zugehörige Themen | Stehen bei der Themenauswahl die Häufigkeit von Browserbesuchen an? Stehen aufgrund von Segmentierung auch nachgeordnete Themen nie ganz oben? | Chrome bewertet derzeit andere Ranking-Methoden und untersucht weitere Signale, die das Ranking verbessern können. Wir werden unsere überarbeiteten Pläne zu gegebener Zeit an das Ökosystem weitergeben. |
| Vertraulichkeit | Ziel der Topics API ist es, sicherzustellen, dass Nutzerinformationen, die über die Topics API abgerufen oder abgeleitet werden, weniger personenbezogene Daten enthalten sollten, als dies mit den heutigen Tracking-Methoden möglich wäre. | Wir sind der Meinung, dass die Topics API wesentlich privater als mit aktuellen Technologien ist, die Re-Identifikation von Nutzern erheblich einschränkt und sensible Themen ausschließen soll. Uns ist bewusst, dass Themen mit selbst erhobenen Daten in Beziehung zueinander stehen oder diese zum Erstellen sensibler Kategorien kombiniert werden können. Wir sind jedoch der Meinung, dass die Topics API einen Schritt in Richtung Datenschutz für Nutzer darstellt, und sind bestrebt, die API weiter zu verbessern. |
| Taxonomiestruktur | Der Themen-Taxonomie ID, Versionsverwaltung und andere Metadatenstrukturen hinzufügen | Aktuell fügen wir in der API-Antwort die Taxonomie-ID ein. Auf dem Weg zur langfristigen Governance ist es sinnvoll, das Topics-Objekt zu überprüfen und bei Bedarf zusätzliche Metadaten für die Versionsverwaltung hinzuzufügen. |
| Steuerung durch den Publisher | Publisher sollten mitentscheiden können, unter welchen Themen ihre Websites klassifiziert werden sollen. | Eine falsche Klassifizierung von Websites kann dazu führen, dass das Topics-Signal insgesamt weniger nützlich als Signal ist. Die falsch klassifizierten Websites werden davon aber nicht stärker und ebenso wenig beeinträchtigt wie alle anderen Websites. Der Grund dafür ist, dass die Kontextinformationen einer Website immer für Auktionen auf der Website verfügbar sind, sodass auch bei falscher Klassifizierung vergleichbare Informationen zum richtigen Thema bereitgestellt werden. Du kannst uns gern Feedback zu diesem Thema geben. Es birgt Risiken, wenn Publisher ihre Klassifizierung steuern können. Websites können ihre Websites absichtlich falsch klassifizieren, um den Nutzen für alle zu reduzieren oder sensible Bedeutungen zu weniger gängigen Themen zu codieren, wodurch die Privatsphäre der Nutzer verletzt wird. |
| 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 vonseiten der Community. |
| Umstellung auf General Availability | Hat die Umstellung vom Ursprungstest auf die allgemeine Verfügbarkeit Auswirkungen auf die Topics API? | Für Nutzer, die vom Ursprungstest auf die allgemeine Verfügbarkeit umstellen, gehen keine Daten verloren. |
| Datenschutz | Hostnamen können private Informationen enthalten, die von der Topics API offengelegt werden | Wir haben eine Reihe von Maßnahmen zum Schutz der Privatsphäre, die hier beschrieben sind. |
| Betrug und Missbrauch | Manipulation von Topics durch betrügerische Besuche verhindern | Informationen zu den Maßnahmen zur Risikominimierung |
| Themenklassifikator | Können Websites eine Änderung der Topics-Klassifizierung anfordern? | Wir freuen uns immer über Feedback zu diesem Thema. Hier kannst du uns gerne Feedback dazu geben. |
| Websites von Topics-Anbietern | Bestimmte Websites, auf denen Inhalte zu vielen Themen gehostet werden, können als „Websites von Anbietern spezieller Themen“ gekennzeichnet werden. und Klassifikatoren basierend auf den auf den Webseiten bereitgestellten Tags trainieren. | Wir beraten den Vorschlag hier und freuen uns über zusätzliches Feedback. |
Protected Audience API (früher FLEDGE)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Anpassung an den Traffic | Auswirkungen der SSP-gesteuerten Filterung auf die Leistung, um die Last für Abfragen pro Sekunde (Queries per Second, QPS) zu optimieren | Wir haben viel über Trafficmuster nachgedacht. Wir empfehlen SSPs, die Vorteile des Cachings zu nutzen. |
| Testvolumen | Es ist schwierig, Protected Audience zu testen, da SSPs und DSPs Schwierigkeiten haben, große Traffic-Volumen zu erhalten. | Wir arbeiten ständig mit SSP- und DSP-Partnern zusammen, um Protected Audience einzuführen und zu testen. General Availability hat begonnen und wir sind zuversichtlich, dass der Prozentsatz der Zugriffe mit aktiviertem privaten Inventar für Partner zum Testen besser geeignet wird. |
| Komplexität | Die Implementierung von Protected Audience-Lösungen ist mit erheblichen Aufwand und Kosten verbunden. | Uns ist bewusst, dass es schwierig ist, neue Technologien zu implementieren, einschließlich der Privacy Sandbox. Das Privacy Sandbox-Team arbeitet eng mit einer Vielzahl von Interessenvertretern zusammen, um ihre Bemühungen zu informieren und zu unterstützen, und prüft kontinuierlich andere Technologien, um die Einführung des Ökosystems zu unterstützen. |
| Vertrauenswürdige Ausführungsumgebungen | Unterstützung für Trusted Execution Environments (TEE) in nicht öffentlichen Cloud-Umgebungen | Wir prüfen zwar mögliche zusätzliche Optionen, die über cloudbasierte Lösungen hinausgehen, aber es ist derzeit nicht möglich, lokale TEEs zu unterstützen, da lokale Sicherheitseinschränkungen eine zeitaufwendige Bewertung für die Privacy Sandbox erfordern. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, sind wir der Meinung, dass die Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z.B. die Unterstützung von GCP zusätzlich zu AWS) für das Ökosystem am vorteilhaftesten ist. Wir freuen uns aber über zusätzliches Feedback darüber, warum eine solche Anforderung notwendig ist. |
| Kostenstruktur | Gebote und Das Angebot für Auktionsdienste erhöht die Kosten und die Komplexität für Anzeigentechnologien im Vergleich zu clientseitigen Modellen. | Wir arbeiten derzeit an einem Leitfaden zur Schätzung der Kosten für die Unterstützung von Gebots- und Auktions-Workflows in der Auktionsserver, der mit der Nutzung von Anzeigentechnologie korreliert und eines der Ziele unserer Designs erfüllt. |
| K-Anon-Zeitachsen | Wann werden die geplanten k-Anonymitätsbeschränkungen für "renderUrl" erzwungen? | Wir arbeiten an einer Erläuterung des Zeitplans für die Durchsetzung, die wir bald veröffentlichen werden. |
| runAdAuction-Einschränkungen | Kann in Chrome festgelegt werden, dass runAdAuction nur von der obersten Seite aus aufgerufen werden kann? |
Unser Design unterstützt zwar in vollem Umfang, dass runAdAuction von der obersten Seite aus aufrufbar ist, aber wir sind der Meinung, dass es für Publisher schädlicher wäre, die App so zu beschränken, dass sie nur von der Top-Domain aus aufrufbar ist.Wir haben insbesondere von der Branche gehört, dass die Privacy Sandbox die Belastung von Publishern und Werbetreibenden minimieren muss. Dieses Feedback entspricht dem allgemeinen Grundsatz der Webentwicklung, dass Websiteinhaber Tools von Drittanbietern für den Betrieb ihrer Websites verwenden können. Das Ziel der Privacy Sandbox ist es, eine gesunde Umgebung zu fördern, ohne vorschreiben zu müssen, wie Publisher und Anzeigentechnologie-Anbieter funktionieren. Da der Publisher auswählen kann, wie und wer runAdAuction auf seiner Website aufruft, sind wir der Meinung, dass wir Publishern die Flexibilität bieten, die beste Methode für ihre Anforderungen zu finden. |
| Unterstützung bei der Implementierung | Kann Chrome eine Open-Source-Implementierung einer Auktion für mehrere Verkäufer erstellen oder an dieser teilnehmen? | Ziel der Privacy Sandbox ist es, datenschutzfreundliche Technologien zu entwickeln, die nicht auf Drittanbieter-Cookies oder anderen websiteübergreifenden Kennungen beruhen. Wir möchten eine gesunde Umgebung fördern, ohne vorschreiben zu müssen, wie Anzeigentechnologien funktionieren. Wir haben eine Anleitung zur Funktionsweise der APIs in unserem GitHub-Repository veröffentlicht und sind offen für die Erkundung von Lösungen in der Branche. Wir planen keine spezifische Implementierung, da unsere Hauptaufgabe darin besteht, Plattformtechnologien zu entwickeln, und nicht, Strategien für die Nutzung dieser Technologien vorzugeben. Mit unseren Technologien können Unternehmen im Bereich Anzeigentechnologie ihren Kunden die richtigen Datenschutzvorkehrungen bieten. |
| Mehrfachkundenauktionen | Erzwingt Chrome die Freigabe eines Komponentenauktionen für den Sieg bestimmt? | Mit der Protected Audience API können Parteien, die eine Auktion mit mehreren Verkäufern initiieren, Informationen an die Komponentenauktion weitergeben (Hinweis: nur vor Beginn der Auktion). Dennoch sehen wir keine Möglichkeit für den Browser, zu erkennen, ob eine Information kontextbezogen gewinnt oder nicht. Daher konnten wir die Sperrung oder die Anforderung bestimmter Informationen nicht erzwingen. |
| Nutzereinstellung für das Einwilligungs-Tracking | AdTech fragt PA, wie die Nachverfolgung der Nutzereinwilligung korrekt implementiert werden soll | Unsere Antwort enthält das, was wir im 1. Quartal gesagt haben: „Bei bestimmten Anzeigen ist die relevante Anzeigentechnologie die Partei, die am besten Kontrolle darüber hat, welche Creatives präsentiert oder wie sie ausgewählt werden.“ Wir haben bei der WICG Protected Audience-Besprechung im Mai über einige Szenarien mit diesem Problem gesprochen und freuen uns über zusätzliches Feedback und weitere Diskussionen zu diesem Thema. |
| 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 eingebunden werden kann, werden derzeit entwickelt. Sie werden SSPs und anderen Anzeigentechnologie-Anbietern zur Verfügung gestellt, um sie bei ihren Integrationsschritten zu unterstützen. |
| Formate | Werden Videos von der Protected Audience API unterstützt? | Videoanzeigen werden auf zwei Arten ausgeliefert: als VAST-XML oder als HTML (Out-Stream-Anzeige, die letztendlich auch VAST-XML in einen Videoplayer laden kann). Käufer können jedes Format über eine render-URL zurückgeben. Die VAST-Spezifikation wurde vor Kurzem aktualisiert, um die Attribution Reporting API zu unterstützen. Websites, auf denen Videoanzeigen ausgeliefert werden, müssen auf die Art und Weise vorbereitet sein, wie Anzeigen über die Protected Audience API ausgeliefert werden. Das bedeutet, dass Placement-Tags die URL von einem Protected Audience-iFrame an einen Videoplayer übergeben können. Bei Fenced Frames werden wir uns um die Anforderungen an Videos kümmern, bevor wir Fenced Frames erst ab 2026 verwenden müssen. |
| Taktung | Wie funktioniert die Budgetabstufung mit der Protected Audience API? | Vielen Dank für dein Feedback. Wir würden uns über weitere Instanzen dieser Anfrage mit weiteren Details von mehr SSP-Partnern freuen, da dies bisher hauptsächlich ein Problem der DSP war. |
| Aktualisierungshäufigkeit | Die Häufigkeit von Anrufen über dailyUpdate (bis zu einer pro Interessengruppe und Tag) reicht für bestimmte Anwendungsfälle wie die Aktualisierung von Produktinformationen möglicherweise nicht aus. |
Vielen Dank für dein Feedback. Es gibt andere Lösungen, mit denen Anzeigentechnologie-Anbieter Signale verwenden können, die in unterschiedlichen Intervallen aktualisiert werden, z. B. Schlüssel/V-Suchen. |
| Anzeigenqualitätskontrolle | Wie implementieren Publisher die Qualitätskontrolle für Anzeigen? | Die Protected Audience API bietet Publishern derzeit Funktionen, mit denen sie ihre SSPs über bestimmte Einstellungen informieren können, die sie im Rahmen der Auktionskonfiguration vor der Gebotsabgabe 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 für die Plattform möglicherweise erforderlich sind. |
| Debugging | Wann wird die Funktion „forDebuggingOnly“ entfernt? |
Wir planen, forDebuggingOnly aufgrund von Verlustereignissen aufgrund der Einstellung von Drittanbieter-Cookies einzustellen. forDebuggingOnly soll 2026 für Siegerveranstaltungen frühestens 2026 eingestellt werden. |
| 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 birgt erhebliche datenschutzrechtliche Bedenken, wie in diesem GitHub-Problem erläutert. |
| (Auch im 1. Quartal erfasst) Dynamisches Remarketing | Ist dynamisches Remarketing mit der Protected Audience API auch nach der Einstellung von Drittanbieter-Cookies möglich? | Wir sind der Meinung, dass dieser Anwendungsfall mit Protected Audience möglich ist. Weitere Informationen finden Sie hier. |
| Klickbezogene Daten | Klickbezogene Daten zu browserSignals. hinzufügen |
Wir bitten derzeit um Informationen zum Zeitpunkt des Klicks, um eine vorläufige Position zu bieten. |
| (Auch im 4. Quartal 2022 gemeldet) Benutzerdefinierte Funktionen in Protected Audience | Wie werden benutzerdefinierte Funktionen (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. | Die AdTech-Abteilung, die dieses Problem gemeldet hat, gab auch an, dass sie noch auswertet, was sie mit UDFs tun können. Daher gibt es hier noch kein umsetzbares Feedback, auf das sie reagieren müssen, erst nach der allgemeinen Verfügbarkeit. |
| Währung | Währungsbeträge sollten nicht durch Gleitkommazahlen dargestellt werden. | Ausführliche Informationen zu diesem Problem |
| Nicht-DSP-Funktionen für die Anzeigenauswahl | Welche Rolle spielen Ad-Server bei Protect Audience API-Auktionen? | Uns sind die Anfragen von Ad-Servern bekannt, die sie uns weiterhin zur Verfügung stellen möchten, um Dienste zur Anzeigenauswahl nach Gebotsabgabe oder zur Optimierung dynamischer Creatives anzubieten. Wir prüfen derzeit die detaillierte Analyse der Lücke zwischen der aktuellen Protected Audience API und diesen Anfragen. |
| GenerateBid | Unterstützung für Google Ads Vorschlag, mehr als eine mögliche Anzeige pro Interessengruppe von generateBid zurückzugeben und diese Kandidaten in "scoreAd" zu bewerten. |
Diese wird derzeit ausgewertet. Hier kannst du uns zusätzliches Feedback geben. |
| Auktionsauftrag | Müssen Protected Audience API-Auktionen als letzte ausgeführt werden, damit die Ergebnisse der anderen Auktionen berücksichtigt werden können? | Es gibt keine technischen Anforderungen, dass die Protected Audience API zuletzt verwendet werden kann. |
| Nicht vom Nutzer initiierte Navigation | Nicht vom Nutzer initiierte Navigation freigeben | Wir prüfen diese Anfrage und betreuen sie hier . Wir freuen uns über zusätzliches Feedback. |
| Caching | Bei einer SSP sollten die proBuyerSignals-Daten einer DSP einer bestimmten DSP nicht aus einem Cache erstellt werden, wenn sich der Nutzerstatus ändert. | Uns ist bewusst, dass das Caching nicht bei jedem Anwendungsfall für PerBuyer-Signale funktioniert, und arbeiten daran, weitere Optionen zu testen. Wir freuen uns über zusätzliches Feedback aus der Branche, ob Caching für ihre Anwendungsfälle geeignet ist. |
| Attributionsberichte und Protected Audience | Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? | Integrationen sind derzeit für die Protected Audience API für beide Attribution Reporting API-Modi (Berichte auf Ereignisebene und zusammenfassende Berichte) verfügbar. am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung der Protected Audience API und Attributionsberichte veröffentlicht. Weitere Informationen dazu finden Sie hier. |
| Serverendpunkt | Wird der Serverendpunkt im endgültigen Design der vertrauenswürdige Aggregationsserver? | Der Serverendpunkt ist ein von AdTech verwalteten Endpunkt, der von den vertrauenswürdigen Aggregationsservern unabhängig ist, die zur Verarbeitung der erfassten und transformierten Berichte verwendet werden. Derzeit sind keine Änderungen am Berichtsendpunkt geplant. Das aktuelle Design zielt darauf ab, sicherzustellen, dass die aggregierbaren Berichte selbst (mit verschlüsselten Nutzlasten) keine websiteübergreifenden Daten verlieren. Daher sollte ein vertrauenswürdiger Endpunkt nicht erforderlich sein. Eine weitere Komplikation besteht darin, dass unterschiedliche Anzeigentechnologie-Anbieter wahrscheinlich unterschiedliche Batch-Strategien verfolgen 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 betreuen 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 behandeln dieses Problem und würden uns über zusätzliches Feedback freuen. |
| Kontobasiertes Marketing | Sind Anwendungsfälle für kontobasiertes Marketing möglich? | Die Protected Audience API unterstützt eine Vielzahl von zielgruppenbasierten Marketinganwendungsfällen. Wir verstehen weiterhin, wie die Protected Audience API diesen speziellen Anwendungsfall am besten unterstützen kann, und freuen uns auf zusätzliches Feedback zu diesem Problem. |
| Komponentenauktion | Was schneiden die Teilnehmer einer Komponentenauktion ab? | Bei den Komponentenauktionen werden Interessengruppen nicht direkt bewertet. Stattdessen werden die Anzeigen und Gebote bewertet, die eine DSP über die Funktion generateBid einreicht. Die Funktion generateBid() wird pro Interessengruppe ausgeführt und 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 in der GitHub-Codebasis des Schlüssel/Wert-Servers. | Wir arbeiten daran, unsere relevanten Prozesse so zu aktualisieren, dass auch externe Beiträge zum GitHub-Code unterstützt werden. |
| Größe der Interessengruppe | Wie viele Schlüssel kann „IG“ maximal unterstützen? | Die Größe eines IG beträgt aktuell 50 KB, wobei die Tasten dabei berücksichtigt werden. Wir freuen uns über weitere Diskussionen zur 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 für Komponentenauktionen und auch für 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 Anzeigentechnologie-Code. In der Bidding and Auktion API kann in der SelectAd-Anfrage die Version des Codes angegeben werden, der für die Auktionsanfrage verwendet wird (d.h. für Gebote / Auktionen und auch für die Berichterstellung). |
| Gemeinsam genutzter Speicher | Unterstützung beim Schreiben an freigegebenen Speicher im Gebots- und Auktionsdienst. | Gemeinsamer Speicher wird von Gebots- und Auktionsdiensten derzeit nicht unterstützt. Wir freuen uns jedoch über zusätzliches Feedback dazu, warum solche Anwendungsfälle für die Plattform wichtig sind. |
| Web-to-App | Sie können die Web-zu-App-Freigabe von Interessengruppen unterstützen. | Web-to-App wird bei der Bereitstellung der Protected Audience API in Chrome und Android derzeit nicht berücksichtigt. Wir würden uns jedoch über die Bedeutung dieses Anwendungsfalls freuen. |
| K-Anonymität | Umgang mit K-Anonymitäts-Fallbacks | Wir behandeln das Problem und würden uns über zusätzliches Feedback freuen. |
Digitale Anzeigen analysieren
Attribution Reporting (und andere APIs)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Konfigurationen für Berichte auf alternative VTC-Ereignisebene | Feedback zu Konfigurationen für Berichte zu alternativen VTC-Ereignissen auf Ereignisebene | Wir haben von einigen Rückmeldungen erhalten, dass die aktuellen Konfigurationen auf Ereignisebene nicht optimal sind. Deshalb möchten wir Sie um Feedback zu optimalen globalen Konfigurationen bitten. Wir freuen uns über zusätzliches Feedback dazu und sind der Meinung, dass unsere flexible Erläuterung auf Ereignisebene ebenfalls hilfreich ist, um dieses Problem anzugehen. |
| Flexible Konfigurationen auf Ereignisebene | Wie lautet der Status der Funktion für flexible Konfigurationen auf Ereignisebene? | Wir haben eine Dokumentation zur flexiblen Konfiguration auf Ereignisebene veröffentlicht. Die Funktion befindet sich noch in der Entwurfsphase und wir freuen uns auf mehr Feedback dazu, ob sie für die Plattform nützlich sein wird. |
| Flexible Konfigurationen auf Ereignisebene | Wie können in Konflikt stehende Reports von verschiedenen Parteien abgeglichen werden? | Die meisten Berichtsszenarien werden durch aggregierte Berichte abgedeckt. Das flexible Konfigurationsangebot auf Ereignisebene hingegen bietet zusätzliche Flexibilität für Berichte auf Ereignisebene, die am häufigsten zur Optimierung eingesetzt werden. Wir freuen uns über weitere Kommentare/Feedback zu diesem Szenario. |
| Quellenregistrierung | Was geschieht, wenn die Quellenregistrierung nach der Triggerregistrierung erfolgt? | Wenn eine Quellenregistrierung nach der Triggerregistrierung erfolgt, können Quelle und Trigger derzeit nicht einander zugeordnet werden. Dies scheint ein Grenzfallszenario zu sein. Wir freuen uns über zusätzliches Feedback zu diesem Problem und werden uns bemühen, das Problem zu beheben, wenn dies ein Szenario ist, mit dem viele Anzeigentechnologie-Anbieter zu kämpfen haben. |
| 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. Darüber hinaus bestehen einige Einschränkungen in Bezug auf Weiterleitungen, um sicherzustellen, dass die API den Datenschutz verbessert. Wir haben auch eine mögliche Problemumgehung identifiziert, die mithilfe der Shared Storage API für das spezifische Szenario der Anzeigentechnologie funktioniert. Wir freuen uns über zusätzliches Feedback zu diesem Szenario und werden es auf Grundlage dieses Feedbacks weiter iterieren. |
| Limits für Ziele | 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 erfahren, welche Begrenzungen angemessen wären. Wir haben der Erklärung zu Attributionsberichten mit Berichten auf Ereignisebene hinzugefügt, dass der Browser die Anzahl der durch Quellwebsites dargestellten „Ziel“-eTLD+1 einschränken kann. (Siehe Pull-Anfrage). |
| Attributionsberichte und Protected Audience | Wie können die Attribution Reporting API und die Protected Audience API zusammenarbeiten? | Integrationen sind derzeit für die Protected Audience API für beide Attribution Reporting API-Modi (Berichte auf Ereignisebene und zusammenfassende Berichte) verfügbar. am 1. Juni haben wir weitere Informationen zur verbesserten Einbindung der Protected Audience API und Attributionsberichte veröffentlicht. Weitere Informationen dazu finden Sie hier. |
| Flexible Konfigurationen auf Ereignisebene | Teilen Sie Best Practices für die Rauschsimulation, da die Parameter jetzt konfigurierbar sind. | Wir haben Code auf GitHub freigegeben, mit dem jeder den Informationszuwachs und die Auswirkungen des Rauschens für flexible Konfigurationen auf Ereignisebene bewerten kann, die er testen möchte. Wir würden gerne von jedem hören, der sich für einen Test mit dem Code entschieden hat und uns Feedback geben möchte. |
| App- und Web-Attributionsmessung | Ab wann können App- und Web-Attributionsdaten erfasst werden? | Am 9. Mai haben wir einen Test für die App- und Web-Attributionsmessung über die Attribution Reporting API angekündigt. Für die APIs für Relevanz und Messung in Chrome 115 ist „General Availability“ geplant, aber die App- und Web-Attributionsmessung ist derzeit noch nicht für Chrome 115 geplant. |
| Conversions deduplizieren | Wie können unabhängige Analysetools mit ARA abgeglichen werden? | Wie bei der aktuellen Praxis würden Werbetreibende mit einem unabhängigen Anbieter für Messungen zusammenarbeiten, um Conversion-Berichte zu deduplizieren. Wir bieten Ressourcen zum Deduplizieren von Conversions für Berichte auf Ereignisebene. |
| Datenverlust bei Aktualisierungen der Attribution Reporting-Datenbank | Wird es zu Datenverlusten kommen, wenn die Attribution Reporting Database wie angekündigt in Chrome aktualisiert wird? | Ab Chrome 115 werden die APIs für Relevanz und Messung für einen Teil der Chrome-Nutzer standardmäßig aktiviert. Wir prüfen die Verfügbarkeit aber regelmäßig auf potenzielle Probleme. Ziel ist es, bis zum 3. Quartal 2023 über einen Zeitraum von mehreren Wochen 100% Verfügbarkeit zu erreichen. Dies fällt mit dem Ende des Ursprungstests für Relevanz und Messung zusammen. Ab Juli können sich Tester für den allgemeinen Zugriff auf diese APIs registrieren. Dadurch wird eine Überschneidung zwischen der Verfügbarkeit des Ursprungstests und der allgemeinen Verfügbarkeit durch die Registrierung geschaffen. Das Token für den Ursprungstest ist bis zum 19. September gültig. Wir empfehlen Ihnen jedoch, sich vor dem Ablauf für die APIs zu registrieren, um nahtlos vom Ursprungstest zu wechseln, ohne laufende Tests zu unterbrechen. Wie in dieser Mitteilung erwähnt, werden Daten, die aus älteren Versionen (M113 und älter) registriert wurden, nach dem Update nicht migriert, sodass es zu Datenverlusten kommen kann. Dieser Datenverlust wird in Debug-Berichten nicht aufgeführt. Wir versuchen, Datenverluste zwischen 114 und 115 zu vermeiden. |
| Abrechnung | Attribution Reporting für die Cost-per-Conversion-Abrechnung verwenden | Wie in diesem Artikel beschrieben, eignet sich die Attribution Reporting API möglicherweise nicht für die Cost-per-Conversion-Abrechnung, da Berichte auf Ereignisebene und zusammenfassende Berichte mit Rauschen versehen werden. Wir ermutigen alle Beteiligten, Feedback zu den Auswirkungen der Attribution Reporting API auf die verschiedenen Abrechnungsmodelle auf GitHub zu geben. |
Zusammenfassungsdienst
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Änderung der Verzögerung für aggregierte Berichte | Positive Reaktionen auf den Vorschlag, die Verzögerung für den aggregierten Bericht aufgrund des Feedbacks aus dem Ökosystem von [10–60 Minuten] auf [0–10 Minuten] zu ändern | Wir freuen uns über positive Reaktionen auf die vorgeschlagene Änderung und ermutigen die Community, auch weiterhin Feedback zu unseren Vorschlägen zu geben. |
| Lokale Lösung | Kann der Aggregationsdienst in lokalen Rechenzentren bereitgestellt werden? | Wir prüfen zwar mögliche zusätzliche Optionen, die über cloudbasierte Lösungen hinausgehen, aber es ist derzeit nicht möglich, lokale TEEs zu unterstützen, da lokale Sicherheitseinschränkungen eine zeitaufwendige Bewertung für die Privacy Sandbox erfordern. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, sind wir der Meinung, dass die Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z.B. die Unterstützung von GCP zusätzlich zu AWS) für das Ökosystem am vorteilhaftesten ist. Wir freuen uns aber über zusätzliches Feedback darüber, warum eine solche Anforderung notwendig ist. |
| Berichte für verschiedene Zeiträume erneut verarbeiten | Möglichkeit, Berichte für verschiedene Zeiträume erneut zu verarbeiten | Ähnliche Anfragen wurden uns schon gestellt, weil wir versuchen sollen, Batches für unterschiedliche Zeiträume aufzuteilen. Ein Vorschlag besteht darin, die gemeinsame ID mit einem vom Anzeigentechnologie definierten Label zu erweitern, sodass Berichte in verschiedene Batches aufgeteilt werden können. Wir arbeiten an der Auswertung dieses Prozesses und werden ihn laufend aktualisieren, sobald er sich weiterentwickelt. |
| Auswirkungen einer vertrauenswürdigen Ausführungsumgebung auf den Datenschutz | Positive Stimmung zu den Auswirkungen auf den Datenschutz bei vertrauenswürdigen Ausführungsumgebungen | Wir freuen uns über positive Reaktionen auf unsere Vorschläge aus der Community und freuen uns über zusätzliches Feedback, da wir ständig daran arbeiten. |
| 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 System-Unternehmen, die Nutzungsbedingungen so bald wie möglich zu akzeptieren, um Verzögerungen bei der Registrierung zu vermeiden. Wir empfehlen Unternehmen, sich bei Fragen an sie zu wenden. |
| Ermittlung der Schlüssel | Mit der wichtigen Erkennungsfunktion können Tester aggregierte Berichte abfragen, ohne die explizite Liste möglicher Tastenkombinationen zu benötigen. So lassen sich zusammenfassende Berichte für die netzwerkübergreifende Attribution verarbeiten und so Leistung und Genauigkeit verbessern. | Wir arbeiten derzeit an möglichen Lösungen und Behelfslö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? | Der Ursprung der Berichterstellung ist immer der Skriptursprung des Aufrufers der privaten Aggregation. |
| 128-Bit-Schlüsselraum | Klarheit über die Beschränkung des 128-Bit-Schlüsselbereichs | Wir werden diese Beschränkung des Schlüsselraums verdeutlichen und Inkonsistenzen zwischen den Seiten beseitigen. Wir empfehlen die Verwendung von Hash-Strategien, 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, sind wir offen dafür, Berichte aufzuteilen, anstatt sie an der Grenze abzuschneiden. Im Verlauf dieses Vorschlags werden wir uns aktiv mit der Branche engagieren. |
| Reichweitenberichte | Anfrage für plattform- und geräteübergreifende Berichte zur Reichweite Die Reichweite ist ein grundlegender Messwert der Markenwerbung. Werbetreibende stützen sich bei Berichten zu Reichweite und Häufigkeit auf plattform- und geräteübergreifende Schätzungen, um ihre Kampagnen zu analysieren und die Ausgaben zuzuordnen. Bei Reichweitenmodellen werden Drittanbieter-Cookies als Signal für die Messung von Anzeigen verwendet, die in Drittanbieterumgebungen ausgeliefert werden. Daher haben Anzeigentechnologie-Anbieter nach der Einstellung von Drittanbieter-Cookies eine alternative Lösung angefragt. |
Das Privacy Sandbox-Team testet derzeit Funktionen zur Unterstützung von Methoden für die domainübergreifende Reichweite nach der Einstellung von Drittanbieter-Cookies. Wir freuen uns über zusätzliches Feedback. |
Verdecktes Tracking einschränken
Reduzierung des User-Agents/Client-Hints für User-Agent
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| (Auch im 1. Quartal 2023 gemeldet) Hinweise für zusätzliche Formfaktoren | Anfrage nach User-Agent-Client Hints (UA-CH), um zusätzliche Formfaktoren wie TV oder VR bereitzustellen | Wir arbeiten noch an einigen wichtigen Designentscheidungen (z. B. zur Bereitstellung eines einzelnen Werts wie „TV“ oder einer Liste von Formfaktorfunktionen), wir bleiben aber an einem Prototyp für diese Idee interessiert. |
| Datenschutzbudget | 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 Neuigkeiten zum Privacy Budget-Vorschlag, wir haben uns jedoch verpflichtet, Anfragen nach UA-Clienthinweisen nicht einzuschränken, bevor Drittanbieter-Cookies eingestellt werden. |
| Website-Kompatibilität | Websites verwenden die Marke UA-CH, um den Zugriff auf Websites für bestimmte Browser zu verhindern. | Es gibt gute Anwendungsfälle für eine Markenliste. Einer davon ist die Kompatibilität. In UA können mehrere Marken zur Umgehung dieser Probleme eingesetzt werden. |
IP-Schutz (früher Gnatcatcher)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Betrug und Missbrauch | Wie können Unternehmen mit IP-Schutz Maßnahmen zur Betrugsbekämpfung einrichten? | Wir wissen, wie wichtig Anwendungsfälle zur Betrugsbekämpfung sind und welche Auswirkungen sie haben können. Weitere Details zur Unterstützung der Betrugsbekämpfung werden wir im Laufe des Sommers veröffentlichen. Wir bitten Sie um Feedback, wie wir uns bei Anwendungsfällen zur Betrugsbekämpfung 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. Im 3. Quartal sollen weitere Informationen zum Bereitstellungszeitplan veröffentlicht werden. Wir planen, den IP-Schutz zu Beginn als Opt-in-Funktion für Nutzer bei einem kleinen Prozentsatz des Traffics einzuführen. Uns ist bewusst, dass dieser Vorschlag für Unternehmen möglicherweise einige wesentliche Änderungen mit sich bringt. Wir möchten dem System Zeit geben, entsprechende Anpassungen vorzunehmen und Feedback zu geben, bevor die Funktion allgemein eingeführt wird. |
| Kontoauthentifizierung | Wie funktioniert die Kontoauthentifizierung mit dem Proxyserver genau? | Wir planen, im Laufe des Sommers weitere Details zur Kontoauthentifizierung zu veröffentlichen, einige erste Überlegungen haben wir aber bereits erwähnt. |
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 veröffentlicht. Darin finden Sie weitere Informationen dazu, wie Sie die Eindämmung von Bounce-Tracking testen können. |
| Dokumentation | Klarheit im Bounce-Tracking-Angebot | Das aktuelle Angebot ist noch in der Entwicklung und wird von Chrome kontinuierlich aktualisiert, um für mehr Klarheit und Informationen zu sorgen. Wir arbeiten daran, Ihnen weitere Informationen zur Verfügung zu stellen, und freuen uns über jedes zusätzliche Feedback. |
| Löschen von Cookies | Werden bei der Eindämmung von Bounce-Tracking alle Cookies in einer Domain gelöscht? | Bei der Eindämmung von Bounce-Tracking werden der gesamte Speicher und der gesamte Cache geleert, wie hier beschrieben. |
| Umgehung der Eindämmung von Bounce-Tracking | Die Klassifizierung von Bounce-Trackern 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 auf Weiterleitungen auf demselben Tab konzentriert, aber wir planen, in Zukunft Pop-up-Abläufe zu entwickeln. Hier kannst du uns zusätzliches Feedback geben. |
Datenschutzbudget
| 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 sind an Informationen zu den möglichen Auswirkungen auf das Ökosystem interessiert. |
Websiteübergreifende Datenschutzgrenzen stärken
First-Party-Sets
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| (Auch in früheren Quartalen gemeldet) Domain-Limit | Anfrage zur Erhöhung der Anzahl der verknüpften Domains | Chrome prüft derzeit die Grenzwerte für die verknüpfte Teilmenge, um den Datenschutz und die Nutzungsmöglichkeiten für die genannten Anwendungsfälle im Gleichgewicht zu halten. Chrome gab von Anfang an an, dass die genaue Anzahl für die verknüpfte Teilmenge noch nicht endgültig war. |
| Eingebetteter Anwendungsfall | Unterstützung für eingebettete Anwendungsfälle, die First-Party-Sets, CHIPs und gemeinsam genutzten Speicher erfordern | Wir haben das Feedback zu diesem Anwendungsfall erhalten und das Team untersucht das Problem. Wir freuen uns über zusätzliches Feedback. |
| Repository-Verwaltung | Informationen zu Richtlinien zum Entfernen von First-Party-Sets aus dem GitHub-Repository bei Abweichungen oder Vernachlässigung | Chrome hat das Feedback zu diesem Anwendungsfall erhalten. Das Team untersucht das Problem und freut sich über zusätzliches Feedback. |
| Nutzerschulungen | Chrome sollte die Nutzer*innen auf First-Party-Sets aufmerksam machen und verstehen, um die Akzeptanz zu steigern. | Chrome hat sich zum Ziel gesetzt, Nutzer über First-Party-Sets zu informieren. Wir haben daher einen Hilfeartikel zu diesem Thema veröffentlicht (Link zur Chrome-Benutzeroberfläche). Wir bei Chrome investieren außerdem in die Entwicklung von Informationstechniken, mit denen wir Nutzer im richtigen Kontext informieren können. |
| 3PCD-Beitrag posten | Drittanbieter-Cookies bleiben auch nach der Einstellung von Drittanbieter-Cookies in einem First-Party-Set bestehen. | Mit requestStorageAccess und requestStorageAccessFor werden Drittanbieter-Cookies zwar tatsächlich wieder für bestimmte, klar definierte Anwendungsfälle zur Verfügung gestellt, aber sie erfordern jetzt einen aktiven Aufruf durch die Website statt standardmäßig verfügbar, wie es beim aktuellen Status von Drittanbieter-Cookies (in Chrome) der Fall ist.Für diesen Aufruf innerhalb eines Satzes ist keine Genehmigung durch den Nutzer erforderlich. Nutzer können dies jedoch in den Einstellungen deaktivieren. Weitere Informationen finden Nutzer im Hilfeartikel (Link über die Chrome-Benutzeroberfläche). Wir planen, den bestehenden Entwicklerleitfaden zu erweitern, um die Framerate auf bis zu 100 % anzuheben. |
| First-Party-Sets einreichen | Benennen Sie die erforderliche .well-known/first-party-set um, sodass sie eine JSON-Erweiterung enthält. |
Wir haben diese Änderung vorgenommen, damit 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 auf zusätzliches Feedback. |
Fenced Frames API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Anzeigenblockierung | Umgezäunte Frames können Werbeblockern das Blockieren von Anzeigen erleichtern. | Erweiterungen können mit Fenced Frames ähnlich wie mit iFrames interagieren. Die URL, zu der der Fenced Frame weitergeleitet wird, ist auch für Erweiterungen sichtbar. Daher können diese wie bei iFrames beliebige URL-Übereinstimmungsregeln zum Blockieren anwenden. Wenn Sie alle umzäunten Frames einfach sperren, funktionieren die nicht werbebezogenen Anwendungsfälle von Fenced Frames möglicherweise nicht mehr. |
Shared Storage API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Größere Akzeptanz | Gemeinsam genutzter Speicher sollte ein branchenweiter Standard sein, der browserübergreifend verfügbar ist. | Wir freuen uns über dieses Feedback und wissen es zu schätzen. Chrome nimmt weiterhin aktiv an W3C-Foren teil, um den Vorschlag zu unterstützen, Feedback einzuholen und die Akzeptanz zu fördern. |
| Ausgabe-Gatter | Die Ausgabe-Gatter des freigegebenen Speichers sind zu begrenzt. | Wir berücksichtigen dieses Feedback und freuen uns über zusätzliches Feedback aus der Umgebung, in dem erläutert wird, warum die Ausgabe-Gatter zu begrenzt sind. |
| Gesetzliche Vorschriften | Wie handhabt der freigegebene Speicher die Einhaltung gesetzlicher Vorschriften, z. B. durch Aufbewahrungsrichtlinien? | Der freigegebene Speicher bietet die Flexibilität, Logik zu implementieren und anzupassen, um die Lebensdauer und den Ablauf gespeicherter Daten zu steuern. AdTechs 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 Leitlinien zu dieser Angelegenheit zu veröffentlichen, und hoffen, Ihnen in Zukunft weitere Einzelheiten mitteilen zu können. |
| Limit für gemeinsamen Speicher | Was passiert, wenn das Limit für den gemeinsam genutzten Speicher erreicht ist? | Wenn das Limit erreicht ist, werden keine weiteren Eingaben gespeichert. |
| Mehrfachzugriff bei gleichzeitigem Laden einer Seite | Was passiert, wenn beim Laden einer Seite mehrfach auf freigegebenen Speicher zugegriffen wird? | Die beste Möglichkeit, dies zu beseitigen, ist die Verwendung der Funktion window.sharedStorage.append(key, value). Anstatt den Wert für jede Anzeige zu aktualisieren, was zu Konflikten führen könnte, wenn mehrere Anzeigen vorhanden sind. Die Funktion Anfügen fügt lediglich den neuen Wert am Ende des vorhandenen Werts hinzu. |
| iFrame-Funktionalität | Unterstützt Shared Storage bestimmte iFrame-Funktionen, sobald diese nach der Einstellung von Drittanbieter-Cookies nicht mehr funktionieren? | Nach der Einstellung von Drittanbieter-Cookies wird der lokale Speicher in iFrames durch die Website der obersten Ebene partitioniert, aber die iFrames selbst werden nicht blockiert. Die Daten im lokalen Speicher eines iFrames können nicht über mehrere Websites der obersten Ebene repliziert werden. Der lokale Speicher kann jedoch innerhalb des iFrames verwendet werden. |
CHIPs
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Partitionslimit | 10 KiB pro partitionierter Website sind immer noch sehr groß und würden sie gerne verringern. | Firefox hat bereits eine positive Position für CHIPS angegeben. Für den Webkit-Support empfehlen wir Entwicklern, Apple über dieses GitHub-Problem direkt Feedback zu ihren Anwendungsfällen zu geben, bei denen partitionierte Cookies gegenüber partitioniertem Speicher bevorzugt werden. |
| Authentifizierte Einbettungen | CHIPs können sich auf den aktuellen SSO-Anmeldefluss auswirken, da sich unterschiedliche Partitionierungen auf authentifizierte Einbettungen auswirken. | Wir möchten die Storage Access API (mit Nutzeraufforderungen) nutzen, um den Anwendungsfall authentifizierte Einbettungen zu unterstützen, und vor Kurzem einen Intent-to-Prototyp gesendet. |
| Lifetime-Richtlinien | Gelten potenzielle Lifetime-Richtlinien auch für eigene Cookies? | Derzeit ist nicht geplant, eigene Cookies bis zur Lebensdauer zu beschränken. |
FedCM
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Unterstützung für OAuth-Autorisierung | Autorisieren von OAuth-Bereichen ohne Profil | Wir sind aktiv um Feedback der Web Identity-Community über die W3C FedID CG gebeten, um herauszufinden, wie wir die Autorisierung über die Basisauthentifizierung nach der Einstellung von Drittanbieter-Cookies hinaus am besten unterstützen können. |
| Unterstützung für SAML | Anforderungen für den SAML-Support festlegen | Das Team bittet aktiv um Feedback von Forschungs- und Bildungs-Communitys zum SAML-Support (zusätzlich zur Unterstützung von OpenID-Connect) nach der Einstellung von Drittanbieter-Cookies. |
Spam und Betrug bekämpfen
Private State Token API (und andere APIs)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
|---|---|---|
| Neue Signale entdecken | Mehrere Partner äußern positive Meinungen gegenüber der Untersuchung von browsergestützten Signalen der Geräteintegrität oder des Nutzervertrauens. Im Allgemeinen achten sie auch darauf, dass neue, speziell entwickelte Signale ausreichen, um das aktuelle Niveau der Betrugserkennung beizubehalten. | Wir freuen uns darauf, gemeinsam neue Vorschläge in der Community für Betrugsbekämpfung und Websicherheit zu erörtern und ihre Bedenken anzuerkennen und zu teilen. Genau der Grund dafür ist, dass wir „Spam und Betrug bekämpfen“. ist ein wichtiger Arbeitsfluss der Privacy Sandbox und warum wir bei der Verbesserung des Datenschutzes weiterhin in die Wahrung der Sicherheit im Web investieren. |
| Positives Feedback zum PST | Mehrere Partner haben Interesse daran, PSTs für verschiedene Anwendungsfälle zur Betrugsbekämpfung und Websicherheit zu testen oder zu verwenden. | Wir freuen uns auf die Unterstützung und das Interesse, neue Lösungen mit PST-Standards zu erforschen. Auf der Entwicklerwebsite für Chrome finden Sie Ressourcen und Beispielcode. Wir freuen uns über Ihr Feedback. |
| Betrug und Missbrauch | Hinweise zur Vermeidung und Erkennung von Werbebetrug bei der Messung 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 des Signals, das durch Drittanbieter-Cookies verloren gegangen ist, zum Schutz vor Betrug wiedererlangen. Es wurden jedoch neue Datenschutzeinstellungen eingeführt. Wir investieren aktiv in neue Vorschläge zum Schutz vor Betrug und Missbrauch, um die Funktionen auch im Rahmen anderer Änderungen an der Privacy Sandbox aufrechtzuerhalten. |
| Rate von Aussteller-zu-Ursprungs-Informationen | Das Verhältnis zwischen dem Aussteller und dem Ursprung ist hoch genug, um einzelne Nutzer zu identifizieren. | Wir haben die Spezifikation aktualisiert, um deutlicher zu machen, 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“ darstellen können. für einen bestimmten Nutzer. Diese Schlüsselsätze können nur alle 60 Tage aktualisiert werden (außer in seltenen Fällen, in denen ein Notfallschlüssel rotieren muss), wodurch die Möglichkeit der Zusammenführung zusätzlicher Nutzerdaten im Laufe der Zeit verlangsamt wird. Bei jeder neuen Web-API wird ein ausgewogenes Verhältnis zwischen Nutzen und neuen Nutzerinformationen geboten. Wir schätzen, dass PST-Dateien das richtige Gleichgewicht beim Schutz der Privatsphäre der Nutzer schaffen und gleichzeitig wichtige Anwendungsfälle zur Betrugsbekämpfung ermöglichen, die von der Einstellung von Drittanbieter-Cookies betroffen sind. |
| Abrufintegration | Die fetch-Integration ist kompliziert und nicht erforderlich. |
Die Verwendung von fetch hat Vor- und Nachteile und wir würden gerne eine weitere Standardisierung innerhalb des Web-Ökosystems vornehmen, aber wir denken, dass es zu früh ist, diese Änderung vorzunehmen, bis wir ein klareres Vorstellungs davon haben, wie der Standard aussehen wird. Sollte sich ein Standard entwickeln, setzen wir alles daran, Webentwickler verantwortungsvoll auf diesen Standard umzustellen. |
| Speicherstandort | Schlüsselkonfigurationen von Private State Tokens sollten am selben Ort wie das PrivacyPass-Protokoll gespeichert werden. | Während des Ursprungstests gaben die Entwickler an, dass sie die Flexibilität bevorzugen, ihre Schlüssel 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, bei der die Keysets implizite „öffentliche Metadaten“ ermöglichen. Wert. Wenn eine Variante von PrivacyPass mit öffentlichen Metadaten standardisiert wird (entweder als POPRF, teilweise RSA-Verblindung oder Keysets), wird möglicherweise eine zukünftige Version von PST verwendet, um diese Funktion zu unterstützen. |
| Header-Implementierung der API | Fragen zur Header-Implementierung der API | Wenn die API standardisiert wird und die Nutzung der API weiterentwickelt wird, können wir entweder die standardmäßige Nicht-Header-Version dieser API unterstützen und eventuell die Header-Version einstellen, wenn die Nutzung gering genug ist oder genügend Entwicklertools bzw. Unterstützung für standardmäßige Möglichkeiten zur Korrelation von Ausstellungs-/Einlösungsanfragen mit anderen Daten zur Verfügung stehen. Wir besprechen das Problem hier. |
| Anmeldung | Ist es praktikabel, Aussteller bei Browseranbietern zu registrieren? | Wir haben die Spezifikation aktualisiert, um den Ausstellerregistrierungsprozess für Private State Tokens zu beschreiben. Es verwendet zwar einen eigenen Prozess, ähnelt aber den Anmeldeplänen für den Rest der Privacy Sandbox-Funktionen, bei der wir Aussteller dazu auffordern, eine öffentliche Erklärung zu geben, wie sie PST-Dateien verwenden möchten, und die technischen Einschränkungen zum Schutz der Privatsphäre der Nutzer anzuerkennen. |