Diese Seite wurde von der Cloud Translation API übersetzt.

Feedbackbericht – Q3 2023
bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

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

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

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

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

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

Glossar mit Akronymen

CHIPS: Cookies mit unabhängigem partitionierten Status
DSP: Demand-Side-Plattform
FedCM: Federated Credential Management
FPS: First-Party-Sets
IAB: Interactive Advertising Bureau
IDP: Identitätsanbieter
IETF: Internet Engineering Task Force
IP-Adresse: Internet Protocol-Adresse
openRTB: Echtzeitgebote
NSZ: Origin-Testversion
PatCG: Private Advertising Technology Community Group
RP: Vertrauende Partei
SSP: Supply-Side-Plattform
TEE: Vertrauenswürdige Ausführungsumgebung
UA: User-Agent-String
UA-CH: User-Agent-Client-Hints
W3C: World Wide Web Consortium
WIPB: Willful IP Blindness

Allgemeines Feedback, keine bestimmte API oder Technologie

Feedbackthema	Zusammenfassung	Chrome-Antwort
Bereitschaft des Ökosystems	SSPs haben Bedenken geäußert, dass Publisher nicht bereit sind und die erforderlichen Bereitstellungsarbeiten nicht durchführen.	Die Privacy Sandbox richtet sich speziell an Publisher. Dazu gehören spezielle Webinare und Besprechungen mit Publishern und SSPs, um die Implementierung zu beschleunigen.
Einstellung von Drittanbieter-Cookies	Bedenken hinsichtlich der Einstellung von Drittanbieter-Cookies nehmen im 4. Quartal 2023 aufgrund einer technischen Störung in der Branche zu.	Der Zeitplan für die Privacy Sandbox wurde mit der CMA besprochen. Die Abfolge der Schritte führt zu einer Einsatzbereitschaft in der zweiten Jahreshälfte 2024. Die Privacy Sandbox veröffentlicht detailliertere Informationen zur Reihenfolge der Einführung von 3PCD. Gemäß den Zusicherungen ist die 3PCD davon abhängig, dass die wettbewerbsrechtlichen Bedenken der CMA ausgeräumt werden.
Google Ad Manager	Google Ad Manager stellt die API-Oberfläche nicht bereit, was die Tests erschwert.	Antwort von Google Ad Manager:Aus den in dieser Antwort von Google Ad Manager erläuterten Gründen ist die Einbindung der Protected Audience API in Google Ad Manager nicht für die Unterstützung des Publisher-Anzeigenservers von Google ohne Kontrolle der Auktion auf oberster Ebene vorgesehen.
Google Ad Manager	Google Ad Manager hat einen geheimen Mindestpreis, der nur für AdX- oder Open Bidding-SSPs sichtbar ist.	In der öffentlichen Dokumentation zu Google Ad Manager wird angegeben, dass der Gewinner der kontextbezogenen Auktion an die Bewertungslogik der obersten Ebene und nicht an eine Komponentenauktion weitergeleitet wird, einschließlich AdX oder Open Bidding. In dieser Dokumentation wird außerdem Folgendes über die Bewertungslogik der obersten Ebene angegeben: „In Ad Manager wird das Gewinnergebot jeder Komponentenauktion verglichen, einschließlich der Komponentenauktion von Ad Manager für Gebote von Käufern für Interessengruppen sowie der besten kontextbezogenen Anzeige (die über die dynamische Zuordnung ausgewählt wird). Die Anzeige mit dem höchsten Gebot wird ausgeliefert.“
Google Ad Manager	Google Ads-Produkte sollten denselben Regeln unterliegen wie Anzeigenprodukte von Drittanbietern.	Für Google Ads-Produkte gelten bereits dieselben Regeln wie für Drittanbieter.
Von Chrome unterstützte Tests	Fügen Sie Labels für Browser hinzu, die nicht zu A oder B gehören.	Wir haben derzeit keine Pläne dazu, da unsere Untersuchungen gezeigt haben, dass das Hinzufügen von Labels, die nicht zu Tests gehören, Datenschutzbedenken im Zusammenhang mit Zugriffen im Inkognitomodus erschweren kann.
Werbeagentur	Können Agenturen oder Unternehmen ohne JavaScript auf Websites Privacy Sandbox APIs verwenden?	Jeder kann die Privacy Sandbox APIs aufrufen. Wenn eine Agentur oder eine andere Person Technologien direkt auf den APIs entwickeln möchte, ist das möglich. Clientseitige APIs müssen wie Cookies in den Client eingebunden werden. Viele der APIs haben wie Cookies auch eine HTTP-Header-Schnittstelle. Ein Framework der Anzeigenbranche, Prebid, hat bereits clientseitige Integrationen mit den APIs implementiert. Andere Organisationen könnten es ihm gleichtun.
Clientseitige Lösungen	Warum führt Google clientseitige Lösungen für die Privacy Sandbox ein, obwohl ein Entwickler bereits 2012 Bedenken hinsichtlich der Skalierbarkeit solcher Lösungen geäußert hat?	Das Forschungsgebiet „Technologien zur Verbesserung des Datenschutzes“ (Privacy-Enhancing Technology, PET) hat sich seit 2012 erheblich weiterentwickelt und damit auch kommerziell tragfähige Anwendungen. Im Mittelpunkt der Privacy Sandbox stehen Kombinationen von datenschutzfreundlichen Technologien, die vor über einem Jahrzehnt nicht realisierbar gewesen wären. Außerdem hat die Rechenleistung von Computern zugenommen, ebenso wie die Erwartungen der Nutzer an Browser und die rechtlichen Anforderungen an den Datenschutz.
Maschinelles Lernen	Wie wird die Privacy Sandbox von Google für Zwecke des Machine Learnings verwendet?	In weiten Teilen der Anzeigentechnologie wird heute maschinelles Lernen eingesetzt. Wir gehen davon aus, dass sich das nicht ändern wird. Die Privacy Sandbox verhindert nicht, dass Anbieter von Anzeigentechnologien oder andere Personen weiterhin maschinelles Lernen verwenden. Außerdem ist es für Unternehmen, die die APIs einbinden, nicht erforderlich, Machine Learning zu verwenden. Es ist davon auszugehen, dass Unternehmen weiterhin Produkte und Dienstleistungen entwickeln, die den Anforderungen ihrer Kunden entsprechen, unabhängig davon, ob maschinelles Lernen dabei eine Rolle spielt oder nicht. Alle Modelle für maschinelles Lernen, die von Privacy Sandbox-Integratoren erstellt werden, sind ihnen natürlich bekannt und werden daher nicht unkenntlich gemacht.
Datenüberprüfung	Wie können Unternehmen überprüfen, ob die Daten, die sie über die Privacy Sandbox erhalten, korrekt sind? Ist Google bereit, sich von einer Organisation wie dem Media Ratings Council (MRC) prüfen zu lassen?	Privacy Sandbox APIs werden in der Open-Source-Plattform entwickelt, die Chrome antreibt. Die Teile der APIs, die in vertrauenswürdigen Ausführungsumgebungen ausgeführt werden sollen, sind ebenfalls Open Source und können geprüft werden. Jeder, der den Code prüfen möchte, kann das tun, auch das MRC.
(Auch in vorherigen Quartalen gemeldet) Produktionssupport	Wie werden technische Probleme und Eskalierungen im Zusammenhang mit der Privacy Sandbox in Chrome unterstützt?	Google bietet verschiedene Kanäle, über die Werbetechniker technische Probleme melden und erforderliche Eskalationen zur Behebung dieser Probleme veranlassen können. Außerdem wird das Chrome-Team einen Prozess zur Behebung technischer Probleme und Eskalierungen weiterentwickeln und skalieren, die sich auf die Gesundheit des Systems auswirken. Chrome stellt dafür Ressourcen bereit. In unseren öffentlichen und privaten Foren können Sie Feedback geben und Probleme eskalieren.
Von Chrome unterstützte Testmodi	Weitere Informationen zu Zeitplänen und genauen Implementierungen für die von Chrome unterstützten Testmodi.	Wir haben einen Blogpost zu Testmodi veröffentlicht und werden bald weitere Informationen mit Ihnen teilen. Wir nehmen gerne Vorschläge für die Größe der Labels für den Testmodus entgegen.
Integration in andere Branchenstandards	Stellen die Privacy Sandbox APIs eine Verbindung zum TCF v2.* oder zum Einwilligungsmodus her?	Wir haben keine Pläne, die Privacy Sandbox APIs direkt in TCF v2 oder den Einwilligungsmodus einzubinden. Unternehmen und Branchenverbände können ihre Produkte und Frameworks jedoch gerne so anpassen, dass sie mit den Privacy Sandbox-APIs funktionieren. Bei Frameworks wie dem TCF muss jeder Teilnehmer seinen eigenen Ansatz zur Einhaltung der Vorschriften basierend auf dem empfangenen TCF-Signal und den zugehörigen TCF-Richtlinien festlegen. Wir gehen davon aus, dass Unternehmen selbst entscheiden, wann und wie sie die verschiedenen Funktionen unserer Privacy Sandbox-Bausteine nutzen möchten.

Registrierung und Attestierung

Feedbackthema	Zusammenfassung	Chrome-Antwort
Einschränkung	Durch die Registrierung kann Google entscheiden, welches Unternehmen im Ökosystem Privacy Sandbox APIs verwenden darf.	Der Registrierungs- und Attestierungsprozess umfasst im Wesentlichen die Überprüfung der Entität (z. B. ob sie eine D-U-N-S-Nummer hat oder einen Link zu einer Datenschutzerklärung angeben kann) und macht die öffentliche Attestierung zur Voraussetzung für den Aufruf der APIs. Entitäten, die die Registrierungsanforderungen erfüllen, werden validiert. Für Unternehmen ohne D-U-N-S-Nummer bieten wir einen beschleunigten, kostenlosen Prozess mit Dun & Bradstreet an, um eine solche Nummer zu erhalten. Ziel ist es, den Datenschutz der APIs durch die oben genannten Maßnahmen zu verbessern und den Privacy Sandbox APIs eine zusätzliche Transparenzebene hinzuzufügen, damit interessierte Parteien besser nachvollziehen können, wer welche API verwendet und welche Attestationen er dafür vorlegt. Wir sind offen für weiteres Feedback der Branche zu diesem Thema, das bereits bei der Ausarbeitung des Prozesses berücksichtigt wurde.
Mehraufwand durch erneute Registrierung	Die Attestationsdatei läuft alle 12 Monate ab und Websites müssen neu registriert werden.	Wir haben das Feedback der Community berücksichtigt und unseren Ansatz entsprechend angepasst. Das bedeutet, dass Dateien nicht mehr nach 12 Monaten oder einem anderen festgelegten Zeitraum ablaufen. Wir aktualisieren unseren Leitfaden für Entwickler zur Registrierung mit zusätzlichen Informationen.
Attestationsdatei	Wie wird die Attestationsdatei verwendet?	Alle Unternehmen, die APIs zur Relevanz- und Leistungsmessung aufrufen, müssen bis zum Termin für die Durchsetzung die Attestationsdatei auf ihrer Website hochladen und öffentlich zugänglich machen, solange sie die APIs weiterhin aufrufen möchten. Websites können mit etwa einer Anfrage pro Stunde von der Privacy Sandbox rechnen. Auch andere potenzielle Entitäten können Anfragen stellen. Dies geschieht über den Mechanismus des Registrierungssystems, um die Server der registrierten Entitäten abzufragen und sicherzustellen, dass die Attestationsdatei gültig ist. Attestationen werden in Transparenzberichten enthalten sein und für die Allgemeinheit sichtbar sein. Wir erwarten, dass Unternehmen gemäß ihren erklärten Bestätigungen handeln, ebenso wie der Rest des Ökosystems und die zuständigen Regulierungsbehörden.
Registrierung	Ist die Registrierung pro Website oder pro Ursprung?	Die Registrierung erfolgt auf Websiteebene.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema	Zusammenfassung	Chrome-Antwort
Leistung	Leistungsbedenken hinsichtlich der Auswirkungen der Aktivierungsrate von Topics im Europäischen Wirtschaftsraum	Wir empfehlen den betroffenen Stakeholdern, sich wegen dieses Problems an die zuständige Datenschutzaufsichtsbehörde zu wenden. Sie sind am besten in der Lage, solche Bedenken auszuräumen und darauf Einfluss zu nehmen, ob die Verwendung datenschutzfreundlicher Technologien durch Gesetze gefördert oder stattdessen wie Tracking behandelt wird, was dieselben Anforderungen an die Einwilligung erfordert. Letzteres kann dazu führen, dass APIs wie die in der Privacy Sandbox nicht mehr so häufig verfügbar sind.
Registrierung	Müssen Downstream-Bieter sich für die Topics API registrieren, um Topics-Signale von Upstream-SSPs zu verwenden?	Die Downstream-Empfänger von Themen, die nicht der ursprüngliche Topics API-Caller sind, müssen nicht registriert werden. Viele sind jedoch wahrscheinlich für die Verwendung anderer APIs registriert. Im Rahmen der Transparenzbemühungen des Programms wird programmatisch eine Liste der Privacy Sandbox-Teilnehmer zur Verfügung gestellt. So kann ein interessierter Nutzer der Topics API prüfen, ob der Empfänger, an den er ein Thema sendet, registriert ist.
Themenfilter	Sie können anfordern, dass die Filterung eines anderen Aufrufers auf die Themen angewendet wird, die auf der Seite abgerufen werden, um nur die Daten zu teilen, die Käufer abrufen dürfen.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
Ausschließen von Websites	Websites ausschließen, die zu den Themen eines Nutzers beitragen	Themen werden standardmäßig nicht aufgerufen. Bei der Auswahl der Themen werden keine Seiteninhalte berücksichtigt. Alle Themen werden so ausgewählt, dass sie nicht sensibel sind. Außerdem kann der Inhaber einer Website über die folgende Überschrift der Berechtigungsrichtlinie festlegen, dass seine Website nicht in die Topics-Berechnung einbezogen wird: `Permissions-Policy: browsing-topics=()`
Themenbeobachtung	Publishern erlauben, Chrome Berechtigungen zu erteilen, Themen basierend auf dem Seiteninhalt (z. B. Kopf- oder Textbereich) zu klassifizieren.	Wir haben zuvor erwogen, eine Funktion anzubieten, mit der Websites anhand des Seiteninhalts in Themen klassifiziert werden können. Aus Datenschutz- und Sicherheitsgründen haben wir uns jedoch dagegen entschieden. Mit diesem Vorschlag können einige dieser Bedenken möglicherweise ausgeräumt werden, in welchem Umfang ist jedoch unklar. Aufgrund des bevorstehenden Tests für die Conversion-Messung wird diese Änderung voraussichtlich erst nach dem 3. November 2021 erfolgen. Hier können Sie uns zusätzliches Feedback geben.
Themenbeobachtung	Detailliertere Berechtigungsrichtlinien für Publisher bereitstellen	Wenn wir detailliertere Berechtigungsrichtlinien für Publisher bereitstellen, können Publisher-Websites die Nützlichkeit der Topics API für das gesamte System beeinträchtigen, ohne dass sich dies negativ auf die Nützlichkeit der Topics API für die Website selbst auswirkt. Eine ausführlichere Erläuterung des Themas finden Sie im GitHub-Problem Update permissions policy to support separate permissions for retrieve and observe (Richtlinien für Berechtigungen aktualisieren, um separate Berechtigungen für Abrufen und Beobachten zu unterstützen).
Medizinische und gesundheitsbezogene Themen	Warum werden in der Thementaxonomie keine Themen aus den Kategorien „Medizin“ oder „Gesundheit“ abgedeckt?	Kategorien zu Medizin und Gesundheit gelten als sensible Themen und sind daher von der Thementaxonomie ausgeschlossen.
Themen abrufen	DSPs können Themen schneller abrufen, ohne sie über Header abzurufen.	Die Headermethoden sind leistungsfähiger und kostengünstiger als das Erstellen eines plattformübergreifenden iframe und das Erstellen eines `document.browsingTopics()`-Aufrufs daraus. Für den Aufruf muss ein plattformübergreifender IFrame verwendet werden, da der Kontext der obersten Ebene, in dem ein Thema beobachtet werden soll, mit dem Kontext übereinstimmen muss, von dem aus auf Themen zugegriffen wird. Hier finden Sie weitere Informationen dazu.
Themen abrufen	Unterstützung für die Weitergabe von Topics über Header bei ursprungsübergreifenden Script-Tag-Anfragen.	Aus Sicherheitsgründen ist das nicht möglich. Jedes Dokument und seine Ausführungsumgebung sind mit einer einzigen Quelle verknüpft, nämlich der des Dokuments. Untergeordnete Ressourcen von Drittanbietern, die in dieser Umgebung geladen und ausgeführt werden, werden dem Ursprung des Dokuments zugeordnet. So soll verhindert werden, dass Daten ohne Einwilligung von einer Quelle an eine andere weitergegeben werden. Alternativ können Sie ein `browsingTopics`-Attribut für `<script>`-Tags angeben. Dies sollte aus Sicherheitsgründen sauber sein und keine zusätzliche Latenz verursachen. Wir sind offen für Feedback von interessierten Personen.
Bekanntheit	Die Bekanntheit der Topics API und ihrer Verwendung erhöhen.	Wir haben uns mit dem Stakeholder in Verbindung gesetzt, der dieses Feedback gegeben hat, und das Problem wurde auf GitHub behoben. Wir werden das Verständnis der API im Ökosystem auch in Zukunft unterstützen und freuen uns auf die Meinungen der Stakeholder. In der Zwischenzeit empfehlen wir Stakeholdern, die mehr über die Topics API erfahren möchten, sich die Dokumentation im Chrome-Entwicklerleitfaden anzusehen.
Benachrichtigung	Benachrichtigung, die Nutzer darüber informiert, dass ihre Themen von einer Website beobachtet werden.	Wir haben dieses Feedback auf GitHub berücksichtigt. Weitere Informationen zu den Steuerelementen für Themen finden Nutzer in der Chrome-Hilfe.
Maschinelles Lernen	Wie können mithilfe von ML Themen für Nutzer abgeleitet werden?	Wir besprechen dieses Problem und freuen uns über zusätzliches Feedback.
Nützlichkeit für verschiedene Arten von Stakeholdern	Kleinere Anbieter von Anzeigentechnologien können Topics aufgrund der Berechnungsweise in Browsern möglicherweise nicht verwenden.	Nur Anbieter von Anzeigentechnologien, die festgestellt haben, dass der Nutzer innerhalb der letzten drei Wochen eine Seite zum betreffenden Thema besucht hat, erhalten ein Thema. Wenn die Anzeigentechnologie die API in den letzten drei Wochen für diesen Nutzer auf einer Website zu diesem Thema nicht aufgerufen hat, ist der zurückgegebene Wert leer. Aufgrund dieser Funktion erhalten Anbieter von Anzeigentechnologien, deren Dienste von einer größeren Anzahl von Websiteinhabern genutzt werden und die daher mehr Möglichkeiten haben, einen Websitebesuch eines bestimmten Nutzers zu beobachten, möglicherweise mehr Themen als andere Anbieter von Anzeigentechnologien. Diese Funktion ist für den Datenschutz der API unerlässlich, da sie die Verfügbarkeit von Informationen zu einem Nutzer auf diejenigen Parteien beschränkt, die dieselben zugrunde liegenden Informationen bereits beobachten können (derzeit über Drittanbieter-Cookies).
XHR-Anfrage	Wann wird die Einbeziehung von Topics in `XMLHttpRequest`-Anfragen (XHR) eingestellt?	Wie im August 2023 angekündigt, wurde die Unterstützung für XHR in Chrome eingestellt, als die Funktion von der Origin Trial-Phase in die allgemeine Verfügbarkeit überging. Im Zuge der Einführung von Topics wurde die XHR-Unterstützung nur für Nutzer aktiviert, für die die OT-Funktionen aktiviert waren. Nach der Zusammenführung der einzelnen OT-Testgruppen wurde sie vollständig eingestellt. Wenn Sie Topics mit XHR verwendet haben, funktionieren Ihre Websites weiterhin. Die Themen werden einfach nicht den XHR-Anfrageheadern hinzugefügt. Wir empfehlen, für Ihre Anfrage entweder zu `fetch` zu wechseln, das iframe-Attribut zu verwenden oder die JavaScript API zum Abrufen von Themen zu verwenden. Fetch wird von allen modernen Browsern unterstützt, jedoch nicht von Internet Explorer oder Opera Mini.
Aktualisierung von Taxonomie und Klassifikator	Weitere Informationen zur Taxonomie und zum Release-Zyklus von Topics-Klassifikatoren sowie dazu, wie sich Unternehmen auf solche Updates vorbereiten können.	Unsere Antwort bleibt unverändert: Wie im letzten Blogpost erwähnt, gehen wir davon aus, dass sich die Taxonomie im Laufe der Zeit weiterentwickelt und die Verwaltung der Taxonomie schließlich an eine externe Partei übertragen wird, die Stakeholder aus der gesamten Branche vertritt. Wir haben den Plan zur Einführung auch in der Gruppe topics-announce geteilt.
Missbrauch	Potenzieller Angriff über eine Weiterleitungskette.	Wir prüfen dieses Problem und freuen uns über zusätzliches Feedback.
Publisher-Inventartypen	Welche Arten von Publisher-Inventar werden für Tests mit geschützten Zielgruppen und Themen unterstützt?	Weder „Geschützte Zielgruppe“ noch „Themen“ sind von Natur aus in Bezug auf die Inventartypen, für die sie verwendet werden können, eingeschränkt.
Anlaufzeit	Wir empfehlen keine Einarbeitungszeit für neue Taxonomien, um 100 % zu erreichen.	Aufgrund dieser Feedbackanfrage aus der Branche und der Diskussion während der PATCG-Treffen haben wir unseren Plan für die Einführung der neuen Taxonomie bekannt gegeben.

Protected Audience API (früher FLEDGE)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Auktionen der obersten Ebene	Publisher können den Publisher-Ad-Server von Google verwenden, ohne Google Ad Manager die Kontrolle über die Protected Audience API-Auktion der obersten Ebene zu geben.	Antwort von Google Ad Manager: Die Pläne von Google Ad Manager für die Protected Audience API umfassen aus folgenden Gründen keine Unterstützung des Publisher-Ad-Servers von Google ohne Kontrolle der Protected Audience-Auktion der obersten Ebene. Damit wir unseren Kunden im Publisher-Werbemarkt ordnungsgemäß Dienstleistungen anbieten können, muss der Publisher-Ad-Server von Google die Kontrolle über die Protected Audience-Auktion auf oberster Ebene behalten. Als Publisher-Ad-Server stellen wir Publishern Prognosen zur Verfügung, damit sie direkt verkaufte Kampagnen ohne Überbuchung verhandeln und ihre direkten Reservierungen optimal steuern und ausliefern können. Dazu muss die abschließende Auktion durchgeführt werden, um alle infrage kommenden direkten und indirekten Anzeigenquellen zu vergleichen. Prognose und Auslieferungssteuerung sind Kernfunktionen, die Publisher von einem Ad-Server erwarten. Ohne genaue Prognosen kann es passieren, dass Publisher ihr Inventar überverkaufen und so ihren Ruf schädigen. Auch das Tempo ist entscheidend, da die Nichterfüllung von Reservierungsverträgen mit Werbetreibenden die direkte Beziehung zwischen Publisher und Werbetreibenden beeinträchtigen kann, was sich erheblich auf das Geschäft des Publishers auswirken kann. Kurz gesagt: Wir betrachten die Aktivität eines Publisher-Anzeigenservers, die Protected Audience-Auktion der obersten Ebene auszuführen, nicht als von den anderen Aktivitäten des Publisher-Anzeigenservers getrennt.
`directFrom SellerSignals`	Mit `directFrom SellerSignals` kann Google Ad Manager verhindern, dass der Publisher den Preis seiner kontextbezogenen Auktion sieht.	Chrome-Antwort: Informationen, die an `runAdAuction()` übergeben werden, stammen nicht unbedingt vom Verkäufer, es sei denn, der Verkäufer ruft `runAdAuction()` über seinen eigenen iframe auf. Bei einer Mehrfachkunden-Auktion ist es nicht möglich, dass alle Verkäufer den Frame erstellen, der `runAdAuction()` aufruft. `directFromSellerSignals` hat dieses Problem behoben, indem Inhalte aus einem Subresource-Bundle geladen wurden, das vom Ursprung eines Verkäufers geladen wurde. So wird sichergestellt, dass die Authentizität und Integrität der Informationen, die aus den Konfigurationen für Verkäuferauktionen in eine Auktion übergeben werden, nicht manipuliert werden kann. Wenn Publisher die Protected Audience API verwenden möchten, um Informationen zu erhalten, die ihre Technologieanbieter in Protected Audience-Auktionen weitergeben, können sie diese Funktion bei ihren Technologieanbietern anfordern. Antwort von Google Ad Manager: Wir legen seit Jahren großen Wert auf die Fairness von Auktionen. Dazu gehört auch unser Versprechen, dass kein Preis aus den nicht garantierten Anzeigenquellen eines Publishers, einschließlich der Preise für nicht garantierte Werbebuchungen, vor der Gebotsabgabe in der Auktion an einen anderen Käufer weitergegeben wird. Dieses Versprechen haben wir später in unseren Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bekräftigt. Bei Protected Audience-Auktionen möchten wir unser Versprechen einhalten und `directFromSellerSignals` nutzen. Das bedeutet, dass das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion in Auktionen mit mehreren Verkäufern nicht mit anderen Auktionsteilnehmern geteilt wird. Zur Klarstellung: Wir geben den Preis der kontextbezogenen Auktion auch nicht an unsere eigene Komponentenauktion weiter, wie in der Mitteilung Weitere Erläuterungen zur Auktionsdynamik auf oberster Ebene erläutert.
Informationslecks	Vertrauliche Geschäftslogik und vertragliche Details können vom Browser offengelegt werden.	Die Person, die einen Webbrowser verwendet, kann alles sehen, was im Browser passiert. Wenn eine Anzeigenauktion im Browser stattfindet, kann die Person, deren Browser es ist, diese Auktion beobachten und sehen, wie hoch die Gebote der verschiedenen Parteien sind. Da ein Browser der Agent des Nutzers ist, ist es unserer Meinung nach nicht möglich oder wünschenswert, dies zu ändern. Diese Vorgänge sind jedoch nur für die Person sichtbar, die den Browser verwendet. Eine On-Device-Auktion, die mit der Protected Audience API durchgeführt wird, ist für keine Server sichtbar, auch nicht für Google-Server.
`PerBuyerExperiment GroupId`	Mit dem aktuellen Wertebereich von `PerBuyerExperiment GroupId` können Käufer die Kontextdaten mit der vertrauenswürdigen Serveranfrage in Beziehung setzen.	Die Verwendung der Protected Audience API auf diese Weise verstößt gegen die obligatorische Attestierung der Privacy Sandbox, dass API-Nutzer nicht versuchen werden, die Datenschutzmaßnahmen der Privacy Sandbox zu umgehen. Künftig wird die Anforderung, dass Schlüssel/Wert-Server in Trusted Execution Environments (TEEs) ausgeführt werden, einen technischen Schutz vor diesem Angriff bieten.
Richtlinie zu Same-Origin-Zugriff	Lockern Sie die Richtlinie für denselben Ursprung, um Subdomains zuzulassen.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
API-Versionierung	Versions- und Release-Notes für Änderungen an der Protected Audience API anfordern	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
Auktionen mit mehreren SSPs	Ermöglichen Sie die JSON-Zusammenführung mit dem Komponentensignal `auctionSignals` für Auktionssignale der obersten Ebene.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
Gebotslimit	Die Anzahl der Anzeigenkomponenten, die in das Gebot einfließen, wurde von 20 auf 40 erhöht.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback aus der Community dazu, warum dies nützlich wäre.
(wurde auch in früheren Quartalen erfasst) Leistung von Protected Audience-Auktionen	Tester berichten, dass Protected Audience-Auktionen eine hohe Latenz haben.	Bei Fragen zur Latenz wurde bei der Protected Audience API im Allgemeinen das bestehende Standardparadigma verfolgt, mithilfe von Steuerelementen zu bestimmen, wie viel Zeit und Ressourcen die Bieter verbrauchen können, und Tools zu entwickeln, mit denen Käufer entscheiden können, wie sie die verfügbaren Ressourcen am besten nutzen. Diese Steuerelemente und Tools sind zwar heute schon verfügbar, ihre Vorteile werden aber erst nach der Einführung durch Käufer und Verkäufer voll ausgeschöpft. Außerdem arbeiten wir in Chrome kontinuierlich an einer Vielzahl von Infrastrukturverbesserungen zur Steigerung der Auktionsgeschwindigkeit (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Wir freuen uns auf Feedback zu beiden Teilen dieses Projekts: neue Tools, die Käufer und Verkäufer nützlich finden würden, und Berichte zu beobachteten Engpässen, die die Chrome-Entwickler untersuchen sollten.
Buy-Side-Filter	Unterstützung für die Buy-Side-Filterung nach Interessengruppen hinzufügen	Wir haben mehrere Möglichkeiten vorgeschlagen, wie SSPs und DSPs ihre Designs ändern können, um dies zu berücksichtigen: Einige Aufgaben werden auf den Schlüssel/Wert-Server der DSP verschoben. SSPs erstellen einige Kontextsignale und geben diese an DSPs weiter. SSPs, die Kontextsignale für DSPs im Cache speichern
Steuerelement für Interessengruppen von Publishern	Unterstützung für Publisher, die die Verwendung von von ihnen erstellten Interessengruppen delegieren möchten	Wir haben uns mit vielen Parteien über die Anfrage ausgetauscht. Wir sind der Ansicht, dass alle Anwendungsfälle, die die „Delegierung“ der vom Publisher erstellten Interessengruppen betreffen, jetzt berücksichtigt werden können. Außerdem sollten wir zusätzlichen Support einrichten, damit einige Anwendungsfälle in Zukunft reibungsloser ablaufen.
(Auch im 2. Quartal gemeldet) Vertrauenswürdige Ausführungsumgebungen	Unterstützung für vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) in nicht öffentlichen Cloud-Umgebungen.	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir prüfen zwar weiterhin, ob wir auch andere Optionen als öffentliche cloudbasierte Lösungen unterstützen können, haben aber derzeit keine Pläne, On-Premise-TEEs zu unterstützen. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der erheblichen Herausforderungen, die On-Premise-Implementierungen mit sich bringen, sind wir der Meinung, dass die cloudbasierten Implementierungen weiter ausgebaut und verbessert werden sollten (z. B. durch die Unterstützung von Google Cloud zusätzlich zu AWS). Wir würden uns aber über zusätzliches Feedback freuen, warum eine solche Anforderung angesichts der Datenschutz- und Sicherheitsanforderungen notwendig und umsetzbar ist.
eine vertrauenswürdige Ausführungsumgebung	Komponenten im TEE-Bereitstellungspfad, z. B. der Load Balancer, können den gesamten Traffic beobachten und Informationen zur IP-Adresse jeder Anfrage haben.	Derzeit wird die IP-Adresse sowohl bei Gebots- und Auktionsdiensten als auch bei On-Device-Protected Audience-Auktionen als Metadaten in Anfrageheadern an den Werbedienst des nicht vertrauenswürdigen Verkäufers übergeben. Weitere Informationen finden Sie unter Weiterleitung von Metadaten. Langfristig möchten wir Anzeigentechnologien und Tracker-Traffic über einen IP-Proxy leiten, damit Komponenten nicht den gesamten Traffic im Auslieferungspfad beobachten können.
Gültigkeitsdauer (TTL)	Wird die Gültigkeitsdauer (Time to Live, TTL), bevor Dienste neue Schlüssel anfordern müssen, festgelegt oder soll sie flexibel (oder dynamisch) sein?	Die TTL ist in der Regel statisch. Derzeit beträgt die TTL für öffentliche Schlüssel 8 Tage und die Rotation erfolgt alle 7 Tage. Die TTL ist für private Schlüssel im Aggregationsdienst ebenfalls gleich. Bei Gebots- und Auktionsdiensten werden private und öffentliche Schlüssel alle N Stunden über den Pfad ohne Anfrage abgerufen und im Arbeitsspeicher im Cache gespeichert. So liegt zwischen der Schlüsselrotation und der Übernahme dieser Schlüssel durch die Server eine Verzögerung von maximal N Stunden vor. Der Puffer von einem Tag zwischen Schlüsselrotation und Ablauf soll dafür sorgen, dass die Dienste auch dann weiter ausgeführt werden können, wenn die Schlüsselgenerierung fehlschlägt. Wir überlegen, die TTL zu verlängern, um bei Ausfällen besser gewappnet zu sein. Bei einem Schlüsselleck planen wir, die Schlüsselgenerierung manuell zu erzwingen und Schlüssel früher ungültig zu machen. Öffentliche Schlüssel werden derzeit 24 Stunden lang auf den Clients im Cache gespeichert, um sicherzustellen, dass die Dienste auch bei einem Ausfall des Koordinators weiter ausgeführt werden können.
Anpassung an Traffic	Unterstützung für die Verkehrssteuerung für Gebots- und Auktionsdienste.	Käufer können basierend auf selbst erhobenen Daten des Publishers oder kontextbezogenen Daten die Nachfrage nach Auktionen mit geschützten Zielgruppen angeben. Ähnliche Festlegungen können Verkäufer auch auf dem Ad-Server oder Ad Exchange-Server des Verkäufers vornehmen. Die Modelle können mit selbst erhobenen Daten und allen aggregierten Berichten aus Protected Audience-Auktionen trainiert werden. So können Verkäufer vermeiden, Anfragen an Gebot- und Auktionsserver zu senden, wenn keine Nachfrage nach Protected Audience-Auktionen besteht. Wir sind der Meinung, dass dies eine effektive Möglichkeit ist, die Zugriffe zu steuern.
Komponentenbasierte Auktion	Welche Auktionssignale der obersten Ebene werden mit Komponentenverkäufern geteilt?	Käufer in einer Komponentenauktion erhalten nur Signale vom Komponentenverkäufer. Wir werden demnächst eine Dokumentation zur Abfolge einer kombinierten Auktion mit Header Bidding und einer Auktion mit geschützten Zielgruppen veröffentlichen.
Video-Rendering	Unterstützung für das Video-Rendering mit Protected Audience und Fenced Frames	Die Protected Audience API unterstützt das Video-Rendering mit einem Mechanismus, der auf Iframes basiert. Wir haben jedoch noch keine Lösung entwickelt, die mit abgegrenzten Frames kompatibel ist. Dies ist einer der Gründe, warum wir die Durchsetzung für abgegrenzte Frames auf 2026 verschoben haben. Wenn ein Partner also jetzt die Funktion „Umzäunte Frames“ erzwingt, ist die Videounterstützung für diesen Partner nicht verfügbar.
Frequency Capping	(wurde auch in vorherigen Quartalen erfasst) Einstellungen für die Auslieferungshäufigkeit pro Nutzer innerhalb einer Kampagne und Anzeigengruppe.	Unsere Antwort bleibt unverändert: Bei der Funktion „Geschützte Zielgruppe“ wird das Frequency Capping auch für On-Device-Auktionen sowie für kontextbezogene und Branding-Kampagnen unterstützt. Gemeinsam genutzter Speicherplatz und websitespezifische Limits können auch für zusätzliche Einstellungen für das Frequency Capping verwendet werden.
Anzeigenvorgaben	Bietet Protected Audience eine Möglichkeit, die Datenerhebung durch Websites von Werbetreibenden zu deaktivieren oder sie auf die Blockierungsliste zu setzen, oder eine Möglichkeit, alle Interessengruppen desselben Inhabers zu verlassen?	Nutzer haben mehrere Möglichkeiten, den Zugriff auf die Protected Audience API und andere Privacy Sandbox-Funktionen zu blockieren.
Richtlinie zum gleichen Ursprung für die Quell-URL von Gebots- und Auktionsscripts	Die Anforderung, dass alle Felder, die URLs zum Laden von Scripts oder JSON angeben, demselben Ursprung wie der Inhaber zugewiesen sein müssen, wird gelockert.	Wir prüfen diesen Antrag derzeit und freuen uns über zusätzliches Feedback aus der Community.
`forDebuggingOnly`	Es besteht die Gefahr, dass `forDebuggingOnly .reportAdAuctionWin` missbraucht wird, wenn es nach dem 3. Paarungszyklus noch vorhanden ist.	In den letzten Jahren haben wir Feedback aus der Branche zu Funktionslücken bei Protected Audience erhalten, die nach der Einstellung von Drittanbieter-Cookies auftreten. Wir arbeiten daran, einen Plan zu entwickeln, um diese nach der Einstellung von Drittanbieter-Cookies zu unterstützen, ohne die Ziele der Privacy Sandbox zu gefährden. Wir freuen uns über weitere Vorschläge und Feedback zu fehlenden Funktionen, die im Ökosystem gewünscht werden.
Mehrere Interessengruppen	Verwenden Sie mehrere Interessengruppen in einem Gebot.	Das wird derzeit von der Protected Audience API nicht unterstützt, da dies zu einer Änderung des zugrunde liegenden Datenschutzmodells führen würde. Hier können Sie sich mit anderen austauschen.
On-Device-Auktionen	Unterstützt Chrome für Android On-Device-Auktionen für geschützte Zielgruppen?	Ja, On-Device-Auktionen werden in Chrome auf Android-Geräten unterstützt.
Klickbezogene Daten (im 2. Quartal 2023 erfasst)	Fügen Sie browserSignals klickbezogene Daten hinzu.	Wir prüfen diese Funktion weiterhin und freuen uns über zusätzliches Feedback dazu, warum sie priorisiert werden sollte.
Anbieter vertrauenswürdiger Ausführungsumgebungen	Gibt es wesentliche Unterschiede bei den TEE-Angeboten verschiedener Cloud-Anbieter?	Uns sind keine größeren Unterschiede bekannt. Wir empfehlen dem Ökosystem jedoch, die öffentlichen Bereitstellungsanleitungen zu lesen, um herauszufinden, welche Lösung am besten zu seinen Anforderungen passt. Google Cloud. AWS.
(in vorherigen Quartalen gemeldet) Unterstützung für die ausschließende Ausrichtung auf Interessengruppen	Eine API zur Unterstützung des ausschließenden Targetings auf Interessengruppen: Anzeigen werden nur ausgeliefert, wenn ein Nutzer keiner Interessengruppe angehört.	Wir prüfen die Implementierung dieser Funktion und besprechen den Antrag.
Verstoß gegen die Inhaltsrichtlinien	Unterstützen Funktionen, mit denen Nutzer schädliche Anzeigen melden können, die über die Protected Audience API in abgeschotteten Frames ausgeliefert werden.	Wir sind der Meinung, dass der Möglichkeit zur Meldung von Anzeigen mit eingeblendeten Frame gute Optionen für Anbieter von Anzeigentechnologien bietet, die einen von Nutzern erstellten Berichtsablauf für „Schlechte Anzeigen“ wünschen. So könnten Meldungen zu schlechten Anzeigen im Wesentlichen unverändert wie bisher erfolgen. Wir freuen uns über weitere Funktionsanfragen, falls Lücken bleiben, auch in der Zeit nach der Entfernung von Drittanbieter-Cookies, aber bevor das Fenced Frame-Rendering weit verbreitet ist.
Private Aggregation API-Berichterstellung	Wie können wir die Zeit berechnen, die der Nutzer in dieser Interessengruppe verbracht hat?	In Chrome M116 und höher sollte die Relevanz gemäß pull/639 verwendet werden können.
K-Anonymity-Server	Weitere Informationen zum K-Anonymity-Server	Weitere Informationen zu K-Anonymitätsservern finden Sie hier. Wir freuen uns auf Ihr Feedback.
URLs für dynamische Creatives	Unterstützung für Creative-URLs ohne Vorabankündigung unter Wahrung der K-Anonymität.	Wir besprechen diese Funktionsanfrage und freuen uns über zusätzliches Feedback dazu, warum diese Funktion priorisiert werden sollte.
Anforderung an die k-Anonymität	Wird die Anforderung zur k-Anonymität für Aktualisierungen von Interessengruppen wieder eingeführt?	Wir gehen nicht davon aus, dass sich die in diesem GitHub-Beitrag dargelegte Position ändern wird. Wie in diesem Beitrag angekündigt, haben wir uns entschieden, die Anonymisierungsstufe k für Updates von Interessengruppen mit geschützten Zielgruppen zu entfernen. Dies hat keine wesentlichen Auswirkungen auf den Datenschutz der API insgesamt. Wir planen, später andere potenzielle, direktere Schutzmaßnahmen (z. B. den Datenschutz für IP-Adressen oder einen vertrauenswürdigen Updateserver) zu berücksichtigen, sobald die entsprechenden Technologien weiter entwickelt, bereitgestellt und eingesetzt werden.
Betatests für Gebots- und Auktionsdienste	Wann beginnt der Betatest für Gebots- und Auktionsdienste?	Wie in der Zeitachse und Roadmap angegeben, beginnt die erste Phase der Tests für Bidding- und Auktionsdienste im November 2023.
Roadblocking	Unterstützung für die Creative-Koordination für Anzeigennetzwerke anfordern (SSP und DSP gehören zum selben Unternehmen oder zu denselben Properties).	Vielen Dank für Ihr Feedback zu diesem Anwendungsfall. Wir möchten gerne wissen, ob weitere Anbieter von Anzeigentechnologien an einer solchen Unterstützung interessiert sind. Wir freuen uns auf Ihr Feedback.
Native Anzeigen	Unterstützung für abgegrenzte Frames für native Anzeigen	Wir prüfen die Unterstützung des Anwendungsfalls und besprechen mögliche Problemumgehungen und Lösungen.
K-Anonymität	Wie kann ich die Anzahl der Anzeigen für Interessengruppen maximieren, die die K-Anonymisierungsgrenzwerte einhalten?	Wir haben einige taktische Hinweise zu diesem Thema zusammengestellt.
POST-Unterstützung	Unterstützung für das Senden von Auktionsdaten über POST-Anfragen.	Wir prüfen diesen Funktionswunsch und freuen uns über weitere GitHub-Problemmeldungen, in denen Sie erklären, warum diese Funktion priorisiert werden sollte.
Detaillierungsgrad von Berichten	Wie detailliert sind Berichte zu Anzeigen mit abgegrenztem Frame, die aus mehreren Elementen bestehen?	Das aktuelle Design ermöglicht nicht die Erfassung der Produkt-ID oder -Position, da dies die Privatsphäre der Nutzer gefährden könnte. Es kann nur `reserved.top_navigation` aufgerufen werden. Dieser wird gesendet, wenn eine Nutzeraktion (z. B. ein Klick) auf den eingegrenzten Frame der Anzeigenkomponente erfolgt, was zu einer Navigation auf oberster Ebene führt.
Anzeigenauktion	Kann eine SSP, die an einer Komponentenauktion teilnimmt, selbst eine weitere Komponentenauktion auslösen?	Ein `componentSeller` darf kein `componentAuctions` enthalten. Die Mehrfachkundenauktionen haben nur zwei Ebenen: 1. Die Komponentenauktionen laufen parallel. 2. Die Auktion der obersten Ebene, an der die Anzeigen mit dem höchsten Anzeigenrang aus den einzelnen `componentAuction` teilnehmen.
Verfügbarkeit von Gebots- und Auktionsdiensten	Sind Gebote und Auktionen während der Chrome-gestützten Testphase verfügbar?	Bidding- und Auktionsserver sind während der von Chrome unterstützten Testphase nicht verfügbar.
Signale für die Gebotseinstellung	Browsern erlauben, Gebotssignale anzufordern und zu löschen.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback dazu, warum diese Anfrage priorisiert werden sollte.
`generateBid()`	Möglichkeit, das `userBiddingSignals` der Interessengruppe über `updateURL` zu aktualisieren	Wir prüfen diesen Vorschlag und freuen uns über zusätzliches Feedback und eine Diskussion.
Publisher-Inventartypen	Welche Publisher-Inventartypen werden von Tests für geschützte Zielgruppen und TOPICS unterstützt?	Weder „Geschützte Zielgruppe“ noch „Themen“ sind von Natur aus in Bezug auf die Inventartypen, für die sie verwendet werden können, eingeschränkt.
Server-zu-Server-Integration	Ist für „Geschützte Zielgruppe“ eine direkte Integration zwischen SSP und DSP erforderlich?	Eine direkte Integration zwischen SSP und DSP ist nicht erforderlich, wenn die DSP keine kontextbezogenen Signale auf ihrem eigenen Server verarbeiten muss, um diese verarbeiteten Informationen an die On-Device-Gebotsfunktion weiterzuleiten.
Ein `bid_currency`-Feld in B&A	Unterstützung für das Feld `bid_currency` im Gebots- und Auktionsdienst.	B&A unterstützt noch keine `bid_currency`, wir planen jedoch, dies bis Ende Januar 2024 zu tun. Hier finden Sie einen Zeitplan.
`perBuyerSignals`	Gibt es eine Größenbeschränkung für `perBuyerSignals`?	Die Anzahl der Signale pro Käufer ist unbegrenzt. Das Senden zu vieler Daten kann sich jedoch negativ auf die Leistung des Browsers auswirken.
Websiteübergreifende Anwendungsfälle	Können wir Interessengruppen der Protected Audience API auf mehreren Websites verwenden?	Protected Audience ist nicht für solche Anwendungsfälle vorgesehen, wie unter turtledove/issues/282 erläutert.
HTTP-Anfragen für Interessengruppen	Fügen Sie den Blob der Interessengruppe in die HTTP-Header ein.	Wir prüfen diese Anfrage und freuen uns über weiteres Feedback.
Kontrolle der Anzeigenqualität	Verlust der Kontrolle der Anzeigenqualität aufgrund von websiteübergreifenden Informationen	Wir berücksichtigen dieses Feedback und freuen uns über weiteres Feedback.
Chrome-Entwicklertools	Ausgehende Netzwerkanfragen für das Protected Audience-Programm sollten auf dem Tab „Netzwerk“ in den Chrome-Entwicklertools angezeigt werden.	Wir arbeiten daran, diese Funktion auf dem Tab „Netzwerk“ zu aktivieren. Wir freuen uns über zusätzliches Feedback dazu, warum diese Funktion priorisiert werden sollte.
eine vertrauenswürdige Ausführungsumgebung	Wann werden dem Hilfeartikel zum Monitoring von Trusted Execution Environments Details dazu hinzugefügt, welche Messwerte sich auf den Datenschutz auswirken und in welchem Maße?	Wir aktualisieren die Erläuterung derzeit mit diesen Informationen. Die aktualisierte Erläuterung wird bis November 2023 verfügbar sein.
`directFrom SellerSignals`	Warum ist `directFrom SellerSignals` nicht als Web-Bundle verpackt?	Hier findest du weitere Informationen zu dieser Entscheidung.
Impressionsdelegierung	Gibt es eine praktikable Möglichkeit, die Impressionsdelegierung so zu konfigurieren, dass die Auswahl einer Interessengruppe zu einer weiteren Targeting-Aktion führt?	Mehrere verschachtelte Auktionen sind aus zwei Gründen nicht mit unseren Datenschutzzielen vereinbar. Erstens: Wenn das Creative des Gewinners einer Auktion in einem eingegrenzten Frame gerendert wird, ist das resultierende Creative-Rendering ohne Kenntnis des Kontexts eine Datenschutzverletzung. Das liegt daran, dass die URL der umgebenden Seite oder das selbst erhobene Cookie ein Datenschutzverstoß sind. In dieser Umgebung ist eine verschachtelte Auktion nicht möglich. Zweitens: Beim Modell für geschützte Zielgruppen soll der Gewinner jeder Auktion auf Daten nur einer zusätzlichen Website basieren. Verschachtelte Auktionen könnten diese Möglichkeit verbessern, da Anzeigen dann anhand eines Profils mit vielen Websites ausgewählt werden können.
Kriterium für ruhende Daten	Erläutern Sie das Kriterium „Ruhedaten“ im Vertrauensmodell für Schlüssel/Wert-Dienste.	Daten im Schlüssel/Wert-Dienst werden in den Arbeitsspeicher geladen und von dort aus bereitgestellt, anstatt Lese-Caching zu verwenden.
Käuferdatensignal	Gibt es eine definierte Größenbeschränkung für die `buyer_data`-Signale, die von den DSPs empfangen werden?	Derzeit gibt es keine vom Browser auferlegten Limits für `buyer_data`-Signale, die von DSPs empfangen werden.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Geräteübergreifend	Berücksichtigen Sie die geräteübergreifende Unterstützung der Attribution Reporting API.	Geräteübergreifende Anzeigen stellen neben 3 PC neue Herausforderungen im Hinblick auf den Datenschutz dar. Außerdem ergeben sich aufgrund der Vielzahl von Geräten und Plattformen, die Nutzer verwenden können, Herausforderungen bei der Technologiebereitstellung. Wir prüfen derzeit mögliche Lösungen, konzentrieren uns aber auf die wichtigen Anwendungsfälle, die derzeit von Attributionsberichten unterstützt werden. Wir planen nicht, vor der Einstellung von Drittanbieter-Cookies eine geräteübergreifende Unterstützung einzuführen.
(wurde auch in vorherigen Quartalen erfasst) Trigger-Datengröße	Warum ist die Größe der Triggerdaten auf 3 Bit begrenzt?	Die Größe ist auf 3 Bit und 8 verschiedene Werte beschränkt, damit die Menge der website- und kontextübergreifenden Informationen über einen Nutzer begrenzt ist. Wir freuen uns über Feedback von Partnern aus dem Google-Werbenetzwerk dazu, ob die aktuelle Parametrisierung für Berichte auf Ereignisebene ausreicht.
Conversion-Trichter	Mehrere Domains angeben, die für die Conversion verwendet wurden.	Dieser Anwendungsfall ist seit der Hinzufügung mehrerer Ziele möglich. Wir freuen uns auf Ihr zusätzliches Feedback.
Unterstützung für dieselbe Domain in verschiedenen Ländern	Funktionieren Attributionsberichte für Websites mit derselben Domain, aber mehreren länderspezifischen TLDs?	Dieses Problem wurde mit dem Stakeholder besprochen und gelöst, der die Frage gestellt hat. Wenn eine Anzeigentechnologie mehrere länderspezifische TLDs verwenden muss, sind mehrere Registrierungen erforderlich, eine für jede länderspezifische TLD.
Berichte zu Protected Audience und Attribution	Können Werbetechnologien sowohl auf View-through-Conversions für Gebote für geschützte Zielgruppen als auch auf Klick-Conversions für Attributionsberichte zugreifen?	Ja, die Privacy Sandbox sollte sowohl VTCs als auch CTCs in Protected Audience unterstützen.
Verzögerungen bei Berichten, die zusammengefasst werden können	Verzögerungen bei aggregierten Berichten weiter reduzieren.	Wir haben vor Kurzem Feedback zu diesem Thema erhalten und haben hier einige Ideen geteilt. Wir freuen uns über zusätzliches Feedback aus der Community.
Verzögerungen bei Berichten, die zusammengefasst werden können	Verzögerungen durch die Einführung der Serververmittlung reduzieren.	Wir prüfen diesen Vorschlag und freuen uns über zusätzliches Feedback .
Verzögerungen bei Berichten auf Ereignisebene	Verzögerungen bei Berichten auf Ereignisebene werden reduziert.	Mit dem vollständigen flexiblen Vorschlag auf Ereignisebene, der unter Flexible Konfigurationen auf Ereignisebene beschrieben ist, können Verzögerungen bei Berichten auf Ereignisebene auf eine Stunde reduziert werden. Allerdings ist dabei mit mehr Rauschen zu rechnen.
Herkunft der Berichtsquelle pro Quelle	Durch die Begrenzung der maximalen Anzahl von Quellen für die Berichterstellung pro Website für die Berichterstellung von Quellen können Anbieter von Anzeigentechnologien keine Quellen aus verschiedenen Quellen für die Berichterstellung für eine einzelne Publisher-Quelle registrieren.	Wir haben das Problem mit dem Stakeholder besprochen, der es gemeldet hat. Derzeit wird eine mögliche Lösung getestet, bei der eine Meldequelle pro Website verwendet wird, auf der Berichte gesendet werden. Danach werden andere mögliche Lösungen mit Weiterleitungen getestet. Wir freuen uns auch über Feedback zum gesamten System im Hinblick auf diese Einschränkung.
Problemmeldungen	Wie können wir Fehler oder Probleme mit der Attribution Reporting API an Chrome melden?	Wir empfehlen derzeit, alle Fehler der Attribution Reporting API als Problem auf GitHub zu melden. Wenn das Problem mit Chrome zusammenhängt, empfehlen wir, einen Chromium-Fehler zu melden. Unter Mit anderen interagieren und Feedback geben finden Sie Links dazu, wie und wo Sie Probleme melden können.
Deduplizierung	Wie können wir Conversions in verschiedenen Pipelines und auf verschiedenen Geräten deduplizieren?	Die geräte- und messungspipelineübergreifende Deduplizierung ist eine bekannte und aktuelle Herausforderung, der sich auch Anbieter von Anzeigentechnologien heute mit 3PCs stellen müssen. Mit der Attribution Reporting API können Werbetreibende festlegen, wann bestimmte Conversions registriert werden sollen, und bestimmte Metadaten hinzufügen, um anzugeben, welche Analysepipelines sie zum Erfassen der Conversions verwendet haben (d. h. einen Teil des Aggregationsschlüssels), der mit anderen Analysepipelines verglichen werden kann. Wir freuen uns über weiteres Feedback zu diesem Thema.
Deduplizierung und Priorität	Fordern Sie vor der Deduplizierung eine Priorität an.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback.
Schutz vor Betrug	Risiko, dass böswillige Nutzer die Daten auf Ereignisebene manipulieren.	Die Berichtsüberprüfung funktioniert für Berichte auf Ereignisebene aus den im Artikel Warum werden Berichte auf Ereignisebene nicht unterstützt? beschriebenen Gründen nicht.
Conversion-Typ	Wie können wir in den Attributionsberichten zwischen „Zielvorhaben nach Aufruf“ und „Zielvorhaben nach Navigation“ unterscheiden?	Wir haben die folgende integrierte Filteroption: `source_type`. Weitere Informationen finden Sie hier.

Zusammenfassungsdienst

Feedbackthema	Zusammenfassung	Chrome-Antwort
Budgetwiederherstellung	Einige Anbieter von Anzeigentechnologien haben die Möglichkeit angefragt, Berichte noch einmal zu verarbeiten, wenn es zu Ausfällen, Fehlern oder Löschungen ihrer Berichte kommt.	Das Team arbeitet an Lösungen, um dieses Problem datenschutzfreundlich zu lösen.
Websiteregistrierung	Mehrere Anbieter von Anzeigentechnologien haben Unterstützung für die Verarbeitung mehrerer Ursprünge im selben Konto für Anwendungsfälle wie die Aufteilung von Daten nach Standort oder Werbetreibendem angefordert. Dieses Verhalten wird auch von Anbietern von Anzeigentechnologien erwartet, da die Client API-Registrierung jetzt websitebasiert (und nicht quellenbasiert) ist. Die Migration von der Ursprungs- zur Websiteregistrierung optimiert den Onboarding-Prozess für Anzeigentechnologien, da er mit dem Registrierungsprozess für Kunden übereinstimmt.	Wir werden demnächst die Migration von der Registrierung des Ursprungs zur Registrierung der Website für den Aggregationsdienst einführen und freuen uns auf Feedback aus dem System.
Veröffentlichungs- und Einstellungsplan	Veröffentlichungs- und Einstellungszeitplan für Funktionen und Patches des Aggregationsdiensts. Ziel des Plans ist es, Werbetechnologieanbietern Transparenz über unsere Release-Richtlinien zu bieten, damit sie sich auf bevorstehende Releases und Einstellungen vorbereiten und für stabile und sichere Versionen der Dienste sorgen können.	Wir haben vor Kurzem einen Vorschlag für den Veröffentlichungs- und Einstellungsplan für den Aggregationsdienst veröffentlicht und freuen uns über zusätzliches Feedback.
Koordinatoren	Was passiert, wenn die Koordinatoren des Aggregationsdiensts ausfallen?	Beide Koordinatoren müssen voll verfügbar sein, damit das System ordnungsgemäß funktioniert. Kurze Zeiträume der Nichtverfügbarkeit werden in unseren Clientbibliotheken durch Wiederholungen berücksichtigt. Bei einer längeren Nichtverfügbarkeit eines der beiden Koordinatoren schlagen Aggregationsjobs fehl. Jobs können noch einmal ausgeführt werden, wenn das Budget für den Datenschutz noch nicht aufgebraucht ist. Wenn ein Dienstfehler zu einer Budgetausschöpfung geführt hat, ohne dass ein Zusammenfassungsbericht in den Speicher der Anzeigentechnologie geschrieben wurde, empfehlen wir derzeit, mithilfe des Tools für lokale Tests mithilfe von Debugberichten Ergebnisse abzurufen. Außerdem arbeiten wir an Funktionen, mit denen sich das Budget bei Fehlern wiederherstellen lässt, damit Werbetreibende ihre Jobs noch einmal ausführen können.

Private Aggregation API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Blob-URL	Unterstützung von Blob-URLs im freigegebenen Speicher anfordern	In Chrome M116 wurde die Unterstützung für Blob-URLs hinzugefügt.

Verdecktes Tracking einschränken

Reduzierung des User-Agents und User-Agent-Client-Hints

Feedbackthema	Zusammenfassung	Chrome-Antwort
JavaScript API	Verfügbarkeit der User-Agent Client Hints JavaScript API	Wir haben keine Pläne, diese Funktion zu entfernen, da sie unsere Hauptlösung für Partner ist, die aktiv auf Daten mit hoher Entropie zugreifen möchten, die über die standardmäßig in der eingefrorenen und reduzierten UA verfügbaren Daten hinausgehen.
Informationen zum Gerät und zum Formfaktor	Die Fähigkeit von Websites, Eingaben, Ausgaben und andere Informationen zu verstehen, die das Gerät, das die Website besucht, unterstützen kann.	Wir haben diesen Antrag unterstützt, da wir Feedback von Nutzern erhalten haben.

IP-Schutz (früher Gnatcatcher)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Infrage kommende Zugriffe von Drittanbietern	Worauf bezieht sich in der Erläuterung der Begriff „zulässige Zugriffe von Drittanbietern“?	Uns ist bewusst, wie wichtig diese Frage ist. Wir arbeiten aktiv daran, zu ermitteln, welcher Drittanbieter-Traffic infrage kommt und welcher nicht. Wir freuen uns über Feedback zu diesem Thema.
Netzwerkverkehrsanalysen	Unterstützung für Unternehmen bei der Durchführung von Netzwerkverkehrsanalysen für ihre Netzwerke.	Betroffen ist nur der Traffic von Drittanbietern, der in Websites von selbst erhobenen Daten eingebettet ist. Dadurch sollte die Menge an Traffic, der gefiltert werden muss, begrenzt werden. Außerdem möchten wir Nutzern die Möglichkeit geben, den IP-Schutz zu aktivieren oder zu deaktivieren. Für von Unternehmen verwaltete Chrome-Versionen gibt es Unternehmensrichtlinien, mit denen der IP-Schutz deaktiviert werden kann. Schließlich prüfen wir, welche Einstellungen Netzwerkbetreibern zur Verfügung gestellt werden, um den IP-Schutz zu deaktivieren. Wir freuen uns über Feedback zu diesem Thema.
Zugriffssteuerung	Der IP-Schutz kann sich auf Webdienste auswirken, die IP-Adressen für die Zugriffssteuerung verwenden.	Wir sind uns der Bedeutung von Anwendungsfällen zur Betrugsprävention und der möglichen Auswirkungen auf diese Anwendungsfälle bewusst. Wir möchten von Ihnen wissen, wie wir Anwendungsfälle zur Betrugsprävention, die in der Regel auf IP-Adressen basieren, besser unterstützen können.
Kommunikation zwischen den 2-Hop-Proxys	So sorgen Sie dafür, dass keine Informationen zwischen Proxys ausgetauscht werden.	Wir sind gerade dabei, die Proxy-Interaktionen zu entwerfen. Unser Ziel ist es, die Wahrscheinlichkeit einer solchen Weitergabe von Informationen über geschäftliche, prozessuale und technische Mittel zu minimieren.
Authentifizierungen von Drittanbietern	Unterstützung für Authentifizierungen von Drittanbietern	Wir planen, in Zukunft weitere Details zur Kontoauthentifizierung zu veröffentlichen. Hier finden Sie einige erste Überlegungen.
Tracker-Klassifizierung	Wie wird mit IP Protection bestimmt, was ein Tracker und seine Varianten sind?	Uns ist bewusst, wie wichtig diese Frage ist. Wir arbeiten aktiv daran, zu ermitteln, welcher Drittanbieter-Traffic infrage kommt und welcher nicht. Wir freuen uns über Feedback zu diesem Thema.
Analytics	Der IP-Schutz kann sich auf die Genauigkeit von Analysediensten auswirken.	Wir möchten die Auswirkungen des IP-Schutzes weiter untersuchen und freuen uns über zusätzliches Feedback und Beispiele aus der Branche.
Proxy	Wie funktioniert die IP-Maske in diesem Fall, wenn ein Nutzer einen Proxy verwendet oder einen Proxy manuell definiert hat?	Wir möchten die Auswirkungen des IP-Schutzes auf andere Proxys besser verstehen. Aktuell gibt es keine konkreten Pläne dazu. Wir freuen uns über Feedback zu diesem Thema.
Premium-Angebot	Ist der IP-Schutz eine kostenpflichtige Funktion?	Der IP-Schutz ist für Chrome-Nutzer als Teil des grundlegenden Browsererlebnisses verfügbar. Die Funktion ist kostenlos.
Proxy server	Werden während der Nutzersitzungen dieselben Proxyserver verwendet?	Eine HTTP/S-Verbindung verwendet ein einzelnes Proxy-Paar und stellt dem Ursprung eine einzelne maskierte IP-Adresse vor. Außerdem gibt es keine strengen Einschränkungen, dass verschiedene HTTP-/S-Verbindungen dieselben Server verwenden müssen.
Plattform-Support	Auf welcher Plattform wird der IP-Schutz unterstützt?	Der IP-Schutz ist anfangs in Chrome für Android und auf dem Computer verfügbar. Wir prüfen derzeit, wie wir den Schutz auf andere Plattformen ausweiten können.
Deaktivieren	Können Nutzer den IP-Schutz deaktivieren?	Wir möchten Nutzern die Möglichkeit geben, zu entscheiden, ob sie den IP-Schutz verwenden möchten oder nicht.
Anonymisierung	Welche Arten von Anfragen werden im Rahmen des IP-Schutzes anonymisiert?	HTTP/S- und DNS-Anfragen an berechtigte Drittanbieterdomains werden über die Datenschutz-Proxys anonymisiert. Weitere Informationen dazu, wie wir festlegen, welche Domains aufgenommen werden, finden Sie in einer kommenden Erklärung. Der Rest des Traffics (z. B. der Rest der DNS-Anfragen oder anderer HTTP/S-Traffic) ist davon nicht betroffen.
Datensichtbarkeit	Auf Netzwerkadressen kann während des ersten Hops im IP‑Schutz zugegriffen werden.	Beim Zwei-Hop-Proxy-Modell sieht der erste Hop (von Google gesteuert) nur die Quell-Client-IP und eine Anfrage zur Verbindung mit dem zweiten Hop. Der zweite Hop (von einem externen CDN gesteuert) sieht nur ein Tupel für den ersten Hop (Proxy-IP + Port) und die Ziel-IP. Bei der Antwort vom Ursprung kann der zweite Hop die Antwort an den Proxy und Port des ersten Hops weiterleiten, der mit der Anfrage verknüpft ist, und muss nichts über die ursprüngliche Client-IP erfahren. Der erste Hop gibt die Antwort einfach an den Client zurück, ohne etwas über die Ziel-IP zu erfahren. Auf diese Weise lernt der erste Hop nur die Client-IP und der zweite Hop, während der zweite Hop nur die Ziel-IP lernt.
WebView	Wird der IP-Schutz in Zukunft für Android WebView verfügbar sein?	Derzeit gibt es keine konkreten Pläne dazu. Wir möchten diesen Schutz aber so weit wie möglich anbieten.

Eindämmung von Bounce-Tracking

Feedbackthema	Zusammenfassung	Chrome-Antwort
Interaktions-Tracking	Wie werden Nutzerinteraktionen erfasst?	Mit der Funktion zur Eindämmung von Bounce-Tracking werden zwei Arten von Nutzerinteraktionen erfasst: Nutzeraktionen gemäß der HTML-Spezifikation. Dazu gehören Klicks, Tastendrücke, Tippen auf Touchbildschirme usw. Erfolgreiche webauth-Behauptungen. In diesen Fällen tippt ein Nutzer auf einen Sicherheitsschlüssel oder verwendet einen Passkey als Authentifizierungsmethode. Diese Interaktionen werden der Website der obersten Ebene auf den Seiten zugeordnet, auf denen sie auftreten. Wenn ein Nutzer beispielsweise in einem eingebetteten Iframe klickt, wird die Interaktion der Website auf oberster Ebene und nicht der eingebetteten Website zugeordnet. Die Interaktionen werden in einer Datenbank gespeichert, die die schemalose etld+1 und die Uhrzeit der Interaktion enthält. Interaktionen schützen die zugehörige Domain 45 Tage lang vor dem Löschen des Status zur Bounce-Tracking-Mitigation.
Ausnahmen auf der Zulassungsliste	Können Domains davon ausgenommen werden?	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.

Datenschutzbudget

In diesem Quartal haben wir kein Feedback erhalten.

Websiteübergreifende Datenschutzgrenzen stärken

Gruppen ähnlicher Websites (früher „First-Party-Sets“)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Zentraler Ansatz	Bedenken hinsichtlich des Ansatzes mit zentralem Repository für die Verwaltung von Gruppen ähnlicher Websites	Ein öffentliches, leicht zugängliches Repository ist für die Gestaltung von RWS von entscheidender Bedeutung, da es für Einreichungen Rechenschaftspflicht schafft. Die Funktionsweise von Drittanbieter-Cookies wird letztendlich durch die Verwendung der Storage Access API oder der rSAFor API bereitgestellt. Mit einer RWS-Mitgliedschaft erhalten Sie automatisch Zugriff (im Gegensatz zu Aufforderungen mit der Storage Access API). Wir sind der Ansicht, dass ein Ansatz wie der RWS-Einreichungsprozess eine angemessene Anforderung für den automatisch gewährten Zugriff auf Drittanbieter-Cookies ist.
JSON-Datei umbenennen	Muss der Name der gehosteten JSON-Datei geändert werden, wenn der API-Name geändert wird?	Ja, die Richtlinien für die Einreichung wurden geändert. Die primäre Domain muss unter `/.well-known/related-website-set.json` eine JSON-Datei bereitstellen. Bestehende Sets in der RWS-Liste müssen nicht geändert werden. Wenn jedoch Änderungen an vorhandenen Sets eingereicht werden, muss die JSON-Datei geändert werden.
(Auch in vorherigen Quartalen erfasst) Domainlimit	Mehr verknüpfte Domains beantragen	Wie in einem Blogpost vom 31. August angekündigt, haben wir das Limit für verknüpfte Domains auf fünf Domains erhöht. Wir haben uns entschieden, das zugehörige Domainlimit auf fünf Domains (zuzüglich einer primären Domain) zu erhöhen, was der am besten vergleichbaren Implementierung eines anderen großen Browsers entspricht.
Drittanbieter-Cookies	Funktionieren Gruppen ähnlicher Websites nur, wenn Drittanbieter-Cookies deaktiviert sind?	Sets mit ähnlichen Websites funktionieren auch dann, wenn ein Nutzer Drittanbieter-Cookies nicht blockiert hat. Es gibt jedoch keine wahrnehmbaren Auswirkungen, da die relevanten Cookies ohne Sets mit ähnlichen Websites und die Storage Access API verfügbar sind.
Legitime Änderungen	Wie verhindert das Repository für zugehörige Website-Sets, dass nicht berechtigte Nutzer Sets ändern?	Gemäß den Anleitungen zur Einreichung kann jeder eine Pull-Anfrage auf GitHub einreichen, um die Datei `first_party_sets.JSON` zu bearbeiten. Wenn der PR jedoch genehmigt wird (technische Validierungen usw. besteht), wird er einmal pro Woche (Dienstags um 12:00 Uhr (Eastern Time)) von Google manuell in Batches in die kanonische FPS-Liste aufgenommen. Wenn ein Angreifer versucht, ein Set zu ändern, das ihm nicht gehört, sollte das kein Problem sein, da er die `.well-known`-Dateien nicht ändern kann und die Validierungen daher fehlschlagen.
Domain-Hijacking	Bei einem Domain-Hijacking können zugehörige Domaindaten für Unbefugte freigegeben werden.	Das ist nicht möglich, wie in diesem GitHub-Problem zu Protected Audience erläutert.

Fenced Frames API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Verstoß gegen die Inhaltsrichtlinien	Nutzer dürfen verdächtige Anzeigen melden.	Verdächtige Anzeigen können auch über eingeblendete Frames gemeldet werden. Nutzer können weiterhin mit der Anzeige interagieren und verdächtige Anzeigen auf die übliche Weise an die Anzeigentechnologie melden.
Interaktion mit umliegenden Standorten	Interaktionen mit der umgebenden Website oder der Website auf oberster Ebene zulassen.	Wir möchten wissen, warum diese Anfrage erforderlich ist, und freuen uns über zusätzliches Feedback aus der Branche.
Native Anzeigen	Unterstützung für abgegrenzte Frames für native Anzeigen	Wir prüfen die Unterstützung des Anwendungsfalls und besprechen mögliche Umgehungslösungen und Lösungen.

Shared Storage API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Domainübergreifend	Domainübergreifende Kommunikation für lokalen Speicher zulassen.	Dieser Anwendungsfall entspricht derzeit nicht den datenschutzfreundlichen Ausgabe-Grenzwerten von Shared Storage. Wir freuen uns aber über zusätzliche Informationen, während wir Vorschläge für nicht partitionierten Speicher weiterentwickeln.
Blob-URL	Unterstützung von Blob-URLs im freigegebenen Speicher anfordern	In Chrome M116 wurde die Unterstützung für Blob-URLs hinzugefügt.

CHIPs