Vierteljährlicher Bericht für das 1. Quartal 2022 mit einer Zusammenfassung des Feedbacks zu den Privacy Sandbox-Vorschlägen und den Reaktionen von Chrome.
Im Rahmen seiner Verpflichtungen gegenüber der Wettbewerbs- und Marktaufsichtsbehörde hat Google zugestimmt, vierteljährlich Berichte über den Prozess der Einbeziehung der Stakeholder im Rahmen seiner Privacy Sandbox-Vorschläge zu veröffentlichen (siehe Abschnitte 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch eine Zusammenfassung des Feedbacks von Chrome aus den verschiedenen Quellen generiert, die in der Feedbackübersicht aufgeführt sind. Dazu gehören unter anderem: GitHub Issues, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Community und sucht aktiv nach Möglichkeiten, die gewonnenen Erkenntnisse in Designentscheidungen einfließen zu lassen.
Feedbackthemen sind nach Verbreitung pro API geordnet. Dazu wird eine Zusammenfassung des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, in absteigender Reihenfolge sortiert. Die gemeinsamen Feedbackthemen wurden ermittelt, indem Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktes Feedback, GitHub und häufig gestellte Fragen, die über interne Teams und öffentliche Formulare von Google gestellt wurden, überprüft wurden.
Genauer gesagt wurden die Gesprächsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, E-Mails, die von einzelnen Entwicklern eingegangen sind, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Anschließend koordinierte Google die Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, um die relative Verbreitung der Themen zu ermitteln, die in Bezug auf die einzelnen APIs entstehen.
Die Erklärungen zu den Reaktionen von Chrome auf Feedback basieren auf veröffentlichten häufig gestellten Fragen, aus tatsächlichen Antworten auf von Stakeholdern geäußerte Probleme und aus der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts von Entwicklung und Tests wurden Fragen und Feedback insbesondere zu Topics, Fledge und Attribution Reporting APIs und Technologien erhalten.
Kürzlich erhaltenes Feedback wurde möglicherweise noch nicht als Antwort in Chrome berücksichtigt.
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
Gemeinsame Themen aus allen Feedbackquellen
Ein gemeinsames Thema in unseren Diskussionen und Feedbackkanälen sind Fragen zum Zeitplan, zu den Zugriffszahlen und zur Verfügbarkeit von Tests. Insbesondere wollten die Tester wissen, wann APIs für Tests verfügbar sind und ob Tests weltweit verfügbar sein werden.
Um auf dieses Feedback reagieren zu können, hat Chrome eine umfassende Kommunikation gegeben und Chrome wird demnächst häufig gestellte Fragen veröffentlichen, in denen dies bestätigt wird, dass Tests weltweit verfügbar sein werden. Darüber hinaus wird Chrome in Absprache mit der CMA weiterhin öffentliche Zeitpläne aktualisieren.
Relevante Inhalte und Anzeigen präsentieren
| API / Technologie | Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Themen | Nützlichkeit grober Themen | Es wurde Bedenken geäußert, dass die grobe Thementaxonomie für interessenbezogene Werbung möglicherweise nicht ausreicht. | Die Nützlichkeit der API wird durch Tests erforscht. Chrome geht davon aus, dass sich die Taxonomie basierend auf den Testergebnissen weiterentwickelt. |
| Themen | Taxonomie | Die Stakeholder der Branche möchten die Taxonomie mitbestimmen. | Chrome bleibt offen für Eingaben in der Taxonomie. Chrome ist sehr an Feedback zum Governance-Modell für die Änderung der Taxonomie interessiert. Außerdem wird diskutiert, wie andere Branchenverbände langfristig eine aktivere Rolle bei der Entwicklung und Verwaltung der Taxonomie spielen können. |
| Themen | Nützlichkeit für verschiedene Arten von Websites | Es gibt Bedenken hinsichtlich der Nützlichkeit von Websites, die sich nach dem Grad des Traffics oder der Spezialisierung ihres Contents richten. | Die Nützlichkeit der API wird durch Tests erforscht. 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. |
| Themen | Methodik der Websiteklassifizierung | Websites sollen die Möglichkeit haben, die Klassifizierung ihrer Topics-Themen festzulegen oder zu beeinflussen. | Chrome prüft diese Anfrage, hat jedoch Bedenken aus der Webbrowser-Community und von DSPs bezüglich des potenziellen Risikos geäußert, dass Websites in der Lage sind, das System zu manipulieren, um Nutzer auf datenschutzkonforme Weise anzusprechen oder die Relevanz von Anzeigen zu verringern. Chrome bittet um Feedback und wägt mögliche Änderungen ab. |
| Themen | Rauschende Signale | Die Übermittlung eines zufälligen Themas in 5% der Fälle kann zu viel Rauschen / falsches Signal erzeugen. | Rauschen ist eine wichtige Methode, um die Privatsphäre der Nutzer zu schützen, und die Rauschpegel im Vergleich zur Nützlichkeit der Themen werden in Tests untersucht. |
| Themen | Websitegesteuerte Berechtigungen durch Drittanbieter | Websites müssen die Möglichkeit haben, auszuwählen, welche Anzeigentechnologie-Anbieter die Topics API von ihrer Website aus aufrufen dürfen. | Diese gewünschte Funktion wird bereits über die Berechtigungsrichtlinie „browsing-topics“ unterstützt, wie in der Erläuterung beschrieben. |
| Themen | Auswirkungen der Topics API auf die Seitenleistung | Bedenken hinsichtlich Zeitverzögerungen bis zur ersten Anzeige aufgrund der Abhängigkeit von der Topics API | Chrome erörtert mögliche Unterstützung von Themen in HTTP-Anfrageheadern zur Leistungsverbesserung. Wir sind auf Tests angewiesen, um festzustellen, ob solche Änderungen notwendig sind. |
| Themen | Datenschutzbestimmungen | Fragen zum Zweck des Filterns von Antworten nach Anrufern, wenn Dritte ihre Themen mit allen Personen teilen, die anrufen | Basierend auf dem Feedback vieler Nutzer aus dem System hat Chrome dieses Design gewählt, um den Zugriff auf Informationen auf diejenigen zu beschränken, die sonst keinen Zugriff auf solche Informationen gehabt hätten. Natürlich können Publisher und Drittanbieter, die Topics erhalten, selbst entscheiden, welche Informationen sie mit den Parteien auf ihrer Website teilen möchten. Wenn sie diese Art der Freigabe nutzen, wird ihnen von Chrome dringend empfohlen, den Nutzern gegenüber transparent zu sein und ihnen Kontrolle über das Teilen zu geben. |
| Themen | Dokumentation | Interesse an Dokumentation mit Details zum von Chrome verwendeten Klassifikatormodell und der Taxonomie, die Sie für FLoC verwendet haben, z. B. wie oft sich Klassifikator und Taxonomie ändern | Chrome stellt bereits die Taxonomie bereit, die im Rahmen der Ursprungstests verwendet wird, und das Klassifikatormodell, mit dem Websites nach Themen kategorisiert werden, wird in der Codebasis von Chrome als Teil des Open-Source-Codes zur Verfügung gestellt. Chrome behält sich im Rahmen der Ursprungstests das Recht vor, Änderungen daran vorzunehmen, sobald Feedback eingeht und Erkenntnisse zur Funktionsweise gesammelt werden. |
| FLEDGE | Frequency Capping | Sie möchten die Häufigkeit pro Nutzer innerhalb einer Kampagne oder innerhalb einer Anzeigengruppe kontrollieren können. | FLEDGE unterstützt Frequency Capping für On-Device-Auktionen. Es gibt ein offenes Problem, das für FLEDGE behandelt wird, auch zur Unterstützung von Kontext- und Branding-Kampagnen. Freigegebener Speicher, eine weitere API, die sich in der Entwicklung befindet, und websitespezifische Obergrenzen können ebenfalls für zusätzliche Steuerungsmöglichkeiten für das Frequency Capping verwendet werden. |
| FLEDGE | Auswirkungen von FLEDGE auf die Leistung | Es gibt Bedenken hinsichtlich der möglichen Auswirkungen rechenintensiver Bieter auf die FLEDGE-Auktion. | Chrome befindet sich in aktiven Gesprächen mit Entwicklern über die möglichen Auswirkungen auf die Websiteleistung. Chrome freut sich über die Möglichkeit, während der Tests mehr darüber zu erfahren. |
| FLEDGE | FLEDGE mit anderen Funktionen testen | Wann und wie werden Tests mit anderen Funktionen (k-Anonymitätsserver, Schlüssel/Wert-Server usw.) durchgeführt? | In unseren ersten Ursprungstests werden Funktionen in Chrome schrittweise eingeführt, um die Tests zu vereinfachen. Chrome erkennt an, dass es wichtig ist, für andere Funktionen Klarheit über den Zeitplan zu geben, und klären dies, wenn möglich. |
| FLEDGE | Testkoordination | Koordinierung von Tests für mehrere Anzeigentechnologien | Chrome prüft derzeit, ob es zusätzliche Unterstützung gibt, um Tests zu koordinieren, damit verschiedene Anzeigentechnologien mit denselben Nutzern experimentieren. Dies ist auch ein wichtiger Schwerpunkt der Zusammenarbeit mit Chrome-Partnerschaften. Auch Branchenverbände haben Interesse an einer Rolle bekundet. |
| FLEDGE | Beschränkungen für Interessengruppen | Gibt es Beschränkungen für die Anzahl der Interessengruppen, denen ein Nutzer hinzugefügt werden kann oder die an der Auktion teilnehmen können? | Chrome ist offen dafür, diese Grenzwerte aus Gründen der Webseitenleistung oder der Nutzerfreundlichkeit während der Testphase basierend auf Feedback und gemessenen Latenzauswirkungen zu verfeinern. Unter den Testern werden derzeit noch weitere Möglichkeiten diskutiert, wie Käufer und Verkäufer die Ressourcennutzung anpassen können. |
| FLEDGE | API-übergreifende Funktionen | Wie funktionieren Attributionsberichte mit FLEDGE? | Alle Details stehen noch nicht fest. Im 2. Quartal wird Chrome voraussichtlich im 2. Quartal Neuigkeiten dazu bekannt geben. Während des Ursprungstests werden in Chrome weiterhin Berichte auf Ereignisebene zu Auktionsergebnissen (Siege und Verluste) bereitgestellt. |
Digitale Anzeigen analysieren
| API / Technologie | Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Attribution Reporting (und andere APIs) | Traffic wird getestet | Bedenken, ob genügend Traffic für Tests vorhanden ist | Chrome startet den Ursprungstest bei sehr geringem Traffic, um zu verhindern, dass schwerwiegende Programmfehler oder Probleme mit Nutzereinstellungen auftreten. Erste Tester spielen eine wichtige Rolle dabei, zu prüfen, ob die APIs aus technischer Sicht wie vorgesehen funktionieren. Dies trägt dazu bei, die Anlaufzeit schneller auf einen größeren Traffic zu erhöhen. Wenn sich sicher ist, dass die APIs wie erwartet funktionieren, erhöht Chrome den Ursprungstest, um Dienstprogrammtests zu unterstützen. |
| Attributionsberichte | Ergonomie bei der Registrierung von Veranstaltungen | Fragen zu unterstützten Registrierungsformen für Veranstaltungen. | Chrome hat eine Antwort auf GitHub veröffentlicht, in der erläutert wird, welche Registrierungsformen derzeit unterstützt werden. Chrome holt Feedback zum aktuellen Design ein, um zu sehen, ob die vorgeschlagenen Änderungen diese Bedenken ausreichend beseitigen oder ob weitere Aktualisierungen erforderlich sind. |
| Attributionsberichte | Geräuscherzeugung | Sie möchten mehr darüber erfahren, wie Rauschen für aggregierte Berichte generiert wird. | Chrome hat eine Antwort auf GitHub veröffentlicht, die weitere Informationen zur systematischen Generierung von Rauschen enthält. Für Chrome ist geplant, eine Bibliothek zur Simulation von Geräuschen und Tests mit einer Reihe von Parametern während des UT. Für Chrome ist außerdem geplant, zusätzliche Entwicklerdokumentationen und Leitfäden für den Modus für aggregierte Berichte zur Verfügung zu stellen. |
| Attributionsberichte | Weniger genaue Daten für kleine Websites | Bedenken, dass kleinere Websites oder Kampagnen weniger genaue Daten erhalten | Chrome erkennt, dass rauschenbasierte Datenschutzmaßnahmen sich stärker auf kleinere Datensegmente auswirken. Es ist jedoch möglich, dass dieses Problem mit Methoden wie der Zusammenfassung über einen längeren Zeitraum behoben wird. Es ist auch unklar, ob die Schlussfolgerungen, die auf sehr kleinen Datensegmenten (z. B. ein oder zwei Käufe) basieren, für Werbetreibende von Bedeutung sind. Während des Ursprungstests empfiehlt Chrome Testern, die Möglichkeit zu nutzen, mit einer Vielzahl von Datenschutz- und Rauschparametern zu experimentieren, um genaueres Feedback zu diesem Problem zu geben. |
| Attributionsberichte | Auswirkungen von Conversion-Verzögerungen auf den Verbrauch | Sie befürchten, dass Conversion-Verzögerungen die Kampagneneinrichtung und -überprüfung oder die Kampagnenoptimierung beeinträchtigen. | Für Chrome wurden widersprüchliche Rückmeldungen zu den Auswirkungen von Verzögerungen bei Conversion-Berichten erfasst. Da die Attribution Reporting API jedoch zu zufälligen Verzögerungen bei der Berichterstellung zum Schutz der Daten der Nutzer führt, geht Chrome davon aus, dass bestimmte Anwendungsfälle und Bedenken während der Testphase deutlicher werden. Möglicherweise werden zusätzliche Debugging-Support- oder Entwickler-Anleitungen hinzugezogen. |
| Attributionsberichte | Längerer Attributionszeitraum | Anfrage zur Verlängerung des 30-tägigen Attributionszeitraums | Chrome hat eine Antwort veröffentlicht, in der um mehr Feedback zur Länge des Attributionszeitraums gebeten wurde, wobei sowohl die Datenminimierung als auch der Nutzen berücksichtigt werden sollten. |
| Attributionsberichte | Nicht sichtbare Impressionen | Fragen dazu, ob nicht sichtbare Impressionen in View-through-Conversion-Berichten berücksichtigt werden | Chrome hat eine Antwort auf GitHub veröffentlicht, um mehr Klarheit über sichtbare Impressionen zu erhalten. |
Verdecktes Tracking eindämmen
| API / Technologie | Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Reduzierung des User-Agents | Leistung | Es gibt Bedenken hinsichtlich der Latenz beim Abrufen von Hinweisen über Critical-CH (beim ersten Seitenaufbau). | Chrome sucht nach Möglichkeiten, die Leistung zu verbessern. |
| Reduzierung des User-Agents / User-Agent-Client-Hints | Betrug und Missbrauchsbekämpfung | Beim Debuggen bestimmter Arten von Angriffen, einschließlich Denial of Service, ist es wichtig, so viele Informationen wie möglich zu haben. Der Verlust einiger Informationen aus dem UA-String kann Probleme darstellen. | Chrome arbeitet derzeit an Diskussionen und evaluiert Möglichkeiten, wie der Datenschutz gewährleistet werden kann, während gleichzeitig ausreichende Informationen zur Verfügung gestellt werden, die für die Fehlerbehebung nützlich sind. |
| Reduzierung des User-Agents | Unklarheiten rund um die Einrichtung der OT | Mehrere Teilnehmer des Ursprungstests haben empfohlen, die Dokumentation mit Beispielen für die Registrierung für den Ursprungstest zu verbessern. | Der reduzierte UA-Ursprungstest endet, aber Chrome plant, die Anleitung für den Einstellungstest zu verbessern und die Beispieldemo besser sichtbar zu machen. |
| Reduzierung des User-Agents | Bedenken in Bezug auf Werte eines bestimmten Hinweises | Fragen dazu, ob Sec-CH-UA-Model mit <deviceModel> im User-Agent-String identisch ist. | Sec-CH-UA-Model ist identisch mit <deviceModel> im User-Agent-String. Chrome wird versuchen, dies in einer zukünftigen Dokumentation noch klarer zu verdeutlichen. |
| Reduzierung des User-Agents | Bedenken hinsichtlich der Anmeldung für den Test zur Einstellung von Produkten und Diensten | Fragen zur Registrierung einer großen Anzahl von Domains für den Test zur Einstellung von Produkten und Diensten | Chrome hat bei der Entwicklung des Einstellungstests zentralisierte Ansätze in Betracht gezogen. Für Chrome ist der bestehende Ursprungstest jedoch die beste Option, da er den Entwicklern die volle Kontrolle gibt, da sie entscheiden können, ob der Header gesendet wird oder nicht. |
| User-Agent-Client-Hints | Bedenken hinsichtlich der präskriptiven Natur von UA-CH | Es gibt Bedenken, dass UA-CH im Vergleich zur Flexibilität des User-Agent-Headers gemäß rfc7231-Definition zu allgemein gehalten ist. | Chrome betrachtet den präskriptiven Charakter von UA-CH-Headern als wichtige Verbesserung der Flexibilität des UA-Strings, sowohl im Hinblick auf die letztendliche browserübergreifende Interoperabilität und den Datenschutz für Nutzer, da das willkürliche Hinzufügen von Kennungen mit hoher Entropie verhindert wird.
Das Problem bleibt jedoch offen, falls auch andere Personen dasselbe Anliegen haben und Feedback geben möchten. |
| User-Agent-Client-Hints | Bedenken, dass die API zum Blockieren bestimmter Browser verwendet wird | Bedenken, dass eine Website das API für die Suche nach „Google Chrome“ oder „Microsoft Edge“ verwendet und alle anderen Browser blockiert. | Das Konzept der Markenliste ist darauf ausgelegt, diesen Fall zu berücksichtigen: Ein Browser kann neben den eigenen Marken auch "Google Chrome" senden. |
| User-Agent-Client-Hints | Anfrage für eine Methode zur Aufzählung aller unterstützten Hinweise | Interesse an einer programmatischen Methode, um alle unterstützten Hinweise für einen Browser zu kennen | Chrome wertet die Funktionsanfrage aus. |
| Reduzierung des User-Agents / User-Agent-Client-Hints | Betrug und Missbrauchsbekämpfung | Clienthinweise sind beim ersten Laden für HTTP1 nicht verfügbar | Eine der Client Hints Reliability APIs (Accept_CH) ist nur über HTTP2 und HTTP3 verfügbar. Bei Servern, die weiterhin über HTTP1 bereitgestellt werden, müssen sie sich ausschließlich auf Critical-CH verlassen. |
| Reduzierung des User-Agents | Auswirkungen auf Chrome für Android | Fragen dazu, wie sich das insbesondere auf Chrome unter Android auswirkt. | UA-Reduction und UA-CH werden nicht nur auf Computern, sondern auch in Chrome für Android eingeführt. In Chrome auf Android treten die Änderungen erst in Phase 6 in Kraft, die derzeit für Chrome 110 geplant ist. |
| Gnatcatcher (WIPB) | Nicht konforme Verwendungen und Methoden | Klarheit darüber, welche nicht konformen Verwendungen und nicht konformen Methoden vorliegen. | Die erklärende Erklärung wird demnächst mit weiteren Details aktualisiert. |
| Gnatcatcher + Reduzierung des User-Agents | Weniger Signale zur Betrugsbekämpfung | Schutz vor Betrug durch die gleichzeitige Reduzierung des IP- und UA-Zugriffs. | Durch die Erwartung von Richtlinien zur Betrugsbekämpfung vorsätzlicher IP-Blindheit (um die Verwendung von geistigem Eigentum zum Schutz vor Betrug zu ermöglichen) können Bedenken hinsichtlich der Abwehrmöglichkeiten im Zusammenhang mit IP-Proxys ausgeräumt werden. |
| Navigations-Tracking | Bedenken hinsichtlich künftiger Ausfälle | Werbetreibende machen sich Gedanken über mögliche Ausfälle. Auch Identitätsanbieter haben Interesse an den Plänen von Chrome bekundet. | In Chrome werden derzeit keine funktionsgefährdenden Änderungen vorgenommen und Anwendungsfälle werden derzeit untersucht. |
| SameSite-Cookies | Interoperabilität mit anderen Browsern | Fragen zu den Plänen von Chrome für die Behebung von crbug.com/1221316, da die Implementierungen von Chrome in diesem Bereich von anderen Browsern abweichen. | Chrome hat einen Fehler in den Messwerten erkannt und entsprechende neue Messwerte veröffentlicht. Chrome erhebt Daten, um die Auswirkungen der Fehlerbehebung besser nachvollziehen zu können. |
| Speicherpartitionierung | Bedenken hinsichtlich der Partitionierung von Nachrichtenkanälen | Fragen dazu, ob Messaging-Kanäle (z.B. SharedWorker und BroadcastChannel) sollten partitioniert werden. | Chrome wertet das Feedback aus, aber Chrome ist der Meinung, dass die Partitionierung von Messaging-Kanälen sowie Speicherplatz erforderlich ist, um verdecktes Tracking zu verhindern. |
Websiteübergreifende Datenschutzgrenzen stärken
| API / Technologie | Feedback-Design
(Sortiert nach Verbreitung) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| First-Party-Sets | Allgemeine Anforderung der Datenschutzerklärung | Es ist nicht möglich, für alle Produkte und Rechtsprechungen eine gemeinsame Datenschutzerklärung zu verwenden. | Chrome definiert noch unsere Richtlinienanforderungen und wird dieses Feedback berücksichtigen. |
| First-Party-Sets | Die Independent Enforcement Entity (IEE) erhält wahrscheinlich viele Identitätsbestätigungen für die FPS-Gültigkeit. | Zusammenfassung der vorhersehbaren Herausforderungen bei der Bestimmung der FPS-Gültigkeit: Text- und Datenschutzrichtlinien stimmen nicht bei allen Mitgliedern der Gruppe überein, Klarheit darüber, wie für Nutzer offensichtliche Set-Mitgliedschafts-, Bandbreiten- und Timing-Herausforderungen definiert werden können, und spezielles Fachwissen in Bezug auf die Unternehmensstruktur. | Chrome definiert noch unsere Richtlinienanforderungen und wird dieses Feedback berücksichtigen. |
| First-Party-Sets | Prozess zur Pflege der FPS-Liste der Browser | Bedenken hinsichtlich der Zugangsbarrieren für Websites in nicht westlichen Ländern, inkonsistente Versionen der FPS-Liste bei verschiedenen Browsern aufgrund unterschiedlicher Aktualisierungsrhythmen und der Möglichkeit, die Liste mit kleineren/neueren Browsern zu verwenden. | Chrome definiert noch unsere Richtlinienanforderungen, den Annahmeprozess und die Nutzungsrechte für die Liste und wird dieses Feedback berücksichtigen.
Chrome berücksichtigt auch Erkenntnisse aus anderen statischen Listen, die auf der Webplattform verwendet werden, z. B. die Liste öffentlicher Suffixe |
| First-Party-Sets | Dynamisches Assertion-Design pro Website | Ein dynamisches Design ist im Gegensatz zu einer statischen Liste anfälliger für falsche Zusicherungen gemeinsamer Eigentumsrechte sowie Latenz/Fehler beim Seitenaufbau. | Für Chrome wird derzeit die statische Liste verwendet. Wir werden dieses Feedback berücksichtigen, wenn der Ansatz mit signierten Assertions in Zukunft neu bewertet wird. |
| First-Party-Sets | Mögliche Anwendungsfälle für First-Party-Sets (wenn eine vertrauenswürdige und inklusive Version der FPS-Liste erstellt werden kann) | Einmalanmeldung (SSO), anpassbare Datenaufforderungen, Möglichkeiten für verbesserte Transparenzberichte für Nutzer. | Chrome berücksichtigt dieses Feedback bei der Berücksichtigung der nächsten Schritte für First-Party-Sets |
| CHIPS | Browserkompatibilität | Interesse daran, wie andere Browser mit partitionierten Cookieattributen umgehen | Chrome arbeitet weiterhin in öffentlichen Standardgruppen wie dem W3C daran, Designs und Implementierungen zu identifizieren, die browserübergreifend funktionieren. |
| CHIPS | Designanforderung | Bedenken, dass das Namenspräfix __Host- nicht angegeben werden kann | Für den Ursprungstest müssen keine Namen mehr angegeben werden. Am Ende des Testzeitraums wird er nun dauerhaft festgelegt. |
| CHIPS | Einsatz von CHIPS für Anzeigen | Fragen dazu, ob CHIPS für Anzeigenanwendungsfälle verwendet werden kann. | Mit CHIPS können Drittanbieter clientseitige Cookies erstellen, die nach der Top-Level-Website (oder ihrem First-Party-Set) partitioniert sind. Wenn der Anwendungsfall einen partitionierten Status und keinen websiteübergreifenden Status benötigt, kann CHIPS für diesen Anwendungsfall verwendet werden. |
| CHIPS | Integration von CHIPS in fps | Bedenken, dass Tests mit CHIPS zusammen mit anderen Privacy Sandbox-Angeboten wie First-Party-Sets möglicherweise nicht möglich sind | Chrome arbeitet aktiv daran, Testumgebungen zu schaffen, in denen solche Tests möglich sind. Für Chrome gibt es außerdem Anleitungen für lokale Tests für FPS und CHIPS, die in der Zwischenzeit verwendet werden können. |
| FedCM | Ausdrucksstärke | Da der Browser einen Teil des Flusses für föderierte Identitäten rendert, ist es schwierig, alle Nuancen zu erfassen, die IdPs ihren Nutzern präsentieren möchten. | Chrome erkennt die Kompromisse und arbeitet weiterhin mit der Plattform zusammen, um möglichst viele Bereiche abzudecken und sie so ausdrucksstark wie möglich zu gestalten. Einige Ideen, die Chrome entwickelt, umfassen auch Anpassungen des Brandings (z.B. Logos, Farben) und die Anpassung von Strings (z.B. „Zugriff auf diesen Artikel“ statt „Anmelden mit“). |
| FedCM | Browserbeteiligung | Bedenken, dass der Browser stärker in den Ablauf der Identitätsföderation eingebunden ist als zuvor, sodass er explizit erkennen kann, bei welchen Websites der Nutzer angemeldet ist (auch mit welchem IdP). | Chrome erkennt, dass der Browser jetzt eine aktivere Rolle spielt. Diese zusätzliche Beteiligung ist jedoch erforderlich, damit der Browser websiteübergreifendes Tracking unterscheiden und verhindern kann und gleichzeitig die Föderation weiterhin unterstützt. |
| FedCM | Anwendbarkeit und Interoperabilität | Bedenken, dass andere Browser FedCM nicht einführen oder implementieren werden | Chrome arbeitet außerdem mit anderen Browseranbietern zusammen, um in der FedID Community Group gängige Föderationslösungen zu finden. |
| FedCM | Verschiedene API-Herausforderungen | Ich befürchte, dass FedCM noch sehr früh / nicht ausgereift ist und viel Zeit in Anspruch nehmen wird, um alle Funktionen bereitzustellen, die das System benötigt. | Chrome wird dies im Rahmen von Tests im Rahmen unseres Ökosystems näher untersuchen. |
| FedCM | Unternehmensrichtlinien und Nutzersteuerungen | Bedenken, ob es ein Steuerelement (z.B. Unternehmensrichtlinien und/oder Nutzereinstellungen) geben könnte, das es Unternehmen ermöglicht, die Bereitstellung der föderierten Identität ohne Änderungen beizubehalten. Es gibt viele lokale Bereitstellungen föderierter Identität, die sich außerordentlich schwer neu bereitstellen oder ändern lassen. Es wird daher viel Widerstand gegen neue Browser-APIs gegeben, die eine erneute Bereitstellung durch IdPs erfordern. | Chrome testet derzeit Steuerelemente für Administratoren und Nutzer in Unternehmen, um diese Bedenken auszuräumen. Wir freuen uns über Feedback von Unternehmen zu bestimmten Anwendungsfällen, die berücksichtigt werden sollten. |
Spam und Betrug bekämpfen
| API / Technologie | Feedback-Design
(Gliederung nach Verbreitung pro API) |
Zusammenfassung der Fragen und Bedenken | Chrome-Antwort |
| Trust Token API | Einlöselimits | Bedenken, dass etwa zwei pro Seite zu restriktiv sind, insbesondere in Fällen, in denen eine URL mehrmals auf derselben Seite eingebettet ist oder eine zweite Ausstellerdomain innerhalb ihrer Organisation hat. Man würde die Grenze wahrscheinlich selbst erreichen, ohne andere Marktteilnehmer zu berücksichtigen. | Chrome ist offen dafür, das Einlösungslimit pro Seite geringfügig zu erweitern, wenn sich dadurch die Akzeptanz erhöhen lässt. Es sollte jedoch relativ niedrig gehalten werden, um übermäßige Entropie einzuführen. Außerdem kann das Caching eines Einlösungsdatensatzes die Notwendigkeit verringern, dass ein Aussteller mehrere Tokens für einen einzelnen Nutzer innerhalb kurzer Zeit einlösen kann. |
| Trust Token API | Latenz | In der Regel müssen Gebotsanfragen innerhalb von maximal 10 ms beantwortet werden. Das Einlösen eines Tokens beim ersten Seitenaufbau macht es also fast unmöglich, Entscheidungen über ungültige Zugriffe vor der Gebotsabgabe einzubeziehen. | Chrome versucht mithilfe von Tests herauszufinden, wie sich die Latenz auf Anwendungsfälle vor der Gebotsabgabe auswirkt. |
| Trust Token API | Einführung von OpenRTB | Bei Prebid-Anwendungsfällen müssen die Informationen zum eingelösten Token an SSPs und DSPs übergeben werden, die bei der Anzeigenentscheidung verwendet werden. | Chrome ist offen für eine Zusammenarbeit mit dem IAB, um sicherzustellen, dass alle nützlichen Signale zur Betrugs- und Missbrauchsbekämpfung über OpenRTB weitergegeben werden können, auch wenn das IAB den Standard zum Hinzufügen neuer Standardfelder besitzt. |
| Trust Token API | Datenschutz | Fragen zur langfristigen Durchführbarkeit jeder Form der websiteübergreifenden Datenverbreitung, wenn auch mit einer geringen Entropie (ca.2,5 Bit) | Angesichts des robusten Schutzes für Nutzer, mit dem die Identifizierung einzelner Nutzer verhindert wird, glaubt Chrome, dass die Akzeptanz der Plattform ein gutes Argument ist. Chrome arbeitet eng mit wichtigen Interessenvertretern zusammen, um die langfristige Rentabilität zu sichern. |
| Signale für Plattformzertifizierungen | Abschätzen des Interesses an einer neuen Idee/einem neuen Vorschlag | Starke Unterstützung für verschiedene durchführbare (und nicht umsetzbare) Signale, z. B. die Übertragung von Signalen zur Geräteintegrität, die die Plattform bereitstellen kann | Chrome plant, diese Idee als neue Feedback-Idee an die Community-Gruppe zum Schutz vor Betrug des W3C weiterzugeben. |
| Vertrauenswürdige Server zum Schutz vor Betrug | Abschätzen des Interesses an einer neuen Idee/einem neuen Vorschlag | Interessantes Konzept, erfordert aber wahrscheinlich eine genauere Untersuchung der anwendbaren Anwendungsfälle | Je nach Interesse kann Chrome weitere Ideen zu diesem Konzept entwickeln und sie als Erklärung für zukünftiges Feedback aus der Community festhalten. |