Rapport de commentaires - T1 2024

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

Dans le cadre de ses engagements envers la CMA, Google a accepté de fournir publiquement des rapports trimestriels sur le processus d'engagement des parties prenantes pour ses propositions de la 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 compilant les commentaires reçus par Chrome à partir des différentes sources, comme indiqué 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 acteurs du secteur et les forums sur les normes Web. Chrome se réjouit des commentaires reçus de l'écosystème et étudie activement les moyens d'intégrer les enseignements tirés dans les décisions de conception.

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

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

Les explications des réponses de Chrome aux commentaires ont été développées à partir des questions fréquentes publiées, des réponses réelles apportées aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifiquement pour les besoins de cet exercice de publication publique. Pour refléter l'objectif actuel de développement et de tests, nous avons reçu des questions et des commentaires en particulier concernant les API Topics, Protected Audience et Attribution Reporting.

Il est possible que les commentaires reçus après la fin de la période de référence en cours n'aient pas encore été pris en compte dans Chrome.

Glossaire des acronymes

ARA

API Attribution Reporting

CHIPS

Les cookies ayant un état partitionné indépendant

DSP

Plate-forme côté demande

FedCM

Federated Credential Management

Lecteur d'empreinte digitale

Ensembles internes

IAB

l'Interactive Advertising Bureau

.

IdP

Fournisseur d'identité

IETF

Internet Engineering Task Force

interne

L'adresse IP

openRTB

Enchères en temps réel

Prolongation

Phase d'évaluation

API PAT

API Protected Audience (anciennement FLEDGE)

PatCG

Groupe de la communauté sur la technologie publicitaire privée

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

Indices client User-Agent

W3C

Consortium World Wide Web

En cours

Aveugle volontaire des adresses IP

Commentaires généraux (pas d'API ni de technologie spécifiques)

Thème du commentaire	Résumé	Réponse Chrome
Gouvernance	Votre intérêt pour une période de consultation publique concernant les modifications apportées à la gouvernance de la Privacy Sandbox.	Nous sommes ouverts à des commentaires raisonnables de la part des personnes concernées sur tout développement important concernant la Privacy Sandbox, y compris sa future gouvernance.
Test	Phases de test supplémentaires pour les 3PCD en plus des tests actuels gérés par Chrome (1 %).	Nous ne prévoyons pas de proposer des tests géré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é entre le Web et l'application ne soit pleinement effectuée.	Nous sommes d'accord pour dire qu'il est souhaitable de prendre en charge l'interopérabilité entre les applications et le Web. C'est pourquoi nous avons lancé la mesure de l'attribution entre les applications et le Web, et nous étudions des solutions de ciblage web-to-app. Toutefois, nous ne prévoyons pas de retarder le format 3PCD sur le Web mobile. Notre objectif n'est pas de 100% de couverture à la fin de la 3PCD. Nous nous attendons plutôt à ce que la compatibilité sur Android pour les mesures entre applications et Web soit raisonnablement élevée à 3PCD et qu'elle augmente au fil du temps à mesure que les utilisateurs mettent à jour leur téléphone.
Rôle du navigateur	Chrome semble jouer le rôle d'un ad server ou d'une SSP.	Chrome n'assume pas le rôle d'ad server ou de SSP. Avec l'API PA, Chrome fournit un conteneur pour les ad servers, les SSP, les DSP et d'autres technologies publicitaires leur permettant d'utiliser leur propre logique d'enchères et d'évaluation.
Conseils pour les cas d'utilisation	Des conseils plus précis sur les cas d'utilisation qui seront pris en charge par les API Privacy Sandbox.	Au début du projet Privacy Sandbox, la documentation destinée aux développeurs était principalement axée sur l'implication des développeurs dans les processus de discussion et de commentaires concernant toutes les propositions. Le contenu était généralement structuré autour de la compréhension des motivations et des concepts du projet, puis des détails des premiers développements et tests de chaque proposition. Cela a permis de mettre en place une véritable collaboration dans l'écosystème pour développer les propositions. Toutefois, comme les API sont désormais en disponibilité générale, une nouvelle audience de développeurs est ici principalement chargée de s'appuyer sur les API plutôt que de contribuer à leur développement sous-jacent. Nous avons récemment mis à jour la navigation de cas developer.google.com/privacy-sandbox. Nous poursuivrons cette approche de documentation basée sur les cas d'utilisation.
Environnement de développement local	Comment pouvons-nous continuer à développer et à tester notre interface en local sur http://localhost lorsque le cookie est SameSite=Secure et que le backend est géré par un CDN ?	Nous discutons de ce problème sur cette page, et nous aimerions recevoir d'autres commentaires de la part de l'écosystème.
Atténuation des attaques 3PCD	Existe-t-il un moyen programmatique pour savoir si les cookies tiers sont bloqués ou quand l'heuristique est active ?	Dans Chrome, la détection de fonctionnalités et l'appel document.hasStorageAccess dans un iFrame permettent à un développeur de savoir si l'origine de l'iFrame a accès à des ordinateurs tiers.
Test vidéo	Impossible de tester les annonces vidéo dans la Privacy Sandbox pour l'instant.	Chrome a publié une discussion et une démonstration sur plusieurs façons possibles de réaliser des vidéos avec l'API PA à l'heure actuelle (voir les sections 242 et 254 dans notre dépôt de démonstration sur GitHub). Notez qu'il ne s'agit pas d'un exemple de code que les technologies publicitaires adopteraient pour la vente en gros, mais plutôt d'une démonstration de faisabilité et d'une démonstration des techniques compatibles avec le rendu vidéo VAST avec l'API PA. Au cours de cette discussion, il est également apparu que, bien que le rendu vidéo soit déjà possible aujourd'hui, des modifications pourraient être apportées dans Chrome pour simplifier 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évu d'apporter suite aux commentaires sur les cas d'utilisation de la brand safety dans le vérificateur d'annonces tiers devraient également prendre en compte les commentaires concernant le cas d'utilisation vidéo, où l'acheteur cherche à savoir quelles macros de vendeur utiliser pour le rendu. À ce jour, la plupart des discussions portent principalement sur l'affichage des annonces vidéo VAST. L'affichage des annonces natives peut adopter les mêmes approches, et est à bien des égards plus simple. Les annonces natives semblent recevoir moins d'attention que les annonces vidéo, mais il s'agit simplement de prioriser le secteur de la technologie publicitaire, et non d'un obstacle technique à l'implémentation.
Mesures non publicitaires	Les 3PCD peuvent avoir un impact sur les solutions de mesure de l'audience qui ne sont pas 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 éléments de base peuvent être utilisés pour traiter un large éventail d'activités de mesure.
Créateurs de contenu	La Privacy Sandbox est structurée de manière à encourager les créateurs de contenu à créer davantage de contenus pour YouTube plutôt que moins sur leurs propres sites.	L'initiative Privacy Sandbox vise à préserver la confidentialité des activités des utilisateurs sur un Internet ouvert et sans frais. Nous savons que les éditeurs comptent sur les annonces pour produire du contenu et le rendre aussi largement accessible que possible. Les annonceurs aident les utilisateurs à découvrir de nouveaux produits ou offres susceptibles de les intéresser. Les fonctionnalités de la Privacy Sandbox permettent aux sites Web de toutes sortes, y compris ceux qui travaillent avec des créateurs de contenu, de présenter aux internautes des annonces utiles en fonction de leur activité avec différentes parties, sans révéler l'identité de l'utilisateur à ces parties.
Des chronologies plus claires	Des calendriers de publication plus clairs et plus détaillés pour les technologies de la Privacy Sandbox.	La documentation de l'API Privacy Sandbox inclut les pages d'état et de disponibilité de l'API. Ces pages répertorient les fonctionnalités à venir et leur calendrier (par exemple, API PA, ARA). Vous trouverez une vue centralisée de ces états sur cette page.
Machine learning	Les technologies publicitaires ne peuvent pas entraîner correctement les modèles de machine learning tant que le 3PCD n'a pas dépassé 1%.	L'extension des 3PCD à d'autres navigateurs à des fins de test ne signifie pas nécessairement que les API seront plus utilisées, ce qui est vraisemblablement ce que les technologies publicitaires recherchent pour entraîner davantage les modèles de machine learning. Si les technologies publicitaires ne cherchent pas à entraîner davantage les modèles de machine learning à plus grande échelle dans l'écosystème, il n'y a aucune raison de développer la 3PCD en tant que technologie publicitaire qui souhaite entraîner des modèles avec plus de trafic. Cela peut se faire sans que Chrome semble passer à l'étape 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 pris en compte actuellement.	Plusieurs DSP en libre-service envoient régulièrement des commentaires publics sur les API. Plusieurs de ces DSP qui envoient régulièrement des commentaires publics se sont également répertoriées en tant que testeurs. De plus, Chrome s'engage activement sur des sujets typiques des DSP en libre-service, comme les vidéos et les ad servers tiers. Les appels hebdomadaires récents d'API PA ont abordé ces sujets.
Phase d'évaluation	Demande d'OT pour les sites qui souhaitent une montée en puissance plus agressive et test de la couverture pour les 3PCD.	Chrome développe actuellement un dispositif OT propriétaire qui permettra aux origines d'activer un comportement de suppression progressive des cookies tiers. Pour les origines de premier niveau qui s'inscrivent à cet essai et à ce jeton de déploiement, les 3PC seront bloquées, comme si la protection contre le suivi était activée sur l'appareil de l'utilisateur. Cette OT offrira aux sites une opportunité intéressante pour tester à plus grande échelle des alternatives à long terme aux 3PC, avant l'abandon des 3PC prévu après consultation avec la CMA. Nous sommes encore en train de finaliser le calendrier de déploiement de l'OT.
Rapport de l'IAB Tech Lab	Commentaires sur la Privacy Sandbox fournis par le rapport de l'IAB Tech Lab.	Nous avons répondu en détail au rapport de l'IAB Tech Lab sur cette page. Nous avons également reconnu que "le rapport soulève des questions sur la fragmentation de la documentation, les exigences commerciales, les audits tiers, l'accréditation du secteur, l'évolutivité, la transparence et la gouvernance future. Nous nous engagerons avec l'écosystème et mettrons à jour nos questions fréquentes publiques en conséquence." Nous avons déjà abordé la documentation fragmentée. Nous répondons aux exigences commerciales dans la section "Garanties des données" sur cette page, et certains produits publicitaires Google ont partagé leur approche. Nous traitons les audits tiers au titre de la "Garantie de l'intégrité des algorithmes" sur cette page. En ce qui concerne l'accréditation, nous attendons de ces organismes qu'ils continuent à accréditation des produits, y compris pour leur utilisation des technologies, plutôt que les technologies seules. En ce qui concerne l'évolutivité, nous restons ouverts aux données des développeurs qui montrent des problèmes. En ce qui concerne la transparence et la gouvernance, nous continuons à nous développer en public sur GitHub et sur des forums comme le W3C, tout en communiquant avec la CMA conformément aux engagements.
Google Sign-In	Google Sign-In donnerait la possibilité à Google d'utiliser des données de connexion d'identification croisée contraire aux Engagements.	Google Sign-In ne permet pas à Google d'utiliser des données contraires aux Engagements.
Compatibilité	Que prévoyez-vous pour la prise en charge des API de la Privacy Sandbox et la compatibilité ascendante / rétrocompatible ?	Lorsqu'une fonctionnalité de Chrome est en disponibilité générale, nous nous efforçons de maintenir la compatibilité de cette fonctionnalité. Bien sûr, il n'est pas toujours possible d'assurer la rétrocompatibilité. Dans ce cas, nous avons mis en place un processus clair pour l'abandon et la suppression des fonctionnalités existantes, décrit ici. Nous prévoyons d'ajouter des fonctionnalités aux API Privacy Sandbox au fil du temps, en réponse aux commentaires de l'écosystème sur les cas d'utilisation qui bénéficieraient d'une assistance améliorée. Dans ce cas, nous avons tendance à inclure une technique de détection de fonctionnalités, afin qu'une technologie publicitaire intéressée par une nouvelle fonctionnalité puisse demander directement au navigateur si elle est compatible. C'est mieux que de demander aux développeurs de vérifier un certain numéro de version de Chrome, car certaines fonctionnalités peuvent ne pas être déployées en même temps pour tous les utilisateurs de Chrome. Par exemple, cliquez ici pour consulter notre procédure de détection de fonctionnalités pour l'API PA.
Implémentation serveur	Plutôt que d'être couplé à leur propre implémentation, Chrome doit spécifier les comportements qu'une implémentation satisfaisante d'un serveur de signaux de confiance, d'un serveur d'agrégation et de tout autre composant obligatoire autre qu'un navigateur doit respecter. Cela permettrait d'innover dans des limites acceptables en termes de confidentialité.	Nous apprécions et apprécions le désir d'innovation de la part d'intervenants externes. Pour tous les services et API, nous nous efforçons d'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 lors de la conception d'une logique d'enchères pour les enchères. De plus, nous prenons en compte régulièrement les commentaires des technologies publicitaires et nous les intégrons à nos conceptions, lorsque cela est justifié. Pour permettre à d'autres personnes d'exécuter leur propre code dans des environnements d'exécution sécurisés, la Privacy Sandbox devra examiner le code (et les éventuels changements) pour vérifier qu'il respecte les garanties de confidentialité. Cela nécessitera un effort important de la part de l'équipe Privacy Sandbox. Par conséquent, nous aimerions comprendre les avantages que le partenaire cherche à obtenir et que nous n’avons pas atteints aujourd’hui.
Heuristique	Quels sont les plans à long terme concernant l'heuristique ?	Comme indiqué par d'autres navigateurs, nous prévoyons de supprimer ces méthodes heuristiques à mesure que d'autres solutions seront utilisées, sous réserve d'une analyse de faisabilité plus approfondie. Nous l'avons partagée sur cette page.
Test du volume	Volume de trafic différent lorsque vous comparez différentes dimensions.	Le test de 1% comporte des critères d'exclusion qui entraînent des différences d'éligibilité au test, entre différents groupes de clients Chrome. Par exemple, le test exclut les utilisateurs Chrome Enterprise. La part du trafic avec des libellés de test devrait donc être plus élevée le week-end. Il est normal de constater des pourcentages de trafic différents pour les différentes tranches de données (données géographiques, dates, plates-formes, etc.), ce qui correspond à ce que nous observons dans les données Chrome.
Réactiver manuellement les appareils tiers	Les sites pourront-ils connaître le nombre d'utilisateurs (%) ayant réactivé manuellement les cookies après l'application de la loi 3PCD ?	En cas de dysfonctionnement, les utilisateurs auront la possibilité de réactiver l'accès aux tiers au niveau du site via le contournement des paramètres utilisateur. Les 3PC peuvent également être réactivées par d'autres mesures, telles que l'API Storage Access. Il existe des mesures techniques, comme hasStorageAccess(), qui permettent aux sites de détecter si les 3PC sont activés ou désactivés. Toutefois, Chrome ne fournit aucun moyen pour les sites Web de connaître les raisons de la réactivation.
Protection contre le suivi	Pendant combien de temps la fonctionnalité UI de Protection contre le suivi de Chrome sera-t-elle disponible ?	L'interface utilisateur de Protection contre le suivi, disponible dans la barre d'adresse, devrait rester affichée au-delà de l'abandon des produits tiers.
(Également disponible au cours des trimestres précédents) Compatibilité multinavigateur	D'autres fournisseurs de navigateurs adoptant les API Privacy Sandbox.	D'autres fournisseurs de navigateurs, tels qu'Apple, Mozilla et Microsoft, participent activement à des forums publics où sont abordés les principes de confidentialité et les approches basées sur les navigateurs. Nous sommes encouragés par les discussions collaboratives sur des forums tels que la dernière réunion annuelle du TPAC du W3C et les forums en cours sur le W3C PATCG où nous constatons des signes de convergence. Par exemple, Microsoft Edge a récemment annoncé son plan qui "vise à maximiser la compatibilité syntaxique" avec l'API PA et l'ARA, tout en offrant des fonctionnalités supplémentaires aux développeurs.
Option de remplacement pour les intégrations incompatibles après la 3PCD	Fournissez des hooks d'API pour détecter si un iFrame ou un élément intégré tiers est conforme ou non aux 3PCD.	Pour discuter de la demande, cliquez ici. N'hésitez pas à nous faire part de vos commentaires.
Test	Demande d'indicateurs supplémentaires dans les instances gérées de Chrome, qui désactive temporairement les comportements personnalisés.	Nous envisageons cette demande pour les instances gérées de Chrome. Nous apprécions toute entrée supplémentaire de l'écosystème si un tel indicateur s'avère utile.

Inscription et attestation

Thème du commentaire	Résumé	Réponse Chrome
Validation d'attestation	Comment Google vérifiera-t-il l'authenticité des attestations ?	Tous les titulaires sont tenus de conserver le fichier d'attestation 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 de l'attestation.
Processus d'inscription à l'API Private Aggregation	Existe-t-il un moyen de vérifier l'état de l'inscription à l'API Private Aggregation ?	Tous les inscrits approuvés reçoivent un e-mail de la part de l'équipe d'assistance chargée des inscriptions une fois l'inscription validée. Si le titulaire a des questions au cours du processus, il peut contacter l'équipe d'assistance (avec laquelle il a envoyé son formulaire d'inscription). L'équipe d'assistance répondra à vos questions et vous fournira toute indication supplémentaire nécessaire.

Afficher des annonces et des contenus pertinents

Sujets

Thème du commentaire	Résumé	Réponse Chrome
(Également présenté aux trimestres précédents) Calendrier et documentation du classificateur	Il devrait y avoir une forme de mécanisme permettant de faire examiner la classification, ou au moins une transparence supplémentaire sur la façon dont le mode de classification détermine les catégories.	Notre réponse reste la même par rapport aux trimestres précédents: "Si la classification des sites est incorrecte, le signal de Topics peut être globalement moins utile, mais les sites spécifiques mal classés ne sont pas plus ni moins affectés que tout autre site. En effet, les informations contextuelles d'un site seront toujours disponibles pour les enchères sur ce site, ce qui fournirait des informations comparables sur le sujet approprié, même en cas d'erreur de classification. N'hésitez pas à nous faire part de vos commentaires à ce sujet ici."
Google Ad Manager	Google Ad Manager est déjà intégré à la plupart des sites et permet d'obtenir des informations beaucoup plus larges sur les thèmes des utilisateurs que ses concurrents, qui sont présents sur moins de sites.	L'exigence d'observation existe pour s'assurer que l'API Topics n'entraîne pas le partage de données utilisateur avec plus d'entités que les technologies qu'elle remplace (y compris les 3PC). D'autres solutions du secteur, telles que Prebid, fonctionnent avec des milliers de sites et permettent aux acteurs du marché d'appeler l'API Topics via leur technologie. En outre, notez que la limite de cinq thèmes principaux par semaine peut avoir un effet d'égalisation, car les acteurs du marché présents sur de nombreux sites qui pourraient être en mesure d'apprendre plus de cinq thèmes équivalents à l'aide de 3PC seront limités à cinq.
(Également signalé aux trimestres précédents) Utilité pour différents types de personnes concernées	Ils s'inquiètent de la valeur créée et de la répartition de cette valeur pour les sites en fonction de leur niveau de trafic ou de la spécialisation de leur contenu.	Nous sommes conscients que les sites spécialisés sont plus susceptibles de proposer des thèmes plus précis que des domaines d'intérêt général. Cependant, tous les sites spécialisés ne fournissent pas des thèmes présentant un intérêt commercial. De plus, cette dynamique reflète le statu quo et est entièrement indépendante de la fin de la prise en charge des 3PC dans Chrome. Toujours dans l'environnement actuel, certains sites offrent plus de valeur que d'autres dans les systèmes de pertinence des annonces basés sur les 3PC. En outre, les thèmes sur des sites spécialisés peuvent s'avérer mutuellement bénéfiques, car divers annonceurs peuvent diffuser des campagnes sur divers ensembles de thèmes, et la logique d'enchères peut observer de la valeur sur de nombreux 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 ? Est-ce que cela réduit le risque lié à la confidentialité par rapport aux URL complètes ?	Nous avons envisagé d'utiliser des URL d'informations ou des titres de pages en plus des noms d'hôte, et nous avons déterminé que les avantages potentiels seraient compensés par les risques pour la confidentialité et la sécurité des utilisateurs. Il peut s'agir, par exemple, de la classification des informations sensibles incluses dans l'URL ou le titre de la page dans les thèmes d'un utilisateur.
Sujets utilisés comme signal	Demande de conseils sur la manière de combiner Topics avec d'autres signaux et sur ceux 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, cliquez ici.

API Protected Audience (anciennement FLEDGE)

Thème du commentaire	Résumé	Réponse Chrome
Tester le volume de trafic	Les testeurs signalent un faible volume de réponses à l'enchère pour les enchères de l'API PA.	1. La densité des enchères est liée à la participation de l'écosystème à l'API PA, qui devrait continuer d'augmenter en 2024 et au-delà. En définitive, c'est aux annonceurs, à leurs agences et aux fournisseurs de technologies de déterminer comment répartir les budgets de leurs campagnes. Il est probable que certains participants à l'écosystème retardent leurs investissements dans diverses solutions sans cookie, y compris l'API PA, jusqu'à la fin de la phase 3PCD. À ce stade, nous prévoyons d'allouer davantage de budget de campagne à ces solutions. 2. Le volume de demandes d'enchères dans les enchères de l'API des enchères d'API peut être impacté (1) par le fait que les éditeurs et leurs fournisseurs de technologie publicitaire peuvent décider de ne pas lancer d'enchères d'API d'API d'enchères personnalisées s'ils estiment que la demande est faible. Il appartient aux éditeurs de déterminer la priorité de mise à jour de leurs pages et d'y participer. Nous estimons que les éditeurs peuvent avoir besoin de temps pour tester et augmenter progressivement le trafic pour ces raisons. Ce rapport inclut également une réponse de Google Ad Manager concernant les paramètres éditeur concernant la participation à l'API PA.
(Également signalé au cours des trimestres précédents) Fraude / Utilisation abusive	Comment l'écosystème peut-il réduire les risques et empêcher les acteurs ou acheteurs mal intentionnés de se positionner comme une audience convoitée ?	Les mécanismes de signalement des annonces diffusées via l'API des API conservent les informations utilisées pour distinguer les humains du trafic généré par des robots à l'heure actuelle. En outre, les techniques actuelles d'inclusion ou d'exclusion de domaines basées sur les domaines peuvent être utilisées dans l'API PA. Ce point est décrit plus en détail dans notre réponse au rapport de l'IAB Tech Lab sur la Privacy Sandbox.
Restriction d'origine identique pour le propriétaire de l'IG et l'URL de la logique d'enchères	Avec une exigence de même origine, les points de terminaison d'un propriétaire d'IG seront forcés de passer par le même équilibreur de charge, ce qui peut entraîner le refus des redirections.	L'exigence de même origine pour le chargement des scripts constitue une protection de sécurité importante. Cliquez ici pour obtenir plus de détails sur une solution proposée qui équilibre les commentaires de l'écosystème et d'autres considérations.
Enchères privées à plusieurs emplacements	Vous disposez d'une large marge de manœuvre pour autoriser les enchères privées multi-emplacements tout en respectant les limites de confidentialité, en utilisant du bruit et une intégration plus étroite avec les pratiques actuelles en matière d'annonces.	Nous prenons en compte ces commentaires et évaluons la demande d'enchères de plusieurs tags en fonction de la complexité accrue et des risques liés à la confidentialité associés à cette fonctionnalité. Nous avons discuté plus en détail de ce problème au cours d'un appel du PA API Web Incubator Community Group (WICG) sur cette page.
Vendeurs de premier niveau	La structure actuelle de l'API des enchères pour les acheteurs fournit aux vendeurs de premier niveau beaucoup plus de données et de 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 obtient la meilleure enchère. En outre, nous avons appris de l'écosystème que les éditeurs peuvent envisager de considérer 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ù certains acteurs doivent avoir accès à l'ensemble des options pour choisir une annonce à diffuser, est antérieur à l'API PA. L'API PA vise à répondre aux enchères multivendeurs et à la volonté des éditeurs de prendre en compte la meilleure enchère de chaque vendeur par rapport aux campagnes publicitaires vendues directement, lorsque cette dernière s'applique. Cela signifie qu'il doit exister un mécanisme permettant de choisir parmi ces opportunités de monétisation, comme c'est le cas actuellement. Nous avons estimé que le choix de l'annonce à diffuser ne devrait pas incomber au navigateur. 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 examiner les meilleures enchères de chaque vendeur avec lequel l'éditeur décide de travailler. En outre, la logique de ce vendeur peut choisir de fournir des informations sur les campagnes de vente directe de l'éditeur, lorsqu'elles sont disponibles. Toutes ces informations peuvent être prises en compte dans la logique de sélection des annonces de premier niveau. Cela signifie que la logique de premier niveau voit les meilleures enchères issues de la mise aux enchères de l'API PA et, le cas échéant, les options d'annonces vendues directement par l'éditeur afin de désigner le 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, empêchant les annonces de marques concurrentes d'être diffusées les unes à côté des autres)	Nous ne savons pas comment assurer la séparation concurrentielle dans l'écosystème actuel de publicité numérique multivendeur, avec enchères et programmatique. Toutefois, l'API PA permet aux vendeurs d'extraire des signaux en temps réel supplémentaires en fonction d'une combinaison d'URL de rendu et de nom d'hôte (représentant le domaine de l'éditeur) qui peuvent être utilisés pendant scoreAd() lors de l'évaluation des créations. Les vendeurs peuvent l'utiliser pour empêcher les annonces de marques concurrentes d'être diffusées les unes à côté des autres, si l'éditeur souhaite appliquer cette règle.
Informations limitées	L'API PA réduit les informations mises à la disposition des é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ères, ainsi que les enchères perdues.	Nous avons proposé quelques solutions potentielles sur cette page, et nous aimerions recevoir tout commentaire supplémentaire de l'écosystème.
Création de rapports au niveau des événements	Les éditeurs ne sont plus en mesure d'obtenir suffisamment d'informations sur l'annonce diffusée après l'abandon de l'API PA de création de rapports au niveau des événements.	Nous sommes conscients des différents cas d'utilisation liés à la création de rapports que nous devrons continuer à prendre en charge lorsque la création de rapports au niveau des événements sera supprimée. C'est pourquoi nous avons décidé que la suppression des rapports au niveau des événements ne soit pas antérieure à 2026. En attendant, nous vous invitons à participer activement à nos échanges avec l'écosystème sur des pistes durables, qui pourraient inclure de nouvelles idées pour obtenir des informations tout en protégeant la confidentialité.
Plusieurs SSP	La valeur ajoutée générée par plusieurs SSP sera trop faible pour les éditeurs.	Nous pensons que cette affirmation n'est pas correcte, et nous aimerions recevoir d'autres commentaires de la part de l'écosystème pour comprendre la raison de cette affirmation.
Activités de sélection	Les activités de sélection ne sont pas possibles avec l'API PA.	Nous avons tenu compte de leurs commentaires concernant la possibilité pour les vendeurs d'utiliser l'API PA pour fournir des informations sur leur audience aux acheteurs sur le Web (ou extension d'audience). Nous pensons que cela est possible aujourd'hui, grâce à la fonctionnalité de délégation de PA et aux accords commerciaux. En parallèle, nous réfléchis activement à la manière dont nous pourrions mieux répondre à ces types de cas d'utilisation.
Désactivation par l'acheteur	La désactivation par défaut de l'acheteur risque d'entraîner de moins bons résultats pour les enchères de composants.	Qu'il s'agisse d'une mise aux enchères unique ou multivendeur, le vendeur doit indiquer explicitement les acheteurs dans le champ "interestGroupBuyers" de l'objet "BiddingConfig". Cette mesure s'appuie sur les commentaires de l'écosystème selon lesquels les vendeurs ont des accords contractuels avec certains acheteurs, mais pas avec d'autres. Ils auraient donc besoin de contrôler explicitement les acheteurs à inclure dans la mise aux enchères. N'hésitez pas à approfondir le sujet sur GitHub.
Annonces	Impossible d'effectuer un pré-filtrage basé sur adsize et adSlotSize.	Nous travaillons à l'ajout de cette fonctionnalité. Pour en savoir plus, cliquez ici.
Prise en charge du ciblage IG à exclure	API prenant en charge le ciblage par IG à exclure: diffusion d'annonces uniquement si un utilisateur n'appartient pas à un IG.	Ce problème sur GitHub proposait une autre méthode pour implémenter le ciblage par exclusion, dans laquelle le navigateur indique directement à l'ad server quelles règles de ciblage négatives doivent être appliquées pour une demande d'annonce particulière. Bien que cette approche semble attrayante, toutes les versions de cette idée sur lesquelles nous avons étudié permettent au serveur d'identifier l'utilisateur de façon unique.
règlement sur les services numériques	Comment un éditeur peut-il utiliser Fenced Frames tout en empêchant l'affichage des réponses contenant des informations soumises à la loi sur les services numériques ?	Comme pour toute nouvelle technologie, chaque entreprise est tenue de s'assurer que son utilisation de la Privacy Sandbox est conforme à la loi. Google n'est pas en mesure de fournir des conseils juridiques à des tiers. Pour chaque API, nous avons publié une documentation technique complète qui devrait servir de base aux évaluations juridiques nécessaires. L'utilisation de Fenced Frames n'est pas obligatoire dans l'API PA avant 2026, ce qui laisse plus de temps aux parties prenantes pour s'assurer que leur utilisation de cette technologie est conforme à toutes les lois applicables.
Documentation	updateAdInterestGroups() est-il temporaire ?	Nous n'avons annoncé aucun abandon concernant updateAdInterestGroup. À l'avenir, nous pourrons appliquer des mesures de protection de la confidentialité semblables à celles dont nous avons parlé publiquement pour d'autres mécanismes de mise à jour d'IG, par exemple en utilisant une adresse IP également proxy et en ajoutant un certain délai avant la mise à jour.
Prise en charge de la propriété logique et des métadonnées côté acheteur pour les non-DSP	Demande d'un moyen d'agir en tant que mandataire pour les DSP.	Nous avons pris connaissance de ces commentaires de la part de segments hors DSP, et nous étudions cette demande. N'hésitez pas à nous faire part de vos commentaires.
Utilisation des rapports	Demande d'ajout d'une fonctionnalité de gestionnaire personnalisé pour l'ensemble / la valeur des signaux dans les rapports d'agrégation privée.	Nous sommes au courant, et cette demande de fonctionnalité est en attente d'examen. N'hésitez pas à nous envoyer d'autres commentaires de la part de l'écosystème.
Documentation	Existe-t-il un lien permettant d'afficher tous les en-têtes de réponse qui doivent être définis par l'annonceur et le domaine du propriétaire (délégué) ?	Nous prévoyons de mettre à jour la documentation pour clarifier ce point et nous aimerions recevoir d'autres commentaires de la part de l'écosystème.
Enchères pour plusieurs tours	Demande d'explication du workflow (entraînement et inférence) via un diagramme d'architecture ou de bloc expliquant comment une approche multitour est envisagée dans le contexte de l'API PA	Merci d'avoir donné votre avis. Nous proposons des présentations sur le sujet à partir desquelles nous prévoyons d'étoffer la documentation.
Ciblage par exclusion	Capacité de la Privacy Sandbox à protéger les audiences sensibles et les mineurs contre les annonces inappropriées (par exemple, les jeux d'argent et de hasard).	L'API PA ne prend pas en compte le contenu des annonces diffusées. Ce contrôle est contrôlé par les développeurs de technologies publicitaires qui utilisent les enchères publicitaires. En général, l'éditeur et ses fournisseurs de technologie publicitaire peuvent bloquer les créations lors des 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 actuelle de l'écosystème face à ces défis. Pour les acheteurs, la fonctionnalité de ciblage IG par exclusion peut également s'avérer utile pour certains cas d'utilisation liés à la conformité.
Conception d'API	Google souhaite que les technologies publicitaires utilisent une fonction d'enchères universelles afin d'augmenter la latence, au lieu d'utiliser différentes valeurs biddingLogicURL dans différents IG, ce qui est autorisé.	Au cours de nos discussions sur la latence des enchères, nous avons vu que si vous réutilisez le même script dans tous les IG d'un acheteur, ses enchères s'exécuteraient plus rapidement. Vous trouverez des informations plus détaillées sur cette page, ainsi que sur 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 marketing basés sur des comptes.	N'hésitez pas à nous faire part de vos commentaires sur des cas d'utilisation spécifiques qui, selon eux, ne sont pas possibles. Nous encourageons les participants à poursuivre ces discussions via notre dépôt GitHub public ou lors d'appels hebdomadaires.
Test A/B	Lorsque l'API PA est configurée dans GAM pour un éditeur, elle doit être activée pour tout l'inventaire ou pour aucun. Cela limite la capacité des éditeurs à exécuter 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. Par conséquent, les éditeurs peuvent effectuer des tests A/B à l'aide de la fonctionnalité des règles d'autorisation de Chrome. Ils peuvent ainsi désactiver l'API sur un sous-ensemble du trafic à utiliser comme groupe de contrôle pour un test A/B.
Machine learning	Les éditeurs ont besoin de mieux contrôler l'utilisation du machine learning proposée par GAM.	Réponse fournie par Google Ad Manager: En janvier 2024, nous avons lancé une commande qui permet aux éditeurs de désactiver notre limitation du machine learning et d'activer les enchères de l'API PA avec des vendeurs autres que Google sur l'ensemble de leur trafic. Pour en savoir plus sur cette commande, consultez notre Centre d'aide.
(également enregistré au cours des trimestres précédents) Enchères de premier niveau	Possibilité d'utiliser l'ad server des éditeurs de Google sans donner à GAM le contrôle du système d'enchères de premier niveau de l'API PA.	Réponse fournie par Google Ad Manager: Pour les raisons expliquées dans le rapport du 3e trimestre 2023 de Google, GAM ne prévoit pas d'intégrer l'API PA aux éditeurs qui utilisent GAM comme ad server sans contrôler l'enchère de premier niveau.
Accès aux informations	GAM a accès à des informations précieuses provenant de concurrents, comme 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: Depuis des années, nous accordons une grande importance à l'équité des enchères. Par exemple, nous avons promis qu'aucun prix provenant des sources publicitaires non garanties d'un éditeur, y compris celui des éléments de campagne non garantis, ne sera communiqué à un autre acheteur avant qu'il ne participe à la mise aux enchères. Nous avons ensuite réaffirmé dans nos engagements envers l'autorité française de la concurrence. Pour les enchères de l'API PA, nous voulons tenir notre promesse et ne partager l'enchère d'un participant aux enchères avec aucun autre participant avant qu'elle ne soit finalisée dans les systèmes d'enchères multivendeurs. Précisons que nous ne partagerons pas le prix de l'enchère contextuelle avec une enchère pour les composants, y compris la nôtre, comme expliqué dans cette mise à jour. De plus, nous n'utilisons pas d'informations sur les configurations d'enchères des composants, y compris les signaux fournis par les acheteurs aux SSP, dans le cadre de nos propres enchères. En fait, nous apprécions les changements apportés à l'API des API pour permettre aux vendeurs de composants de spécifier la configuration de leurs enchères de composants d'une manière qui soit masquée pour le vendeur de premier niveau.
Enchères de composants	En tant qu'enchère de premier niveau, GAM contrôle quelles SSP effectuent des enchères de composants pour chaque opportunité d'annonce.	Réponse fournie par Google Ad Manager: En tant qu'ad server d'éditeur, GAM propose une API allégée pour les SSP, avec laquelle un éditeur est susceptible de travailler pour spécifier les configurations des 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 mises aux enchères des composants pour cette opportunité d'annonce. GAM n'impose aucune restriction sur les enchères des composants incluses. Toute SSP qui souhaite organiser une enchère de composants pourra le faire, à condition que l'éditeur l'ait autorisée à exécuter le code nécessaire sur sa page.
Enchères de composants	GAM peut appliquer un prix plancher spécifique et non communiqué à chaque composant d'enchère gagnante.	Réponse fournie par Google Ad Manager :GAM met l'accent sur l'équité des enchères depuis des années. Afin de garantir un système d'enchères équitable et transparent, 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, qui continuera de l'être pour les enchères d'API PA.
Serveurs publicitaires tiers	Les ad servers 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 SSP de Google dans le contexte de l'API PA.	Réponse fournie par Google Ad Manager: À l'heure actuelle, GAM permet de tester l'API PA auprès de plusieurs vendeurs via l'API décrite sur cette page. La participation de GAM en tant qu'enchère intégrée à d'autres enchères de premier niveau n'est pas acceptée pour l'instant.
(également indiqué aux trimestres précédents) Performances des enchères des API PA	Rapport des testeurs indiquant que les enchères de l'API PA présentent une latence élevée.	Nous avons reçu des inquiétudes concernant la latence. C'est en partie pour cette raison que 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 susceptibles de réduire la latence. Nous avons récemment mis à jour notre guide des bonnes pratiques en matière de latence, qui contient plus d'informations sur la façon de profiter de ces fonctionnalités. Nous continuons également de développer de nouvelles améliorations en matière de latence, que vous pouvez voir ici.
(Également disponible au cours des trimestres précédents) Rendu des vidéos	Prise en charge du rendu vidéo à l'aide de l'API PA et de Fenced Frames.	En janvier, nous avons publié une démonstration du fonctionnement des vidéos InStream dans une mise aux enchères des annonces personnalisées, avec des détails supplémentaires sur les autres approches possibles. Nous voyons également des acteurs de l'écosystème commencer à proposer le fonctionnement du rendu vidéo aux partenaires qui s'intègrent à eux, comme les propositions de GAM pour la création d'URL de rendu compatibles avec les vidéos ou le processus de bout en bout complet. Nous tenons également compte des commentaires des écosystèmes sur les modifications que nous pouvons apporter pour favoriser l'adoption. L'une de ces modifications est détaillée dans GitHub. Nous continuons d'identifier tout autre obstacle à l'adoption que nous pourrions rencontrer et de les résoudre dans les meilleurs délais.
(Également indiqué aux trimestres précédents) Règles de traitement des données	Quelle est la politique de traitement des données pour les IG / l'API PA ?	Dans la conception de l'API des API, toutes les données stockées dans les IG, ou concernant la composition des utilisateurs et les IG, (i) restent sur l'appareil ou (ii) sont traitées dans les services d'enchères et de mise aux enchères (B&A) exécutés dans un environnement d'exécution sécurisé (TEE). Dans les deux cas, les données ne peuvent pas être lues par d'autres parties ni utilisées autrement 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 de k-anonymat géré par Google. Cette interaction est soigneusement conçue pour éviter de partager des informations sur les utilisateurs et pour garantir la parité des informations dans l'écosystème publicitaire. Google s'est engagé auprès de la CMA à concevoir et à mettre en œuvre les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se référant à 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 à travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces obligations.
(Également présenté au cours des trimestres précédents) Depuis la publication de l'application	Demande de prolongation de la durée de vie des IG de 30 à 90 jours.	Un tel changement nécessite une évaluation minutieuse, en évaluant les avantages pour le secteur par rapport à l'impact sur les utilisateurs de Chrome et d'autres intervenants. Nous examinons cette demande. Si vous avez d'autres commentaires, cliquez ici.
(Également présenté au cours des trimestres précédents) modelSignals	Demandez un nouveau champ en plus de modelSignals qui ne peuvent encoder que les informations d'affichage et de clic.	Nous avons envoyé une proposition de contestation en réponse à ces commentaires. Nous collaborons activement avec les acteurs du secteur pour comprendre leur point de vue sur notre proposition, et nous comparons 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 un certain temps, car nous recherchons également des approches pour nous assurer d'avoir un plan de confidentialité à long terme.
Conception des enchères	Les demandes d'enchères uniques qui renvoient les URL de rendu avec le score correspondant	Nous avons envisagé de partager plusieurs URL de rendu et leur score respectif à partir d'une même mise aux enchères PA. Nous comprenons que vous ne souhaitez pas que la même annonce soit diffusée plusieurs fois auprès d'un même internaute sur une même page. C'est pourquoi nous vous encourageons à poursuivre la discussion sur GitHub.
reportWin	journaliser les champs arbitraires dans la fonction reportWin().	Cela se produit déjà aujourd'hui, pendant la période de test. Une fois que Chrome ne sera plus compatible avec les 3PC, la version forDebuggingOnly de l'API migrera pour permettre le débogage sous-échantillonné (voir cette page).
Vendeurs de composants	disposer d'un mécanisme indépendant pour comptabiliser ses propres impressions et autres événements, sans avoir à dépendre uniquement des rapports des technologies publicitaires ;	Cette demande de fonctionnalité est en attente d'examen. Nous ne prévoyons pas d'aborder ce problème pendant la période de test gérée par Chrome.
Facturation au coût par clic	Implémentez la facturation au coût par clic dans l'API PA.	Nous l'examinons sur cette page. Il s'agit actuellement d'une demande de suggestions sur la façon de l'implémenter avec la surface d'API actuelle.
browserSignals	Ajout d'ingressBidInSellerCurrency à la spécification browserSignals pour le vendeur.	Nous examinons cette demande. Si vous avez d'autres commentaires, cliquez ici.
Prise en charge de la propriété logique et des métadonnées côté achat pour les autres plates-formes côté demande	La conception actuelle de l'API pourrait entraîner un changement significatif dans les campagnes de reciblage au niveau du produit, où les campagnes devront peut-être migrer vers des plates-formes servant à la fois de DSP et de fournisseurs DCO.	Nous discutons de ce problème. Si vous souhaitez nous faire part d'autres commentaires, cliquez ici .
Prise en charge de la propriété logique et des métadonnées côté achat pour les autres plates-formes côté demande	Fournissez des exemples lorsque la DSP n'est pas le propriétaire de l'IG.	Nous sommes conscients que les non-enchérisseurs souhaitent utiliser certaines fonctionnalités des IG, mais pas d'autres. Nous étudions activement des options pour traiter ces cas d'utilisation. Si vous avez besoin d'autres commentaires, consultez cette page.
Contrôles de délai d'inactivité	Les éditeurs doivent pouvoir dicter le nombre d'IG pouvant participer, ainsi que le délai d'expiration de premier niveau / délai global.	Nous sommes conscients que vous souhaitez améliorer la visibilité et le contrôle du délai d'expiration entre les vendeurs de composants et les vendeurs de composants. C'est pourquoi nous étudions cette demande.
Plusieurs tailles d'annonces	Prise en charge de l'API PA pour les cas d'utilisation de plusieurs tailles d'annonce.	Nous étudions cette demande et nous aimerions recevoir des commentaires de la part de l'écosystème.
Documentation	Existe-t-il une liste d'attributs IG qui sont soumis à k-anon ?	Nous avons répondu à 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 travaillent avec l'API PA. Nous nous engageons à améliorer l'expérience des développeurs en explorant les moyens de mieux intégrer la récupération de fichiers .well-known aux outils pour les développeurs. Notre objectif est d'améliorer la visibilité et les fonctionnalités de dépannage dans l'environnement de développement. Nous abordons ce problème plus en détail sur cette page et nous aimerions recueillir vos commentaires.
Étiquettes	Les API Privacy Sandbox sont-elles activées pour tous les utilisateurs associés aux libellés de traitement en mode B ?	L'attribution des groupes de test Chrome est déterminée de manière aléatoire et indépendante des paramètres Chrome configurés par l'utilisateur. Bien que ces API puissent être disponibles pour les utilisateurs de groupes de traitement spécifiques (par exemple, traitement_1.*), leur fonctionnalité peut être modifiée ou désactivée via les paramètres Chrome. Groupe "control_2" (mode B) : l'inclusion dans ce groupe désactive par nature les API de mesure et de pertinence de la Privacy Sandbox. Ce paramètre ne peut pas être ignoré par l'utilisateur dans les paramètres 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 à la fin de runAdAuction(). Parallèlement, le processus de rendu de l'annonce peut commencer lorsque le résultat de l'enchère est placé dans un iFrame ou un cadre Fenced Frame. Une fois que reportWin() est exécuté et que l'annonce commence à s'afficher, les URL fournies à sendReportTo() sont extraites.
(Également disponible au cours des trimestres précédents) Assistance pour les tests A/B	Demandez de l'aide pour les tests A/B de l'API PA.	Pour en savoir plus sur cette demande, cliquez ici. Vos commentaires sont les bienvenus.
lissage du trafic	Une proposition de Google concernant la gestion de 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 complique le lissage du trafic.	Comme indiqué dans le problème GitHub, le fait d'exposer la présence d'IIG sur une DSP individuelle peut poser des problèmes au niveau du fingerprinting des utilisateurs. Nous avons suggéré d'autres solutions pour résoudre ce problème et nous sommes ouverts à d'autres suggestions.
lissage du trafic	Les mécanismes de mise en cache ajoutent une couche de complexité significative et empêchent les DSP de connaître la véritable forme du trafic sur lequel elles enchérissent.	Le mécanisme de mise en cache était simplement proposé comme suggestion. Les technologies publicitaires peuvent choisir d'utiliser les suggestions correspondant à leur cas d'utilisation. Nous vous invitons à discuter plus en détail sur cette page.
Étiquettes	Chrome doit partager le libellé en tant que paramètre dans les requêtes adressées aux serveurs de confiance de l'acheteur et du vendeur.	Cette demande semble raisonnable, car elle semble globalement correspondre à l'objectif d'une utilisation responsable des données IG. Toutefois, nous examinons actuellement votre demande et nous vous tiendrons informé de l'avancement des discussions.
Utilisation de l'API	Clarification de la définition explicite du groupe "control_1" dans le document "Consignes CMA supplémentaires concernant les tests pour les tiers". Plus précisément, on craint qu'un changement de formulation ne soit interprété à tort comme nécessitant l'exclusion de toutes les API 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, et nous vous suggérons de lui soumettre directement vos questions concernant l'interprétation des conseils relatifs aux tests.
Utilisation de l'API	Chrome autorisera-t-il l'appel de joinAdInterestGroup() sur une page vierge lors de la redirection vers une autre ressource ?	Si un utilisateur visite un site donné, son propriétaire peut déléguer la possibilité d'appeler joinAdInterestGroup à un tiers. Cette délégation permet à un tiers de créer des IG sans avoir à ajouter de redirection via une page vierge. Nous vous invitons à nous faire part de vos commentaires sur des 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 travaillent, et déléguer ensuite l'autorisation d'enchérir sur ces IG à un acheteur ou à une DSP donnés.	Nous avons bien reçu vos commentaires et évaluons actuellement si une telle demande pourrait être acceptée. N'hésitez pas à nous faire part de vos commentaires.
Utilisation de l'API	Il n'y a pas de notification de perte de débogage si personne ne remporte une enchère pour l'API PA.	Les fonctions reportWin et reportResult de Chrome sont conçues pour générer des rapports sur les victoires au niveau des événements dans le système d'enchères sur la confidentialité. Dans les cas où toutes les enchères sont refusées lors d'une enchère aux enchères associées, ces fonctions ne sont pas appelées, car aucun gagnant n'est déterminé. Une récente mise à jour de Chrome peut expliquer des écarts lorsque les URL transmises à forDebuggingOnly.reportAdAuctionLoss() n'apparaissent pas dans le panneau DevTools Network. Nous vous recommandons de vérifier cette fonctionnalité à l'aide d'une version Canary ou de la version en développement de Chrome.
Utilisation de l'API	La valeur adCost renvoyée par generateBid peut-elle être négative (elle est déjà arrondie de manière stochastique à 2 octets) ?	AdCost est le coût du clic ou de la conversion de l'annonceur transmis de generateBid() à reportWin(). Cette valeur peut être nulle ou double. Les valeurs négatives seront ignorées et ne seront pas transmises. Lorsqu'elle est transmise, la valeur est arrondie de manière stochastique.
Amélioration de l'API	Est-il possible d'utiliser des serveurs d'exécution sécurisée et chiffré plutôt que le navigateur Chrome pour gérer le ciblage / les cohortes / l'attribution et les enchères ?	Nous vous recommandons d'examiner 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 les TEE d'Attribution Reporting et de Private Aggregation (par exemple, le service d'agrégation) qui répondent à cette question.
Amélioration de l'API	La réponse à l'enchère de la Privacy Sandbox peut-elle être une réponse à l'enchère (comme les enchères d'en-tête) plutôt qu'une réponse d'annonce (comme des tags d'emplacement publicitaire) ?	Ce type de modification modifie fondamentalement les propriétés de confidentialité de l'API PA. Nous n'envisageons donc pas de le faire.
Contrôles à la disposition des éditeurs	Les éditeurs peuvent-ils bloquer les créations utilisant l'API PA sur leurs pages ?	Une proposition concernant l'analyse des créations en temps réel dans Chrome n'est pas encore disponible à des fins de test. Même si cette fonctionnalité n'est pas encore disponible, nous avons constaté que la plupart des SSP ont créé des solutions pour y parvenir.
Utilisation de l'API	Quelle est la limite de taille pour "perBuyerSignals" ?	Dans sa version classique, perBuyerSignals n'est soumise à aucune limite de taille inhérente à Chrome. Les principales contraintes sont que les données restent sérialisables en JSON et n'entraînent pas une utilisation excessive de mémoire. Toutefois, il convient de noter que des signaux "perBuyerSignals" très importants et complexes peuvent avoir un impact négatif sur les performances. Il existe une autre méthode pour transmettre perBuyerSignals via directFromSellerSignalsHeaderAdSlot. Cette approche transmet perBuyerSignals dans un en-tête, en étant soumis à une 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 concernant la taille maximale de l'en-tête.
Documentation	Vous devez modifier la documentation sur l'appel RegisterAdBeacon depuis "generateBid".	Nous avons mis à jour cette documentation le 17 février.
Utilisation de l'API	Comment reportEvent choisit-il l'URL de la balise appropriée parmi les différentes options enregistrées ?	Chaque mise aux enchères génère une configuration distincte, laquelle génère un rapport distinct. Les enchères individuelles (et les images qui en résultent) sont complètement distinctes les unes des autres et ne partagent pas de données. L'article explicatif Rapports sur les annonces Fenced Frames fournit plus de détails à ce sujet.
UI Chrome	Ajout d'un filtre dans les outils pour les développeurs Chrome : Application -> onglet Groupes de centres d'intérêt. Vous pouvez ainsi filtrer les données par propriétaire de l'éditeur intégré (ou aussi par nom).	Nous évaluons actuellement cette demande et nous aimerions recevoir des commentaires de la part de l'écosystème.
Headless Chrome	Prise en charge de l'API PA dans Chrome sans interface graphique.	Certains composants de l'API PA sont liés à Chrome, tels que les appels k-anon aux serveurs de Google, qui peuvent ne pas fonctionner dans l'"ancien" Chrome headless. Nous pensons que la "nouvelle" version de Headless Chrome publiée dans Chrome 112 peut résoudre ce problème.
Utilisation de l'API	Dans le cas d'un rapport de perte avec reportAdAuctionLoss, "topLevelWinnerBid=0" s'affiche dans de nombreux cas. Quelle est l'interprétation de cela ?	La valeur topLevelWinnerBid provient de la fonction scoreAd() du composant vendeur de premier niveau. Cette valeur joue un rôle dans la détermination du résultat de l'enchère de premier niveau. Comme expliqué dans le message d'explication, une valeur topLevelWinnerBid définie sur zéro ou un nombre négatif signifie que l'annonce correspondante ne peut pas remporter l'enchère. Ce mécanisme permet, par exemple, d'exclure les annonces ciblées par groupes de centres d'intérêt qui ne dépassent pas un candidat pour un ciblage contextuel. Bien qu'une enchère topLevelWinnerBid sans valeur à zéro puisse indiquer qu'une enchère contextuelle a prévalu, la spécification de l'API PA reconnaît que d'autres facteurs peuvent contribuer à ce résultat.
Mode A/B Testing	Clarification concernant la sélection du trafic des modes B et A, et des invites de désactivation.	Les critères d'inclusion pour les modes A et B sont identiques. L'objectif est d'avoir des groupes représentatifs du trafic Chrome normal, à condition qu'ils acceptent les API Privacy Sandbox et la méthode d'étiquetage. Par conséquent, certaines configurations client ne sont pas compatibles. Pour les besoins du test, il est important de ne comparer que le trafic libellé à d'autres. 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	Est-il possible d'inclure "lifetimeMs" en tant que propriété directe dans l'appel joinAdInterestGroup ou de le gérer comme un argument distinct ?	Nous étudions attentivement les commentaires de la communauté des développeurs Web concernant la fonctionnalité "joinAdInterestGroup" dans la proposition d'API de PA. Un point de discussion clé se concentre 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 de futures améliorations potentielles de la spécification. Nous discutons de ce problème ici, et nous aimerions connaître votre avis .
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 à entropie faible.	L'équipe Chrome participe activement à l'amélioration continue du cadre de l'API PA. Nous vous remercions de la discussion à propos des éventuels taux de faux négatifs résultant de collisions d'ID de navigateur. Nous évaluons attentivement ces commentaires et veillerons à ce que les analyses mises à jour reflètent de manière exhaustive tous les facteurs pertinents. Nous nous sommes engagés à proposer une solution offrant les résultats souhaités en termes de confidentialité, tout en assurant la justesse et la fiabilité. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos 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 "Join" pour le même objet dans un système de k-anonymat ?	Nous apprécions et apprécions les discussions en cours concernant l'utilisation d'identifiants de navigateur dans la mise en œuvre des systèmes de k-anonymat. Nous comprenons les préoccupations liées aux implications potentielles de ces identifiants sur la confidentialité. Notre implémentation initiale utilisait un identifiant à faible entropie comme mécanisme de protection contre les utilisations abusives. Toutefois, 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 permettant d'équilibrer une utilisation responsable des données et une protection efficace de la confidentialité, et nous nous réjouissons de poursuivre le dialogue avec la communauté des chercheurs. Nous en discutons ici, et nous aimerions connaître votre avis.
Utilisation de l'API	Les pages AMP (Accelerated Mobile Pages) sont-elles compatibles avec l'API PA ?	AMP n'est actuellement pas compatible de manière native avec l'API PA. N'hésitez pas à nous faire part d'autres commentaires de la part de l'écosystème si la prise en charge des pages AMP est une priorité absolue.
Amélioration de l'API	Envisagez de supprimer le type des vérifications de k-anonymat.	Nous étudions attentivement vos commentaires sur l'optimisation potentielle des structures de requêtes de k-anonymat. Nous comprenons qu'il est recommandé de regrouper les paramètres et éventuellement d'unifier les types pour simplifier le processus. Notre objectif est de garantir l'efficacité et la facilité de gestion, et nous évaluons toutes les options à mesure que nous développons nos solutions de confidentialité. Nous discutons de ce problème ici, et nous aimerions connaître votre avis .
UI Chrome	Demande de mécanisme permettant aux utilisateurs moins techniques d'afficher et de gérer facilement les IG auxquels ils appartiennent, y compris des commandes de désactivation au niveau du site Web.	Nous savons qu'il est important de fournir des outils conviviaux pour comprendre et gérer les IG. Nous avons soigneusement examiné différentes méthodes et avons constaté que l'identification des IIG par le site Web à l'origine de leur participation offre le meilleur équilibre entre clarté et protection de la confidentialité. Actuellement, la gestion globale des IG se fait 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 aimerions recueillir vos commentaires.
Sécurité des API	L'API PA est-elle vulnérable aux fuites de confidentialité liées aux interactions avec les créations, même dans le contexte de Fenced Frames ?	Nous sommes conscients du risque de fuite d'informations lié à des interactions sophistiquées avec les annonces. Nous étudions activement l'interaction entre Fenced Frames, l'API PA et les vecteurs d'attaque potentiels. La réduction des risques liés à la confidentialité est une priorité absolue, et 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 aimerions recueillir vos commentaires.
Latence	Le délai par défaut de 50 ms pour la logique d'enchères de l'acheteur est-il réaliste ?	Nous prenons en compte les préoccupations concernant les incohérences potentielles entre la spécification et la fréquence des requêtes réseau pour la logique d'enchères. Nous examinons activement les spécifications pour garantir leur précision et recherchons des paramètres de délai d'inactivité par défaut optimaux pour trouver le bon équilibre entre performances et faisabilité. Nous discutons de ce problème ici, et nous aimerions connaître votre avis .
Documentation	Fuite éventuelle de données temporelles dans la spécification permettant à un site Web de déterminer 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 potentielle fuite de temps. Nous avons constaté une incohérence dans les spécifications, et nous prenons des mesures pour s'assurer que le k-anonymat des annonces est déterminé avant la mise aux enchères afin d'éviter de telles fuites. Nous prenons ces préoccupations très au sérieux et mettrons à jour les spécifications en conséquence. Nous discutons de ce problème ici, et nous aimerions connaître votre avis .
Utilisation de l'API	Comment implémenter une liste de blocage SSP dans l'API PA	Nous sommes conscients qu'il est nécessaire de mettre en place des mécanismes permettant de gérer les restrictions appliquées aux annonces par les SSP. Nous vous encourageons à explorer des solutions qui donnent la priorité à l'évaluation sur l'appareil et exploitent les métadonnées d'annonces existantes pour protéger la confidentialité des utilisateurs tout en offrant une grande flexibilité. Nous nous engageons à collaborer avec les développeurs afin d'identifier les approches optimales au sein de l'API PA. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Quelqu'un peut-il dire à son navigateur de faire semblant d'utiliser l'API PA d'une manière que les sites ne peuvent pas détecter ?	Nous reconnaissons que, dans 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, le ciblage par exclusion et le rendu Fenced Frames, 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 aimerions recueillir vos commentaires.
Mode A/B Testing	Trafic des centres de données censé être considéré comme un traitement 1.1.	L'équipe Chrome a confirmé auprès de l'équipe GAM que ce trafic est maintenant exclu du test. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Efficacité et équité de l'implémentation deinterestGroupBuyers dans l'API PA.	Nous sommes conscients des discussions en cours sur l'efficacité et l'équité du champ "interestGroupBuyers" dans les enchères de l'API PA. Nous savons qu'il existe des compromis entre efficacité, confidentialité et équité sur le marché. Même si les vendeurs doivent gérer des relations commerciales avec les acheteurs, nous étudions des moyens d'optimiser le processus de mise en correspondance. Ceux-ci peuvent inclure des ajustements dynamiques basés sur des données en temps réel et des modèles hybrides. Nous nous engageons à trouver des solutions qui donnent la priorité à la confidentialité des données des utilisateurs et favorisent un écosystème publicitaire compétitif. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
UI Chrome	Problèmes potentiels de mémoire et clarté de l'interface utilisateur liés à IG dans Chrome.	Nous comprenons les préoccupations liées à l'affichage des IG dans les outils de développement. Bien que la vue actuelle reflète tous les événements d'IG pour le suivi historique, nous reconnaissons qu'il est important de fournir une meilleure visibilité sur l'état actuel des IG stockés. Nous explorerons les optimisations et les améliorations potentielles à apporter à l'interface utilisateur afin d'améliorer les insights pour les développeurs. En ce qui concerne la gestion de la mémoire, l'implémentation 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 aimerions recueillir vos commentaires.
Documentation	L'auteur d'origine 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 s’il s’agit d’un comportement intentionnel.	Nous savons qu'il est important de simplifier la configuration des annonces au sein de la fonction "joinAdInterestGroup". Nous nous efforçons de résoudre ce problème et prévoyons d'activer cette fonctionnalité dans les prochaines mises à jour. Cette amélioration reflète notre engagement à 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 aimerions recueillir vos commentaires.
Libellé des tests gérés par Chrome	Demandez à obtenir des données directes sur le mode A ou B et les libellés exacts dans sendReportTo pour que nous puissions suivre le test de manière cohérente.	Pour discuter de cette demande, cliquez ici. Vos commentaires sont les bienvenus.
Documentation	Le nom de domaine du vendeur est-il inclus dans les demandes adressées au serveur de confiance d'un vendeur à des fins de validation ?	Nous reconnaissons l'omission initiale du paramètre de nom d'hôte dans la documentation de l'API Protected Audience KV Server. Nous souhaitons assurer aux développeurs que le nom de domaine du vendeur est automatiquement inclus dans les demandes envoyées à son serveur de confiance. Cette fonctionnalité est essentielle aux processus efficaces de validation des annonces. Nous avons mis à jour la documentation pour répondre à cette omission, et nous continuerons à privilégier la clarté et la transparence pour la communauté des développeurs. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Méthodes possibles pour inclure le nom IG dans les appels de suivi des impressions d'annonces à des fins de création de rapports.	Nous nous engageons à trouver un juste équilibre entre la nécessité de mécanismes de signalement efficaces et le principe fondamental de la confidentialité des utilisateurs. L'inclusion de noms IG dans le suivi des impressions d'annonces est soumise à des mesures de protection du k-anonymat visant à empêcher l'identification des individus. Nous continuerons à explorer des solutions innovantes de reporting pour respecter ces contraintes de confidentialité. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Fonctionnalité d'API	Requête pour que le serveur de confiance de l'acheteur reçoive les en-têtes HTTP des indications client.	Pour effectuer le suivi de cette demande de fonctionnalité, cliquez ici.
Utilisation de l'API	Si le fichier de délégation nécessite de charger l'en-tête "Access-Control-Allow-Origin", étant donné qu'il détermine le comportement d'appartenance à l'IG pour le navigateur,	Nous nous engageons à respecter les bonnes pratiques concernant la sécurité sur le Web. L'exigence d'un en-tête "Access-Control-Allow-Origin" pour les fichiers de délégation garantit la cohérence avec les principes CORS et empêche l'exposition involontaire d'informations sensibles. Nous étudions des 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 aimerions recueillir vos commentaires.
Utilisation de l'API	Permettre aux ad servers de personnaliser les créations dans le cadre de l'API des API publicitaires	Nous sommes conscients du rôle que peuvent jouer les ad servers dans la personnalisation des créations. Nous étudions activement des solutions permettant d'optimiser les ad servers au sein de l'API PA, par exemple le modèle "joint IG" qui permet de combiner les logiques d'enchères et de sélection des créations publicitaires. Notre objectif est de trouver le juste équilibre entre la mise en place de fonctionnalités efficaces de création d'annonces et la protection de la confidentialité des utilisateurs. N'hésitez pas à nous aider à continuer de collaborer et à nous faire part de vos commentaires sur l'évolution de l'API afin de répondre aux besoins de toutes les personnes concernées. Pour ce faire, consultez cette page.
Questions relatives à la confidentialité	Disponibilité d'autres identifiants (par exemple, RampID, ID5) dans les demandes d'enchères contextuelles pourrait aller à l'encontre des objectifs de confidentialité de l'API PA en facilitant la collecte de données intersites.	Nous sommes conscients des tensions potentielles entre les identifiants intersites et les objectifs de confidentialité de l'API PA. Bien que les éditeurs puissent choisir de partager ces identifiants, la conception de l'API PA vise fondamentalement à dissocier la sélection des annonces de la nécessité d'un suivi intersites. Nous nous engageons à promouvoir 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 aimerions recueillir vos commentaires.
Mise en cache	Existe-t-il un moyen d'empêcher la réutilisation des scripts d'enchères dans plusieurs systèmes d'enchères ?	Nous reconnaissons le comportement de mise en cache observé pour les scripts d'enchères dans le framework de l'API PA. Bien que les mécanismes de mise en cache HTTP standards soient compatibles, il est possible de réutiliser les scripts dans les enchères en raison du comportement de suspension de l'appareil et de la conception des exécuteurs d'enchères. L'équipe cherche des solutions pour permettre aux acheteurs de mieux contrôler la mise en cache des scripts afin de gérer efficacement leurs stratégies d'enchères. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Centralisez les rapports sur l'activité d'enchères sur tous les IG d'une DSP, tout en respectant la confidentialité des utilisateurs.	Nous accordons la priorité à la confidentialité des utilisateurs lors de la conception d'une API PA. Même s'il n'est pas possible de signaler directement des événements d'enchères individuels en raison des risques liés au suivi intersites, nous proposons des mécanismes tels que le stockage partagé et l'agrégation privée. Elles permettent aux DSP d'obtenir des insights agrégés sur l'activité d'enchères, tout en respectant la confidentialité des utilisateurs.
Utilisation de l'API	La récupération à partir de sendReportTo() dans reportResult() n'est effectuée que dans 94% des cas par rapport à l'enregistrement d'une exploration auprès de forDebuggingOnly.reportAdAuctionWin().	Bien qu'elles n'aient pas les mêmes codes temporels, il est possible que les deux URL soient extraites en même temps. Dans certains cas, le worklet du vendeur de composants a été supprimé et doit être actualisé pour pouvoir exécuter la fonction reportResult(). Toutefois, ni le temps nécessaire pour récupérer la logique d'évaluation, ni le délai d'actualisation du worklet n'ont d'incidence sur le délai d'attente de 50 ms pour reportResult(). Veuillez noter que Chrome utilisera des en-têtes de mise en cache pour définir son comportement de récupération dans les cas où le worklet doit être rechargé. Pour en savoir plus sur les phases d'une mise aux enchères des enchères par enchères, cliquez ici.
K-anonymat	Demande de confirmation indiquant que le nom du centre "interestGroup" n'affecte pas le k-anonymat de la diffusion d'annonces.	Pour qu'une création soit considérée comme k-anonyme, le tuple de l'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 afin de fournir le type de "visibilité interne" sans frais par de nombreux frameworks MVC, ORM, etc. Par exemple, commencez par enregistrer les événements internes sélectionnés dans un nouveau panneau sous Outils de développement > Application > Application.	Pour discuter de la proposition, cliquez ici. Vos commentaires sont les bienvenus.
UI Chrome	La participation à l'IG dans les outils de développement n'affiche pas d'éléments prioritaires.	Nous avons résolu ce problème ici.
Amélioration de l'API	Il est préférable d'autoriser le serveur publicitaire créatif à suivre ses propres événements. Est-il possible de configurer une liste de domaines de suivi autorisés ?	Nous avons partagé une proposition sur cette page et nous aimerions recevoir des commentaires supplémentaires de la part de l'écosystème.
Demande de fonctionnalité de l'API	L'API PA peut-elle être étendue pour prendre en charge les transactions média avec enchères en différé et pour gérer les cas d'utilisation critiques tels que la diffusion d'annonces et l'Optimiseur de campagne display ?	Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Expiration du délai de mise aux enchères de l'éditeur	Les éditeurs ont besoin de contrôler la durée des enchères pour éviter de perdre des impressions, en particulier dans les configurations d'enchères d'en-tête où les annonces sont sélectionnées de manière séquentielle.	Nous sommes conscients qu'il est important d'offrir aux éditeurs un contrôle précis sur le délai avant expiration des enchères publicitaires. Nous étudions activement la manière de mettre en œuvre un mécanisme global de délai avant expiration des enchères, potentiellement dans l'objet "auctionConfig", tout en examinant attentivement les cas limites. Cette fonctionnalité vise à optimiser les taux de remplissage des impressions pour les éditeurs. Nous continuerons à collaborer avec la communauté pour trouver la meilleure solution. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Amélioration de l'API	La conception actuelle des IG dans l'API PA entraîne des métadonnées de grande taille en raison des URL de rendu longues. Les testeurs aimeraient pouvoir compresser ces URL pour plus d'efficacité.	Nous savons qu'il est important d'optimiser la taille des métadonnées IG, en particulier pour les enchères publicitaires sensibles à l'efficacité. Nous pensons qu'une solution basée sur des modèles pour compresser les URL de rendu présente un potentiel considérable. Nous évaluerons soigneusement les modèles proposés et nous nous assurerons que toute solution implémentée comprend des mécanismes efficaces de prévention des abus afin de maintenir la stabilité du navigateur. En gardant ces considérations à l'esprit, notre priorité reste de collaborer avec la communauté des normes Web afin de développer l'approche optimale. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Les testeurs qui gèrent des formats d'annonces natives souhaitent optimiser le processus d'enchères de la Privacy Sandbox en récupérant plusieurs résultats d'annonces dans un seul appel afin de réduire la charge réseau et d'améliorer la vitesse d'affichage des annonces.	Nous prenons en compte les problèmes de performances soulevés concernant l'affichage des annonces natives dans la Privacy Sandbox. Nous nous engageons à trouver un équilibre entre efficacité et protection renforcée de la confidentialité des utilisateurs. Bien que l'affichage 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 compatibilité de l'API PA pour les formats d'annonces natives et d'étudier d'autres mécanismes pour améliorer l'efficacité face aux fortes contraintes de confidentialité de la Privacy Sandbox. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	La Privacy Sandbox permet d'évaluer et de trier de manière flexible les enchères d'annonces, en particulier pour représenter les niveaux de priorité ou les règles de la place de marché privée.	Nous comprenons qu'il est nécessaire de pouvoir contrôler précisément l'évaluation et le tri des annonces dans la Privacy Sandbox, en particulier dans les scénarios d'enchères complexes. Nous appuyons sur les solutions proposées en utilisant des tuples et des fonctions mathématiques pour obtenir des scores multidimensionnels sans compromettre la confidentialité des utilisateurs. Si ces approches sont susceptibles d'ajouter de la complexité pour les développeurs, elles offrent l'expressivité nécessaire. Nous nous engageons à trouver des moyens de simplifier ces processus, éventuellement par le biais de fonctions d'assistance ou de consignes, afin de garantir une utilisation optimale des fonctionnalités de la Privacy Sandbox pour la logique d'enchères avancée. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
reportEvent()	Ajoutez un nouvel événement réservé (éventuellement une balise automatique) déclenché par le navigateur lorsqu'un frame contenant une création publicitaire est initialisé.	Pour en savoir plus sur cette demande, cliquez ici. Vos commentaires sont les bienvenus.
adCost	Autorisation de la répartition d'adCost.	Chaque valeur de coût représente une opportunité d'envoyer un nombre limité d'informations en dehors de la mise aux enchères. Autoriser une liste complète de N de ces coûts suffirait à envoyer un identifiant d'utilisateur complet, ce qui permettra le suivi intersites. Nous en discuterons sur cette page et nous aimerions recueillir vos commentaires.
resolveToConfig	Dois-je hériter de resolveToConfig du niveau supérieur et être exposé dans browserSignals ?	Pour en savoir plus sur cette demande, cliquez ici. Vos commentaires sont les bienvenus.
Outils optimisés	Existe-t-il quelque chose qui ressemble à chrome://topics-internals, mais qui concerne l'API PA ?	Il n’y a rien de exactement pareil. Cependant, il existe de nombreux outils de développement pour l'API PA.
Étiquettes	Chrome peut-il utiliser des libellés pour identifier la population de 20% de k-anons ?	Nous étudions cette demande et nous aimerions recevoir des commentaires de la part de l'écosystème.
Documentation	Les Worklets d'enchères de la Privacy Sandbox deviendront-ils des types de worklet standard ?	En raison d'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'implémentation et l'environnement 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 valeur-clé (BYOS, Bring Your Own Server)	Les parties peuvent apprendre plusieurs IG (d'un même propriétaire) joints par un utilisateur via des requêtes de services KV dans une configuration de service BYOS KV.	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 de "userBiddingSignals" tout en conservant les autres.	Cela est déjà possible sans aucune modification de l'API.
Utilisation de l'API	Implémentez la limitation de la fréquence d'exposition sur plusieurs IG dans la Privacy Sandbox, en utilisant potentiellement le serveur KV ou des données "prevWinsMs" modifiées.	Nous sommes conscients du souhait d'intégrer des fonctionnalités avancées de limitation de la fréquence d'exposition dans la Privacy Sandbox. Nous sommes conscients que les restrictions actuelles sur le partage des données entre les intégrateurs d'inventaires peuvent poser problème lors de la mise en œuvre de ces stratégies. Même si le serveur KV offre un mécanisme potentiel avec des mesures de protection de la confidentialité appropriées, nous encourageons les développeurs à explorer des solutions avec un seul modèle IG. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.
Utilisation de l'API	Les vendeurs de composants (ceux qui participent aux enchères imbriquées dans la Privacy Sandbox) ont besoin de connaître les délais d'expiration des enchères de premier niveau pour optimiser leurs propres configurations et éviter les retards inutiles.	Nous sommes conscients qu'il est nécessaire d'améliorer la coordination des délais d'expiration entre les vendeurs de premier niveau et les vendeurs de composants dans la Privacy Sandbox. Nous étudions activement la possibilité d'ajouter de nouveaux mécanismes de délai d'expiration, par exemple un délai avant expiration potentiel d'une enchère complète, et nous étudions la possibilité d'appliquer des délais d'expiration de premier niveau aux enchères de composants. Notre objectif est d'améliorer l'efficacité et la prévisibilité de tous les participants au processus d'enchères de la Privacy Sandbox. Nous discutons de ce problème sur cette page et nous aimerions recueillir vos commentaires.

Services Protected Audience

Thème du commentaire	Résumé	Réponse Chrome
Environnements d'exécution sécurisés (TEE)	L'exécution de TEE dans des clouds publics est-elle plus chère que les centres de données ad tech sur site ?	Notre réponse est semblable aux trimestres précédents: Notre modèle de sécurité du TEE actuel bénéficie des pratiques d'implémentation du cloud public. En particulier, les TEE actuels basés sur le matériel ne vous protègent pas contre toutes les attaques physiques. AWS et GCP, nos fournisseurs de cloud public déjà pris en charge ont conçu et mis en place des mesures de protection contre les risques d'accès physique, y compris ceux des employés. Vous trouverez ci-dessous des informations supplémentaires concernant l'assistance sur site. Les technologies publicitaires nous ont indiqué que l'exécution de services cloud coûte plus cher que l'utilisation de centres de données de technologie publicitaire sur site. Bien que nous ne soyons pas en mesure d'évaluer ces déclarations, nous aimerions recevoir des commentaires supplémentaires sur les coûts et continuer à évaluer les options pour étendre notre assistance TEE.
TEE	Compatibilité avec les TEE dans les environnements non cloud publics	Notre réponse est semblable à celle des trimestres précédents: Nous cherchons toujours à proposer d'autres options que les solutions basées sur le cloud public, mais nous n'avons pour l'instant pas l'intention d'accepter les TEE sur site. À ce stade, compte tenu des exigences de sécurité de la Privacy Sandbox et des défis importants posés par les déploiements sur site, nous pensons que continuer à développer et à améliorer les déploiements dans le cloud (par exemple, en prenant en charge Google Cloud en plus d'AWS) est le plus bénéfique pour l'écosystème. Toutefois, nous aimerions recevoir des commentaires supplémentaires sur les raisons pour lesquelles une telle exigence est nécessaire et réalisable compte tenu des contraintes de confidentialité et de sécurité.
Autres fournisseurs cloud	Assistance pour d'autres fournisseurs de services cloud	Nous sommes toujours prêts à recevoir des suggestions d'autres fournisseurs de services cloud, mais nous prévoyons actuellement de prendre en charge GCP et AWS lorsque l'authentification 3PCD est appliquée. Consultez cette vidéo d'explication pour en savoir plus.
API B&A Services	Quelle est la direction de Google concernant l'API B&A Services ? Sera-t-elle prioritaire ou inférieure à l'API Protected Audience du navigateur Chrome lors des enchères sur les appareils ?	Notre réponse est semblable aux trimestres précédents: Nous restons attachés à la conception actuelle des enchères sur l'appareil de l'API Protected Audience. Les services d'enchères et de mise aux enchères ont été proposés afin d'explorer des solutions possibles pour répondre à un sous-ensemble de cas d'utilisation où la puissance de calcul ou la vitesse du réseau de l'appareil peuvent être limitées.
Standardisation	Les services d'enchères et de mise aux enchères ne sont pas passés par un processus de standardisation.	La proposition de services d'enchères et de mise aux enchères se trouve au milieu d'une phase du processus de normalisation, et nous souhaitons un engagement supplémentaire en faveur de cet objectif. Elle a commencé par une proposition (basée sur les propositions précédentes), elle est en cours d'incubation publique grâce à de longues discussions ouvertes au sein du W3C, et les développeurs intéressés peuvent commencer à l'expérimenter et à donner leur avis. Il s'agit du schéma habituel pour le développement de fonctionnalités Web, comme décrit par exemple dans notre article de blog.
KV Server	Exposer l'URL complète au serveur KV de l'acheteur pour le ciblage de contenu / contexte / par sites.	Nous discutons de cette demande sur cette page et nous aimerions recevoir d'autres commentaires de la part de l'écosystème.
Documentation	La documentation sur les composants approuvés/appliqués et facultatifs sur GitHub suscite la confusion avec certaines technologies publicitaires qui disposent de leur propre ensemble d'images et d'infrastructures de déploiement.	Nous cherchons à améliorer la documentation sur les composants fiables/appliqués par rapport aux éléments facultatifs, et j'aimerais avoir votre avis sur l'écosystème si ces tâches doivent être prioritaires.
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 actuellement cette demande et nous aimerions recevoir des commentaires de la part de l'écosystème.
Documentation	Fournissez plus d'informations sur la façon dont les charges de travail JS et WASM seront traitées exactement avec l'exécution de l'UDF.	Nous étudions actuellement ces informations. Si vous souhaitez nous faire part d'autres commentaires, cliquez ici.
Documentation	Requête de mise à jour 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 la collection de services à laquelle il appartient, qui contient également d'autres dépôts, comme ceux de la documentation sur les services d'audience protégés et ceux de la documentation sur les services d'enchères protégés.
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 fonctionne bien pour les autres vendeurs ? Avez-vous des suggestions sur la façon de mesurer les délais avant expiration et les délais ?	L'appel du serveur KV s'effectue dans le contexte des exécuteurs de script, c'est-à-dire dans l'environnement protégé spécifiquement dans le navigateur Chrome. Elle est destinée à protéger les informations de ces exécuteurs de tout accès non-API. Vous trouverez une explication détaillée sur cette page.
Utilisation de l'API	Existe-t-il un délai d'inactivité pour que le serveur KV réponde à un moment donné ?	Les vendeurs peuvent spécifier le champ "perBuyerCumulativeTimeouts" dans la configuration des enchères. Ce délai inclut le temps nécessaire pour récupérer les signaux d'enchères de confiance.
Latence	Comment l'équipe Privacy Sandbox lutte-t-elle pour réduire la latence ?	Pour connaître les stratégies que nous explorons pour maintenir la latence dans des limites acceptables, cliquez ici.

Mesurer vos annonces numériques

Attribution Reporting (et autres API)

Thème du commentaire	Résumé	Réponse 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 expliqué comment utiliser l'ARA pour optimiser manuellement les campagnes. L'ARA a été conçu de manière à permettre la personnalisation et la flexibilité des technologies publicitaires pour résoudre divers cas d'utilisation de technologies publicitaires. Parmi les suggestions proposées figurent l'utilisation de différentes configurations flexibles au niveau des événements et l'utilisation de rapports au niveau des événements avec des rapports récapitulatifs afin de réduire l'impact du bruit et de répondre aux besoins d'optimisation manuelle et automatique. Nous sommes prêts à recevoir d'autres commentaires sur l'écosystème concernant la personnalisation et la flexibilité des configurations ARA.
Type de conversion	Google n'autorise que huit types de conversion, ce qui est restrictif.	Nous avons implémenté la majorité des rapports flexibles au niveau des événements, ce qui offre aux technologies publicitaires une flexibilité supplémentaire concernant le nombre de périodes de référence, le nombre de rapports sur l'attribution et les bits de données de déclenchement 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 de rapport agrégable	Les annonceurs de petite taille disposant d'un budget limité ne peuvent pas définir une valeur numérique minimale de 20 événements de conversion par rapport agrégable.	Aucun nombre minimal d'événements de conversion n'est requis par rapport agrégable. Pour optimiser les rapports agrégables, les annonceurs de petite taille peuvent prendre différentes décisions concernant la conception. Par exemple, vous pouvez modifier la structure et les dimensions clés suivies, tester différents niveaux de bruit, tester des fréquences de traitement par lot plus longues, et tester différentes répartitions de budget de contribution entre les objectifs de mesure. Les petites technologies publicitaires peuvent également tester les rapports récapitulatifs et réduire l'impact des rapports au niveau des événements.
Données en temps réel	Ne pas fournir aux DSP les 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é des campagnes va à l'encontre de leur engagement à conserver 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 des 3PC.
Champs non renseignés	Exigences manquantes dans le déploiement des événements sur l'ensemble flexible: i) champ "Devise" et ii) champ ID de commande / ID de transaction.	Pour le moment, nous ne prévoyons pas d'accepter les champs "Devise" ni les champs "ID de commande / ID de transaction" dans le cadre d'une flexibilité complète au niveau des événements, car il existe déjà des moyens de le faire avec les rapports actuels au niveau des événements. Nous sommes prêts à recevoir d'autres commentaires concernant ces champs et nous y reviendrons si d'autres cas d'utilisation l'exigent. Voici comment utiliser la conception actuelle d'ARA pour mesurer les devises et les types d'ID de commande: 1. Sur la base de ces 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" pour déterminer la devise utilisée. 2. Suite aux commentaires que nous avons reçus, le champ "Order ID" (ID de commande) est nécessaire pour éviter que les conversions et les valeurs ne soient comptabilisées deux fois par erreur. Pour ce faire, vous pouvez utiliser des clés de déduplication.
Privacy Budget	Le budget pour la confidentialité de l'ARA limite la capacité à effectuer des mesures selon plusieurs dimensions	L'ARA a été conçu de manière à permettre aux technologies publicitaires de personnaliser leurs propres configurations ARA afin de couvrir divers scénarios d'attribution. Avec la conception actuelle de l'ARA, les technologies publicitaires devront réfléchir à un compromis entre les dimensions qu'ils doivent mesurer en priorité et l'impact du bruit sur leurs données. Pour protéger la confidentialité, il est essentiel d'ajouter du bruit aux données en fonction de la précision des dimensions mesurées. Nous sommes ouverts à d'autres commentaires concernant la possibilité d'effectuer des mesures dans 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 indiqué que les périodes de création de rapports sur les événements étaient désormais flexibles, elles ne sont plus prises en compte dans les spécifications techniques de Google, qui imposent encore un délai minimal d'une heure.	Les rapports flexibles au niveau des événements permettent actuellement aux technologies publicitaires de modifier le nombre de rapports sur l'attribution par événement source, les bits des données du déclencheur, ainsi que le nombre/la durée des périodes de référence. ARA dispose toujours d'une période minimale de reporting d'une heure pour les rapports au niveau des événements, ce qui est essentiel pour préserver la confidentialité et limiter certains types d'attaques par 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 et sans délai, si nécessaire pour leurs cas d'utilisation.
Conception d'API	craindre que la réduction du nombre d'informations dans les rapports de conversion et l'ajout de bruit puissent avoir un impact plus important sur l'écosystème que Google.	Google s'est engagé à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se préférant lui-même ses propres activités, et à tenir compte de 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 ni de vérifier l'attribution appropriée.	Dans ARA, de nombreuses solutions proposent des fonctionnalités de validation: 1. Les technologies publicitaires peuvent vérifier que le comportement de l'ARA correspond à leurs attentes: – Le code côté client ARA est Open Source. – Le code côté serveur 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 n'a pas eu lieu et pourquoi.
(Également signalé au cours des trimestres précédents) Bruit	Indiquer que le niveau de bruit est trop élevé et qu'il a un impact sur l'utilité du rapport	Nous avons discuté avec les technologies publicitaires avec les mêmes commentaires et avons pu identifier des moyens de personnaliser l'ARA pour mieux répondre à leurs cas d'utilisation, même en cas de bruit. Nous disposons de la documentation destinée aux développeurs qui contient la majorité des décisions de conception et des personnalisations dont nous avons parlé avec les technologies publicitaires. L'ARA a été conçu de manière à permettre aux technologies publicitaires de personnaliser leurs propres configurations ARA afin de couvrir différents scénarios d'attribution. Cependant, les technologies publicitaires devront réfléchir au compromis entre les dimensions qu'elles doivent le plus mesurer et l'impact du bruit sur leurs données. Nous sommes ouverts à des commentaires supplémentaires sur l'écosystème concernant l'impact du bruit et pouvons 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 ?	Les technologies publicitaires peuvent rediriger vers différentes URL de rapport pour résoudre ce cas d'utilisation. Nous sommes ouverts à d'autres commentaires sur l'écosystème concernant cet aspect de la conception de l'ARA.
Amélioration de l'API	Modifiez régulièrement le facteur de mise à l'échelle utilisé lors de l'enregistrement de l'attribution pour les rapports de synthèse ARA.	Sur la base de la discussion sur GitHub, il semble que la gestion de plusieurs facteurs de scaling dans le service d'agrégation se traduit très probablement par une plus grande quantité de bruit ajoutée aux rapports récapitulatifs par rapport à la fonctionnalité actuelle. Nous sommes ouverts à des commentaires supplémentaires concernant la nécessité d'utiliser des facteurs de scaling dans les rapports agrégables, mais nous souhaitons souligner les compromis potentiels avec plus de bruit. Nous cherchons également à déterminer si d'autres fonctionnalités ARA à venir pourraient également aider à résoudre ce cas d'utilisation.
Utilisation de l'API	Possibilité d'unifier la façon 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 synchroniser avec la technologie publicitaire pour mieux comprendre leurs commentaires et les limites qu'elles rencontrent.
Tester le volume de trafic	Le trafic de test pour le mode B dans tous les navigateurs Chrome est-il stable ?	L'inclusion à un groupe de test n'est pas affectée par les paramètres Chrome (indépendants).
Documentation	Prise en charge de l'ARA pour les pixels.	Nous avons publié des informations sur la façon de prendre en charge ce cas d'utilisation et nous aimerions recevoir d'autres commentaires de l'écosystème.
Utilisation de l'API	L'ARA peut ne pas être attribué à la source appropriée pour les vendeurs tiers sur les plates-formes d'e-commerce si la conversion n'est pas effectuée au dernier contact.	Les entreprises peuvent utiliser des filtres pour éviter qu'une attribution incorrecte ne se produise (car aucun rapport sur les conversions ne sera généré). Nous travaillons également sur une proposition de filtrage par pré-attribution pour faciliter ce cas d'utilisation.
Navigateurs pris en charge	L'ARA sera-t-il compatible avec d'autres navigateurs ?	Nous encourageons les autres navigateurs à adopter les API Privacy Sandbox et continuons de consacrer du temps à une discussion ouverte sur notre approche lors du W3C. Nous avons explicitement déclaré que l'interopérabilité est un objectif pour la livraison d'ARA. La conception de l'ARA est conçue pour être indépendante des navigateurs, avec des valeurs flexibles spécifiées par les fournisseurs, pour les fournisseurs ayant différentes opinions sur la confidentialité. D'autres navigateurs choisissent eux-mêmes de proposer des solutions viables en termes de compatibilité et d'identifiants intersites. Nous vous encourageons à noter que Microsoft Edge a indiqué qu'il était compatible avec ARA.
Utilisation de l'API	Quel est le genre de source attendu pour les enregistrements de la source ARA pour les balises automatiques registerAdBeacon/reportEvent (et navigation_start/commit) ?	Cela dépend si ces balises sont automatiques ou manuelles : - réservées*. (automatiques) de type "source de navigation". : les événements déclenchés manuellement doivent être de type source d'événement.
Utilisation de l'API	La limite maximale de 20 rapports agrégables par source correspond-elle à 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, à savoir 20 rapports agrégables par source peuvent être créés. La limite est définie par le navigateur et non configurable. L'objectif de cette limite est d'éviter d'abuser de la protection des rapports sur l'attribution réels avec des rapports nuls. Pour en savoir plus, cliquez ici.
Utilisation de l'API	Assistance pour le marketing par e-mail avec ARA	Pour le moment, il n'existe pas d'assistance directe pour ce cas d'utilisation dans ARA (si vous ne contrôlez pas le site d'hébergement des e-mails). Nous en discuterons sur cette page et nous aimerions recueillir vos commentaires.
Epsilon	Quand la valeur d'epsilon sera-t-elle déterminée pour l'API Aggregate ?	La valeur epsilon actuelle peut être configurée par les technologies publicitaires jusqu'à un seuil prédéterminé défini par la Privacy Sandbox (actuellement 64). Nous vous recommandons de tester différentes valeurs epsilon, d'identifier les points d'inflexion pour vos propres cas d'utilisation et de faire part de vos commentaires. Nous veillerons à en informer les technologies publicitaires avant toute modification de la plage de valeurs epsilon.
Amélioration de l'API	Dans ce cas d'utilisation, l'annonceur peut insérer un identifiant dans le champ "trigger_data" pour le mettre en correspondance avec des données CRM externes afin de lui permettre de vérifier la qualité des conversions.	Nous discutons de la demande. Si vous souhaitez nous faire part de vos commentaires, cliquez ici.
Utilisation de l'API	Comment gérer les URL de redirection en tant qu'URL de destination	Les technologies publicitaires peuvent effectuer l'une des opérations suivantes: 1. Saisissez l'URL de destination finale dans le champ de destination. 2. Le champ de destination accepte jusqu'à trois URL, ce qui vous permet d'en indiquer plusieurs. Pour utiliser les deux options, vous devez connaître l'URL de destination finale. Pour en savoir plus, cliquez ici .

Service d'agrégation

Thème du commentaire	Résumé	Réponse Chrome
Mécanismes de découverte clés	Demande de mécanisme de découverte de clés	Nous avons élaboré une proposition de découverte des clés et vos commentaires sont les bienvenus de la part de l'écosystème.
Utilisation de l'API	Feuille de route pour l'observabilité sur le service d'agrégation	Nous étudions les options qui s'offrent à vous pour améliorer l'observabilité. N'hésitez pas à consulter cette page pour nous faire part de vos commentaires.
Amélioration de l'API	Demande de possibilité d'interroger à nouveau les rapports.	Le service d'agrégation travaille sur une proposition de nouvelle requête permettant aux technologies publicitaires de répartir leur epsilon pour chaque rapport. Cela peut introduire plus de bruit par requête, mais permet aux technologies publicitaires d'effectuer une nouvelle requête et de préserver la confidentialité.
Amélioration de l'API	Souhaiterait pouvoir associer plusieurs origines au même ID AWS.	Le service d'agrégation permet désormais d'intégrer plusieurs sites au même compte cloud (GCP ou AWS). Cela permettra aux technologies publicitaires d'utiliser la même enclave de service d'agrégation pour traiter des rapports provenant de plusieurs sites et de plusieurs origines à partir des mêmes sites.
Utilisation de l'API	En cas d'échec des lots agrégables, vous ne savez pas si le budget est consommé ou non, et s'ils peuvent retraiter leur lot. Lorsqu'un service d'agrégation rencontre une erreur de budget pour des rapports en double, les autres rapports restants sont perdus. Comment minimiser cette perte ?	Dans un scénario classique, si l'intégralité d'une tâche échoue, le budget n'est pas utilisé. En cas d'échec rare lors de l'utilisation du budget, les technologies publicitaires peuvent demander une récupération du budget. Si la technologie publicitaire rencontre des échecs fréquents de tâche avec l'erreur d'épuisement du budget, elle doit confirmer sa stratégie de traitement par lot. Pour savoir comment regrouper correctement vos données et éviter les erreurs et les rapports en double, consultez cette page. N'hésitez pas à nous envoyer vos commentaires sur la récupération du budget sur cette page.
Utilisation de l'API	Si vous utilisez l'API Private Aggregation avec le déclencheur décrit ici, vous obtiendrez un rapport agrégable pour chaque enchère. Quelles sont les capacités de scaling du service d'agrégation ?	Le service d'agrégation lui-même n'impose pas de limite supérieure au nombre de clés ou de rapports dans un lot, mais une échelle de 10^14 rapports et 10^12 clés n'est actuellement pas compatible en raison de la mémoire qui serait nécessaire. Nos conseils de dimensionnement indiquent les plages que nous avons testées et recommandées pour obtenir des performances optimales en fonction de la charge attendue et des types d'instances de VM cloud compatibles.
Traitement des données	Si des données chiffrées contiennent des informations personnelles, quel est l'accord juridique pour fournir ces données au service d'agrégation ? Pouvez-vous me dire si vous avez la certitude que le coordinateur n'accédera pas aux données chiffrées ?	Le service d'agrégation ne partage pas les données utilisateur chiffrées / les données utilisateur avec le coordinateur. Le service d'agrégation utilise le coordinateur pour la gestion et la traçabilité des clés. Vous trouverez plus d'informations sur le coordinateur ici. Pour la traçabilité, le service d'agrégation ne partage que l'ID partagé et l'origine du rapport avec le PBS pour l'utilisation du budget. Lorsque nous lancerons un multisite, nous remplacerons l'origine par le site. Notez que le service d'agrégation s'exécute dans un TEE, 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 du commentaire	Résumé	Réponse 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 plus d'informations, cliquez ici.
Documentation	Quelle est la valeur epsilon utilisée dans les essais 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. Il existe également un budget de contribution secondaire de niveau 1 de 2^20, appliqué sur une base de 24 heures glissantes. En résumé, le paramètre de confidentialité est ⎓ sur une base de 10 minutes glissantes, et de 16ا sur une base glissante de 24 heures (au lieu de 144Ω). Le service d'agrégation est actuellement compatible avec une plage de Scalable à des fins de test (jusqu'à 64) afin de permettre d'expérimenter différentes stratégies d'agrégation et de fournir des retours sur l'utilité du système avec différents paramètres de confidentialité pour Private Aggregation et d'autres API. Nous prévoyons de réévaluer la valeur epsilon maximale autorisée au fil du temps à mesure que nous recevrons les commentaires des testeurs et que nous ajouterons des fonctionnalités qui permettent d'utiliser plus efficacement le budget lié à la confidentialité.

Limiter le suivi dissimulé

Réduction du user-agent/Conseils client User-Agent

Nous n'avons reçu aucun commentaire ce trimestre.

Protection des adresses IP (anciennement Gnatcatcher)

Thème du commentaire	Résumé	Réponse Chrome
ID de résolution	La Privacy Sandbox doit s'exprimer plus clairement sur le fait que les ID de résolution, souvent basés sur la propriété intellectuelle, ne sont pas viables pour les annonceurs.	La Privacy Sandbox indique clairement que nous visons à réduire le suivi intersites. Nos initiatives publiques, qui s'étendent au-delà des cookies, sont rendues publiques sur privacysandbox.com et sur GitHub. Nous nous efforçons de réduire le suivi intersites, y compris basé sur les adresses IP. Toutefois, il appartient à chaque site Web de décider d'activer ou non le suivi intersites de manière proactive. À l'heure où la conformité réglementaire est de plus en plus pratiquée, il est prudent pour les entreprises individuelles de bien comprendre les pratiques employées par leurs fournisseurs de services.
Chromecast	La protection IP aura-t-elle une incidence sur Chromecast ou les autres appareils Chrome ?	Il n'existe actuellement aucun plan permettant d'appliquer la protection IP aux appareils Chromecast.
Liste de protection des adresses IP	La liste des tiers identifiés comme potentiellement utilisant des adresses IP pour le suivi intersites sur l'ensemble du Web sera-t-elle publiée ?	La liste sera publiée une fois finalisée, comme indiqué sur cette page.

Atténuation du suivi des rebonds

Thème du commentaire	Résumé	Réponse Chrome
Exemption de l'authentification unique (SSO)	Comment le système d'atténuation du suivi des rebonds vérifiera-t-il les cas d'utilisation de l'authentification unique pour l'exception ?	La fonctionnalité BTM sera désactivée par l'heuristique Chrome. Cliquez ici pour en savoir plus.
Essai d'abandon	Le mode d'exécution en ligne est-il activé pour les sites participant à l'essai d'abandon des tiers ?	Non, BTM respecte les exceptions liées aux cookies créées lors de l'essai d'abandon, comme indiqué sur cette page.

Privacy Budget

Comme indiqué dans l'explication sur GitHub et le site pour les développeurs,Privacy Budget n'est plus activement pris en compte dans les propositions de la Privacy Sandbox.

Renforcer les limites de confidentialité intersites

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

Thème du commentaire	Résumé	Réponse Chrome
Feature request (Demande de fonctionnalité)	L'accès aux CHIP et / ou au Storage Partitioning est automatiquement autorisé dans RWS, sans avoir besoin de l'API Storage Access ni d'intervention de l'utilisateur.	Nous réfléchissons aux avantages et à la faisabilité d'une fonctionnalité pouvant remplir cette fonction. L'un des points à prendre en compte est une lacune potentielle dans l'interopérabilité entre les navigateurs, que RWS résout en exploitant l'API Storage Access. Il n'existe actuellement aucun équivalent à cette fonctionnalité demandée dans d'autres navigateurs. Nous encourageons les développeurs à soumettre leurs cas d'utilisation sur ce sujet pour faciliter la discussion sur cette page.
Suppression des Ensembles non conformes	Quel est le processus pour supprimer les ensembles qui ne sont plus conformes du dépôt ?	Nous travaillons à la définition d'une procédure à cet effet, et nous vous tiendrons informé dès qu'elle sera disponible.
Procédure d'application du règlement	Le rôle subjectif de Google dans le processus d'application RWS n'est pas clair.	RWS étant un projet continu et que nous continuons à recevoir de nouvelles demandes, certains aspects du processus et de nos critères sont encore en train d'être consolidés. Nous sommes d'accord qu'il est important que nos consignes d'envoi décrivent parfaitement les conditions à remplir. À l'avenir, nous les détaillerons davantage afin d'éviter toute ambiguïté et confusion. Nous souhaitons que le processus d'envoi soit aussi technique que possible afin que nous puissions progressivement mettre fin aux interventions humaines et nous fier uniquement à des vérifications automatisées. Les relations publiques telles que celle-ci nécessitent davantage d'interactions humaines, car elles incluent des comportements que nous n'avions pas anticipés. Elles nous permettent toutefois d'identifier d'autres domaines d'automatisation et de corriger nos consignes pour éviter ces problèmes à l'avenir.
Partager des données	Demande de 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 à une identité authentifiée après que l'utilisateur a accepté une invite d'autorisation. N'hésitez pas à nous faire part de vos commentaires sur les cas d'utilisation spécifiques qui, selon eux, ne sont pas possibles.
Autres méthodes de stockage	Les informations enregistrées sur le stockage local ou de session seront-elles également considérées comme des 3PC ?	Le stockage local, le stockage de session et d'autres formes de stockage hors cookies 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 d'ensembles associés	Que se passe-t-il pour les organisations qui soumettent plus de cinq domaines alors que la limite est fixée à cinq sites associés ?	Ces ensembles seront acceptés via le processus GitHub, mais le navigateur (Chrome) n'appliquera les règles d'attribution 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.	Un correctif a été proposé sur cette page pour résoudre ce problème.
Geste de l'utilisateur	Suppression de l'exigence de geste de l'utilisateur pour accessStorage().	Cette exigence a été élaborée sur la base d'une conception similaire qui existe sur tous les principaux navigateurs pour l'API requestStorageAccess. Nous invitons les autres commentaires et cas d'utilisation présentés dans ce numéro GitHub pour nous aider à hiérarchiser cette demande et à permettre des discussions entre navigateurs.
Geste de l'utilisateur	Un geste de l'utilisateur est-il nécessaire pour accorder l'autorisation d'accès à l'espace de stockage tiers après le redémarrage de Chrome ou de l'OS ?	Oui, mais nous aimerions recevoir d'autres commentaires de la part de l'écosystème pour nous indiquer s'il convient de modifier ce comportement ici.

API Fenced Frames

Thème du commentaire	Résumé	Réponse Chrome
adComponent	Manque de documentation et de flexibilité en utilisant AdComponents avec Fenced Frames.	Nous souhaitons partager davantage de documentation concernant ce cas d'utilisation. Par ailleurs, les composants d'annonce sont compatibles avec Fenced Frames à l'aide de getNestedConfigs(), comme décrit dans les spécifications ici.
(Également présenté aux trimestres précédents) Afficher adComponent	Demande d'exemples de codes sur l'affichage des adComponents dans Fenced Frame.	Nous mettons tout en œuvre pour vous fournir des exemples de code sur cette page.
Validation des annonces tierces	Le rôle de la validation des annonces tierces dans le contexte de Fenced Frames a besoin de plus de détails, notamment en ce qui concerne la brand safety.	Aujourd'hui, les rapports sur les annonces Fenced Frames permettent aux DSP d'envoyer des données sur les impressions et les événements d'enchères à des vérificateurs d'annonces tiers pour la facturation et les contrôles de brand safety post-affichage.
Annonces extensibles	Demande de compatibilité avec les annonces extensibles.	Si l'annonce doit basculer entre deux tailles avec le même format et qu'il n'y a pas de différence fonctionnelle entre les deux (juste la taille), l'outil d'intégration peut redimensionner le Fenced Frame avec la deuxième taille d'annonce et le navigateur adapte l'élément Fenced Frame en conséquence.
(Également disponible au cours des trimestres précédents) Compatibilité avec l'inventaire vidéo et natif	Fenced Frames est-il compatible avec l'inventaire vidéo et natif ?	Notre réponse est semblable aux trimestres précédents: L'API PA gère l'affichage vidéo à l'aide d'un mécanisme qui repose sur les cadres iFrame. Cependant, nous n'avons pas encore conçu de solution compatible avec Fenced Frames pour le rendu des annonces vidéo et natives. C'est l'une des raisons pour lesquelles nous avons décidé de repousser l'application de Fenced Frames à 2026. Par conséquent, si un partenaire décide d'appliquer maintenant les cadres cloisonnés, il ne prendra pas en charge les annonces vidéo et natives.
Comité consultatif	Demande la création d'un comité consultatif de fournisseurs d'annonces natives pour s'assurer que les intégrations de Fenced Frames respectent les normes du secteur.	Les cadres Fenced Frame ne sont pas obligatoires pour être utilisés dans l'API PA avant 2026. Ce délai supplémentaire nous permet de continuer à collaborer avec l'industrie afin de concevoir et de mettre en place une assistance pour un plus grand nombre de cas d'utilisation critiques. Nous avions déjà annoncé que nous allions faire évoluer Fenced Frames avant de devoir continuer à assurer la compatibilité avec les annonces vidéo et natives avec l'API PA. Conformément à nos engagements, nous interagirons avec la CMA et l'informerons de ces changements, et nous continuerons à prendre en compte les commentaires de l'écosystème avant d'exiger Fenced Frames. Notre modèle d'engagement dans l'écosystème au sein du W3C et les organismes de normalisation des annonces comme l'IAB Tech Lab permettent à des experts du secteur de toutes sortes de guider les conceptions avant qu'elles ne soient requises.
(Également indiqué aux trimestres précédents) Différence de taille entre les plates-formes	Indique que la taille du contenu affiché dans Fenced Frame est différente sur ordinateur et sur smartphone.	Il s'agit d'un problème Chromium connu que nous étudions actuellement. Si vous avez d'autres commentaires, cliquez ici.
Amélioration de l'API	L'exigence concernant Fenced Frames a-t-elle été repoussée à 2025 afin que les annonces natives soient désormais compatibles avec la Privacy Sandbox ?	Comme nous l'avions indiqué dans notre annonce publique concernant l'application de Fenced Frames dès 2026, nous avions appris une "grande initiative pour intégrer Fenced Frames". Certes, l'une d'elles était native, mais ce n'était pas le seul facteur. L'objectif était de laisser plus de temps pour que l'écosystème soit prêt à prendre en charge les principaux cas d'utilisation, y compris, mais sans s'y limiter, les annonces natives.

API Shared Storage

Thème du commentaire	Résumé	Réponse Chrome
Performances	Les temps de retour du stockage partagé en dehors du worklet semblent dépendre de l'activité de ce dernier.	Pour en savoir plus sur les résultats de ce test, cliquez ici.
Adoption plus large	Il s'agit d'une norme sectorielle disponible pour tous les navigateurs.	Vos commentaires sont les bienvenus. Chrome continue de participer activement aux forums du W3C, y compris au WICG, pour promouvoir la proposition, solliciter des commentaires et favoriser l'adoption.
Worklets d'enchères	Est-il possible de lire à partir du stockage partagé dans l'élément generateBid (qui s'exécute déjà dans un worklet) pour appliquer une décision d'annonce / une logique métier (comme la limitation de la fréquence d'exposition) basée sur des informations intersites et sélectionner un sous-ensemble d'annonces ?	Non, il est impossible de lire à partir du stockage partagé au sein des Worklets d'enchères.

CHIPS

Thème du commentaire	Résumé	Réponse Chrome
Capacité de partition	Clarification du comportement en cas de dépassement de la capacité de partition.	Lorsque la capacité est atteinte, les cookies les plus anciens sont écartés du ou des cookies consultés le moins récemment 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 suivantes.
Accès iFrame tiers	Le contenu iFrame tiers intégré ouvrant un nouvel onglet ou une nouvelle fenêtre sur le même site tiers doit avoir accès aux mêmes cookies partitionnés que l'outil d'ouverture.	Nous discutons de ce cas d'utilisation et nous aimerions recevoir d'autres commentaires de la part de l'écosystème sur cette page.
Cookies en double	S'il existe un cookie partitionné et un cookie non partitionné portant le même nom, quelle clé-valeur 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'est pas possible de différencier ces deux cookies. La spécification RFC à ce sujet est disponible ici, qui explique que l'ordre dans lequel les cookies sont envoyés ne doit pas être pris en compte.
Feature request (Demande de fonctionnalité)	Activer les cookies partitionnés en fonction de l'origine.	Nous examinons cette demande. Si vous souhaitez nous faire part d'autres commentaires de la part de l'écosystème, cliquez ici.

FedCM

Nous n'avons reçu aucun commentaire ce trimestre.

Lutter contre le spam et la fraude

API Private State Token (et autres API)

Thème du commentaire	Résumé	Réponse Chrome
Vue Web	Les jetons d'état privés (PST) sont-ils conservés dans plusieurs WebViews d'un même appareil mobile (profil) ?	Chaque application qui utilise WebView dispose d'un espace de stockage local différent, ce qui signifie que les émetteurs PST ne peuvent pas émettre de jetons dans la WebView d'une application, puis dans une application distincte, autoriser l'utilisation de jetons. Cela est également vrai pour d'autres formes de données stockées localement dans des WebViews, telles que les cookies. Les fichiers PST ne sont pas encore entièrement disponibles dans WebView. Nous prévoyons de vous communiquer des informations à ce sujet 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 nous continuons à explorer les possibilités d'application et d'adaptation des PST. Nous avons hâte d'en savoir plus sur cette proposition lors des prochaines réunions du groupe de la communauté antifraude au deuxième trimestre 2024.
Identification de l'utilisateur	Comment empêcher l'identification des utilisateurs en fonction de leurs fichiers PST spécifiques ?	Ce problème est actuellement atténué en limitant les tentatives d'utilisation sur un site à deux émetteurs, qu'ils proposent ou non des jetons. Vous devez comptabiliser un émetteur par rapport à la limite, même s'il n'y a pas de jetons disponibles. Sinon, le site pourrait itérer tous les émetteurs jusqu'à ce qu'il trouve une correspondance positive.
Inscription	Pendant combien de temps l'enregistrement sera-t-il nécessaire pour les fichiers PST ?	Dans un avenir proche, cet enregistrement restera obligatoire, comme expliqué plus en détail sur cette page.
Compatibilité avec d'autres navigateurs Chromium	L'enregistrement auprès des émetteurs PST pour d'autres navigateurs basés sur Chromium sera-t-il possible via le dépôt d'enregistrement des émetteurs Chrome ?	Chrome récupère les principaux engagements et les distribue aux clients Chrome via un mécanisme appelé Component Updater. Étant donné que d'autres navigateurs offrent une compatibilité plus complète avec l'API, ils doivent mettre en place un processus pour obtenir les engagements clés auprès du client, soit par le biais d'une méthode de mise à jour des composants, soit par une autre méthode. Vous trouverez plus de détails sur cette page.