Vierteljährlicher Bericht für das 3. Quartal 2022 mit einer Zusammenfassung des Feedbacks aus der Community zu Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.
Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google bereit erklärt, vierteljährliche Berichte über den Prozess der Einbeziehung der Stakeholder im Rahmen seiner Privacy Sandbox-Vorschläge zu veröffentlichen (siehe Abschnitte 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch eine Zusammenfassung des Feedbacks von Chrome aus den verschiedenen Quellen generiert, die in der Feedbackübersicht aufgeführt sind. Dazu gehören unter anderem: GitHub Issues, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Community und sucht aktiv nach Möglichkeiten, die gewonnenen Erkenntnisse in Designentscheidungen einfließen zu lassen.
Feedbackthemen sind nach Verbreitung pro API geordnet. Dazu wird eine Zusammenfassung des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, in absteigender Reihenfolge sortiert. Die gemeinsamen Feedbackthemen wurden ermittelt, indem Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen, die über interne Teams und öffentliche Formulare von Google gestellt wurden, überprüft wurden.
Genauer gesagt wurden die Gesprächsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, E-Mails, die von einzelnen Entwicklern eingegangen sind, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Anschließend koordinierte Google die Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, um die relative Verbreitung der Themen zu ermitteln, die in Bezug auf die einzelnen APIs entstehen.
Die Erklärungen zu den Reaktionen von Chrome auf Feedback basieren auf veröffentlichten häufig gestellten Fragen, aus tatsächlichen Antworten auf von Stakeholdern geäußerte Probleme und aus der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts von Entwicklung und Tests wurden Fragen und Feedback insbesondere zu Topics, Fledge und Attribution Reporting APIs erhalten.
Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingeht, hat möglicherweise noch keine Antwort von Chrome als Antwort erhalten.
Glossar der Akronyme
- CHIPS
- Cookies mit unabhängig partitioniertem Status
- DSP
- Demand-Side-Plattform
- FedCM
- Federated Credential Management
- fps
- First-Party-Sets
- IAB
- Interactive Advertising Bureau
- IdP
- Identitätsanbieter
- IETF
- Internet Engineering Task Force
- IP-Adresse
- Internet Protocol-Adresse
- openRTB
- Echtzeitgebote
- ÜS
- Ursprungstest
- PatCG
- Private Advertising Technology Community Group
- RP
- Verlassende Partei
- SSP
- Supply-Side-Plattform
- TEE
- Vertrauenswürdige Ausführungsumgebung
- UA
- User-Agent-String
- UA-CH
- User-Agent-Client-Hints
- W3C
- World Wide Web Consortium
- WIPB
- Vorsätzliche IP-Blindheit
Allgemeines Feedback, keine spezifische API/Technologie
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| (Auch im 2. Quartal berichtet)
Nützlichkeit für verschiedene Arten von Stakeholdern |
Bedenken, dass die Privacy Sandbox-Technologien größere Entwickler bevorzugen und dass Nischenwebsites (kleinere Websites) einen höheren Beitrag leisten als generische (größere) Websites. | Update im 3. Quartal:
Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verfälscht wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende unabhängig von ihrer Größe berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird. Im Zuge der Tests der Privacy Sandbox ist eine der wichtigsten Fragen, die wir bewerten, die Leistung der neuen Technologien für verschiedene Arten von Interessenvertretern. Feedback ist dabei von entscheidender Bedeutung, insbesondere spezifisches und umsetzbares Feedback, das uns helfen kann, die technischen Designs weiter zu verbessern. Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen, in dem Marktteilnehmer mehr Informationen erhalten und die vorgeschlagenen Ansätze kommentiert werden können. |
| (Auch im 2. Quartal berichtet)
Dokumentationsanfragen |
Anfragen nach weiteren Ressourcen zur Verwaltung von Tests, Analysen und Implementierungen | Update im 3. Quartal:
Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden, und werden in den kommenden Wochen und Monaten weitere Informationen bereitstellen, damit Entwickler besser nachvollziehen können, wie sie von den neuen Technologien profitieren können. Außerdem haben wir öffentliche Sprechstunden für Entwickler abgehalten, bei denen Best Practices und Demos vorgestellt wurden. Außerdem gab es Fragerunden mit Produkt- und Entwicklerteams, um Live-Diskussionen und -Fragen zu ermöglichen. |
| Browserübergreifende Unterstützung | Andere Browseranbieter, die die Privacy Sandbox APIs verwenden | Andere Browser-Anbieter wie Apple, Mozilla und Microsoft nehmen aktiv an den öffentlichen Foren teil, in denen Datenschutzprinzipien und browserbasierte Ansätze diskutiert werden. Die gemeinsamen Diskussionen in Foren wie das letzte jährliche W3C-TPAC-Meeting und die fortlaufenden W3C PATCG-Foren, in denen wir Anzeichen für eine Konvergenz erkennen, freuen uns sehr. |
| Plattformunterschiede | Beantragen Sie die Angleichung der Funktionen im Web und in Android so weit wie möglich, um den Ressourcenaufwand für die Umstellung zu reduzieren. | Wir arbeiten intensiv daran, unsere Ansätze für Chrome und Android aufeinander abzustimmen, um Verwirrung/Fragmentierung innerhalb der Branche zu vermeiden. Wenn wir Unterschiede in unserem Ansatz verfolgen, ist das hauptsächlich auf notwendige technische Unterschiede zwischen den Plattformen für das Web und für mobile Apps zurückzuführen, die von den Entwicklern bereits berücksichtigt werden. |
| Ressourcen zum Testen der Privacy Sandbox APIs | Schwierigkeiten beim Zuordnen
Ressourcen zum Testen der Privacy Sandbox APIs angesichts des aktuellen wirtschaftlichen Gegenwinds. |
Google verbessert kontinuierlich die Dokumentation und den Support für Tester, um deren Komplexität zu vereinfachen und die Einführung der APIs zu erleichtern. Dazu gehören API-spezifische Mailinglisten, offene Sprechstunden und laufende Updates auf developers.chrome.com. |
| Sandbox API-Deaktivierungssignal | Anfrage zur Übermittlung des Signals „Nutzer hat die Sandbox APIs deaktiviert“, das von Anzeigentechnologien und Websites verwendet werden darf. | Es gibt schon viele Fälle, in denen Websites auf Nutzereinstellungen reagieren, z. B. das „Deaktivieren von Drittanbieter-Cookies“, indem sie den Nutzer dazu drängen, seine Einstellungen zu ändern. Manchmal wird auch der Zugriff auf die Website blockiert, es sei denn, er hat dies getan. Ein Deaktivierungssignal kann auch als zusätzliches Signal für das Fingerprinting verwendet werden. Derzeit hat Google nicht die Absicht, ein Widerspruchssignal bereitzustellen. |
| (Auch im 2. Quartal berichtet)
Präzisere Zeitpläne |
Klarere, detailliertere Veröffentlichungspläne | Update im 3. Quartal:
Wie im Abschnitt „Änderungen als Reaktion auf Feedback“ unten erläutert, hat Google den Zeitplan der Privacy Sandbox im Juli aktualisiert, um dem Markt mehr Zeit für vorläufige Tests und Feedback zu geben. Außerdem hat Google mehr Zeit für Tests, sobald die Privacy Sandbox APIs vollständig eingeführt sind, bevor Drittanbieter-Cookies eingestellt werden. |
| (Auch im 2. Quartal berichtet)
Fristen für die Einstellung von Drittanbieter-Cookies |
Anfragen zur Vermeidung weiterer Verzögerungen bei der Einstellung von Drittanbieter-Cookies | Update im 3. Quartal:
Im Juli haben wir für Chrome einen aktualisierten Zeitplan für die Einstellung von Drittanbieter-Cookies angekündigt. Damit möchten wir verantwortungsbewusst handeln, wenn man bedenkt, dass die Technologien komplex sind und ihre Bedeutung für die Plattform so wichtig ist. Das Feedback von Regulierungsbehörden und der Branche wurde vor dieser Änderung berücksichtigt und wir arbeiten weiterhin eng mit allen Stakeholdern zusammen. |
| Eigene Cookies | Werden auch Einschränkungen für eigene Cookies vorgeschlagen? Falls ja, haben wir Bedenken in Bezug auf die langfristige Stabilität, das Risiko weiterer unvorhersehbarer Browseränderungen und damit verschwendete Entwicklungsarbeit jetzt. | Wir haben keine Einschränkungen für eigene Cookies berücksichtigt. Der Schwerpunkt der Privacy Sandbox liegt auf der Einstellung von Drittanbieter-Cookies. |
Relevante Inhalte und Werbung zeigen
Themen
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| (Auch im 2. Quartal berichtet)
Nützlichkeit für verschiedene Arten von Stakeholdern |
Es gibt Bedenken hinsichtlich der Nützlichkeit von Websites, die sich nach dem Grad des Traffics oder der Spezialisierung ihres Contents richten. | Update im 3. Quartal:
Die Nützlichkeit der API wird durch Tests erforscht. Wie in Paragraf 17.c.ii der Vereinbarungen vorgesehen, gibt Google die Ergebnisse solcher Tests an die CMA weiter. Chrome geht davon aus, dass sich die Taxonomie und andere Parameter basierend auf den Testergebnissen weiterentwickeln werden. Für die Weiterentwicklung der Taxonomie oder der Parameter sind keine abwärtsinkompatiblen Änderungen erforderlich. Außerdem geht Chrome davon aus, dass sich das Feedback auch nach der Einstellung von Drittanbieter-Cookies auf die Weiterentwicklung der Topics API auswirken wird. |
| Datenschutzbestimmungen | Anfrage zum Entfernen der Filteranforderung für Themen pro Aufrufer. | Basierend auf dem Feedback von Datenschutz-KOLs, Datenschutzbeauftragten, Sicherheitsexperten, Gruppen für digitale Rechte und anderen Akteuren im System hat Chrome dieses Design gewählt, um nur denjenigen Zugriff auf Informationen zu gewähren, die sonst einen solchen Zugriff hatten. Zu den Gründen zählten unter anderem die Beschränkung des inkrementellen plattformübergreifenden Datenlecks, die Gewährleistung von Transparenz und Erklärbarkeit, die Einführung eines einfach zu implementierenden und beschreibenden Ansatzes sowie die Begrenzung des Risikos von Fingerprinting. Publisher und Drittanbieter, die die Topics API erhalten, können selbst entscheiden, welche Informationen sie an die Parteien auf ihrer Website weitergeben möchten. Falls Dritte diese Informationen weitergeben, empfiehlt Chrome diese, den Nutzern gegenüber transparent zu sein und ihnen Kontrollen zu bieten. |
| Falsch kategorisierte Websites | Websites sind dem falschen Thema zugeordnet, was zu einer ungenauen Anzeigenausrichtung führen kann. | Websites werden mithilfe einer Kombination aus einer von Menschen zusammengestellten Liste mit den beliebtesten Websites und einem ML-Modell auf dem Gerät klassifiziert. Chrome prüft weiterhin, welche Websites zur Klassifizierung von Themen beitragen können. Jegliche Verbesserungen des Nutzens müssen gegen die Risiken in Bezug auf Datenschutz und Missbrauch abgewogen werden. Zu den Risiken gehören beispielsweise:
Diese Komponenten sind über chrome://topics-internals oder dieses Colab verfügbar. Im Rahmen der Tests gehen wir davon aus, dass sich die Klassifizierung mit der Zeit verbessern wird. Wir freuen uns über Feedback zu Beispielen für Websites, die möglicherweise falsch kategorisiert wurden. |
| Zugriffsanforderungen | Die aktuelle Topics-Anforderung für eine DOM-Entität auf der Seite als Skript oder iFrame für den Zugriff kann zu unerwünschtem Verhalten von Spielern im Anzeigensystem führen. | Wir haben eine Änderung in der Erläuterung zu GitHub zusammengeführt. Wir beabsichtigen, Topics in HTTP-Headern zu unterstützen. |
| Thementaxonomie nicht detailliert genug | Aktuelle Klassifizierungen für Themen sind zu weit gefasst und enthalten keine detaillierteren Themen wie z. B. regionale Themen. | Verbesserungen an der Taxonomie sind fortlaufende Bemühungen und wir erwarten, dass sich die Taxonomie durch Tests und Eingaben weiterentwickeln wird.
Wir sind aktiv auf der Suche nach Feedback zur Taxonomie, die für die Plattform am nützlichsten wäre. Bei der Entscheidung, ob Sie die Anzahl der Themen erweitern oder detailliertere Themen einbeziehen sollten, sind einige Aspekte zu berücksichtigen: 1) mögliche Auswirkungen auf den Datenschutz (z.B. kann mehr Themen ein Fingerprinting-Risiko darstellen) und 2) die Möglichkeit, zuvor beobachtete Themen abzurufen (z.B. mit mehr Themen ist die Wahrscheinlichkeit geringer, dass ein AdTech das ausgewählte Thema in der Vergangenheit gesehen hat). Google versucht auch, im Rahmen der bestehenden Filteranforderungen die Möglichkeit des Aufrufers zu maximieren, zuvor beobachtete Themen abzurufen. Dabei soll sowohl der Nutzen als auch der Datenschutz gewährleistet werden. |
| Maximal zulässige Anzahl von Themen | Drei Themen pro Website sind zu wenig Informationen, um für Werbetreibende Anzeigen zu schalten. | Das Feedback aus der Community, insbesondere die Testergebnisse aus unseren Ursprungstests, wird die Weiterentwicklung der API weiterhin beeinflussen. Es ist zu beachten, dass die Topics API andere Signale wie Kontextinformationen ergänzen soll, damit dem Besucher passende Werbung präsentiert wird. So stehen dem Werbetreibenden über die Themen hinaus noch mehr Informationen zur Verfügung. |
| (Auch im 2. Quartal berichtet)
Steuerelemente und Sicherheit für Nutzer |
Bestimmte Themen können als Anhaltspunkte für sensible Gruppen dienen und Nutzer benötigen mehr Kontrollen, um negative Ergebnisse zu verhindern. | Update im 3. Quartal:
Themen stellen einen bedeutenden Schritt nach vorn für mehr Kontrolle und Transparenz dar. Nutzer können Themen deaktivieren, die ihnen zugewiesenen Themen überprüfen, Themen entfernen und sehen, welche Unternehmen mit ihren Themen auf einer bestimmten Seite interagieren. Außerdem haben Nutzer die Möglichkeit, ihre Themen zu löschen, indem sie ihren Browserverlauf löschen, aus dem Themen abgeleitet werden. Diese Einstellungen sind derzeit im Chrome-Browser auf Geräteebene implementiert. Wir begrüßen weitere Diskussionen über fortgeschrittene Nutzersteuerungsmöglichkeiten, wie sie von den Entwicklern vorgeschlagen werden. Wir müssen jedoch sicherstellen, dass neue Ergänzungen gut auf die geäußerten Bedenken reagieren und nicht zu kleinteiligen Änderungen führen. |
| Auswirkungen auf die SEO | Publisher, die die Hostnamen ihrer Website anpassen, um die Topics API besser widerzuspiegeln, kann sich negativ auf die SEO auswirken. | Wir raten Websites davon ab, ihre Hostnamen nur zugunsten der Topics API zu ändern. Es stimmt, dass eine Website die Themen beeinflussen kann, die ihnen zugewiesen sind. Die Vorteile für Publisher sind jedoch bestenfalls unklar und es würde den Wert von Topics für die gesamte Plattform untergraben, wenn Websites versuchen, das Klassifizierungsmodell zu „spielen“. Die Themenzuweisungen werden ebenfalls nicht festgelegt. Wir gehen davon aus, dass sich die Taxonomie auch durch Tests und Eingaben weiterentwickeln wird. Im Zusammenhang mit diesen Tests ermutigen wir Feedback, einschließlich Beispielen für Websites, die möglicherweise falsch kategorisiert wurden. |
| Betrug und Missbrauch | Bieten Sie dem Käufer die Möglichkeit, zu prüfen, ob das Thema, das er sieht, auch tatsächlich vom Browser generiert wurde. | Wir freuen uns über den Vorschlag, einen Mechanismus für AdTech-Käufer zu unterstützen, mit dem die Themen, die von Verkäufern in programmatischen Werbeauktionen weitergegeben werden, überprüft werden können. Wir ermutigen alle dazu, sich an der Diskussion zu beteiligen. Während wir uns derzeit auf andere Verbesserungen mit höherer Priorität konzentrieren, sind wir uns bewusst, dass dies eine wichtige Ergänzung des Designs in Zukunft sein könnte. |
| Betrug und Missbrauch | Sie ermöglichen die öffentliche Überprüfung von Parteien, die rechtmäßige Nutzer von Topics-Daten sind, und zwar auf die gleiche Weise, wie sie öffentlich gepostet und überprüft werden können. | Wir schätzen den Vorschlag und sind uns einig, dass die Verantwortung der Öffentlichkeit ein wichtiges Instrument ist, um die Ziele der Privacy Sandbox zu erreichen. Topics API-Aufrufe sind grundsätzlich öffentlich, da jeder eine Website besuchen und die Aufrufe einer Domain an die JavaScript API beobachten kann. Einzelpersonen und Organisationen können daher die entsprechende Aktivität einsehen und beurteilen, auf welchen Websites Topics wie verwendet wird. Wir sind der Meinung, dass dies ein besserer Ansatz ist, als die „Rechtmäßigkeit“ einer Website als Teil der Funktionalität der Topics API selbst zu beurteilen. |
| Auswirkungen auf eigene Signale | Topics-Signale können sehr wertvoll sein und werden daher andere selbst erhobene interessenbezogene Signale abgewertet. | Wir sind der Meinung, dass interessenbezogene Werbung ein wichtiger Anwendungsfall für das Web ist, und Topics wurde entwickelt, um genau diesen Anwendungsfall zu unterstützen. Wie oben beschrieben, haben andere Stakeholder des Ökosystems Bedenken geäußert, dass die Topics API möglicherweise nicht nützlich genug ist, um einen Mehrwert zu bieten. In jedem Fall sind Verbesserungen an der Taxonomie ein fortlaufender Prozess und wir erwarten, dass sich die Taxonomie durch Tests und Eingaben weiterentwickeln wird. |
FLEDGE
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| FLEDGE-Auktion | Wie können SSPs Daten formatieren, die an Google Ads gesendet werden, um in einer FLEDGE-Auktion zu bieten? | Unternehmen, die an den Tests teilnehmen, werden gebeten, Dokumentationen über ihre Testpläne zu veröffentlichen und gegebenenfalls zusammenzuarbeiten.
Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen. Der CMA soll Marktteilnehmern, die die Tests durchführen möchten, weitere Informationen sowie die Gelegenheit bieten, die vorgeschlagenen Ansätze zu kommentieren. Das Ad Manager-Team hat hier eine Dokumentation für Verkäufer veröffentlicht, die FLEDGE bei Publishern testen möchten, die Ad Manager als ihren Ad-Server verwenden. |
| FLEDGE in verschachtelten Fenced Frames | Fenced Frames ermöglichen weniger restriktive Tests und schränken in einer undefinierten Zukunft mehr ein. Dieser unbekannte Zeitplan stellt eine Herausforderung für das System dar. | Unternehmen können FLEDGE noch heute mit Fenced Frames testen. Um die Onboarding-Option zu vereinfachen, können Unternehmen zuerst FLEDGE implementieren. Nach der Implementierung von FLEDGE können sie Fenced Frames mit ihrem FLEDGE-Design testen. |
| Richtlinie zur Datenverarbeitung | Wie lauten die Datenverarbeitungsrichtlinien für Interessengruppen / FLEDGE? | Im FLEDGE-Design bleiben alle Daten, die in Interessengruppen gespeichert sind oder zu Personen in welchen Interessengruppen, auf dem Gerät gespeichert. Keine dieser Daten wird an einen Google-Server gesendet.
Einige Datenschutzmaßnahmen, die Chrome für FLEDGE plant, umfassen die Interaktion mit einem von Google betriebenen k-Anonymitätsserver. Diese Interaktion wird sorgfältig so gestaltet, dass keine Informationen über Nutzer weitergegeben werden und dass sie in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt werden, um die Gleichheit der Informationen im gesamten Anzeigensystem zu gewährleisten. \ Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch Selbstausübung des eigenen Unternehmens verzerrt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird. |
| Altersbeschränkungen | Wie sorgt Chrome dafür, dass über FLEDGE erstellte Zielgruppen den Altersbeschränkungen entsprechen? | Publisher und Werbetreibende sind am besten in der Lage zu beurteilen, ob die Zielgruppen, die sie mit FLEDGE erstellen, den anwendbaren Gesetzen entsprechen. Zum weiteren Schutz der Nutzer werden die Privacy Sandbox APIs für in Chrome angemeldete Nutzer nicht aktiviert, wenn das mit ihrem Konto verknüpfte Alter noch nicht 18 Jahre alt ist. Das gilt auch während der Testphase. Bei nicht angemeldeten Nutzern erfasst Chrome keine Profilsignale, die es dem Browser ermöglichen, das Nutzeralter abzuleiten. |
| FLEDGE-Schlüssel/Wert-Dienste | Mehr Klarheit darüber, was der FLEDGE-Dienst für Schlüssel/Wert-Paare zulässt, z. B. die Anzahl der Schlüssel und wie oft diese aktualisiert werden können. | Unternehmen, die FLEDGE verwenden, können so viele Schlüssel haben, wie in den RAM passen. Weitere Informationen
Wir arbeiten daran, Daten schneller zu ändern, und freuen uns über Vorschläge für sämtliche Anforderungen. |
| Testen | Schwieriges Testen von FLEDGE mit Google Ads | In der Google Ads-Onboarding-Dokumentation erfahren Sie, wie Sie am Ursprungstest teilnehmen und ihn testen können. |
| Bidding and Auktion Services API | Wie sieht die Strategie von Google für die Bidding and Auktion Services API aus? Wird es bei Geräteauktionen über oder unter den FLEDGE-Werten für den Chrome-Browser priorisiert? | Wir halten uns weiterhin an das aktuelle FLEDGE-basierte On-Device-Gebotsdesign. Die Gebots- und Auktionsdienste wurden vorgeschlagen, um mögliche Lösungen für bestimmte Anwendungsfälle zu finden, bei denen die Rechenleistung oder Netzwerkgeschwindigkeit des Geräts begrenzt sein kann. |
| Zusammengefasste Berichte | Anfrage zur Unterstützung aggregierter Berichte basierend auf allen für „generateBid“ verfügbaren Signalen | Weitere Informationen dazu werden wir in Kürze veröffentlichen. |
| Kontextbezogene Anzeigen | Kontextbezogene Anzeigen mit FLEDGE bereitstellen | Wir haben diese Option in Betracht gezogen und würden aus den in dieser Diskussion beschriebenen Gründen derzeit nicht empfehlen, FLEDGE für kontextbezogene Anzeigen zu verwenden. |
| Tests in der Praxis | Anleitung zum Isolieren von FLEDGE von Drittanbieter-Cookies für reale Tests. | Wir untersuchen derzeit Möglichkeiten, Testpopulationen bereitzustellen.
Wir haben gemeinsam mit der CMA einen Ansatz für quantitative Tests entwickelt und unterstützen die CMA dabei, einen Hinweis zum Testdesign zu veröffentlichen, in dem Marktteilnehmer mehr Informationen erhalten und die vorgeschlagenen Ansätze kommentiert werden können. |
| FLEDGE und Attribution Reporting API testen | Wie implementieren Sie die Attribution Reporting API am besten mit FLEDGE? Ist es sinnvoll, FLEDGE und Attribution getrennt oder zusammen zu testen? | Langfristig werden wir sowohl das Testen von FLEDGE als auch der Attribution Reporting API als integrierte Lösung unterstützen. Wir empfehlen Entwicklern jedoch, die Attribution Reporting API zuerst eigenständig und dann mit FLEDGE zu testen, wenn die Integration abgeschlossen ist. |
| Sichtbarkeit von Gebotspreisen | Anfrage zur Verschleierung von Gebotspreisen | Es ist möglich, Haltepunkte in „generateBid()“ oder „scoreAd()“ festzulegen, um auf Gebotswerte aus den Entwicklertools zuzugreifen. Das Chrome-Team hat den in diesem Feedback zu FLEDGE angegebenen engen Angriffsvektor berücksichtigt. Bei den Sicherheits- und Datenschutzmodellen von Chrome wird jedoch davon ausgegangen, dass Nutzer die Informationen auf ihrem eigenen Gerät in vollem Umfang nutzen können. Daher gibt es keine Möglichkeit, Gebotsdaten wie gewünscht auszublenden. |
| Dokumentationsanfragen | Dokumentation und Beispiele für Tests in einer Live-Umgebung. | Wir wissen es zu schätzen, dass die Entwickler unser aktuelles Material hilfreich finden, und werden in den kommenden Wochen und Monaten weitere Informationen bereitstellen, damit Entwickler besser nachvollziehen können, wie sie von den neuen Technologien profitieren können.
Außerdem haben wir öffentliche externe Sprechstunden für Entwickler veranstaltet, um Best Practices und Demos sowie Fragerunden mit Produkt- und Technikexperten zu teilen, um Live-Diskussionen und -Fragen zu ermöglichen. |
| Private Aggregation API | Möchten Sie weitere Informationen zur Private Aggregation API anfordern? | Es gibt eine öffentliche Erläuterung mit den neuesten Informationen, die wir derzeit zur Verfügung stellen können. Weitere Informationen werden bereitgestellt, wenn sich diese API in der Entwicklung befindet und Anwendungsfälle definiert sind. |
| Datenlatenz | Werden die Daten des FLEDGE-Schlüssel/Wert-Servers in Echtzeit abgerufen? | Bevor aktualisierte Daten für Abfragen vom Server zurückgegeben werden können, ist eine geringe Veralterung von nur wenigen Minuten und nicht mehreren Stunden zu erwarten, wie in einem offenen GitHub-Problem erläutert. Wir freuen uns auch über Entwicklerfeedback. |
| Gebots- und Auktionsdienste | Werden Gebotspreise für den Nutzer ausgeblendet, wenn Bidding und Auktionsdienste (B&A) verwendet werden? | Beim serverseitigen Ansatz für B&A ist der individuelle Gebotspreis für den Nutzer nicht sichtbar, da die Gebotsanfrage vom SSP-Auktionsdienst direkt an den DSP-Auktionsdienst gesendet wird und daher im Browser nicht mehr verfügbar ist.
Der Preis des erfolgreichen Gebots ist für den Browser jedoch weiterhin sichtbar. Weitere Informationen zu Anfragen zur Verschleierung von Gebotspreisen finden Sie oben. |
| Gebots- und Auktionsdienste | Wie lässt sich ein Load-Balancing für Gebots- und Auktionsdienste vornehmen? | Derzeit haben wir keine Hinweise zum Load-Balancing, aber dies ist aus Leistungs- und Datenschutzperspektive wichtig. Weitere Einzelheiten folgen zu einem späteren Zeitpunkt. |
| FLEDGE-Limits | Beantragen Sie eine Erhöhung des JoinAdInterestGroup-Limits für die Dauer von 30 Tagen auf 90 Tage. | Wir sind der Meinung, dass die 30-tägige Datenaufbewahrung mit den anderen Privacy Sandbox-Werbe-APIs übereinstimmt, z. B. dem 30-Tage-Limit in Attribution Reporting und dem dreiwöchigen Rückblick bei der Topics API. Dieser Zeitrahmen berücksichtigt sowohl die Anforderungen der Anzeigentechnologie als auch die Erwartungen der Nutzer in Bezug auf den Datenschutz.
Wir würden uns aber über weiteres Feedback freuen, während wir das Problem hier weiter besprechen. |
| Freigegebener Speicher in FLEDGE | Ist es möglich, die Shared Storage API in FLEDGE zu verwenden? | Wir beabsichtigen, die Shared Storage API in FLEDGE künftig zu unterstützen, und arbeiten daran, diese in einem bevorstehenden Ursprungstest verfügbar zu machen. |
| Häufigkeitssteuerung nach Klicks | Ist es möglich, Frequency Capping nach Klicks (nicht nach Gewinnen) in FLEDGE zu verwenden? | FLEDGE gibt jedoch an, dass ein Fenced Frame navigator.leaveAdInterestGroup() (ohne Parameter) aufrufen kann, um die Interessengruppe zu verlassen, die die Auslieferung der Anzeige ausgelöst hat. Dieser Aufruf könnte beim ersten Empfang eines Klicks erfolgen, um zukünftige Gebote zu verhindern. Dies ist eine Form des Frequency Cappings. Diese Lösung würde sich derzeit nicht für eine Begrenzung nach mehr als einem Klick eignen. |
| FLEDGE in verschachtelten Fenced Frames | Klicks auf Anzeigen mit Fenced Frame können nicht erfasst werden, wenn sie auf einem verschachtelten Fenced Frame erfolgen. | Hier finden Sie einen Vorschlag zur Behebung des Problems. |
| Messwerte ermitteln | Sie benötigen Informationen zum Erfassen von Latenzdaten für Bieter in einer FLEDGE-Auktion. | Wir arbeiten daran, bald ein Dokument zur Leistungsmessung zu veröffentlichen. |
| Berichte | Wie werden FLEDGE-Berichte verarbeitet? | FLEDGE-Berichte zu Gewinnen, Auktionsergebnissen und Ereignissen (z. B. zu Klicks) sind über FLEDGE APIs wie reportResult() verfügbar. Bei Berichten mit Anzeigen-Conversions ist die Einbindung in die Attribution Reporting API unabhängig von FLEDGE. Es werden jedoch laufend Gespräche über mögliche Ansätze geführt.
Mit der Private Aggregation API können auch aus den isolierten Ausführungsumgebungen Berichte zu Auktionsergebnissen erstellt werden. Weitere Informationen |
| Größe der Interessengruppe | Gibt es eine Möglichkeit für Anzeigentechnologie-Anbieter, die Größe einer Interessengruppe (d.h. die Anzahl der Nutzer in der Gruppe) zu überprüfen? | Die Mitgliedschaft in Interessengruppen wird vom Browser auf dem Gerät des Nutzers gespeichert und nicht an den Browseranbieter oder andere weitergegeben.
Allerdings kann der Inhaber einer Interessengruppe theoretisch jeden Aufruf an navigator.joininterestgroup(...) erfassen. Die Erfassung dieses Anrufs garantiert nicht die genaue Größe einer IG, da Nutzer eine Gruppe jederzeit verlassen können. Der Inhaber erhält jedoch eine Obergrenze und eine ungefähre Schätzung. |
| Leistung | Wird bei jeder Auktion ein Bidding-JS-/WebAssembly-Code kompiliert? | Bidding-JS-/WebAssembly-Code wird bei jeder Auktion einmal kompiliert. |
| Leistung | Was ist der Umfang von biddingDurationMsec? | BiddingDurationMsec beinhaltet die Kompilierung der Skriptzeit. Nicht enthalten sind die Download-Zeit, Wasm-Kompilierungszeit, Netzwerkzeit, Abrufzeit vom Schlüsselwert-Server oder Daten, die der JS-Kompilierung vorausgehen. |
| Anpassbare | Ist es möglich, adComponent so zu aktualisieren, dass sie an den User angepasst ist? | adComponent kann aktualisiert werden, wenn Interessengruppen aktualisiert werden. Dies geschieht entweder durch den Aufrufer beim Anrufen von "joinInterestGroup" oder wenn Chrome einen Aufruf an dailyUpdateURL startet. Auf diese Weise kann der Aufrufer die adComponent auf Grundlage des Wissens des Nutzers auf der aktuellen Website bzw. basierend auf k-anonymen Informationen aktualisieren. Den ursprünglichen Vorschlag einer Turtledove auf Produktebene finden Sie hier, der eine Analyse von RTB House zur Auswirkung auf die wichtigsten Messwerte für den Anwendungsfall der Empfehlung enthält. |
| Interessengruppe | Kann ein Inhaber einer Interessengruppe bestimmte Nutzer unter bestimmten Bedingungen entfernen? | Die Mitgliedschaft in einer Interessengruppe wird nur im Browser des Nutzers gespeichert und kann nur auf dessen Seite entfernt werden, z.B. durch Löschen der Websitedaten.
Allerdings kann ein Inhaber einer Interessengruppe die Methode navigator.leaveAdInterestGroup() (mit einer bestimmten Bedingungslogik) aufrufen, wenn der Nutzer zu einer Seite zurückkehrt, die der Kontrolle des Inhabers der Interessengruppe unterliegt. |
| Leistung | Wie kann die Leistung von „generateBid“ gemessen werden? | Die Kompilierungs- und Ausführungszeit kann mit biddingDurationMsec gemessen werden. Die Downloadzeit kann über chrome://net-export gemessen werden. In aktuellen Versionen von Chrome wird die Kompilierungs- und Ausführungszeit auf dem Tab „Leistung“ der Entwicklertools angezeigt. |
| Häufigkeit der Aktualisierung von Interessengruppen | Wie häufig wird die Interessengruppe von den Browsern aktualisiert? | Interessengruppen, die in den letzten 24 Stunden nicht aktualisiert wurden, werden in Chrome aktualisiert, wenn navigator.updateAdInterestGroups() aufgerufen wird oder wenn sie an einer Auktion teilnehmen konnten. Weitere Informationen |
| Anbieter von Aggregationsdiensten | Wann werden andere Cloud-Anbieter vom Aggregation Service unterstützt? | Derzeit gibt es kein Update zu den genauen Zeiten, aber wir werden dies später bekannt geben. Aktuell erfüllt nur AWS die Sicherheitsanforderungen des Aggregationsdienstes. |
| Zeitplan für FLEDGE-Tests | Wie lange wird FLEDGE in BYOS getestet? Bleibt ausreichend Zeit, um vom BYOS-Modell zum TEE-basierten Modell zu wechseln? | Damit dem System genügend Zeit für Tests bleibt, gehen wir davon aus, dass die Verwendung der TEEs erst kurz nach der Einstellung von Drittanbieter-Cookies erforderlich ist. Wir werden Entwickler rechtzeitig informieren, bevor diese Umstellung erfolgt, damit sie mit dem Testen und der Akzeptanz beginnen können. Derzeit gibt es keine weiteren Neuigkeiten, aber wir werden sie bekannt geben, sobald dies der Fall ist. Die neuesten Informationen findest du hier. |
| Datengrößenlimit | Wie groß ist die maximale Datengröße für Wasm in der Bidding-Funktion? | Wie hier beschrieben darf die Aktualisierung von Interessengruppen nicht zu einer Interessengruppe führen, die größer als 50 KB ist, aber die maximale Datengröße für Wasm wurde noch nicht definiert. Daher würden wir uns über Feedback zu diesem Thema freuen. |
| Auktionssignale | Wird es eine standardisierte Datenstruktur für AuktionSignals geben? | Dies wurde noch nicht definiert, wir sind jedoch offen für Feedback. |
| AdTech-Server abfragen | Ist es möglich, AdTech-Serverdaten in Echtzeit von einem K/V-Server abzurufen? | Nein, der K/V-Server wird in einem Vertrauensmodell ausgeführt, das „Kein Netzwerk-, Laufwerkszugriff, Timer oder Logging“ erzwingt, um die Offenlegung von Nutzerdaten zu vermeiden. Weitere Informationen zum Vertrauensmodell |
| Häufigkeit der Aktualisierung von adComponents | Das Feld „adComponents“ kann derzeit nicht anhand des Browserverlaufs des Nutzers aktualisiert werden (derzeit nur in IG-Einstellung) | Die Privacy Sandbox soll die Anforderungen der Webcommunity ohne websiteübergreifendes Tracking erfüllen, d. h. den Zugriff auf den Browserverlauf verhindern. Wir empfehlen, Alternativen wie Topics zu verwenden. |
| Auktionsergebnisse | Gibt es eine Möglichkeit für Anzeigentechnologie-Anbieter, die Gewinnraten bei Auktionen zu ermitteln? | Das Auktionsergebnis wird gemeldet, indem die Funktionen reportResult() und reportWin() im Auktionscode des Verkäufers bzw. des gewinnenden Käufers aufgerufen werden. Beide können also Protokolldaten und Berichte zum Auktionsergebnis erstellen. |
| (Auch im 2. Quartal berichtet)
Unterstützung für die Ausrichtung auf auszuschließende Interessengruppen |
Eine API zur Unterstützung der Ausrichtung auf negative Interessengruppen: Anzeigen werden nur geschaltet, wenn ein Nutzer nicht zu einer Interessengruppe gehört. | Update im 3. Quartal:
Wir haben einen neuen Vorschlag veröffentlicht und würden gerne Feedback dazu einholen. |
Digitale Anzeigen analysieren
Attribution Reporting (und andere APIs)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| OT-Anforderungen | Entfernen Sie die Einschränkungen der Berechtigungsrichtlinie während / nur für das OT. | Bitte sehen Sie sich auch unsere angekündigten Änderungen an der Richtlinie für Berechtigungen beim Testen an. Die Bedenken der Stakeholder, auf die sich diese Änderung auswirkt, besteht darin, dass DSPs die API auf einer größeren Anzahl von ursprungsübergreifenden iFrames testen können. Ursprünglich mussten DSPs sich mit Publishern/SSPs abstimmen, um sicherzustellen, dass die richtige Berechtigungsrichtlinie festgelegt wurde, um die API in ursprungsübergreifenden iFrames zu testen. Nach dieser Änderung können DSPs die API jetzt standardmäßig aufrufen und SSPs/Publisher können die API bei Bedarf während des Ursprungstests deaktivieren. |
| Geräusche | Geben Sie an, dass das Rauschen zu hoch ist, was den Nutzen der Berichterstellung beeinträchtigt. | Wir erfreuen uns über Feedback bezüglich des Rauschens. Anhand dieses Feedbacks können wir bestimmen, wie bestimmte rauschenbezogene Parameter festgelegt werden. Wir arbeiten daran, weitere Ressourcen, Tools und andere Dokumente zu veröffentlichen, um Testern dabei zu helfen. |
| Domainübergreifende Conversions | Wie erfassen Sie domainübergreifende Conversions, z. B. mit zwei oder mehr Zielen? | Wir werden diese Frage aktuell diskutieren und Feedback einholen. |
| Anforderungen für die Fehlerbehebung | Möchten Sie Entwicklern erlauben, das verbleibende Datenschutzbudget bei der Bereitstellung / Tests für einen zusammenfassenden Bericht zu prüfen? | Sie können diese Funktionsanfrage hier verfolgen. |
| API-Nutzungsrichtlinien | Feedback zu Richtlinien, die auf der Grundlage von Einschränkungen für Dinge wie Fingerprinting eine bestimmte API verwenden können | Das ist eine sehr interessante Idee, die wir gerne mit anderen Browser-Anbietern und dem Web-Ökosystem im weiteren Sinne besprechen würden. |
| Ablaufeinstellung im Conversion-Bericht | Anfrage zur Unterstützung des Berichtsfilters / Ablaufs von weniger als 24 Stunden. | Stundenbasierte Ablaufzeiten sind ein Grund für Datenschutzprobleme, da Anzeigentechnologie so genau wissen kann, zu welcher Uhrzeit ein Nutzer die Website des Werbetreibenden besucht. Dank der Ablaufzeit auf Tagesebene können Anzeigentechnologie-Anbieter ungültige Impressionen herausfiltern, ohne zu ermitteln, zu welcher Uhrzeit der Nutzer die Website besucht hat. |
| Ablauf des OT-Tokens | Anfrage zur Verlängerung der Gültigkeit der vorhandenen OT-Tokens, um den operativen Aufwand zu reduzieren. | Wir sind uns bewusst, dass Tokens verlängert werden müssen, und arbeiten daran, dies für Entwickler einfacher zu machen, und informieren sie entsprechend. |
| Regionaler Support | Der Aggregationsdienst unterstützt derzeit nicht alle Regionen. | Dies ist eine aktuelle Einschränkung der Betaversion. Wir gehen davon aus, dass im Laufe der Tests weitere Regionen unterstützt werden, aber es gibt noch keinen genauen Zeitplan dafür. |
| Verzögerung bei Berichten auf Ereignisebene | Die Verzögerung von 2 bis 30 Tagen bei Berichten auf Ereignisebene kann für bestimmte Anwendungsfälle zu lang sein. | Hier finden Sie einen Vorschlag, nach dem Anzeigentechnologie-Anbieter steuern können, wann Berichte auf Ereignisebene bis zum Ablaufdatum gesendet werden. Die Standardeinstellung beträgt 30 Tage, Sie können aber auch einen kürzeren Zeitraum festlegen. |
| (Auch im 2. Quartal berichtet)
Multi-Touchpoint-Attribution |
Multi-Touchpoint-Attribution zulassen, z. B. geräteübergreifend oder appübergreifend | Update im 3. Quartal:
Aktuelle Methoden der Multi-Touchpoint-Attribution erfordern eine deterministische Verknüpfung der Impressionen (und damit der Identität) eines Nutzers über verschiedene Websites hinweg. Daher entspricht diese Funktion in ihrer aktuellen Form nicht den Zielen der Privacy Sandbox, die wichtige Anwendungsfälle für Werbung ohne websiteübergreifendes Tracking unterstützen soll. |
| Zeitplan für die Einbindung von FLEDGE und Attributionsberichten | Wie sieht der Zeitplan für die Einbindung von FLEDGE und der Attribution Reporting API aus? | Aktuell gibt es keine Neuigkeiten dazu, aber wir werden weitere Informationen veröffentlichen, sobald wir einen festen Termin festlegen können. |
| Mehrere Triggertypen | Anfrage nach mehr Flexibilität bei der Trigger-Registrierung. | Wir haben ein Deduplizierungssystem für die Aggregate API vorgeschlagen, das Anzeigentechnologie-Anbietern mehr Flexibilität bei der Steuerung der Berichte auf Ereignisebene und der zusammengefassten Berichte bietet. |
| Messwerte ermitteln | Fordern Sie Messdaten an, die belegen, ob das Inventar eine gute Leistung erzielt. | Wir freuen uns über das Feedback und bitten Sie um weitere Klarheit über die Anwendungsfälle für diese Anfrage. |
| Conversion-Ablauf | Anfrage zur Unterstützung des Ablaufs von Conversions im Trigger-Tag statt nur im Quell-Tag. | Wir freuen uns über das Feedback und bitten Sie um weitere Klarheit über die Anwendungsfälle für diese Anfrage. |
| Batch-Berichte | Fordern Sie zusätzliche Analysen in Batchberichten an. | Wir freuen uns über Ihr Feedback, während wir weiter über die Auswirkungen auf den Aggregationsdienst nachdenken. Wir würden gerne erfahren, wie AdTech das Zusammenfassen von Berichten und die erwartete Häufigkeit in Betracht ziehen wird. Außerdem würden wir uns über Feedback dazu freuen, wie sich die Batch-Strategie im Laufe des Jahres ändert. |
| Epsilon | Wann wird der Wert von Epsilon bestimmt? | Wir arbeiten aktiv mit Testern der Plattform zusammen, um den Epsilon-Wert festzulegen und seine Implementierung in Google Analytics abzuschließen. Der Wert ist öffentlich sichtbar, zusammen mit der Diskussion, die zur Entscheidung geführt hat. Wenn Sie Feedback haben, posten Sie es bitte in diesem GH-Problem. |
Verdecktes Tracking begrenzen
Reduzierung des User-Agents
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Bereitstellungsabhängigkeiten | Bereitstellungsabhängigkeiten des Structured User-Agents (SUA) beheben | Wir haben „Phase 4“, eine kleinere Versionsreduzierung, für alle Chrome-Nutzer ab Version 101 eingeführt. Weitere Informationen |
| Testen | Verlängern des Ursprungstests zur User-Agent-Reduction – von Meta anfordern. | Wir haben den Ursprungstest verlängert und die Berechtigung erhalten, Traffic-Limits zu entfernen, um größere Websites zu berücksichtigen. Die gelockerten Traffic-Limits gelten für alle Websites, egal ob groß oder klein. |
User-Agent-Client-Hints
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| (Auch im 2. Quartal berichtet)
Betrug und Missbrauchsbekämpfung |
Bestimmte Funktionen, die über UA-CH verloren gehen können: Klickweiterleitungs-Tracker und betrügerische Klicks. | Update im 3. Quartal:
Wir haben positives Feedback von Unternehmen erhalten, die uns mitteilen, dass sie keine nachteiligen Auswirkungen auf ihre Pipelines zur Betrugsbekämpfung festgestellt haben (Ergebnisse hier und hier). Das Team untersucht diese potenziellen Probleme weiterhin mit Stakeholdern, um Betrug zu verhindern und Analysen durchzuführen. |
| Berechtigungsrichtlinie | Wird die Berechtigungsrichtlinie im Cache gespeichert? | Die Berechtigungsrichtlinie wird nicht im Cache gespeichert, wie in diesem GitHub-Problem beschrieben. |
Gnatcatcher (WIP)
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Anwendungsfälle für die Standortbestimmung | Gnatcatcher kann verhindern, dass legitime Anwendungsfälle für die Standortbestimmung in Zukunft funktionieren, z. B. die Personalisierung von Inhalten auf Grundlage der Standortbestimmung. | Wir arbeiten mit verschiedenen Interessenvertretern zusammen, um sicherzustellen, dass Chrome weiterhin legitime Anwendungsfälle von IP-Adressen unterstützt. |
Websiteübergreifende Datenschutzgrenzen stärken
First-Party-Sets
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Richtlinie | Bedenken, dass der FPS nicht mit den Bestimmungen der CMA zu den anwendbaren Datenschutzvorschriften vereinbar ist, da die DSGVO die Anzahl der Websites in einem Satz nicht begrenzt, während der Anbieter eine Beschränkung von drei Websites vorsieht. | Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verfälscht wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung, Publisher und Werbetreibende sowie die Auswirkungen auf den Datenschutz und die Einhaltung der Datenschutzprinzipien gemäß den anwendbaren Datenschutzvorschriften berücksichtigt werden. Aus den geäußerten Bedenken geht keine Auskunft über eine Inkompatibilität mit der DSGVO hervor. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen gerecht wird. Weitere Informationen finden Sie unten im Abschnitt „Änderungen als Reaktion auf Feedback“. |
| Dokumentation | Fordern Sie zusätzliche Beispiele an und aktualisieren Sie vorhandene erklärende Erklärungen. | Die Beispiele in unseren Erklärungen werden gerade überprüft. Bei Bedarf werden sie verdeutlicht oder entfernt. |
| Teilen von Präferenzen | Vorschlag, Präferenzen für Gruppen derselben Gruppe festzulegen. | Wir freuen uns über Feedback und diskutieren die Idee hier aktiv. |
| Durchsetzung der Richtlinien | Transparente Durchsetzungsprozesse bergen das Risiko eines Missbrauchs durch böswillige Akteure. | Wir wissen das Feedback zu schätzen und sind aktiv im Austausch mit Stakeholdern auf GitHub (unter Berücksichtigung der Punkte, die in diesem Thema erwähnt wurden, und in anderen Foren berücksichtigen), um dieses Risiko zu bewerten und mögliche Risikominderungen zu ermitteln. |
| Gemeinsame Eigentumsrechte | Vorschlag für eine maschinenlesbare Erklärung für gemeinsame Eigentumsrechte | Wir freuen uns über Beiträge zu unserem Vorschlag. |
| Subdomains-Eigentumsrechte | Sollten verschiedene Subdomains mit unterschiedlichen Datenverantwortlichen, unterschiedlichen Datenschutzerklärungen oder verschiedenen Rechtspersönlichkeiten zum selben First-Party-Set gehören? | Basierend auf dem Feedback planen wir, den gängigen Anwendungsfall für eTLD zu entfernen. |
| Missbrauchsminderung | Bitte um weitere Details zu den Maßnahmen zur Missbrauchsbekämpfung. | Das Verfahren wird derzeit geprüft. Weitere Einzelheiten geben wir in den kommenden Monaten bekannt. |
| Möglicher Angriffsvektor | Ein irreführendes Set für leicht auffindbare Seiten könnte verwendet werden, um Traffic auf andere Seiten zu lenken, die in betrügerischer Absicht als unabhängig dargestellt werden. | Wir sammeln aktiv Beiträge aus der Öffentlichkeit und suchen nach Möglichkeiten, dieses Problem anzugehen. |
| Validierung festlegen | Validierung des Satzes über allgemeine Richtlinien, für die eingewilligt wurde | Verschiedene Mitglieder der Community für Webstandards und die allgemeine Plattform haben darauf hingewiesen, dass dies nicht umsetzbar ist. |
| Domain limit | Anfrage zur Erweiterung der Anzahl verknüpfter Domains. | Wir diskutieren derzeit aktiv über das Domainlimit bei der Framerate und würden uns über Feedback von der Community zur Anzahl der verknüpften Domains freuen, die sie für ihre Anwendungsfälle benötigen. |
| Interaktion mit Teilmengendienst | Bedenken in Bezug auf den Dienst und die zugehörige Teilmengeninteraktion. | Wir schätzen das Feedback und werden prüfen, ob dies in den zukünftigen Spezifikationen genauer wird. |
| (Auch im 2. Quartal berichtet)
Verbesserter Datenschutz |
Zu viele Websites in derselben Gruppe können ähnliche Ergebnisse erzielen wie Drittanbieter-Cookies. | Update im 3. Quartal:
Im neuesten Vorschlag wird eine Beschränkung auf drei Domains für die zugehörige Untergruppe vorgeschlagen, die keine ccTLDs und Dienstdomains umfasst. Chrome interagiert aktiv mit der Plattform, um festzustellen, ob dieses Limit angemessen ist. |
| (Auch im 2. Quartal berichtet)
Allgemeine Anforderung der Datenschutzerklärung |
Es ist nicht möglich, für alle Produkte und Rechtsprechungen eine gemeinsame Datenschutzerklärung zu verwenden. | Update im 3. Quartal:
Eine gemeinsame Datenschutzerklärung ist nicht mehr erforderlich, um zum selben Datenpool gehören zu können. |
Fenced Frames-API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Warum ein neues Element anstelle von Attributen in iFrames? | Frage bezüglich des Angebots „Fenced Frame“ anstelle von vorhandenen iFrame-Angeboten. | Wir freuen uns über Ihr Feedback und sind offen für neue Ideen, wie wir den aktuellen Stand der Dinge wie hier beschrieben angleichen können. |
| Schnittmengenbeobachter in abgegrenzten Frames | Fragen zur Sichtbarkeit von Informationen in einem Fenced Frame | Dies ist eine aktive Diskussion und der Kommentarzeitraum in diesem Dokument und auf GitHub. Wir begrüßen es, wenn Partner Anwendungsfälle mit uns teilen, damit wir besser nachvollziehen können, wie wir Sie unterstützen können. |
| Videoinventar und natives Inventar unterstützen | Wird für Fenced Frames Videoinventar und natives Inventar unterstützt? | Im Hinblick auf die Videowiedergabefunktionen unterscheiden sich Fenced Frames nicht von iFrames und deshalb wird sie in keiner öffentlichen Dokumentation explizit erwähnt. Sollten Sie Probleme mit Videoanzeigen feststellen, senden Sie uns Feedback, damit wir die Angelegenheit weiter untersuchen können. |
| Web-Bundles | Wird die Anzeigenbereitstellung und das Rendering durch Websets in Zukunft mit Fenced Frame x FLEDGE eine Anforderung sein? | Das langfristige Ziel ist die Unterstützung von Web Bundles zum Rendern von Anzeigeninhalten in einem abgegrenzten Frame. Die aktuelle Implementierung von FLEDGE unterstützt dies jedoch nicht und erfordert das Rendern einer HTML-Ressource, die aus renderUrl abgerufen wurde. |
| Asset-Abmessungen | Anfrage für render_url, um ein Makro für die Höhe und Breite der Anzeigenfläche zu unterstützen, damit wir mit einem Creative der passenden Größe antworten können | Dieses Thema wird hier aktiv diskutiert. |
Shared Storage API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| FLEDGE-Integration | Wie werden freigegebener Speicher und FLEDGE integriert? | Obwohl wir dies derzeit nicht verfolgen, möchten wir diese Idee untersuchen, um die Wahrung des Datenschutzes sicherzustellen. Wir empfehlen interessierte Parteien, Vorschläge für mögliche Anwendungsfälle einzureichen, die dieser Vorschlag im GitHub-Repository für gemeinsam genutzten Speicher oder im GitHub-Repository für FLEDGE unterstützt. . |
| Datenaufbewahrung | Das Leeren des freigegebenen Speichers reduziert den Nutzen. Wurden als Alternative eine Verlängerung der Aufbewahrungsdauer oder die Möglichkeit zum Löschen einzelner Schlüssel/Wert-Paare in Betracht gezogen? | Wir sind immer auf der Suche nach einem Gleichgewicht zwischen Datenschutz und Nutzen. Wir freuen uns über Feedback zu Anpassungen und empfehlen unseren Partnern, beim Testen des gemeinsamen Speicherplatzes mehr Feedback und Details zu geben. |
| Negatives Signal | Negatives Signal von Mozilla in Bezug auf den Vorschlag für freigegebenen Speicher. | Wir danken Mozilla für die sorgfältige Prüfung unseres Vorschlags. Wir planen, in naher Zukunft auf ihr Feedback zu reagieren. |
CHIPS
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Partitionierte Anforderung | Für das Attribut „Partitioniert“ bei eigenen Cookies muss eine explizite Verhaltensanforderung hinzugefügt werden. | Wir haben das in einem Gespräch über die PrivacyCG besprochen und uns auf das GitHub-Problem gewarnt. Wir arbeiten weiterhin mit Browsern, Entwicklern und der Datenschutz-Community zusammen, um uns auf ein bestimmtes Verhalten einigen und es spezifizieren zu können. |
| Authentifizierte Einbettungen | CHIPS können den aktuellen SSO-Anmeldevorgang aufgrund der unterschiedlichen Partitionierung beeinträchtigen, die sich auf authentifizierte Einbettungen auswirkt. | Der Anwendungsfall für authentifizierte Einbettungen ist uns bekannt und wir arbeiten bereits an Lösungen. |
| Cookie-Partitionslimit | Bedenken, dass die derzeitige Beschränkung von 10 Cookies für bestimmte Anwendungsfälle möglicherweise nicht ausreicht. | Wir entfernen von der Beschränkung der Anzahl an Cookies auf eine Speicherbeschränkung von 12 KB. So können wir Bedenken hinsichtlich der Cookie-Begrenzung ausräumen und gleichzeitig gewährleisten, dass die Leistung und der Speicherbedarf des Browsers nicht beeinträchtigt werden. |
| Zeitplan für Ursprungstests | Erweitern Sie UT nach dem Entfernen der Begrenzungsanforderung für Hostnamen. | Aufgrund von Feedback aus der Umgebung haben wir die Frist für den Ursprungstest verlängert. |
| Testeinschränkungen in Chrome | CHIPS-Testmöglichkeit in Firefox aufgrund aktueller Beschränkungen in Chrome | Die Implementierung in Firefox unterscheidet sich nur geringfügig, Chrome hat eine niedrigere Cookie-Grenze und CHIPS ist ein Opt-in-Mechanismus, aber Firefox ist standardmäßig partitioniert. |
| (Auch im 2. Quartal berichtet)
Authentifizierte Einbettungen |
Wird der Anmeldestatus mit CHIPS beibehalten? | Update im 3. Quartal:
Der Anmeldestatus wird derzeit nicht beibehalten, ist aber nicht der vorgesehene Anwendungsfall für CHIPS. Der Anwendungsfall für authentifizierte Einbettungen ist uns bekannt und wir arbeiten bereits an Lösungen. |
FedCM
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| (Auch im 2. Quartal berichtet)
Potenzielle Angriffsvektoren |
Potenzielle Angriffsvektoren durch Linkdekoration und Timing-Angriffe. | Update im 3. Quartal:
Wir haben mit Mozilla zusammengearbeitet, um ein gemeinsames Verständnis dafür zu entwickeln, wie das Problem beim Timing-Angriff angegangen werden kann. Die Details dazu finden Sie hier. Wir erstellen nun einen Prototyp für diese architektonische Änderung und planen, in den nächsten Quartalen Tests durchzuführen. |
| Identitätsanbieter | Kontoauswahl: Einzelner Identitätsanbieter. Anfrage zum Zulassen mehrerer Identitätsanbieter. | Wir haben mit Browseranbietern und der FedID CG zusammengearbeitet, um die Möglichkeit zu schaffen, mehrere Identitätsanbieter zuzulassen, und sind zu einer Formulierung gekommen, die sich lohnen könnte. Eine Beschreibung des Vorschlags finden Sie hier. In den nächsten Quartalen werden voraussichtlich Prototypen entwickelt und Tests durchgeführt. |
| Bekannte Probleme mit Föderation | Anfrage zur Aufzählung von Fällen, in denen bei der Föderation Probleme mit der Einstellung von Drittanbieter-Cookies auftreten können. | Die FedID-CG hat ein Arbeitselement, mit dem hier und hier aufgezählt wird, wie die Föderation aufbregt. Das Unternehmen erstellt außerdem eine Entscheidungsmatrix, um Fehler bei Web Platform APIs abzubilden. |
| Nounce parameter | Könnte der Parameter „Nounce“ sich auf den Anmeldevorgang auswirken? | Dies kann als websiteübergreifendes Tracking betrachtet werden, aber wir sammeln noch Informationen und analysieren, wie solche Fälle zu behandeln sind. |
| Nutzereinwilligung | Verknüpfung verschiedener vertrauender Parteien (RPs) und Nutzereinwilligung für jeden Ursprung. | Mit dieser Spezifikation kann nicht gesteuert werden, wie Quellen innerhalb derselben Domain Cookies gemeinsam nutzen. Die Spezifikation lässt das IDtoken vom IdP-Ursprung zum RP-Ursprung zu. Es liegt jedoch an der RP, zu entscheiden, ob der Anmeldestatus des Nutzers in einem Cookie gespeichert werden soll, das an diesen einzelnen Ursprung gesperrt ist, oder in einem Cookie, das für Ursprünge innerhalb derselben Domain freigegeben ist. |
| IdP-Konto
Übertragbarkeit |
Nutzeroption, IdPs zu migrieren, wenn sie sich für die Übertragung zwischen zwei IdPs entscheiden | Das scheint etwas zu tun, das der Nutzer direkt auf der Anmeldeseite seines neuen IdPs tun müsste, nicht über die FedCM API. |
| Konto löschen | IdP-Widerruf für die Kontolöschung beim IdP | Für diese Funktionsanfrage können wir jetzt Feedback geben und sie wird derzeit geprüft. |
| UI-Anspruch | Behauptungen über browserspezifische Aspekte der Benutzeroberfläche | Weitere Informationen hierzu finden Sie unter Pull-Anfrage. |
| Prüfung auf IdP-Empfehlung | Der IdP prüft die Referrer-URL von RP. | Der Spezifikation wurde eine obligatorische Prüfung der IdP-Verweis-URLs hinzugefügt. Siehe Pull-Anfrage. |
| Anmeldung | Anfrage für eine Anpassung der Anmeldevorgänge an die RP-Einstellungen. | Wir freuen uns über Ihre Idee und besprechen intensiv. |
Spam und Betrug bekämpfen
Trust Tokens API
| Feedback-Design | Zusammenfassung | Chrome-Antwort |
| Betrug und Missbrauch | Tools, um sicherzustellen, dass ein Bot einen Aussteller nicht dazu verleitet hat, ihm ein Token zu geben, dass ein Bot kein Token übernommen hat, das einem echten Nutzer ausgestellt wurde, und um zu verhindern, dass Bots schädliche Tokens ausgeben? | Bots können zwar Tokens von einem Aussteller erhalten, Aussteller werden jedoch dazu angehalten, die Häufigkeit von Tokens und robusten Methoden für die Ausstellung von Tokens und die Aktualisierung ihrer Ausstellungslogik einzuschränken, wenn böswillige Akteure versuchen, sie zu umgehen. Aussteller ohne eine ausreichende Logik für die Ausgabe von Tokens werden im System wahrscheinlich weniger vertrauenswürdig sein, da Websites auf zuverlässigere Aussteller setzen. |
| Betrug und Missbrauch | Gibt es eine Möglichkeit für den Einlösen von Trust Tokens, anzugeben, dass er nur Trust Tokens von bestimmten Entitäten akzeptiert? | Ja, das ist möglich. Die Funktionsweise wird im Abschnitt Einlösung von Trust Tokens beschrieben. |
| Betrug und Missbrauch | Gibt es eine Möglichkeit für den Aussteller von Trust Tokens, eine Liste der Einlösungsstellen zu erstellen und anderen das Einlösen von Tokens nicht zu gestatten? | Derzeit nicht, aber das Team untersucht diesen Anwendungsfall. |
| Zeitplan | Wann wird die Trust Token API allgemein verfügbar sein? | Sobald wir einen genauen Zeitplan festlegen können, werden wir weitere Informationen öffentlich bekannt geben. |
| (Auch im 2. Quartal berichtet)
Wartungsaufwand |
Es ist nicht klar, wie lange Protokollversionen unterstützt werden. | Update im 3. Quartal:
In den APIs wird zusätzlicher Support für mehrere gleichzeitige Versionen hinzugefügt, um einen reibungslosen Übergang zwischen Versionen zu ermöglichen. Die Fristen für den Support bzw. die Einstellung befinden sich jedoch noch in der Entwicklung. |