Rapport de commentaires - T1 2024

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Rapport trimestriel du 1er trimestre 2024 résumant les commentaires reçus de l'écosystème sur les propositions de la Privacy Sandbox et la réponse de Chrome.

Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.

Les thèmes des commentaires sont classés en fonction de leur prévalence par API. Pour ce faire, nous prenons la quantité de commentaires que l'équipe Chrome a reçus sur un thème donné et l'organisons par ordre décroissant. Les thèmes courants des commentaires ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquentes soulevées par les équipes internes de Google et les formulaires publics.

Plus précisément, les comptes rendus des réunions des organismes de normalisation du Web ont été examinés. Pour les commentaires directs, les enregistrements de Google des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires publics ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation pour déterminer la prévalence relative des thèmes émergents en lien avec chaque API.

Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifique aux fins de cet exercice de rapport public. En raison de l'objectif actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Protected Audience et Attribution Reporting.

Les commentaires reçus après la fin de la période de création de rapports en cours n'ont peut-être pas encore fait l'objet d'une réponse de Chrome.

Glossaire des acronymes

ARA

API Attribution Reporting

CHIPS

Cookies ayant un état partitionné indépendant

DSP

Plate-forme côté demande

FedCM

Gestion des identifiants fédérés

Lecteur d'empreinte digitale

Ensembles propriétaires

IAB

Interactive Advertising Bureau

IDP

Fournisseur d'identité

IETF

Internet Engineering Task Force

IP

Adresse IP

openRTB

Enchères en temps réel

Prolongation

Essai Origin

API PAT

API Protected Audience (anciennement FLEDGE)

PatCG

Groupe de la communauté sur les technologies publicitaires privées

RP

Partie de confiance

RWS

Ensembles de sites Web associés (anciennement "Ensembles internes")

SSP

Plate-forme côté offre

TEE

Environnement d'exécution sécurisé

UA

Chaîne user-agent

UA-CH

Hints client User-Agent

W3C

World Wide Web Consortium

WIPB

Blanchement volontaire des adresses IP

Commentaires généraux, aucune API ni technologie spécifique

Thème des commentaires	Résumé	Réponse de Chrome
Gouvernance	Intérêt pour une période de commentaires publics concernant les mises à jour de la gouvernance de la Privacy Sandbox.	Nous sommes ouverts aux commentaires raisonnables des personnes concernées sur les développements importants concernant la Privacy Sandbox, y compris sur la gouvernance future de la Privacy Sandbox.
Tests	Phases de test supplémentaires pour le 3PCD en plus des tests facilités par Chrome actuels (1 %).	Nous n'avons pas l'intention d'étendre les tests facilités par Chrome au-delà du 1% actuel du trafic Chrome activé depuis début janvier.
Web to App	La 3PCD sur les appareils mobiles ne doit pas avoir lieu avant que l'interopérabilité complète entre le Web et l'application ne soit atteinte.	Nous sommes d'accord qu'il est souhaitable de prendre en charge l'interopérabilité entre les applications et le Web. Nous avons lancé la mesure de l'attribution entre les applications et le Web, et nous étudions des solutions de ciblage Web vers application. Toutefois, nous ne prévoyons pas de retarder l'implémentation de la fonctionnalité 3PCD sur le Web mobile. Nous n'avons pas pour objectif d'atteindre une couverture de 100% à la fin de la période de transition. Nous nous attendons plutôt à ce que la compatibilité sur Android pour la mesure entre les applications et le Web soit raisonnablement élevée à 3 PCD et qu'elle augmente au fil du temps à mesure que les utilisateurs mettent à jour leurs téléphones.
Rôle du navigateur	Chrome semble jouer le rôle d'ad server ou de SSP.	Chrome ne joue pas le rôle d'un ad server ni d'un SSP. Avec l'API PA, Chrome fournit un conteneur permettant aux ad servers, aux SSP, aux DSP et aux autres technologies publicitaires d'apporter leur propre logique d'enchères et de notation.
Conseils sur les cas d'utilisation	Des consignes plus claires sur les cas d'utilisation qui seront pris en charge par les API de la Privacy Sandbox.	Au début du projet Privacy Sandbox, la documentation destinée aux développeurs était principalement axée sur leur participation aux processus de discussion et d'envoi de commentaires pour toutes les propositions. Cela a permis de développer une véritable collaboration au sein de l'écosystème pour développer les propositions, mais à mesure que les API ont évolué vers la disponibilité générale, une nouvelle audience de développeurs est apparue, qui est principalement là pour s'appuyer sur les API plutôt que de contribuer à leur développement sous-jacent. Nous avons récemment modifié la navigation sur le site des développeurs de la Privacy Sandbox pour la concentrer sur les cas d'utilisation, en utilisant des catégories similaires à celles de l'IAB Tech Lab dans son récent rapport de la Privacy Sandbox Task Force. Nous allons continuer à utiliser cette approche basée sur les cas d'utilisation.
Environnement de développement local	Comment continuer à développer et à tester notre frontend localement sur http://localhost lorsque le cookie est SameSite=Secure et que le backend est présenté par un CDN ?	Nous discutons de ce problème ici et nous accueillons les commentaires supplémentaires de l'écosystème.
Atténuation des 3PCD	Existe-t-il un moyen programmatique de savoir si les cookies tiers sont bloqués ou si les heuristiques sont actives ?	Dans Chrome, la détection de fonctionnalités et document.hasStorageAccess appelé dans un iframe permettent au développeur de savoir si l'origine de l'iframe a accès aux cookies tiers.
Tests vidéo	Il n'est actuellement pas possible de tester les annonces vidéo dans la Privacy Sandbox.	Chrome a publié une discussion et une démonstration de plusieurs façons d'utiliser la vidéo avec l'API PA aujourd'hui (voir les numéros 242 et 254 dans notre dépôt de démonstrations sur GitHub). Notez qu'il ne s'agit pas d'un exemple de code que les technologies publicitaires adopteraient en bloc, mais plutôt d'une preuve de concept et d'une démonstration des techniques pouvant prendre en charge le rendu vidéo VAST avec l'API PA. Au cours de cette discussion, il est également apparu clairement que, bien que le rendu vidéo soit déjà possible aujourd'hui, Chrome pourrait apporter des modifications qui simplifieraient l'implémentation avec l'API PA. Par exemple, les modifications apportées à la substitution de macro ( décrites ici), que nous avions déjà prévues de prendre en compte en fonction des commentaires sur les cas d'utilisation de la vérification des annonces tierces en termes de brand safety, répondront également aux commentaires concernant le cas d'utilisation des vidéos, où l'acheteur cherche les macros du vendeur à utiliser pour l'affichage. La plupart des discussions à ce jour ont porté principalement sur l'affichage des annonces vidéo VAST. L'affichage des annonces natives peut utiliser les mêmes approches, et est de bien des façons plus simple. Les annonces natives semblent actuellement recevoir moins d'attention que les annonces vidéo, mais il ne s'agit que d'une question de priorité dans le secteur de la technologie publicitaire, et non d'une barrière technique à l'implémentation.
Mesure des données non publicitaires	Les 3PCD peuvent avoir un impact sur les solutions de mesure d'audience non liées aux annonces.	Les API de mesure n'exigent pas que le cas d'utilisation soit lié aux annonces. Alors que l' ARA est plus spécifique à un parcours publicitaire typique,l' agrégation privée est à usage général. Ces deux composants peuvent être utilisés pour répondre à un large éventail d'activités de mesure.
Créateurs de contenu	La Privacy Sandbox est conçue pour encourager les créateurs de contenus à créer davantage de contenus pour YouTube et moins sur leurs propres sites.	L'initiative Privacy Sandbox vise à préserver la confidentialité de l'activité des utilisateurs sur un Internet ouvert et libre. Nous savons que les éditeurs s'appuient sur les annonces pour produire des contenus et les rendre aussi largement disponibles que possible. Les annonceurs aident les utilisateurs à découvrir de nouveaux produits ou offres qui pourraient les intéresser. Les fonctionnalités de la Privacy Sandbox permettent aux sites Web de tous types, y compris ceux qui collaborent avec des créateurs de contenu, de diffuser des annonces utiles aux utilisateurs en fonction de leur activité avec différentes parties, sans révéler leur identité à ces parties.
Chronologies plus claires	Calendriers de publication plus clairs et détaillés pour les technologies de la Privacy Sandbox.	La documentation de l'API Privacy Sandbox inclut des pages sur l'état et la disponibilité de l'API. Ces pages répertorient les fonctionnalités à venir et leurs délais (par exemple, API PA, ARA). Pour consulter une vue centralisée de ces états, cliquez ici.
Machine learning	Les technologies publicitaires ne peuvent pas entraîner correctement les modèles de machine learning tant que le taux de données de conversion anormales (3PCD) n'est pas supérieur à 1%.	L'extension de la fonctionnalité 3PCD à d'autres navigateurs à des fins de test ne garantit pas que les API seront davantage utilisées, ce qui est probablement ce que les technologies publicitaires recherchent pour entraîner davantage de modèles de machine learning. Si les technologies publicitaires ne cherchent pas à utiliser un écosystème plus large pour entraîner davantage de modèles de machine learning, il n'y a aucune raison d'étendre la 3PCD. En effet, une technologie publicitaire souhaitant entraîner des modèles sur davantage de trafic peut le faire dès aujourd'hui sans augmenter la 3PCD. Cela peut être fait sans que Chrome semble avancer sur la 3PCD avant la fin de l'arrêt.
Cas d'utilisation non compatible	Les cas d'utilisation des DSP en libre-service ne sont pas actuellement pris en compte.	Plusieurs DSP en libre-service fournissent régulièrement des commentaires publics sur les API. Plusieurs de ces DSP qui fournissent régulièrement des commentaires publics se sont également identifiés comme testeurs. De plus, Chrome s'intéresse activement aux sujets typiques des DSP en libre-service, comme les ad servers vidéo et tiers. Ces sujets ont été abordés dans les appels hebdomadaires récents de l'API PA.
Évaluation Origin	Demande d'OT pour les sites souhaitant une montée en puissance et une couverture de test plus agressives pour la 3PCD.	Chrome développe actuellement une OT propriétaire, qui permettra aux origines d'activer le comportement d'abandon progressif des cookies tiers. Les origines de niveau supérieur qui s'inscrivent à ce test et déploient des jetons verront les 3PC bloqués comme si la protection contre le suivi était activée sur l'appareil de l'utilisateur. Cette période d'essai permettra aux sites de tester plus largement les alternatives à long terme aux PGC, avant l'abandon progressif des PGC prévu après consultation de la CMA. Nous travaillons toujours à finaliser le calendrier de déploiement de cette période d'essai.
Rapport du laboratoire technique de l'IAB	Commentaires sur la Privacy Sandbox reçus du rapport de l'IAB Tech Lab.	Vous trouverez notre réponse détaillée au rapport de l'IAB Tech Lab sur cette page. Nous avons également reconnu que "le rapport soulève des questions concernant la documentation fragmentée, les exigences commerciales, les audits tiers, l'accréditation du secteur, la scalabilité, la transparence et la gouvernance future, sur lesquels nous allons échanger avec l'écosystème et mettre à jour nos questions fréquentes publiques en conséquence". Nous avons déjà abordé la documentation fragmentée. Vous trouverez les exigences commerciales dans la section "Garanties de données" ici. Certains produits Google Ads ont partagé leur approche. Pour en savoir plus sur les audits tiers, consultez la section "Garantie d'intégrité des algorithmes" ici. En ce qui concerne l'accréditation, nous nous attendons à ce que ces organismes continuent d'accréditer les produits, y compris leur utilisation des technologies, plutôt que les technologies elles-mêmes. En ce qui concerne l'évolutivité, nous restons à l'écoute des données des développeurs qui démontrent des problèmes. En ce qui concerne la transparence et la gouvernance, nous continuons de développer des solutions en Open Source sur GitHub et sur des forums tels que le W3C, tout en collaborant avec la CMA dans le cadre des engagements.
Google Sign-In	Les connexions Google permettraient à Google d'utiliser des données de connexion permettant l'identification croisée, ce qui est contraire aux engagements.	La fonctionnalité Se connecter avec Google ne permet pas à Google d'utiliser les données contrairement aux engagements.
Compatibilité	Quels sont les plans concernant la prise en charge des API Privacy Sandbox et la rétrocompatibilité ?	Une fois qu'une fonctionnalité est disponible pour tous les utilisateurs, nous nous efforçons de la maintenir. Bien sûr, il n'est pas toujours possible de maintenir la rétrocompatibilité. Dans ce cas, nous disposons d'un processus clair pour l'abandon et la suppression des fonctionnalités existantes, décrit ici. Nous prévoyons d'ajouter progressivement d'autres fonctionnalités aux API de la Privacy Sandbox, en réponse aux commentaires de l'écosystème sur les cas d'utilisation qui pourraient bénéficier d'une meilleure prise en charge. Dans ce cas, nous avons tendance à inclure une technique de détection de fonctionnalités afin qu'une technologie publicitaire souhaitant tester une nouvelle fonctionnalité puisse demander directement au navigateur si elle est prise en charge. Cette approche est préférable à celle consistant à demander aux développeurs de vérifier un certain numéro de version de Chrome, car certaines fonctionnalités ne sont pas déployées auprès de tous les utilisateurs de Chrome en même temps. Par exemple, cliquez ici pour en savoir plus sur notre travail de détection des fonctionnalités pour l'API PA.
Implémentation du serveur	Plutôt que de s'associer à sa propre implémentation, Chrome doit spécifier les comportements qu'une implémentation satisfaisante d'un serveur de signaux approuvés, d'un serveur d'agrégation et de tout autre composant non navigateur requis doit respecter. Cela permettrait d'innover dans le respect de limites de confidentialité acceptables.	Nous apprécions et encourageons l'innovation de la part de tiers. Pour toutes les API et tous les services, nous souhaitons offrir aux technologies publicitaires la flexibilité nécessaire pour implémenter leurs fonctionnalités. Par exemple, nous autorisons les technologies publicitaires à utiliser des informations commerciales confidentielles pour concevoir la logique d'enchères. De plus, nous tenons compte en permanence des commentaires des technologies publicitaires et, le cas échéant, les intégrons à nos conceptions. Pour permettre à d'autres d'exécuter leur propre code dans des environnements d'exécution sécurisés, la Privacy Sandbox devra examiner le code (et toute modification) pour s'assurer qu'il respecte les garanties de confidentialité. Cela nécessitera des efforts importants de la part de l'équipe Privacy Sandbox. Nous aimerions donc comprendre quels avantages l'entreprise souhaite obtenir, qui ne sont pas actuellement satisfaits.
Heuristiques	Quels sont les projets à long terme pour les heuristiques ?	Comme l'ont indiqué d'autres navigateurs, nous prévoyons de supprimer progressivement ces heuristiques à mesure que d'autres solutions seront largement utilisées, sous réserve d'une analyse de faisabilité supplémentaire. Vous trouverez plus d'informations sur cette page.
Volume de test	Volume de trafic différent lorsque vous comparez différentes dimensions.	Le test du 1% comporte des critères d'exclusion qui entraînent des différences d'éligibilité entre les différentes populations de clients Chrome. Par exemple, le test exclut les utilisateurs de Chrome Enterprise. Par conséquent, la fraction du trafic avec des libellés de test devrait être plus élevée le week-end. Il est normal de constater des pourcentages de trafic différents pour différents segments de données (par exemple, la zone géographique, la date et la plate-forme), ce qui correspond à ce que nous observons dans les données Chrome.
Réactiver manuellement 3 PC	Les sites pourront-ils savoir combien d'utilisateurs (%) ont réactivé manuellement les cookies après l'application du 3PCD ?	Les utilisateurs pourront réactiver l'accès des tiers au niveau du site via le contournement par l'utilisateur s'ils rencontrent un problème. Les cookies tiers peuvent également être réactivés par d'autres mesures, telles que l'API Storage Access. Des mesures techniques, comme hasStorageAccess(), permettent aux sites de détecter si les cookies tiers sont activés ou désactivés. Toutefois, Chrome ne permettra pas aux sites Web de connaître les raisons de la réactivation.
Protection contre le suivi	Combien de temps la fonctionnalité d'interface utilisateur de la protection contre le suivi de Chrome sera-t-elle disponible ?	L'UI de la protection contre le suivi dans la barre d'adresse devrait rester disponible après l'abandon des cookies tiers.
(également indiqué dans les trimestres précédents) Compatibilité multinavigateur	Autres fournisseurs de navigateurs adoptant les API Privacy Sandbox	D'autres fournisseurs de navigateurs, tels qu'Apple, Mozilla et Microsoft, participent activement aux forums publics où les principes de confidentialité et les approches basées sur les navigateurs sont discutés. Nous sommes encouragés par les discussions collaboratives dans des forums tels que la récente réunion annuelle du TPAC du W3C et les forums en cours du PATCG du W3C, où nous observons des signes de convergence. Par exemple, Microsoft Edge a récemment annoncé son plan visant à "maximiser la compatibilité syntaxique" avec l'API PA et ARA, tout en proposant des fonctionnalités supplémentaires aux développeurs.
Option de remplacement pour les éléments intégrés incompatibles après le 3PCD	Fournissez des hooks d'API pour détecter si une iFrame / intégration tierce est conforme ou non à la 3PCD.	Nous discutons de la demande sur cette page et nous accueillons les commentaires supplémentaires de l'écosystème.
Tests	Demander des indicateurs supplémentaires dans les instances gérées de Chrome pour désactiver temporairement les comportements personnalisés.	Nous examinons cette demande pour les instances gérées de Chrome et nous accueillons les commentaires supplémentaires de l'écosystème si un tel indicateur serait utile.

Inscription et attestation

Thème des commentaires	Résumé	Réponse de Chrome
Vérification de l'attestation	Comment Google s'assurera-t-il de l'authenticité des attestations ?	Tous les inscrits doivent conserver le fichier d'attestation en place lorsqu'ils utilisent les API. Google vérifie que le fichier est en place et que la syntaxe est correcte, mais ne valide pas le comportement de la technologie publicitaire par rapport au langage d'attestation.
Processus d'inscription à l'API Private Aggregation	Existe-t-il un moyen de vérifier l'état de l'enregistrement de l'API Private Aggregation ?	Une fois l'inscription validée, l'équipe d'assistance chargée des inscriptions envoie un e-mail à tous les participants approuvés. Si le participant a des questions au cours de la procédure, il peut contacter l'équipe d'assistance (à laquelle il est mis en relation lorsqu'il envoie son formulaire d'inscription). L'équipe d'assistance vous répondra, répondra à vos questions et vous fournira toute aide supplémentaire nécessaire.

Afficher des publicités et des contenus pertinents

Thèmes

Thème des commentaires	Résumé	Réponse de Chrome
(également indiqué dans les trimestres précédents) Calendrier et documentation des classificateurs	Il devrait exister un mécanisme permettant de faire examiner la classification ou, à tout le moins, une transparence supplémentaire sur la façon dont le mode de classification détermine les catégories.	Notre réponse n'a pas changé depuis les trimestres précédents: "La mauvaise classification des sites peut rendre le signal Topics légèrement moins utile dans l'ensemble, mais les sites spécifiques qui sont mal classés ne sont pas plus ou moins affectés que les autres. En effet, les informations contextuelles d'un site sont toujours disponibles pour les enchères sur son site, ce qui fournit des informations comparables à celles du bon thème, même en cas de mauvaise classification. N'hésitez pas à nous faire part de vos commentaires à ce sujet en cliquant ici."
Google Ad Manager	Google Ad Manager est déjà intégré à la plupart des sites et dispose d'informations beaucoup plus complètes sur les sujets des utilisateurs que les concurrents, qui sont présents sur moins de sites.	L'exigence d'observation vise à s'assurer que l'API Topics ne partage pas les données utilisateur avec plus d'entités que les technologies qu'elle remplace (y compris les PGC). D'autres solutions du secteur, comme Prebid, fonctionnent avec des dizaines de milliers de sites et permettent aux acteurs du marché d'appeler l'API Topics via leur technologie. En outre, il est important de noter que la limite de cinq sujets principaux par semaine peut avoir un effet égalisateur, car les participants au marché présents sur de nombreux sites qui pourraient apprendre plus de cinq sujets équivalents à l'aide de trois PC seront limités à cinq.
(également indiqué dans les trimestres précédents) Utilité pour différents types de personnes concernées	Inquiétudes concernant la valeur créée et la distribution de cette valeur pour les sites en fonction de leur niveau de trafic ou du niveau de spécialisation de leur contenu.	Nous sommes conscients que les sites spécialisés sont plus susceptibles de proposer des sujets plus précis que les domaines d'intérêt général. Toutefois, tous les sites spécialisés ne proposent pas de sujets commercialement intéressants. De plus, cette dynamique reflète l'état actuel et est entièrement indépendante de l'abandon des 3PC dans Chrome. Dans l'environnement actuel, certains sites sont plus intéressants que d'autres dans les systèmes de pertinence des annonces basés sur des tiers. De plus, les thèmes des sites spécialisés peuvent être mutuellement bénéfiques, car différents annonceurs peuvent diffuser des campagnes sur différents ensembles de thèmes, et la logique d'enchères peut observer la valeur sur un large éventail de thèmes.
Noms d'hôte et URL complètes	La classification basée sur les noms d'hôte des sites Web est-elle suffisamment efficace et permet-elle de réduire le risque de confidentialité par rapport aux URL complètes ?	Nous avons envisagé d'utiliser des URL d'informations ou des titres de page en plus des noms d'hôte, et nous avons conclu que les avantages potentiels seraient contrebalancés par les risques pour la confidentialité et la sécurité des utilisateurs. Par exemple, la classification d'informations sensibles incluses dans l'URL ou le titre de la page dans les sujets d'un utilisateur peut présenter des risques pour la confidentialité des utilisateurs.
Thèmes en tant que signal	Demander des conseils sur la façon de combiner Topics avec d'autres signaux et sur les autres signaux qui pourraient être utiles.	Les solutions de technologie publicitaire peuvent obtenir les meilleurs résultats en combinant tous les outils disponibles, tels que le machine learning et les signaux respectueux de la confidentialité provenant d'API protégeant la confidentialité, ainsi que des données contextuelles, des données de création et des données first party. Pour en savoir plus, consultez cette page.

API Protected Audience (anciennement FLEDGE)

Thème des commentaires	Résumé	Réponse de Chrome
Volume de trafic de test	Les testeurs signalent un faible volume de réponses aux enchères pour les enchères via l'API PA.	1. La densité des enchères est corrélée à la participation de l'écosystème à l'API PA, qui devrait continuer d'augmenter tout au long de l'année 2024 et au-delà. C'est finalement aux annonceurs, à leurs agences et à leurs fournisseurs de technologie de déterminer comment allouer les budgets de leurs campagnes. Nous nous attendons à ce que certains participants à l'écosystème retardent leur investissement dans diverses solutions sans cookies, y compris l'API PA, jusqu'après le 3PCD. À ce moment-là, nous nous attendons à ce qu'ils augmentent l'allocation de leur budget de campagne à ces solutions. 2. Le volume de demandes d'enchères dans les enchères de l'API Protected Audience peut être affecté par (1), car les éditeurs et leurs fournisseurs de technologie publicitaire peuvent décider de ne pas lancer d'enchères de l'API Protected Audience s'ils estiment que la demande est faible. Il appartient aux éditeurs de déterminer la priorité de la mise à jour de leurs pages et de leur participation. Pour ces raisons, nous pensons que les éditeurs peuvent prendre du temps pour tester et augmenter progressivement le trafic. Ce rapport inclut également une réponse de Google Ad Manager concernant les commandes des éditeurs pour la participation à l'API PA.
(également signalés au cours des trimestres précédents) Fraude / Abus	Comment l'écosystème peut-il réduire les risques et empêcher les acteurs malveillants ou les acheteurs de se présenter comme une audience souhaitable ?	Les mécanismes de création de rapports des annonces de l'API PA conservent les informations utilisées pour distinguer le trafic humain du trafic généré par des robots. De plus, les techniques actuelles d'inclusion ou d'exclusion de domaines basées sur les domaines peuvent être utilisées dans l'API PA. Pour en savoir plus, consultez notre réponse au rapport de l'IAB Tech Lab sur la Privacy Sandbox.
Restriction de même origine sur l'URL du propriétaire de l'IG et de la logique d'enchères	Avec l'exigence de même origine, les points de terminaison d'un propriétaire d'IG seront obligés de passer par le même équilibreur de charge, ce qui peut entraîner le rejet des redirections.	L'exigence de même origine pour le chargement de script est une mesure de sécurité importante. Vous trouverez plus d'informations sur une solution proposée qui équilibre les commentaires de l'écosystème et d'autres considérations sur cette page.
Enchères privées multi-emplacements	Il existe de nombreuses possibilités d'autoriser les enchères privées multi-emplacements dans les limites de la confidentialité en utilisant du bruit et une intégration plus étroite aux pratiques publicitaires actuelles.	Nous tenons compte de ces commentaires et évaluons la demande de mise aux enchères multi-balises par rapport à la complexité accrue et aux risques de confidentialité associés à cette fonctionnalité. Nous avons abordé ce problème plus en détail lors d'un appel du groupe de la communauté Web Incubator (WICG) de l'API PA ici.
Top-level Sellers	La structure actuelle de l'API PA fournit à tout vendeur de premier niveau beaucoup plus de données et une meilleure compréhension de la valeur relative des impressions que les éditeurs ou les vendeurs de composants.	Dans une mise aux enchères multivendeur, chaque vendeur a une enchère optimale. De plus, nous avons appris de l'écosystème que les éditeurs peuvent souhaiter examiner la demande vendue directement à côté des meilleures enchères de chaque vendeur avec lequel ils travaillent. Il est nécessaire d'examiner toutes ces opportunités de monétisation potentielles pour déterminer quelle annonce diffuser. Cette situation, où un acteur doit voir l'ensemble des options pour choisir une annonce à diffuser, remonte à l'époque antérieure à l'API PA. L'API PA vise à prendre en charge les enchères multi-vendeurs et le souhait des éditeurs de prendre en compte la meilleure enchère de chaque vendeur à côté des campagnes publicitaires vendues directement, le cas échéant. Par conséquent, un mécanisme doit être mis en place pour permettre aux utilisateurs de choisir parmi ces opportunités de monétisation, comme c'est le cas aujourd'hui. Nous ne pensons pas que le navigateur soit le bon acteur pour sélectionner l'annonce à diffuser. Le concept de vendeur de premier niveau est donc nécessaire pour sélectionner une annonce gagnante parmi de nombreuses possibilités. La logique de ce vendeur de premier niveau doit pouvoir prendre en compte les meilleures enchères de chaque vendeur avec lequel l'éditeur choisit de travailler. La logique de ce vendeur peut choisir de fournir des informations sur les campagnes vendues directement par l'éditeur lorsque ces informations sont disponibles. Toutes ces informations peuvent être prises en compte dans la logique de sélection des annonces de niveau supérieur. Cela signifie que la logique de niveau supérieur voit les meilleures enchères de l'enchère de l'API PA et, le cas échéant, toutes les options d'annonces vendues directement par l'éditeur pour déterminer un gagnant. Google Ad Manager détaille son implémentation de l'API PA en tant que vendeur de premier niveau dans ce rapport, sous le thème Accès aux informations.
Séparation des annonces concurrentes	Demande de séparation des annonces concurrentes, par exemple pour empêcher les annonces de marques concurrentes d'apparaître l'une à côté de l'autre.	Nous ne connaissons aucun moyen d'assurer une séparation concurrentielle dans l'écosystème publicitaire numérique programmatique, basé sur les enchères et multivendeur d'aujourd'hui. Toutefois, l'API PA permet aux vendeurs d'extraire des signaux supplémentaires en temps réel en fonction d'une combinaison de renderURL et d'un nom d'hôte (représentant le domaine de l'éditeur) qui peuvent être utilisés lors de l'évaluation des créations. Les vendeurs peuvent l'utiliser pour empêcher les annonces de marques concurrentes d'apparaître l'une à côté de l'autre, si l'éditeur souhaite appliquer cette règle.
Informations limitées	L'API PA réduit les informations disponibles pour les éditeurs, telles que la valeur de l'annonce, le nom de l'acheteur du composant, le nom de l'annonceur, l'URL de la page de destination, la taille de la création, le temps de réponse et le taux d'enchère, ainsi que les enchères perdantes.	Nous avons proposé quelques solutions potentielles ici et nous attendons les commentaires supplémentaires de l'écosystème.
Rapports au niveau des événements	Les éditeurs ne peuvent plus obtenir suffisamment d'informations sur l'annonce diffusée après l'abandon de l'API PA pour les rapports au niveau des événements.	Nous sommes conscients des différents cas d'utilisation des rapports que nous devons continuer à prendre en charge lorsque les rapports au niveau des événements seront abandonnés. C'est pourquoi nous avons fixé la date d'abandon des rapports au niveau des événements à 2026. En attendant, nous vous invitons à participer activement à nos échanges avec l'écosystème pour trouver des solutions durables, qui pourraient inclure de nouvelles idées pour obtenir des informations tout en protégeant la confidentialité.
Plusieurs SSP	La valeur ajoutée de plusieurs SSP sera trop faible pour les éditeurs.	Nous ne pensons pas que ce soit le cas et nous aimerions recevoir d'autres commentaires de la part de l'écosystème pour comprendre la raison de cette affirmation.
Activités de curation	Les activités de curation ne sont pas possibles avec l'API PA.	Nous avons reçu des commentaires sur la possibilité pour les vendeurs d'utiliser l'API PA pour partager leurs informations sur l'audience avec les acheteurs sur le Web (également appelée "extension d'audience"). Nous pensons que cela est possible aujourd'hui, en utilisant la fonctionnalité de délégation de l'API Attribution Partner et les accords commerciaux. Parallèlement, nous étudions activement si et comment nous pouvons mieux répondre à ces types de cas d'utilisation.
Désactivation par l'acheteur	La désactivation par défaut de l'acheteur est susceptible de réduire les résultats des enchères de composants.	Que vous définissiez une mise aux enchères PA pour un seul vendeur ou plusieurs vendeurs, le vendeur doit lister explicitement les acheteurs dans le champ "interestGroupBuyers" de AuctionConfig. D'après les commentaires de l'écosystème, les vendeurs ont des contrats avec certains acheteurs et non avec d'autres. Ils auraient donc besoin de contrôler explicitement les acheteurs à inclure dans les enchères. Nous sommes à votre disposition pour discuter de ce point sur GitHub.
Taille de l'annonce	Impossible de préfiltrer en fonction de la taille de l'annonce et de la taille de l'emplacement d'annonce.	Nous travaillons à l'ajout de cette fonctionnalité. Pour en savoir plus, cliquez ici.
Compatibilité avec le ciblage par exclusion sur Instagram	Une API compatible avec le ciblage IG négatif: diffusion d'annonces uniquement si un utilisateur n'appartient pas à une IG.	Ce problème GitHub propose une autre méthode d'implémentation du ciblage négatif, dans laquelle le navigateur indique directement au serveur d'annonces les règles de ciblage négatif qui doivent être en vigueur pour une demande d'annonce spécifique. Bien que cette approche semble attrayante, toutes les versions de cette idée que nous avons étudiées permettent au serveur d'identifier de manière unique l'utilisateur.
règlement sur les services numériques	Comment un éditeur peut-il utiliser des cadres délimités, tout en empêchant l'affichage des réponses contenant des informations soumises au Digital Services Act ?	Comme pour toute nouvelle technologie, chaque entreprise est tenue de s'assurer que son utilisation de la Privacy Sandbox est conforme à la loi. Google ne peut pas fournir de conseils juridiques. Pour chaque API, nous avons publié une documentation technique détaillée, qui devrait servir de base pour effectuer les évaluations juridiques nécessaires. Les cadres délimités ne seront pas obligatoires dans l'API PA avant 2026, ce qui permettra aux personnes concernées de s'assurer que leur utilisation de cette technologie est conforme à toutes les lois applicables.
Documentation	La méthode updateAdInterestGroups() est-elle temporaire ?	Nous n'avons pas annoncé notre intention d'abandonner updateAdInterestGroup. À l'avenir, nous pourrons appliquer des mesures de protection de la confidentialité similaires à celles que nous avons évoquées publiquement pour d'autres mécanismes de mise à jour d'Instagram, par exemple en utilisant une adresse IP également proxy et en ajoutant un délai avant la mise à jour.
Prise en charge de la propriété des métadonnées et de la logique côté acheteur pour les non-DSP	Demande d'un moyen d'agir en tant que proxy pour les DSP.	Nous sommes au courant de ces commentaires provenant de segments autres que les DSP et nous examinons cette demande. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème.
Rapports	Demande d'ajout de la fonctionnalité de gestionnaire personnalisé pour le bucket / la valeur des signaux dans les rapports d'agrégation privée.	Nous en sommes conscients, et cette demande de fonctionnalité est en attente d'examen. N'hésitez pas à nous envoyer d'autres commentaires sur cette page.
Documentation	Existe-t-il un lien permettant de consulter tous les en-têtes de réponse qui doivent être définis par l'annonceur et le domaine propriétaire (délégataire) ?	Nous prévoyons de mettre à jour la documentation pour clarifier ce point et nous accueillons les commentaires supplémentaires de l'écosystème.
Enchères multi-tour	Demande d'explication du workflow (entraînement et inférence) via un schéma d'architecture / de blocs sur la façon dont une approche multi-tours est envisagée dans le contexte de l'API PA.	Merci d'avoir donné votre avis. Nous avons quelques présentations sur le sujet, à partir desquelles nous prévoyons de créer des documents supplémentaires.
Ciblage par exclusion	Capacité de la Privacy Sandbox à protéger les audiences sensibles et les mineurs contre les annonces inappropriées, comme les jeux d'argent et de hasard.	L'API PA ne prend pas en compte le contenu des annonces diffusées. C'est les développeurs de technologies publicitaires qui utilisent PA qui contrôlent ce paramètre. En général, l'éditeur et ses fournisseurs de technologies publicitaires peuvent bloquer les créations publicitaires dans les enchères Protected Audience à l'aide des informations contextuelles de la page et des ensembles de règles de l'éditeur. Cela reflète notre compréhension de l'approche de l'écosystème face à ces défis aujourd'hui. Pour les acheteurs, la fonctionnalité de ciblage par liste d'exclusion peut également être utile dans certains cas d'application des règles.
Conception d'API	Google s'oppose à cette pratique et souhaite que les technologies publicitaires utilisent une fonction d'enchères universelles, ce qui augmente la latence, plutôt que différentes biddingLogicURL dans différents IG, ce qui est autorisé.	Au cours de nos discussions sur la latence des enchères, nous avons souligné que réutiliser le même script pour tous les IG d'un acheteur accélérerait l'exécution de ses enchères. Pour en savoir plus, consultez cette page, ainsi que nos autres recommandations pour améliorer la latence des enchères de l'API PA.
Marketing basé sur les comptes	L'API PA n'est pas une API propre pour les cas d'utilisation du marketing axé sur le compte.	Nous accueillons les commentaires de l'écosystème sur les cas d'utilisation spécifiques qu'ils pensent ne pas être possibles. Nous invitons les participants de l'écosystème à poursuivre cette discussion via notre dépôt GitHub public ou nos appels hebdomadaires.
Test A/B	Lorsque l'API PA est configurée dans GAM pour un éditeur, elle doit actuellement être activée pour l'ensemble de l'inventaire ou pour aucun. Cela limite la capacité des éditeurs à effectuer un test A/B viable.	Réponse fournie par Google Ad Manager : Les commandes de l'API PA dans Google Ad Manager (GAM) affectent la capacité de GAM à utiliser l'API, à condition qu'elle soit disponible. Les éditeurs peuvent donc effectuer des tests A/B à l'aide de la fonctionnalité de règles d'autorisation de Chrome pour désactiver l'utilisation de l'API sur un sous-ensemble de trafic à utiliser comme groupe de contrôle pour un test A/B.
Machine learning	Les éditeurs ont besoin de plus de contrôle sur l'utilisation proposée du machine learning par GAM.	Réponse fournie par Google Ad Manager: En janvier 2024, nous avons lancé une option permettant aux éditeurs de désactiver notre limiteur d'apprentissage automatique et d'activer les enchères de l'API Protected Audience avec des vendeurs autres que Google sur l'ensemble de leur trafic. Pour en savoir plus sur ce paramètre, consultez notre Centre d'aide.
(également indiqué dans les trimestres précédents) Enchères de premier niveau	Possibilité d'utiliser le serveur d'annonces pour les éditeurs de Google sans accorder à GAM le contrôle de l'enchère de l'API PA de niveau supérieur.	Réponse fournie par Google Ad Manager: Pour les raisons expliquées dans le rapport du troisième trimestre 2023 de Google, les plans d'intégration de l'API PA de GAM n'incluent pas la prise en charge des éditeurs qui utilisent GAM comme ad server d'éditeur sans contrôler les enchères de premier niveau.
Accès à l'information	Le GAM a accès à des informations précieuses sur les concurrents, y compris les prix des enchères contextuelles, les signaux fournis par les acheteurs aux SSP pour les enchères de l'API PA et les paramètres de configuration des SSP.	Réponse fournie par Google Ad Manager: Nous accordons depuis des années une attention toute particulière à l'équité des enchères, y compris en nous assurant qu'aucun prix d'une source publicitaire non garantie d'un éditeur, y compris les prix des éléments de campagne non garantis, n'est partagé avec un autre acheteur avant qu'il ne définisse son enchère. Nous avons ensuite réaffirmé cette promesse dans nos engagements envers l'Autorité de la concurrence française. Pour les enchères via l'API PA, nous avons l'intention de tenir notre promesse et de ne pas partager l'enchère d'un participant aux enchères avec un autre participant aux enchères avant la fin des enchères dans les enchères multi-vendeurs. Pour être clair, nous ne partagerons pas le prix de l'enchère contextuelle avec une enchère de composant, y compris la nôtre, comme expliqué dans cette mise à jour. De plus, nous n'utilisons pas les informations sur les configurations d'enchères de composants, y compris les signaux fournis par les acheteurs aux SSP, dans le cadre de nos propres enchères. En fait, nous serions ravis de voir des modifications apportées à l'API PA permettant aux vendeurs de composants de spécifier leurs configurations d'enchères de composants de manière à les masquer du vendeur de premier niveau.
Enchères de composants	En tant qu'enchère de premier niveau, GAM contrôle les SSP qui exécutent des enchères de composants pour chaque opportunité publicitaire.	Réponse fournie par Google Ad Manager: En tant que serveur d'annonces pour les éditeurs, GAM propose une API légère aux SSP avec lesquels un éditeur peut travailler pour spécifier les configurations de mise aux enchères de ses composants via l'API Google Publisher Tag (GPT). Pour en savoir plus, cliquez ici. Si une SSP fournit une configuration d'enchères de composants via cette API, elle sera incluse dans la liste des enchères de composants pour cette opportunité publicitaire. GAM n'impose aucune restriction aux enchères de composants incluses. Tout SSP qui souhaite lancer une mise aux enchères de composants peut le faire, à condition que l'éditeur lui ait autorisé à exécuter le code nécessaire sur sa page.
Enchères de composants	GAM peut appliquer un prix plancher spécifique et non divulgué à chaque enchère gagnante de l'enchère par composant.	Réponse fournie par Google Ad Manager: GAM accorde depuis des années une attention toute particulière à l'équité des enchères. Afin de garantir des enchères équitables et transparentes, nous n'acceptons pas les prix planchers qui ne s'appliquent qu'à des segments de demande spécifiques. Il s'agit d'un principe cohérent dans notre produit et il le restera pour les enchères via l'API PA.
Ad servers tiers	Les serveurs publicitaires tiers n'auraient pas accès à la participation de Google aux enchères de niveau supérieur, ce qui limiterait leur capacité à bénéficier de la demande du SSP Google dans le contexte de l'API PA.	Réponse fournie par Google Ad Manager: Actuellement, GAM permet de tester l'API PA avec plusieurs vendeurs sur GAM via l'API décrite ici. La participation de GAM en tant qu'enchère de composant dans d'autres enchères de premier niveau n'est pas actuellement prise en charge.
(également indiqué dans les trimestres précédents) Performances des enchères de l'API PA	Les testeurs signalent que les enchères de l'API PA ont une latence élevée.	Nous avons entendu des inquiétudes concernant la latence. C'est pourquoi nous avons développé un certain nombre de fonctionnalités dans l'API PA, qui permettront aux SSP de définir des limites sur la latence des DSP et d'apporter des améliorations qui peuvent réduire la latence. Nous avons récemment mis à jour notre guide des bonnes pratiques concernant la latence, qui contient plus d'informations sur la façon de profiter de ces fonctionnalités. Nous continuons également à améliorer la latence, comme vous pouvez le voir sur cette page.
(également indiqué dans les trimestres précédents) Affichage vidéo	Prise en charge du rendu vidéo à l'aide de l'API PA et des frames clôturés.	En janvier, nous avons publié une démonstration du fonctionnement des annonces InStream dans une mise aux enchères au premier prix, avec des informations supplémentaires sur les autres approches. Les acteurs de l'écosystème commencent également à proposer le fonctionnement du rendu vidéo pour les partenaires qui s'intègrent à eux, comme les propositions de GAM sur la création d'une URL de rendu compatible avec la vidéo ou le processus E2E complet. Nous tenons également compte des commentaires de l'écosystème sur les modifications que nous pouvons apporter pour accroître l'adoption. Une de ces modifications est détaillée sur GitHub. Nous restons activement engagés dans l'écosystème pour identifier les autres obstacles à l'adoption que nous pourrions rencontrer et les résoudre dans les meilleurs délais.
(signalé également au cours des trimestres précédents) Règles de gestion des données	Quelle est la politique de gestion des données pour les API IG / PA ?	Dans la conception de l'API PA, toutes les données stockées dans les IG ou concernant les personnes qui se trouvent dans les IG sont (i) conservées sur l'appareil ou (ii) traitées dans les services d'enchères et de mise aux enchères exécutés dans un environnement d'exécution sécurisé (TEE). Dans les deux cas, les données ne peuvent être lues par aucune autre partie ni utilisées à d'autres fins que pour générer des enchères lors de la mise aux enchères. Certaines améliorations de la confidentialité que Chrome explore impliquent une interaction avec un serveur d'anonymat k géré par Google. Cette interaction est conçue avec soin pour éviter de partager des informations sur les utilisateurs et pour s'exécuter dans un TEE afin de garantir la parité des informations dans l'écosystème publicitaire. Google s'est engagé auprès de la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en favorisant ses propres activités, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces obligations.
(également indiqué dans les trimestres précédents) Durée de vie sur Instagram	Demande d'extension de la durée de vie des IG de 30 à 90 jours.	Une telle modification nécessite une évaluation minutieuse, en tenant compte des avantages pour le secteur et de l'impact sur les utilisateurs de Chrome et les autres personnes concernées. Nous examinons cette demande et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
(également indiqué dans les trimestres précédents) modelingSignals	Demandez un nouveau champ en plus des modelingSignals qui ne peuvent encoder que des informations sur les affichages et les clics.	Nous avons répondu à ces commentaires en vous proposant une contre-proposition ici. Nous échangeons activement avec les acteurs du secteur pour connaître leur point de vue sur notre proposition. Nous évaluons actuellement les avantages pour le secteur par rapport à l'impact sur les utilisateurs de Chrome et les autres personnes concernées.
Bits supplémentaires dans reportWin()	Fournissez des bits supplémentaires dans reportWin() à partir de la limite actuelle de 12 avant 3PCD.	Nous étudions actuellement des approches pour prendre en charge ce cas d'utilisation. Cela prend du temps, car nous recherchons également des approches qui nous aideront à mettre en place un plan de confidentialité à long terme.
Conception des enchères	Demandes d'une seule enchère qui renvoient des URL de rendu avec leur score correspondant.	Nous avons envisagé de partager plusieurs URL de rendu et leur score respectif à partir d'une seule enchère PA, mais nous ne l'avons pas implémenté pour des raisons de confidentialité. Nous comprenons votre souhait d'éviter de diffuser plusieurs fois la même annonce à un utilisateur sur une même page. Nous serons ravis de poursuivre la discussion sur GitHub.
reportWin	journaliser des champs arbitraires dans la fonction reportWin().	C'est déjà le cas pendant la période de test. Une fois que Chrome aura cessé de prendre en charge les 3PC, la version forDebuggingOnly de l'API sera migrée pour activer le débogage à basse résolution, comme indiqué ici.
Vendeurs de composants	disposer d'un mécanisme indépendant pour comptabiliser ses propres impressions et autres événements, et ne pas avoir à dépendre uniquement des rapports des technologies publicitaires ;	Cette demande de fonctionnalité est en attente d'examen. Nous ne prévoyons pas de résoudre ce problème pendant la période de test facilitée par Chrome.
Facturation au coût par clic	Implémentez la facturation au coût par clic dans l'API PA.	Nous examinons cette demande ici et nous la considérons actuellement comme une demande de suggestions sur la façon de l'implémenter avec la surface d'API actuelle.
browserSignals	Ajout de incomingBidInSellerCurrency aux spécifications de reporting browserSignals pour le vendeur.	Nous examinons cette demande et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Prise en charge de la propriété des métadonnées et de la logique côté achat pour les non-DSP	La conception actuelle de l'API pourrait entraîner un changement important des campagnes de retargeting au niveau des produits, qui devront peut-être migrer vers des plates-formes qui servent à la fois de DSP et de fournisseurs de DCO.	Nous examinons ce problème et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page .
Prise en charge de la propriété des métadonnées et de la logique côté achat pour les non-DSP	Partagez des exemples où la DSP n'est pas le propriétaire de l'IG.	Nous comprenons que les utilisateurs qui ne souhaitent pas enchérir souhaitent utiliser certaines fonctionnalités des enchères inversées, mais pas d'autres. Nous évaluons activement les options permettant de répondre à ces cas d'utilisation. N'hésitez pas à nous faire part de vos commentaires sur cette page.
Commandes de délai avant expiration	Les éditeurs doivent pouvoir définir le nombre d'IG pouvant participer et le délai avant expiration de niveau supérieur / global.	Nous comprenons que vous souhaitez améliorer les commandes de délai avant expiration et la visibilité entre le vendeur de premier niveau et le vendeur de composants. Nous examinons cette demande.
Multitaille	Compatibilité de l'API PA avec les cas d'utilisation de plusieurs tailles d'annonces.	Nous examinons cette demande et nous attendons d'autres commentaires de la part de l'écosystème.
Documentation	Existe-t-il une liste des attributs IG soumis à k-anon ?	Vous trouverez la réponse à cette question sur cette page.
Débogage	Amélioration des fonctionnalités de débogage pour l'API PA.	Nous sommes conscients de l'importance d'outils de débogage robustes pour les développeurs qui utilisent l'API PA. Nous nous engageons à améliorer l'expérience des développeurs en explorant des moyens de mieux intégrer les récupérations de fichiers .well-known aux outils de développement. Notre objectif est de fournir une meilleure visibilité et des fonctionnalités de dépannage dans l'environnement de développement. Cliquez ici pour en savoir plus sur ce problème. N'hésitez pas à nous faire part de vos commentaires supplémentaires.
Étiquettes	Les API Privacy Sandbox sont-elles activées pour tous les utilisateurs des libellés de traitement en mode B ?	L'attribution des groupes d'expérience Chrome est déterminée de manière aléatoire et indépendamment des paramètres Chrome configurés par l'utilisateur. Bien que ces API soient disponibles pour les utilisateurs de groupes de traitement spécifiques (par exemple, treatment_1.*), leur fonctionnalité peut être modifiée ou désactivée via les paramètres Chrome. Groupe control_2 du mode B: l'inclusion dans ce groupe désactive automatiquement les API de pertinence et de mesure de la Privacy Sandbox. L'utilisateur ne peut pas remplacer ce paramètre dans les paramètres de Chrome.
Utilisation de l'API	L'appel à reportWin() et le rendu de l'annonce se produisent-ils en parallèle ou l'un après l'autre ?	reportWin() est appelé directement après l'exécution de runAdAuction(). En même temps, le processus de rendu de l'annonce peut commencer lorsque le résultat de l'enchère est placé dans un iframe ou un frame clôturé. Une fois que reportWin() a terminé son exécution et que l'annonce commence à s'afficher, les URL fournies à sendReportTo() sont récupérées.
(signalé également au cours des trimestres précédents) Assistance pour les tests A/B	Demander de l'aide pour les tests A/B de l'API PA	Nous discutons de cette demande sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Lissage du trafic	La proposition de Google de gérer la prise de décision requise via le serveur KV n'est pas utile, car les vendeurs ne peuvent pas interagir avec leur backend, ce qui rend la gestion du trafic difficile.	Comme indiqué dans le problème GitHub, l'exposition de la présence d'ID de gestion peut poser des problèmes d'empreinte utilisateur. Nous vous avons suggéré d'autres solutions dans le fil de discussion, et nous sommes à l'écoute de vos autres suggestions.
Lissage du trafic	Les mécanismes de mise en cache ajoutent une couche de complexité importante et empêchent les DSP de connaître la véritable forme du trafic sur lequel ils enchérissent.	Le mécanisme de mise en cache a simplement été proposé à titre de suggestion. Les technologies publicitaires peuvent choisir d'utiliser les suggestions qui correspondent à leur cas d'utilisation. Pour en savoir plus, cliquez ici.
Étiquettes	Chrome doit partager le libellé en tant que paramètre dans les requêtes envoyées aux serveurs de confiance de l'acheteur et du vendeur.	Cette demande semble raisonnable, car elle semble globalement conforme à l'objectif d'utiliser de manière responsable les données Instagram. Nous examinons toutefois la demande, qui est soumise à un examen interne, et nous vous tiendrons informé de l'évolution de la situation.
Utilisation de l'API	Clarification de la définition explicite du groupe "control_1" dans le document "Consignes supplémentaires de la CMA aux tiers concernant les tests". Plus précisément, nous craignons qu'un changement de formulation puisse être interprété comme nécessitant l'exclusion de toutes les API de la Privacy Sandbox de control_1.	Nous avons exprimé notre point de vue à ce sujet dans ce fil de discussion GitHub. Toutefois, nous ne sommes pas en mesure de parler au nom de la CMA. Nous vous suggérons de lui signaler directement tout problème concernant l'interprétation de ses consignes de test.
Utilisation de l'API	Chrome autorise-t-il l'appel de joinAdInterestGroup() sur une page vide lors de la redirection vers une autre ressource ?	Si un utilisateur visite un site, le propriétaire du site peut déléguer l'appel de joinAdInterestGroup à un tiers. Cette délégation permet à un tiers de créer des IG sans avoir à ajouter de type de redirection via une page vide. Nous accueillons vos commentaires sur les raisons spécifiques de créer des IG au milieu d'une redirection au lieu d'utiliser le mécanisme de délégation prévu.
Utilisation de l'API	Les places de marché doivent pouvoir écrire des IG sur les pages appartenant aux éditeurs avec lesquels elles collaborent. Elles peuvent ensuite déléguer l'autorisation de définir une enchère sur ces IG à n'importe quel acheteur ou DSP.	Nous avons bien reçu vos commentaires et nous évaluons si une telle demande peut être acceptée. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème.
Utilisation de l'API	Aucune notification de perte de débogage n'est envoyée si personne ne remporte une enchère via l'API PA.	Les fonctions reportWin et reportResult de Chrome sont conçues pour générer des rapports sur les enchères gagnantes au niveau des événements dans le système d'enchères de confidentialité (PA). Lorsque toutes les enchères sont refusées lors d'enchères au premier prix, ces fonctions ne devraient pas être appelées, car aucun gagnant n'est déterminé. Une mise à jour récente de Chrome peut expliquer les écarts lorsque les URL transmises à forDebuggingOnly.reportAdAuctionLoss() n'apparaissent pas dans le panneau "Network" (Réseau) de DevTools. Nous vous recommandons de vérifier cette fonctionnalité à l'aide d'une version Canary ou Dev de Chrome.
Utilisation de l'API	Le coût de l'annonce renvoyé par generateBid peut-il être négatif (il est déjà arrondi de manière stochastique à 2 octets) ?	AdCost correspond au coût de clic ou de conversion de l'annonceur transmis de generateBid() à reportWin(). Cette valeur peut être nulle ou un double. Les valeurs négatives seront ignorées et ne seront pas transmises. La valeur sera arrondie de manière stochastique lorsqu'elle sera transmise.
Amélioration de l'API	Les serveurs d'exécution sécurisés et chiffrés peuvent-ils être utilisés pour gérer le ciblage, les cohortes, l'attribution et les enchères plutôt que le navigateur Chrome ?	Nous vous recommandons d'explorer les composants et les options basés sur le TEE de l'API PA (par exemple, les serveurs KV et les services d'enchères et de mise aux enchères), ainsi que les composants basés sur le TEE d'Attribution Reporting et d'agrégation privée (par exemple, le service d'agrégation) qui répondent à cette question.
Amélioration de l'API	La réponse aux enchères de la Privacy Sandbox peut-elle être une réponse aux enchères (comme les enchères d'en-tête) plutôt qu'une réponse aux annonces (comme les balises publicitaires) ?	Ce type de modification modifie fondamentalement les propriétés de confidentialité de l'API PA. Nous n'envisageons donc pas de le mettre en œuvre.
Contrôles à la disposition des éditeurs	Les éditeurs peuvent-ils bloquer les créations de l'API PA sur leurs pages ?	Chrome propose un examen des créations en temps réel qui n'est pas encore disponible pour les tests. Cette fonctionnalité n'est pas encore disponible, mais nous avons constaté que la plupart des SSP avaient créé des solutions pour la permettre.
Utilisation de l'API	Quelle est la limite de taille pour perBuyerSignals ?	Dans sa forme classique, perBuyerSignals n'est soumis à aucune limite de taille inhérente dans Chrome. Les principales contraintes sont que les données restent sérialisables au format JSON et qu'elles ne provoquent pas une consommation de mémoire excessive. Toutefois, notez que des perBuyerSignals très volumineux et complexes peuvent avoir un impact négatif sur les performances. Il existe une autre méthode pour transmettre des perBuyerSignals via le directFromSellerSignalsHeaderAdSlot. Cette approche transmet des perBuyerSignals dans un en-tête, sous réserve d'une limite de taille maximale de 10 ko pour l'ensemble de la réponse de l'en-tête. De plus, chaque serveur peut imposer ses propres restrictions sur la taille maximale de l'en-tête.
Documentation	La documentation sur l'appel registerAdBeacon à partir de generateBid doit être modifiée.	Nous avons mis à jour cette documentation le 17 février.
Utilisation de l'API	Comment reportEvent choisit-il la bonne URL de balise parmi plusieurs options enregistrées ?	Chaque mise aux enchères génère une configuration distincte, qui génère à son tour une carte de création de rapports distincte. Les enchères individuelles (et les frames qui en résultent) sont complètement distinctes les unes des autres et ne partagent pas de données. Pour en savoir plus, consultez la vidéo d'explication sur les rapports sur les annonces avec frames cloisonnées.
UI Chrome	Ajout d'un filtre dans l'onglet "Application -> "Groupes de centres d'intérêt" de Chrome DevTools, permettant de filtrer par propriétaire de groupe de centres d'intérêt (ou peut-être aussi par nom de groupe de centres d'intérêt).	Nous évaluons cette demande et nous attendons les commentaires supplémentaires de l'écosystème.
Headless Chrome	Prise en charge de l'API PA dans Headless Chrome.	Certains composants de l'API PA sont liés à Chrome, par exemple les appels k-anon aux serveurs de Google, qui risquent de ne pas fonctionner dans l'ancienne version de Chrome sans tête. Nous pensons que la nouvelle version de Chrome sans tête publiée dans Chrome 112 pourrait résoudre ce problème.
Utilisation de l'API	Dans le cas des rapports sur les pertes avec reportAdAuctionLoss, la valeur "topLevelWinningBid=0" s'affiche dans de nombreux cas. Quelle est l'interprétation de cette situation ?	La valeur topLevelWinningBid provient de la fonction scoreAd() du composant vendeur de niveau supérieur. Cette valeur joue un rôle dans la détermination du résultat de l'enchère de premier niveau. Comme indiqué dans la vidéo explicative, une valeur topLevelWinningBid de zéro ou d'un nombre négatif signifie que l'annonce correspondante ne peut pas remporter l'enchère. Ce mécanisme peut être utilisé, par exemple, pour filtrer les annonces ciblées par groupe de centres d'intérêt qui ne surpassent pas une annonce ciblée par contexte. Bien qu'une valeur de topLevelWinningBid nulle puisse indiquer qu'une mise aux enchères contextuelle a prévalu, la spécification de l'API PA reconnaît que d'autres facteurs peuvent contribuer à ce résultat.
Mode Test A/B	Clarification concernant la sélection du trafic en mode B et en mode A, ainsi que les invites de désactivation.	Les critères d'inclusion du mode A et du mode B sont les mêmes. L'objectif est de créer des groupes représentatifs du trafic Chrome normal, à condition qu'ils soient compatibles avec les API Privacy Sandbox et la méthode de libellé. Certaines configurations client ne sont donc pas compatibles. Pour les besoins de l'expérience, il est important de ne comparer que le trafic associé à une balise à un autre trafic associé à une balise. Les utilisateurs en mode B ont activé la fonctionnalité de protection contre le suivi. Ils reçoivent donc une notification à ce sujet.
Amélioration de l'API	"lifetimeMs" peut-il être inclus en tant que propriété directe dans l'appel joinAdInterestGroup ou être géré en tant qu'argument distinct ?	Nous examinons attentivement les commentaires de la communauté des développeurs Web concernant la fonctionnalité "joinAdInterestGroup" de la proposition d'API PA. Un point de discussion clé porte sur la méthode optimale pour gérer la durée de vie des IG. Nous évaluons les avantages d'un argument distinct pour le paramètre "lifetimeMs", car il favorise la flexibilité et l'adaptabilité pour les futures améliorations potentielles de la spécification. Nous discutons de ce problème ici et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Augmentation potentielle des taux de faux négatifs dans le framework de l'API PA en raison de collisions avec des ID de navigateur à faible entropie.	L'équipe Chrome s'engage activement à affiner le framework de l'API PA. Nous vous remercions d'avoir abordé le problème des faux négatifs potentiels liés aux collisions d'ID de navigateur. Nous évaluons attentivement ces commentaires et nous nous efforcerons de nous assurer que les analyses mises à jour reflètent de manière exhaustive tous les facteurs pertinents. Nous nous engageons à proposer une solution qui atteint les résultats de confidentialité souhaités tout en préservant la précision et la fiabilité. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Un identifiant de navigateur à faible entropie est-il nécessaire pour empêcher les clients d'envoyer à plusieurs reprises des requêtes de "Join" pour le même objet dans un système d'anonymat k ?	Nous sommes conscients de la discussion en cours concernant l'utilisation des identifiants de navigateur dans l'implémentation de systèmes d'anonymat k et nous l'apprécions. Nous comprenons les inquiétudes soulevées concernant les conséquences potentielles sur la confidentialité de ces identifiants. Bien que notre implémentation initiale ait utilisé un identifiant à faible entropie comme mécanisme de lutte contre les utilisations abusives, nous étudions activement d'autres techniques, telles que les jetons de comptage anonymes, qui donnent la priorité à la confidentialité des utilisateurs tout en préservant l'intégrité du système. Nous nous engageons à trouver des solutions qui concilient une utilisation responsable des données et une protection stricte de la confidentialité. Nous sommes également prêts à poursuivre le dialogue avec la communauté de chercheurs. Nous en discutons ici et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Les pages AMP (Accelerated Mobile Pages) sont-elles compatibles avec l'API PA ?	AMP n'est actuellement pas compatible nativement avec l'API PA. N'hésitez pas à nous faire part de vos commentaires supplémentaires si l'intégration d'AMP est une priorité.
Amélioration de l'API	Envisagez de supprimer le type des vérifications de k-anonymat.	Nous examinons attentivement les commentaires concernant l'optimisation potentielle des structures de requêtes d'anonymat k. Nous comprenons la suggestion de regrouper les paramètres et éventuellement d'unifier les types pour simplifier le processus. Notre objectif est d'assurer l'efficacité et la facilité de maintenance. Nous évaluons toutes les options à mesure que nous développons nos solutions de confidentialité. Nous discutons de ce problème ici et nous serons ravis de recevoir d'autres commentaires.
UI Chrome	Demande d'un mécanisme permettant aux utilisateurs moins techniques de consulter et de gérer facilement les IG auxquels ils appartiennent, y compris des commandes de désactivation potentielles au niveau du site Web.	Nous sommes conscients de l'importance de fournir des outils conviviaux pour comprendre et gérer les IG. Après avoir examiné attentivement différentes méthodes, nous avons constaté que l'identification des IG par le site Web sur lequel ils ont été rejoints offre le meilleur équilibre entre clarté et protection de la confidentialité. Actuellement, la gestion globale des IG se trouve dans les paramètres de Chrome. Nous cherchons constamment à améliorer l'expérience utilisateur dans ce domaine. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Sécurité des API	L'API PA est-elle vulnérable aux fuites de confidentialité via les interactions publicitaires des créations, même dans le contexte des cadres clôturés ?	Nous sommes conscients du risque de fuite d'informations via des interactions publicitaires sophistiquées. Nous étudions activement l'interaction entre les cadres délimités, l'API PA et les vecteurs d'attaque potentiels. L'atténuation des risques liés à la confidentialité est une priorité absolue. Nous nous engageons à développer des solutions robustes qui concilient innovation et protection des utilisateurs. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Latence	Le délai avant expiration de 50 ms par défaut pour la logique d'enchères de l'acheteur est-il une valeur réaliste ?	Nous prenons acte des inquiétudes soulevées concernant les incohérences potentielles entre la spécification et le calendrier des requêtes réseau pour la logique d'enchères. Nous examinons activement les spécifications pour nous assurer de leur précision et étudions les paramètres de délai avant expiration par défaut optimaux pour équilibrer les performances et la faisabilité. Nous discutons de ce problème ici et nous serons ravis de recevoir d'autres commentaires.
Documentation	Fuite de temps potentielle dans la spécification, où un site Web pourrait déduire si une annonce n'a pas atteint le seuil de k-anonymat, et conséquences potentielles sur le suivi intersites.	Nous sommes conscients du problème soulevé concernant une fuite de temps potentielle. Nous avons confirmé une divergence dans les spécifications et prenons des mesures pour nous assurer que l'état de k-anonymat des annonces est déterminé avant la mise aux enchères afin d'éviter de telles fuites. Nous prenons ces préoccupations au sérieux et nous mettrons à jour la spécification en conséquence. Nous discutons de ce problème ici et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Méthodes d'implémentation d'une liste de blocage de SSP dans l'API PA	Nous reconnaissons la nécessité de mécanismes permettant de gérer les restrictions publicitaires par les SSP. Nous vous encourageons à explorer des solutions qui donnent la priorité à l'évaluation sur l'appareil et exploitent les métadonnées publicitaires existantes pour protéger la confidentialité des utilisateurs tout en offrant de la flexibilité. Nous nous engageons à collaborer avec les développeurs pour identifier les approches optimales dans l'API PA. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Est-il possible de demander à son navigateur de se faire passer pour une API PA de manière à ce que les sites ne puissent pas la détecter ?	Nous sommes conscients que, sous sa forme actuelle, la désactivation de l'API PA peut être détectée par les sites Web. Nous travaillons activement sur des fonctionnalités telles que les enchères supplémentaires et le ciblage négatif, ainsi que sur le rendu des cadres délimités, afin d'améliorer la confidentialité et de proposer des options de désactivation indétectables. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Mode Test A/B	Trafic du centre de données prétendant être du traitement 1.1.	L'équipe Chrome a confirmé avec l'équipe GAM que ce trafic est désormais exclu du test. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Efficacité et équité de l'implémentation de interestGroupBuyers dans l'API PA.	Nous sommes conscients de la discussion en cours sur l'efficacité et l'équité du champ "interestGroupBuyers" dans les enchères de l'API PA. Nous sommes conscients des compromis entre l'efficacité, la confidentialité et l'équité du marché. Bien que les vendeurs doivent gérer les relations commerciales avec les acheteurs, nous cherchons à optimiser le processus de mise en correspondance. Il peut s'agir d'ajustements dynamiques basés sur des données en temps réel et des modèles hybrides. Nous restons déterminés à trouver des solutions qui privilégient la confidentialité des utilisateurs et favorisent un écosystème publicitaire concurrentiel. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
UI Chrome	Problèmes de mémoire potentiels et clarté de l'interface utilisateur liés à IG dans Chrome.	Nous comprenons les inquiétudes soulevées concernant l'affichage des images intégrées dans DevTools. Bien que la vue actuelle reflète tous les événements IG pour le suivi de l'historique, nous reconnaissons l'intérêt de fournir une visibilité plus claire sur l'état actuel des IG stockés. Nous allons explorer les optimisations et les améliorations potentielles de l'interface utilisateur pour améliorer les insights des développeurs. En ce qui concerne la gestion de la mémoire, l'implémentation de l'IG est conçue pour éviter les fuites de mémoire, mais nous surveillons et optimisons en permanence l'utilisation des ressources. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Documentation	L'auteur de la question rencontre une erreur lorsqu'il tente d'utiliser des tailles d'annonces nommées directement dans le champ "sizeGroup" de la fonction "joinAdInterestGroup". Il veut savoir si ce comportement est intentionnel.	Nous reconnaissons l'intérêt de simplifier la configuration des annonces dans la fonction "joinAdInterestGroup". Nous mettons tout en œuvre pour résoudre ce problème et prévoyons d'activer cette fonctionnalité dans les prochaines mises à jour. Cette amélioration s'inscrit dans notre engagement de fournir aux développeurs des outils flexibles et efficaces pour la gestion des annonces. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Libellé de test facilité par Chrome	Demande de données directes sur le mode A par rapport au mode B et d'étiquettes exactes dans sendReportTo afin que nous puissions suivre le test de manière cohérente.	Nous discutons de cette demande sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Documentation	Le nom de domaine du vendeur est-il inclus dans les requêtes envoyées à son serveur de confiance à des fins de validation ?	Nous reconnaissons avoir initialement omis le paramètre de nom d'hôte de la documentation de l'API Protected Audience KV Server. Nous souhaitons vous assurer que le nom de domaine du vendeur est automatiquement inclus dans les requêtes envoyées au serveur approuvé du vendeur. Cette fonctionnalité est essentielle pour des processus de validation des annonces efficaces. Nous avons mis à jour la documentation pour corriger cette erreur et nous continuerons de privilégier la clarté et la transparence pour la communauté des développeurs. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Méthodes possibles pour inclure le nom de l'IG dans les appels de suivi des impressions d'annonces à des fins de création de rapports.	Nous nous engageons à trouver un équilibre entre la nécessité de mécanismes de signalement efficaces et le principe fondamental de la confidentialité des utilisateurs. L'inclusion de noms Instagram dans le suivi des impressions d'annonces est soumise à des mesures de protection de l'anonymat k conçues pour empêcher l'identification d'individus. Nous continuerons d'explorer des solutions de reporting innovantes dans le respect de ces contraintes de confidentialité. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Fonctionnalité de l'API	Demande au serveur de confiance de l'acheteur de recevoir les en-têtes HTTP Client Hints.	Cliquez ici pour suivre cette demande de fonctionnalité.
Utilisation de l'API	Le fichier de délégation doit-il exiger le chargement de l'en-tête "Access-Control-Allow-Origin", étant donné qu'il dicte le comportement d'adhésion à IG pour le navigateur ?	Nous nous engageons à respecter les bonnes pratiques de sécurité Web. L'exigence de l'en-tête "Access-Control-Allow-Origin" pour les fichiers de délégation garantit la cohérence avec les principes CORS et évite l'exposition accidentelle d'informations sensibles. Nous étudions différents moyens d'optimiser ce processus tout en maintenant un niveau de sécurité élevé. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Permet aux ad servers de personnaliser les créations dans le framework de l'API PA.	Nous reconnaissons le rôle que les ad servers peuvent jouer dans la personnalisation des créations. Nous étudions activement des solutions pour renforcer les serveurs d'annonces dans l'API PA, comme le modèle "IG conjoint", qui permet de combiner les enchères et la logique de sélection des créations publicitaires. Notre objectif est de trouver un équilibre entre la possibilité de créer des annonces efficaces et la protection de la confidentialité des utilisateurs. N'hésitez pas à nous faire part de vos commentaires sur l'évolution de l'API pour répondre aux besoins de toutes les personnes concernées. Pour ce faire, cliquez ici.
Problèmes de respect de la vie privée	Disponibilité d'identifiants alternatifs (par exemple, RampID, ID5) dans les demandes d'enchères contextuelles pourraient compromettre les objectifs de confidentialité de l'API PA en facilitant la collecte de données intersites.	Nous sommes conscients de la tension potentielle entre les identifiants multisites et les objectifs de confidentialité de l'API PA. Bien que les éditeurs puissent choisir de partager de tels identifiants, la conception de l'API PA vise essentiellement à dissocier la sélection des annonces de la nécessité d'un suivi intersites. Nous nous engageons à favoriser un écosystème publicitaire axé sur la confidentialité et encourageons les développeurs à privilégier l'approche de l'API PA. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Mise en cache	Est-il possible d'empêcher la réutilisation des scripts d'enchères dans plusieurs enchères ?	Nous sommes conscients du comportement de mise en cache observé des scripts d'enchères dans le framework de l'API PA. Bien que les mécanismes de mise en cache HTTP standards soient acceptés, la réutilisation de script dans les enchères est possible en raison du comportement de suspension de l'appareil et de la conception des exécuteurs d'enchères. L'équipe étudie des solutions pour offrir aux acheteurs un meilleur contrôle du cache de script afin de gérer efficacement leurs stratégies d'enchères. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Centralisez les rapports sur l'activité d'enchères pour l'ensemble des IG d'une DSP, tout en respectant la confidentialité des utilisateurs.	Nous accordons la priorité à la confidentialité des utilisateurs lors de la conception de l'API PA. Bien qu'il ne soit pas possible de créer des rapports directs sur des événements d'enchères individuels en raison des risques de suivi intersites, nous proposons des mécanismes tels que le stockage partagé et l'agrégation privée. Ils permettent aux DSP d'obtenir des insights agrégés sur l'activité d'enchères, tout en préservant la confidentialité des utilisateurs.
Utilisation de l'API	L'extraction de sendReportTo() dans reportResult() ne se produit que dans 94% des cas par rapport à l'enregistrement d'une extraction avec forDebuggingOnly.reportAdAuctionWin().	Bien qu'elles ne soient pas forcément synchronisées, les deux URL peuvent être récupérées en même temps. Dans certains cas, le worklet du vendeur du composant a été supprimé et doit être réactivé pour exécuter la fonction reportResult(). Toutefois, ni le temps nécessaire pour extraire la logique de notation ni le temps de rechargement du worklet n'affectent le délai avant expiration de 50 ms de reportResult(). Veuillez noter que Chrome utilisera des en-têtes de mise en cache pour définir son comportement d'extraction dans les cas où le worklet doit être rechargé. Pour en savoir plus sur les phases d'enchères au système d'enchères programmatique, cliquez ici.
K-anonymat	Demande de confirmation que le nom du groupe d'intérêts n'affecte pas le k-anonymat de la diffusion des annonces.	Pour qu'une création soit considérée comme k-anonyme, le tuple d'URL du propriétaire de l'IG, de l'URL du script d'enchères, de l'URL de la création et de la taille de l'annonce doit atteindre le seuil spécifié (k) au cours d'une période passée (w). L'état de k-anonymat est mis à jour régulièrement (p).
UI Chrome	Proposition visant à fournir le type de "visibilité interne" que de nombreux frameworks MVC, ORM, etc. proposent. Par exemple, commencez par consigner simplement des événements internes sélectionnés dans un nouveau panneau de la section "Dev Tools --> Application --> Application" (Outils de développement --> Application --> Application).	Nous discutons de la proposition sur cette page et nous serons ravis de recevoir d'autres commentaires.
UI Chrome	L'intégration de l'interface de développement IG n'affiche pas les éléments liés à la priorité.	Nous avons résolu ce problème.
Amélioration de l'API	Il est préférable d'autoriser le serveur publicitaire de la création à suivre ses propres événements. Une liste de domaines de suivi autorisés peut-elle être configurable ?	Nous avons partagé une proposition ici et nous attendons les commentaires supplémentaires de l'écosystème.
Requête de fonctionnalité de l'API	L'API PA peut-elle être étendue pour prendre en charge les transactions multimédias autres que RTB et conserver des cas d'utilisation critiques tels que la diffusion d'annonces et le DCO ?	Nous discutons du problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Délai avant expiration des enchères de l'éditeur	Les éditeurs doivent contrôler la durée des enchères pour éviter de perdre des impressions, en particulier dans les configurations d'enchères en en-tête, où les annonces sont sélectionnées de manière séquentielle.	Nous sommes conscients de l'importance de donner aux éditeurs un contrôle précis sur les délais avant expiration des enchères publicitaires. Nous étudions activement comment implémenter un mécanisme de délai avant expiration des enchères à l'échelle mondiale, éventuellement dans l'objet "auctionConfig", tout en examinant attentivement les cas particuliers. Cette fonctionnalité vise à optimiser les taux de remplissage des impressions pour les éditeurs. Nous continuerons de collaborer avec la communauté pour trouver la meilleure solution. Nous discutons du problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Amélioration de l'API	La conception actuelle des IG dans l'API PA entraîne de grandes tailles de métadonnées en raison de longues URL de rendu. Les testeurs aimeraient pouvoir compresser ces URL pour plus d'efficacité.	Nous sommes conscients de l'importance d'optimiser la taille des métadonnées Instagram, en particulier pour les enchères publicitaires sensibles à l'efficacité. Nous pensons qu'une solution basée sur des modèles pour compresser les renderURLs offre un potentiel important. Nous évaluerons attentivement les conceptions de modèles proposées et nous nous assurerons que toute solution implémentée inclut des mécanismes robustes de prévention des utilisations abusives afin de maintenir la stabilité du navigateur. Collaborer avec la communauté des normes Web pour développer l'approche optimale, en tenant compte de ces considérations, reste une priorité. Nous discutons du problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Les testeurs qui gèrent les formats d'annonces natives souhaitent optimiser le processus d'enchères de la Privacy Sandbox en récupérant plusieurs résultats d'annonces en un seul appel afin de réduire la charge réseau et d'améliorer la vitesse d'affichage des annonces.	Nous sommes conscients des problèmes de performances soulevés concernant l'affichage des annonces natives dans la Privacy Sandbox. Nous nous engageons à trouver un équilibre entre l'efficacité et une protection rigoureuse de la confidentialité des utilisateurs. Bien que le retour de plusieurs annonces avec des scores complets compromette la confidentialité, nous étudions activement des moyens d'optimiser le processus d'enchères. Nous nous efforçons d'améliorer la prise en charge des formats d'annonces natives par l'API PA et d'étudier d'autres mécanismes pour améliorer l'efficacité dans le respect des fortes contraintes de confidentialité de la Privacy Sandbox. Nous discutons du problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Flexibilité concernant la façon dont les enchères publicitaires sont évaluées et triées dans la Privacy Sandbox, en particulier pour représenter les niveaux de priorité ou les règles de la place de marché privée.	Nous comprenons que vous avez besoin d'un contrôle précis sur le scoring et le tri des annonces dans la Privacy Sandbox, en particulier dans les scénarios d'enchères complexes. Nous reconnaissons les solutions proposées qui utilisent des tupels et des fonctions mathématiques pour obtenir une évaluation multidimensionnelle sans compromettre la confidentialité des utilisateurs. Bien que ces approches puissent ajouter de la complexité pour les développeurs, elles offrent l'expressivité nécessaire. Nous nous engageons à trouver des moyens de simplifier ces processus, par exemple via des fonctions d'assistance ou des consignes, afin de garantir une utilisation optimale des fonctionnalités de la Privacy Sandbox pour une logique d'enchères avancées. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
reportEvent()	Ajoutez un événement réservé (balise automatique, par exemple) déclenché par le navigateur une fois qu'un frame contenant une création publicitaire est initialisé.	Nous discutons de cette demande sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
adCost	Autoriser la répartition de "adCost".	Chaque valeur de coût est une opportunité d'envoyer une quantité limitée d'informations en dehors de l'enchère. Autoriser une liste complète de N fois ces coûts suffirait à envoyer un identifiant utilisateur complet, ce qui permettrait le suivi intersites. Nous en discutons ici et nous serons ravis de recevoir d'autres commentaires.
resolveToConfig	Le paramètre resolveToConfig doit-il être hérité du niveau supérieur et exposé dans browserSignals ?	Nous discutons de cette demande sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Outils optimisés	Existe-t-il un équivalent de chrome://topics-internals pour l'API PA ?	Rien n'est exactement identique. Toutefois, de nombreux outils pour les développeurs sont disponibles pour l'API PA .
Étiquettes	Chrome peut-il utiliser des libellés pour identifier les 20% de la population k-anon ?	Nous examinons cette demande et nous attendons d'autres commentaires de la part de l'écosystème.
Documentation	Les worklets d'enchères de la Privacy Sandbox deviendront-ils des types de worklets standards ?	En raison de leurs exigences uniques en matière de confidentialité et de sécurité, ces worklets diffèrent considérablement des types de worklets de navigateur standards. Nous ne prévoyons donc pas qu'ils deviendront bientôt des types de worklets standards dans la spécification HTML. Nous nous engageons à améliorer nos ressources pour les développeurs en fournissant des explications claires sur l'environnement d'implémentation et d'exécution des worklets d'enchères, afin de rendre ces informations plus accessibles aux participants à la Privacy Sandbox. Pour en savoir plus, cliquez ici.
Serveur de clés-valeurs (KV) BYOS (Bring-Your-Own-Server)	Les parties peuvent être en mesure d'apprendre plusieurs IG (du même propriétaire) joints par un utilisateur via des requêtes de services KV dans une configuration de service KV BYOS.	Cela ne sera plus possible lorsque les serveurs KV s'exécuteront dans des TEE, et nous pourrons nous assurer qu'ils peuvent respecter le modèle de confiance publié.
userBiddingSignals	mettre à jour une partie des "userBiddingSignals" tout en conservant d'autres.	Cela est déjà possible sans aucune modification de l'API.
Utilisation de l'API	Implémentez la limitation de la fréquence sur plusieurs IG dans la Privacy Sandbox, en utilisant éventuellement le serveur KV ou les données "prevWinsMs" modifiées.	Nous sommes conscients que vous souhaitez disposer de fonctionnalités avancées de limitation de la fréquence dans la Privacy Sandbox. Nous sommes conscients que les restrictions actuelles sur le partage des données entre les IG peuvent poser des difficultés lors de la mise en œuvre de ces stratégies. Bien que le serveur KV fournisse un mécanisme potentiel avec des mesures de protection de la confidentialité appropriées, nous encourageons les développeurs à explorer des solutions dans un seul modèle IG. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.
Utilisation de l'API	Les vendeurs de composants (ceux qui participent aux enchères imbriquées dans la Privacy Sandbox) ont besoin de visibilité sur les délais avant expiration des enchères de premier niveau pour optimiser leurs propres configurations et éviter les retards inutiles.	Nous reconnaissons la nécessité d'améliorer la coordination des délais avant expiration entre les vendeurs de premier niveau et les vendeurs de composants dans la Privacy Sandbox. Nous étudions activement l'ajout de nouveaux mécanismes de délai avant expiration, y compris un délai avant expiration pour l'ensemble des enchères, et nous cherchons des moyens d'appliquer des délais avant expiration de niveau supérieur aux enchères de composants. Notre objectif est d'améliorer l'efficacité et la prévisibilité pour tous les participants au processus d'enchères de la Privacy Sandbox. Nous discutons de ce problème sur cette page et nous serons ravis de recevoir d'autres commentaires.

Services Protected Audience

Thème des commentaires	Résumé	Réponse de Chrome
Environnements d'exécution sécurisés (TEE)	L'exécution de TEE dans des clouds publics est-elle plus coûteuse que dans des centres de données de technologie publicitaire sur site ?	Notre réponse est semblable à celle des trimestres précédents: Notre modèle de sécurité TEE actuel bénéficie des pratiques d'implémentation du cloud public. En particulier, les TEE basés sur du matériel actuels ne protègent pas contre toutes les attaques physiques. Nos fournisseurs de services cloud publics compatibles existants, AWS et Google Cloud, ont conçu et implémenté des mesures d'atténuation des risques d'accès physique, y compris de la part des employés. Consultez les informations suivantes concernant l'assistance sur site. Les technologies publicitaires nous ont indiqué que l'exécution de services cloud est plus coûteuse que les centres de données de technologie publicitaire sur site. Nous ne sommes pas en mesure d'évaluer ces affirmations, mais nous sommes à l'écoute de vos commentaires supplémentaires sur les coûts et continuons d'évaluer les options pour étendre notre prise en charge des TEE.
TEEs	Prise en charge des TEE dans les environnements cloud non publics	Notre réponse est semblable à celle des trimestres précédents: Nous continuons d'explorer des options au-delà des solutions cloud publiques, mais nous ne prévoyons pas pour le moment de prendre en charge les TEE sur site. À ce stade, compte tenu des exigences de sécurité de la Privacy Sandbox et des défis importants que présentent les déploiements sur site, nous pensons que le déploiement dans le cloud (par exemple, en prenant en charge Google Cloud en plus d'AWS) est la solution la plus bénéfique pour l'écosystème. Toutefois, nous serions ravis de recevoir d'autres commentaires sur la nécessité et la faisabilité d'une telle exigence compte tenu des contraintes liées à la confidentialité et à la sécurité.
Autres fournisseurs cloud	Prise en charge d'autres fournisseurs cloud	Nous sommes toujours à l'écoute de suggestions concernant d'autres fournisseurs cloud, mais nous prévoyons d'intégrer au moins Google Cloud et AWS lorsque la 3PCD sera appliquée. Pour en savoir plus, consultez cette vidéo explicative.
API Services d'enchères et de mise aux enchères	Quelle est la stratégie de Google concernant l'API Services de mise aux enchères et de mise aux enchères ? Sera-t-il prioritaire par rapport à Protected Audience du navigateur Chrome lors des enchères sur les appareils ?	Notre réponse est semblable à celle des trimestres précédents: Nous restons attachés à la conception actuelle des enchères sur l'appareil de Protected Audience. Les services d'enchères et de mise aux enchères ont été proposés pour explorer des solutions possibles pour prendre en charge un sous-ensemble de cas d'utilisation où la puissance de calcul ou la vitesse du réseau de l'appareil peut être limitée.
Standardisation	Les services de mise aux enchères et de mise aux enchères avec enchères ascendantes n'ont pas fait l'objet d'un processus de normalisation.	La proposition de services d'enchères et de mise aux enchères est en pleine phase de standardisation. Nous sommes donc à la recherche de nouveaux contributeurs pour nous aider à atteindre cet objectif. Elle a commencé par une proposition (basée sur des propositions précédentes) et est en cours d'incubation publique via de longues discussions ouvertes au W3C. Les développeurs intéressés peuvent commencer à l'expérimenter et à nous faire part de leurs commentaires. Il s'agit du modèle habituel pour le développement de fonctionnalités Web, comme décrit par exemple dans cet article de blog.
Serveur KV	Exposez l'URL complète au serveur KV de l'acheteur pour le ciblage par contenu, contextuel ou site.	Nous discutons de cette demande sur cette page et nous accueillons les commentaires supplémentaires de l'écosystème.
Documentation	La documentation sur les composants approuvés/obligatoires par rapport aux composants facultatifs sur GitHub crée de la confusion auprès de certaines technologies publicitaires qui disposent de leur propre ensemble d'images de déploiement et d'infrastructure.	Nous souhaitons améliorer la documentation sur les "composants approuvés/obligatoires par rapport aux composants facultatifs". Nous aimerions connaître l'avis de l'écosystème sur la priorité à accorder à ce travail.
Amélioration de l'API	Le code d'état HTTP d'un appel de serveur KV doit également être disponible pour la fonction scoreAd() en tant que paramètre.	Nous évaluons cette demande et nous attendons les commentaires supplémentaires de l'écosystème.
Documentation	Fournissez plus d'informations sur la manière exacte dont les charges de travail JS et WASM seraient gérées avec l'exécution des fonctions définies par l'utilisateur.	Nous nous efforçons de vous fournir ces informations et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Documentation	Demande de modification du nom du dépôt.	Nous avons renommé le dépôt "protected-auction-key-value-service". Cela correspond au terme utilisé pour désigner l'ensemble de services auquel il appartient, qui comprend également d'autres dépôts tels que la discussion sur les services Protected Audience et les dépôts de documentation sur les services Protected Auction.
Documentation	Suppression de la référence à l'API Cloud Debugger dans bidding_auction_services_gcp_guide.md.	Nous avons mis à jour la documentation et supprimé la référence.
Utilisation de l'API	La latence introduite par la recherche KV prend plus de 50 ms. Cela prend près de 100 ms. Avez-vous des conseils sur ce qui a bien fonctionné pour d'autres vendeurs ? Avez-vous des suggestions pour mesurer les délais avant expiration et le temps de latence ?	L'appel du serveur KV se produit dans le contexte des exécuteurs de script, c'est-à-dire dans l'environnement protégé spécial du navigateur Chrome. Il vise à protéger les informations contenues dans ces outils d'exécution de script contre tout accès non API. Pour en savoir plus, consultez cette page.
Utilisation de l'API	Le serveur KV doit-il répondre dans un délai spécifique ?	Les vendeurs peuvent spécifier le champ "perBuyerCumulativeTimeouts" dans la configuration des enchères. Ce délai d'inactivité inclut le temps nécessaire pour extraire les signaux d'enchères fiables.
Latence	Comment l'équipe Privacy Sandbox s'efforce-t-elle de résoudre les problèmes de latence ?	Pour en savoir plus sur les stratégies que nous étudions pour maintenir la latence dans des limites acceptables, cliquez ici.

Mesurer les annonces numériques

Attribution Reporting (et d'autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Optimisation manuelle des campagnes	L'ARA n'est pas compatible avec l'optimisation manuelle des campagnes.	Nous avons discuté de ce scénario avec la technologie publicitaire et montré comment l'ARA peut être utilisé pour optimiser manuellement les campagnes. L'API Attribution Reporting a été conçue pour permettre la personnalisation et la flexibilité des technologies publicitaires afin de résoudre un large éventail de cas d'utilisation. Parmi les suggestions proposées, citons l'utilisation de différentes configurations flexibles au niveau des événements et de rapports au niveau des événements avec des rapports récapitulatifs pour réduire l'impact du bruit et répondre aux besoins d'optimisation manuelle et automatique. Nous sommes à l'écoute des commentaires supplémentaires de l'écosystème concernant la personnalisation et la flexibilité des configurations ARA.
Type de conversion	Google n'autorise que huit types de conversions, ce qui est limité.	Nous avons implémenté la majorité des rapports flexibles au niveau des événements, ce qui offre aux technologies publicitaires une flexibilité supplémentaire en termes de nombre de périodes de référence, de rapports sur l'attribution et de bits de données de déclencheur qu'elles peuvent utiliser. Les technologies publicitaires peuvent choisir une configuration permettant de mesurer jusqu'à 32 types de conversions différents.
Limite d'événements pour les rapports agrégables	Le nombre minimal de 20 événements de conversion par rapport agrégable n'est pas adapté aux annonceurs de petite envergure disposant d'un budget limité.	Il n'existe pas de nombre minimal d'événements de conversion requis par rapport agrégable. De plus, vous pouvez prendre un certain nombre de décisions de conception pour optimiser les rapports agrégables pour les petits annonceurs, par exemple en modifiant la structure clé / les dimensions suivies, en testant différents niveaux d'épsilon, en testant des fréquences de traitement par lot plus longues et en testant différentes allocations de budget de contribution entre les objectifs de mesure. Les petites technologies publicitaires peuvent également essayer de combiner des rapports au niveau des événements et des rapports récapitulatifs afin de réduire l'impact du bruit.
Données en temps réel	Priver les DSP de données en temps réel (par exemple, sur les clics, les sessions et les conversions) qu'elles utilisent pour adapter leur stratégie d'enchères et améliorer l'efficacité de leurs campagnes va à l'encontre de l'engagement de maintenir les fonctionnalités existantes.	Même avec l'ARA, les clics et les sessions restent en temps réel, et les conversions sont toujours a posteriori, même avec trois PC.
Champs non renseignés	Conditions requises manquantes lors du déploiement de l'événement Full Flexible: i) champ "Currency" (Devise) et ii) champ "orderID" / "TransactionID".	Nous ne prévoyons pas de prendre en charge un champ de devise ou un champ d'ID de commande / d'ID de transaction dans la création de rapports au niveau des événements flexibles, car il existe déjà des moyens de le faire avec les rapports au niveau des événements actuels. Nous sommes à l'écoute de vos commentaires supplémentaires concernant ces champs et nous réexaminerons la question si d'autres cas d'utilisation les nécessitent. Voici comment utiliser la conception actuelle de l'ARA pour mesurer les informations sur la devise et le type d'ID de commande: 1. D'après les commentaires, la devise est déterminée par la zone géographique de l'utilisateur, qui peut être ajoutée dans le champ source_event_id afin de déterminer la devise utilisée. 2. D'après les commentaires, le champ "ID de commande" est nécessaire pour s'assurer que les conversions et les valeurs ne sont pas comptabilisées deux fois par erreur. Pour ce faire, vous pouvez utiliser des clés de déduplication.
Privacy Budget	Le budget de confidentialité de l'ARA limite la possibilité de mesurer sur plusieurs dimensions	L'ARA a été conçue pour permettre aux technologies publicitaires de personnaliser leurs propres configurations ARA afin de couvrir différents scénarios d'attribution. Avec la conception actuelle de l'ARA, les technologies publicitaires devront réfléchir au compromis entre les dimensions les plus importantes à mesurer et l'impact du bruit sur leurs données. L'ajout de bruit aux données en fonction de la granularité des dimensions mesurées est essentiel pour la confidentialité. Nous sommes ouverts à d'autres commentaires de l'écosystème concernant la possibilité de mesurer sur différentes dimensions, mais nous devons comprendre les cas d'utilisation spécifiques qui le nécessitent.
Mettre à jour la spécification	Bien que Google ait déclaré avoir remplacé les périodes de reporting sur les événements fixes par des périodes flexibles, cela n'a pas été pris en compte dans les spécifications techniques de Google, qui prévoient toujours une période minimale d'une heure.	Les rapports flexibles au niveau des événements permettent actuellement aux technologies publicitaires de modifier le nombre de rapports d'attribution par événement source, les bits de données de déclencheur, ainsi que le nombre/la durée des périodes de référence. L'ARA conserve une période minimale de création de rapports d'une heure pour les rapports au niveau des événements, ce qui est essentiel pour préserver la confidentialité et atténuer certains types d'attaques de reconstruction de l'historique. Étant donné que les rapports récapitulatifs fournissent des informations agrégées, les technologies publicitaires peuvent choisir de recevoir des rapports agrégables immédiatement, sans délai, si nécessaire pour leurs cas d'utilisation.
Conception d'API	Inquiétude concernant la réduction des informations dans les rapports sur les conversions et l'ajout de bruit, qui pourraient avoir un impact plus important sur l'écosystème que sur Google.	Google s'est engagé auprès de la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en favorisant son propre activité, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs de toutes tailles.
Correction de l'attribution	L'ARA ne permet pas au fournisseur de technologie de contrôler et de vérifier l'attribution correcte.	De nombreuses solutions ARA sont disponibles pour la validation: 1. Les technologies publicitaires peuvent vérifier que le comportement d'ARA correspond à leurs attentes: – Le code côté client d'ARA est open source. – Le code côté serveur d'ARA est également open source, et les coordinateurs s'assurent que seules les versions autorisées du service d'agrégation peuvent déchiffrer et traiter les rapports agrégables. 2. Chrome a fourni aux technologies publicitaires une bibliothèque de simulation pour vérifier le comportement d'attribution. La technologie publicitaire peut ainsi tester la façon dont l'ARA effectue l'attribution dans un environnement fictif. 3. ARA est compatible avec un certain nombre de signaux de débogage qui permettent de vérifier si le traitement attendu a bien eu lieu ou non, et pourquoi.
(signalé également au cours des trimestres précédents) Bruit	Commentaires indiquant que le niveau de bruit est trop élevé et que cela affecte l'utilité des rapports.	Nous avons fait part de ces commentaires aux technologies publicitaires et avons pu identifier des moyens de personnaliser l'ARA pour mieux répondre à leurs cas d'utilisation, même en cas de bruit. La documentation destinée aux développeurs contient la plupart des décisions de conception et des personnalisations que nous avons discutées avec les technologies publicitaires. L'API Attribution Reporting a été conçue pour permettre aux technologies publicitaires de personnaliser leurs propres configurations ARA afin de couvrir différents scénarios d'attribution. Toutefois, les technologies publicitaires devront réfléchir au compromis entre les dimensions les plus importantes à mesurer et l'impact du bruit sur leurs données. Nous sommes ouverts à d'autres commentaires de l'écosystème concernant l'impact du bruit et pouvons vous fournir des conseils supplémentaires sur les leviers ARA qui peuvent être utilisés pour modifier l'impact du bruit.
Attribution multidomaine	Comment suivre les attributions multidomaines ?	Pour résoudre ce cas d'utilisation, les technologies publicitaires peuvent rediriger vers différentes URL de création de rapports. Nous sommes ouverts à d'autres commentaires de l'écosystème concernant cet aspect de la conception d'ARA.
Amélioration de l'API	Modifiez régulièrement le facteur de scaling utilisé lors de l'enregistrement de l'attribution pour les rapports récapitulatifs ARA.	D'après la discussion sur GitHub, il semble que la gestion de plusieurs facteurs de mise à l'échelle dans le service d'agrégation entraînera probablement une augmentation du bruit dans les rapports récapitulatifs par rapport à la fonctionnalité actuelle. Nous sommes ouverts à d'autres commentaires concernant la nécessité de facteurs de mise à l'échelle dans les rapports agrégables, mais nous souhaitons souligner le compromis potentiel avec une augmentation du bruit. Nous évaluons également si d'autres futures fonctionnalités ARA peuvent également aider à résoudre ce cas d'utilisation.
Utilisation de l'API	Possibilité d'unifier la manière dont les événements d'attribution sont partagés avec tous les participants, ce qui est bénéfique pour les SSP, les DSP, etc.	Nous prévoyons de nous synchroniser avec la technologie publicitaire pour mieux comprendre leurs commentaires et les limites auxquelles ils font face.
Volume de trafic de test	Le trafic de test pour le mode B pour tous les navigateurs Chrome est-il stable ?	L'inclusion dans un groupe de test n'est pas affectée par les paramètres Chrome (et est indépendante de ceux-ci).
Documentation	Prise en charge de l'ARA pour les pixels.	Nous avons publié des informations sur la prise en charge de ce cas d'utilisation et nous attendons les commentaires supplémentaires de l'écosystème.
Utilisation de l'API	L'ARA peut ne pas être attribuée à la bonne source pour les vendeurs tiers sur les plates-formes d'e-commerce si la conversion n'est pas effectuée par le dernier point de contact.	Les entreprises peuvent utiliser des filtres pour éviter une attribution incorrecte (aucun rapport sur les conversions ne sera généré). Nous travaillons également sur une proposition de filtrage pré-attribution pour vous aider dans ce cas d'utilisation.
Navigateurs pris en charge	L'API Attribution Reporting sera-t-elle compatible avec différents navigateurs ?	Nous invitons les autres navigateurs à adopter les API Privacy Sandbox et nous continuons de consacrer du temps à la discussion de notre approche en public au W3C. Nous avons explicitement indiqué que l'interopérabilité était un objectif pour la diffusion d'ARA. La conception d'ARA est conçue pour être indépendante des navigateurs, avec des valeurs flexibles spécifiées par le fournisseur pour les fournisseurs ayant des positions différentes en matière de confidentialité. Les autres navigateurs font leur propre choix quant à la fourniture d'alternatives viables aux identifiants intersites pouvant prendre en charge l'écosystème numérique de contenus et de services. Nous sommes ravis que Microsoft Edge ait indiqué qu'il serait compatible avec la RA.
Utilisation de l'API	Quel est le type de source attendu pour les enregistrements de sources ARA pour registerAdBeacon/reportEvent (et les balises automatiques navigation_start/commit) ?	Cela dépend si ces balises sont automatiques ou manuelles :  : réservé.* Les événements (c'est-à-dire automatiques) doivent être de type "source de navigation".  : les événements déclenchés manuellement doivent être de type "source d'événements".
Utilisation de l'API	La limite maximale de 20 rapports agrégables par source signifie-t-elle qu'il s'agit de chaque événement source ? La limite est-elle globale ou quotidienne ? Est-il prévu d'augmenter cette limite ?	La limite de 20 rapports agrégables par source est une limite globale. Vous pouvez créer 20 rapports agrégables pour chaque source. Cette limite est définie par le navigateur et n'est pas configurable. L'objectif de cette limite est d'éviter d'abuser de la protection des rapports d'attribution réels avec des rapports nuls. Pour en savoir plus, cliquez ici.
Utilisation de l'API	Prise en charge du marketing par e-mail à l'aide de l'API Attribution Reporting API.	Pour le moment, ce cas d'utilisation n'est pas pris en charge directement dans ARA (si vous ne contrôlez pas le site d'hébergement de messagerie). Nous en discutons ici et nous serons ravis de recevoir d'autres commentaires.
Epsilon	Quand la valeur d'épsilon pour l'API Aggregate sera-t-elle déterminée ?	La valeur actuelle d'épsilon peut être configurée par les technologies publicitaires jusqu'à un seuil prédéterminé défini par Privacy Sandbox (actuellement 64). Nous vous recommandons de tester différentes valeurs d'épsilon, d'identifier les points d'inflexion pour vos propres cas d'utilisation et de nous faire part de vos commentaires. Nous nous assurerons de communiquer à l'avance aux technologies publicitaires toute modification de la plage de valeurs d'épsilon.
Amélioration de l'API	Prise en charge d'un cas d'utilisation dans lequel l'annonceur peut insérer un identifiant dans le champ "trigger_data" pour l'associer à des données CRM externes afin de vérifier la qualité des conversions.	Nous examinons votre demande et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Utilisation de l'API	Gérer les URL de redirection en tant qu'URL de destination	Les technologies publicitaires peuvent effectuer l'une des opérations suivantes: 1. Indiquez l'URL de destination finale dans le champ de destination : 2. Le champ "Destination" peut contenir jusqu'à trois URL, ce qui vous permet d'en saisir plusieurs. Les deux options nécessitent de connaître l'URL de destination finale. Pour en savoir plus, cliquez ici .

Service d'agrégation

Thème des commentaires	Résumé	Réponse de Chrome
Mécanisme de découverte de clé	Demande d'un mécanisme de découverte de clés	Nous avons une proposition de découverte de clés et nous attendons les commentaires de l'écosystème à ce sujet.
Utilisation de l'API	Feuille de route pour l'observabilité sur le service d'agrégation	Nous examinons des options pour améliorer l'observabilité, et nous invitons les membres de l'écosystème à nous faire part de leurs commentaires sur cette page.
Amélioration de l'API	Demande de pouvoir réexécuter des requêtes sur les rapports.	Le service d'agrégation travaille sur une proposition de requêtes permettant aux technologies publicitaires de diviser leur epsilon pour chaque rapport. Cela peut entraîner plus de bruit par requête, mais permettra aux technologies publicitaires de réinterroger et de préserver la confidentialité.
Amélioration de l'API	Je souhaite pouvoir associer plusieurs origines au même ID AWS.	Le service d'agrégation permet désormais d'intégrer plusieurs sites dans le même compte cloud (Google Cloud ou AWS). Cela permettra aux technologies publicitaires d'utiliser la même enclave de service d'agrégation pour traiter les rapports de plusieurs sites et plusieurs origines des mêmes sites.
Utilisation de l'API	Lorsque les lots agrégables échouent, il n'est pas certain que le budget soit consommé ou non, et qu'il puisse réexécuter son lot. Lorsqu'un service d'agrégation rencontre une erreur de budget pour des rapports en double, les autres rapports sont perdus. Comment minimiser cette perte ?	Dans un scénario typique, si l'ensemble de la tâche échoue, le budget n'est pas consommé. En cas de défaillance rare où le budget est consommé, les technologies publicitaires peuvent demander la récupération du budget. Si la technologie publicitaire rencontre des échecs de tâches fréquents avec l'erreur "Budget épuisé", elle doit confirmer sa stratégie de traitement par lot. Pour savoir comment créer des lots correctement et éviter les doublons de rapports et les erreurs, cliquez ici. Pour nous faire part de vos commentaires sur la récupération de budget, cliquez ici.
Utilisation de l'API	L'utilisation de l'API Private Aggregation avec le déclencheur décrit ici génère un rapport agrégable pour chaque mise aux enchères. Quelles sont les fonctionnalités d'évolutivité du service d'agrégation ?	Le service d'agrégation lui-même ne limite pas le nombre de clés ni de rapports dans un lot, mais une échelle de 10 14 rapports et de 10 12 clés n'est actuellement pas prise en charge en raison de la mémoire requise. Nos conseils de dimensionnement indiquent les plages que nous avons testées et que nous recommandons pour des performances optimales en fonction de la charge attendue et des types d'instances de VM cloud compatibles.
Traitement de données	Si des données chiffrées contiennent des informations personnelles, quelle est la disposition légale concernant la fourniture de données chiffrées au service d'agrégation ? Pouvez-vous m'indiquer si le coordinateur n'a pas accès aux données chiffrées ?	Le service d'agrégation ne partage pas les données chiffrées / utilisateurs avec le coordinateur. Le service d'agrégation utilise le coordinateur pour la gestion et la comptabilisation des clés. Pour en savoir plus sur le coordinateur, cliquez ici. Pour la comptabilité, le service d'agrégation ne partage que l'ID partagé et l'origine des rapports avec le PBS pour la consommation du budget. Une fois que nous aurons lancé un multisite, nous remplacerons l'origine par le site. Notez que le service d'agrégation s'exécute dans un TEE, qui est le seul endroit où les rapports des clients peuvent être déchiffrés. Le code exécuté dans le TEE est Open Source et audité par des tiers, comme indiqué ici.

API Private Aggregation

Thème des commentaires	Résumé	Réponse de Chrome
Utilisation de l'API	Possibilité pour les vendeurs de composants d'envoyer des rapports à plusieurs serveurs d'agrégation dans un TEE.	L'état actuel de l'API Private Aggregation n'est pas compatible avec cette fonctionnalité. Pour en savoir plus sur ce problème, cliquez ici.
Documentation	Quelle est la valeur d'épsilon utilisée dans les tests de Google ?	Pour l'API Private Aggregation, la valeur ε spécifiée dans une requête de service d'agrégation correspond au budget de contribution L1 de 2^16 qui est appliqué sur une base glissante de 10 minutes. Un budget de contribution L1 de 2^20 est également appliqué de manière continue sur 24 heures. En résumé, le paramètre de confidentialité est de ε sur une base glissante de 10 minutes et de 16ε sur une base glissante de 24 heures (plutôt que de 144ε). Le service d'agrégation accepte actuellement une plage de valeurs de ε pour les tests (jusqu'à 64) afin de permettre d'expérimenter différentes stratégies d'agrégation et de fournir des commentaires sur l'utilité du système avec différents paramètres de confidentialité pour l'agrégation privée et d'autres API. Nous prévoyons de revoir la valeur d'épsilon maximale autorisée au fil du temps, à mesure que nous recevrons les commentaires des testeurs et que nous ajouterons des fonctionnalités permettant d'utiliser le budget de confidentialité plus efficacement.

Limiter le suivi dissimulé

Réduction de l'User-Agent/Hints client User-Agent

Aucun commentaire reçu ce trimestre.

Protection IP (anciennement Gnatcatcher)

Thème des commentaires	Résumé	Réponse de Chrome
ID de la résolution	La Privacy Sandbox doit être plus franche pour insister sur le fait que les ID de résolution souvent basés sur l'adresse IP ne sont pas viables pour les annonceurs.	La Privacy Sandbox a clairement indiqué que nous souhaitons réduire le suivi intersites. Nos initiatives publiques, qui vont au-delà des cookies, sont publiées à la fois sur privacysandbox.com et GitHub. Nous nous efforçons de réduire le suivi intersites, y compris celui basé sur les adresses IP. Toutefois, c'est aux sites Web individuels de décider d'activer ou non de manière proactive le suivi intersites. À l'heure où la conformité aux réglementations est de plus en plus surveillée, il est prudent pour les entreprises de comprendre les pratiques employées par leurs fournisseurs de services.
Chromecast	La protection par adresse IP aura-t-elle un impact sur Chromecast ou d'autres appareils Chrome ?	Il n'est pas prévu pour le moment d'appliquer la protection IP aux appareils Chromecast.
Liste de protection des adresses IP	La liste des tiers identifiés comme pouvant utiliser des adresses IP pour le suivi intersites sur le Web sera-t-elle publiée ?	La liste sera publiée une fois finalisée, comme indiqué ici.

Atténuation du suivi des rebonds

Thème des commentaires	Résumé	Réponse de Chrome
Exemption pour l'authentification unique (SSO)	Comment la mitigation du suivi des rebonds (BTM) vérifiera-t-elle les cas d'utilisation de l'authentification unique pour l'exemption ?	Le BTM sera désactivé par les heuristiques Chrome. Pour en savoir plus, cliquez ici.
Évaluation avant abandon	Le BTM est-il activé pour les sites participant à l'essai de l'abandon des PGC ?	Non, le BTM respecte les exceptions de cookies créées lors de l'essai de l'abandon, comme indiqué ici.

Privacy Budget

Comme indiqué dans la présentation sur GitHub et sur le site pour les développeurs,Privacy Budget n'est plus activement envisagé dans les propositions de la Privacy Sandbox.

Prévention du suivi intersites pour améliorer la confidentialité

Ensembles de sites Web associés (anciennement "Ensembles propriétaires")

Thème des commentaires	Résumé	Réponse de Chrome
Demande de fonctionnalité	L'accès aux chips et / ou au partitionnement de stockage est automatiquement autorisé sur le RWS, sans l'API Storage Access ni l'intervention de l'utilisateur.	Nous évaluons les avantages et la faisabilité d'une fonctionnalité pouvant remplir cette fonction. Il faut tenir compte d'un écart potentiel d'interopérabilité entre les navigateurs, que RWS résout en exploitant l'API Storage Access. Il n'existe actuellement aucun équivalent de la fonctionnalité demandée compatible avec d'autres navigateurs. Nous invitons les développeurs à nous envoyer leurs cas d'utilisation concernant ce problème pour faciliter la discussion sur cette page.
Suppression des ensembles non conformes	Quelle est la procédure à suivre pour supprimer du dépôt les ensembles qui ne respectent plus les règles ?	Nous travaillons actuellement à la définition d'un processus à cet effet et nous vous tiendrons informé dès que nous aurons des informations à vous communiquer.
Procédure d'application du règlement	Le rôle subjectif de Google dans le processus d'application des règles relatives aux résultats naturels n'est pas clair.	Comme le projet RWS est en cours et que nous continuons de recevoir de nouvelles soumissions, certains aspects du processus et de nos critères sont encore en cours de finalisation. Nous sommes d'accord qu'il est important que nos consignes de soumission décrivent entièrement nos exigences. Nous allons les étoffer pour éviter toute ambiguïté et toute confusion. Notre objectif est que le processus de soumission soit aussi technique que possible afin que nous puissions abandonner progressivement l'intervention humaine et nous appuyer entièrement sur des vérifications automatisées. Les demandes de modifications telles que celle-ci nécessitent plus d'interaction humaine, car elles incluent des comportements que nous n'avions pas anticipés. Elles nous permettent toutefois d'identifier davantage de domaines à automatiser et de trouver des moyens de corriger nos consignes pour éviter ces problèmes à l'avenir.
Partager des données	Demande d'une fonctionnalité permettant aux propriétaires de domaines d'indiquer qu'ils souhaitent qu'un tiers partage également les données RWS, avec le consentement de l'utilisateur.	La fonctionnalité demandée est déjà disponible via des API telles que FedCM et les API Storage Access, qui permettent d'accéder à l'identité authentifiée une fois que l'utilisateur a accepté une invite d'autorisation. Nous attendons les commentaires de l'écosystème sur les cas d'utilisation spécifiques qu'il considère comme impossibles.
Autres méthodes de stockage	Les informations enregistrées dans le stockage local ou le stockage de session seront-elles également interprétées comme des cookies tiers ?	Le stockage local, le stockage de session et d'autres formes de stockage autres que les cookies lorsqu'ils sont utilisés dans des contextes tiers sont partitionnés dans Chrome depuis la version 115. Pour en savoir plus, consultez cet article de blog.
Limite des ensembles associés	Que se passe-t-il pour les organisations qui envoient plus de cinq domaines, même si le nombre de sites associés est limité à cinq ?	Ces ensembles seront acceptés via le processus GitHub, mais le navigateur (Chrome) n'appliquera les règles d'octroi automatique de l'API Storage Access qu'aux cinq premiers domaines, et ignorera les domaines restants, comme indiqué ici.
find_robots_txt	La vérification find_robots_txt ne fonctionne pas avec les redirections.	Une solution a été proposée pour résoudre ce problème. Cliquez ici pour en savoir plus.
Geste de l'utilisateur	Suppression de l'exigence de geste utilisateur pour accessStorage().	Cette exigence a été établie sur la base d'une conception similaire mise en place dans tous les principaux navigateurs pour l'API requestStorageAccess. Nous vous invitons à nous envoyer d'autres commentaires et cas d'utilisation dans ce problème GitHub pour nous aider à hiérarchiser cette demande et à permettre des discussions inter-navigateurs.
Geste de l'utilisateur	Un geste de l'utilisateur est-il nécessaire pour autoriser l'accès au stockage tiers après un redémarrage de Chrome ou de l'OS ?	Oui, mais nous serions ravis de recevoir d'autres commentaires de l'écosystème sur la question de savoir si ce comportement doit être modifié. Pour ce faire, cliquez ici.

API Fenced Frames

Thème des commentaires	Résumé	Réponse de Chrome
adComponent	Manque de documentation et de flexibilité lors de l'utilisation d'AdComponents avec des cadres clôturés.	Nous souhaitons vous fournir plus de documentation sur ce cas d'utilisation. De plus, les composants d'annonces sont compatibles avec les cadres délimités à l'aide de getNestedConfigs() (décrit dans les spécifications).
(également signalé au cours des trimestres précédents) Affichage de adComponent	Demande d'exemples de code pour afficher des composants d'annonces dans un cadre clôturé.	Nous mettons tout en œuvre pour partager des exemples de codes ici.
Validation des annonces tierces	Le rôle de la validation des annonces tierces dans le contexte des cadres délimités doit être précisé, en particulier en ce qui concerne la brand safety et la pertinence contextuelle.	Aujourd'hui, les rapports sur les annonces avec cadres délimités permettent aux DSP de transmettre des données au niveau des événements d'impression et des enchères à des vérificateurs d'annonces tiers pour la facturation et les vérifications de brand safety post-rendu.
Annonces extensibles	Demande d'acceptation des annonces extensibles.	Si l'annonce doit passer d'une taille à une autre avec le même format, et qu'il n'y a aucune différence fonctionnelle entre les deux (juste la taille), l'intégrateur peut redimensionner le cadre délimité avec la deuxième taille d'annonce, et le navigateur met à l'échelle l'élément de cadre délimité en conséquence.
(également indiqué dans les trimestres précédents) Compatibilité avec l'inventaire vidéo et natif	Les cadres délimités sont-ils compatibles avec l'inventaire vidéo et natif ?	Notre réponse est semblable à celle des trimestres précédents: L'API PA prend en charge le rendu vidéo à l'aide d'un mécanisme qui repose sur des iFrames. Toutefois, nous n'avons pas encore conçu de solution de rendu d'annonces vidéo et natives compatible avec les cadres délimités. C'est l'une des raisons pour lesquelles nous avons décidé de repousser l'application des règles sur les cadres délimités à 2026. Cela signifie que si un partenaire décide d'appliquer les cadres délimités dès maintenant, la compatibilité avec les vidéos et les annonces natives ne sera pas assurée.
Comité consultatif	Demande la création d'un comité consultatif de fournisseurs d'annonces natives pour s'assurer que les implémentations de cadres délimités respectent les normes du secteur.	Les cadres délimités ne sont pas obligatoires pour l'utilisation de l'API PA avant 2026. Ce délai supplémentaire nous permet de continuer à travailler avec le secteur pour concevoir et implémenter une prise en charge plus large d'un éventail de cas d'utilisation critiques. Nous avons déjà indiqué que nous allons faire évoluer les cadres délimités avant qu'ils ne soient obligatoires pour continuer à prendre en charge les annonces vidéo et natives avec l'API PA. Conformément à nos engagements, nous tiendrons la CMA au courant de ces modifications et nous nous appuierons sur les commentaires de l'écosystème avant d'exiger l'utilisation de cadres délimités. Notre modèle d'engagement de l'écosystème au sein du W3C et d'organismes de normalisation publicitaire tels que l'IAB Tech Lab permet à des experts du secteur de tous types de guider les conceptions avant qu'elles ne soient requises.
(également indiqué dans les trimestres précédents) Différence de taille entre les plates-formes	Signale que la taille du contenu affiché dans le cadre délimité est différente entre ordinateur et smartphone.	Il s'agit d'un problème connu de Chromium que nous étudions. N'hésitez pas à nous faire part de vos commentaires supplémentaires en cliquant ici.
Amélioration de l'API	La mise en place de la fonctionnalité de cadres délimités a-t-elle été repoussée à 2025 afin que les annonces natives soient désormais compatibles avec la Privacy Sandbox ?	Comme indiqué dans notre annonce publique concernant l'application des cadres délimités à partir de 2026, nous avons appris que de nombreux efforts avaient été déployés pour les prendre en compte. Bien sûr, l'un d'eux était les annonces natives, mais ce n'était pas le seul facteur. L'objectif était de vous laisser plus de temps pour vous assurer que l'écosystème est prêt à prendre en charge les principaux cas d'utilisation, y compris, mais sans s'y limiter, les applications natives.

API Shared Storage

Thème des commentaires	Résumé	Réponse de Chrome
Performances	Les temps de retour du stockage partagé en dehors du worklet semblent dépendre de l'activité dans le worklet.	Cliquez ici pour en savoir plus sur ce résultat de test.
Adoption plus large	Le stockage partagé doit être une norme du secteur, disponible dans tous les navigateurs.	Nous vous remercions de nous avoir fait part de vos commentaires. Chrome continue de participer activement aux forums du W3C, y compris au WICG, pour promouvoir la proposition, recueillir des commentaires et favoriser son adoption.
Worklets d'enchères	Est-il possible de lire à partir de Shared Storage dans generateBid (qui s'exécute déjà dans un worklet) pour appliquer une logique décisionnelle / commerciale (telle que la limitation de la fréquence d'exposition) en fonction d'informations intersites et sélectionner un sous-ensemble d'annonces ?	Non, il est impossible de lire à partir d'un stockage partagé dans les worklets d'enchères.

CHIPS

Thème des commentaires	Résumé	Réponse de Chrome
Capacité de la partition	Clarification du comportement en cas de dépassement de la capacité de la partition.	Lorsque la capacité est atteinte, les cookies les plus anciens sont supprimés des cookies les moins récemment consultés pour libérer de la mémoire jusqu'à ce que la limite ne soit plus dépassée. Les développeurs voient l'en-tête de cookie mis à jour dans les requêtes ultérieures.
Accès à l'iFrame tiers	Le contenu iFrame tiers intégré qui ouvre un nouvel onglet/une nouvelle fenêtre sur le même site tiers doit avoir accès aux mêmes cookies partitionnés que l'ouvreur.	Nous discutons de ce cas d'utilisation et nous invitons l'écosystème à nous faire part de ses commentaires sur cette page.
Cookies en double	S'il existe un cookie partitionné et un cookie non partitionné portant le même nom, quelle valeur de clé le navigateur décide-t-il d'envoyer ?	Si vous avez deux cookies portant le même nom (l'un partitionné et l'autre non), vous obtiendrez les deux cookies. Malheureusement, il n'existe aucun moyen de les différencier. La spécification RFC à ce sujet est disponible sur cette page. Elle explique que l'ordre dans lequel les cookies sont envoyés ne doit pas être pris en compte.
Demande de fonctionnalité	Activez les cookies partitionnés par origine.	Nous examinons cette demande et nous invitons les membres de l'écosystème à nous faire part de leurs commentaires sur cette page.

FedCM

Aucun commentaire reçu ce trimestre.

Lutter contre le spam et la fraude

API Private State Tokens (et autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Vue Web	Les jetons d'état privés (PST) sont-ils conservés sur plusieurs WebViews sur le même appareil mobile (profil) ?	Chaque application qui utilise une WebView dispose d'un stockage local différent. Par conséquent, les émetteurs de PST ne peuvent pas émettre de jetons dans la WebView d'une application, puis autoriser l'échange de jetons dans une application distincte. Cela est également vrai pour d'autres types de données stockées localement dans les vues Web, comme les cookies. Les PST ne sont pas encore entièrement disponibles dans WebView. Nous vous tiendrons informé d'ici la fin du deuxième trimestre.
Nouveau type de jeton	Proposition d'un nouveau type de jeton.	Nous vous remercions pour cette proposition et pour votre exploration continue des applications et des adaptations des PST. Nous avons hâte d'en savoir plus sur cette proposition lors des prochaines réunions du groupe communautaire de lutte contre la fraude au cours du 2e trimestre 2024.
Identification des utilisateurs	Comment empêcher les utilisateurs d'être identifiés en fonction des PST qu'ils possèdent ?	Pour éviter cela, nous limitons actuellement les tentatives d'échange sur un site à deux émetteurs, que des jetons soient disponibles auprès de cet émetteur ou non. Vous devez comptabiliser un émetteur dans la limite, même s'il n'y a pas de jetons disponibles, car le site pourrait parcourir tous les émetteurs jusqu'à ce qu'il trouve une correspondance positive.
Inscription	Combien de temps l'enregistrement sera-t-il obligatoire pour les PST ?	L'enregistrement restera obligatoire dans un avenir prévisible, comme expliqué plus en détail ici.
Compatibilité avec d'autres navigateurs Chromium	L'enregistrement d'émetteurs PST pour d'autres navigateurs basés sur Chromium sera-t-il pris en charge via le répertoire d'enregistrement d'émetteurs Chrome ?	Chrome récupère les engagements clés et les distribue aux clients Chrome via un mécanisme appelé "programme de mise à jour des composants". À mesure que d'autres navigateurs ajouteront une compatibilité plus complète avec l'API, ils devront établir un processus permettant d'obtenir les engagements clés auprès du client, soit via une méthode de mise à jour de composant, soit via une autre méthode. Pour en savoir plus, consultez cette page.