Cette page a été traduite par l'API Cloud Translation.

Rapport sur les commentaires – T2 et T3 2024

Rapport trimestriel pour les 2e et 3e trimestres 2024, qui résume les commentaires reçus sur l'écosystème concernant les propositions Privacy Sandbox et la réponse de Chrome.

Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Le 22 juillet 2024, Google a annoncé qu'il n'abandonnerait pas les cookies tiers dans Chrome et qu'il proposerait plutôt une nouvelle approche pour donner plus d'importance au choix des utilisateurs. Par conséquent, avec l'accord de la CMA, Google n'a pas envoyé de rapport public pour le 2e trimestre 2024 à la CMA afin de laisser suffisamment de temps à Google et à la CMA de prendre en compte les conséquences de l'annonce de Google.

Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.

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

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

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

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

Glossaire des acronymes

ARA: API Attribution Reporting
CHIPS: Cookies ayant un état partitionné indépendant
DSP: Plate-forme côté demande
FedCM: Gestion fédérée des identifiants
Lecteur d'empreinte digitale: Ensembles propriétaires
IAB: Interactive Advertising Bureau
IDP: Fournisseur d'identité
IETF: Internet Engineering Task Force
IP: Adresse IP
openRTB: Enchères en temps réel
Prolongation: Phase d'évaluation
API PAT: API Protected Audience (anciennement FLEDGE)
PatCG: Groupe de la communauté sur les technologies publicitaires privées
tiers assujetti à des restrictions: Partie de confiance
RWS: Ensembles de sites Web associés (anciennement ensembles internes)
SSP: Plate-forme côté offre
TEE: Environnement d'exécution sécurisé
UA: Chaîne user-agent
UA-CH: Hints client user-agent
W3C: World Wide Web Consortium
WIPB: Blanchement d'adresse IP intentionnel

Commentaires d'ordre général, aucune API/technologie spécifique

Thème des commentaires	Résumé	Réponse de Chrome
Abandon des cookies tiers (3PCD)	Quels sont les projets de Google concernant les 3PCD ? Les effets à long terme sur le secteur de la publicité numérique ont-ils été évalués ?	Nous proposons une approche actualisée qui donne plus d'importance au choix des utilisateurs. Comme indiqué ici, au lieu d'abandonner les cookies tiers, nous souhaitons proposer une nouvelle expérience dans Chrome qui permettra aux utilisateurs de faire un choix éclairé qui s'appliquera à toute leur navigation sur le Web. Ils pourront modifier ce choix à tout moment. Nous discutons de cette nouvelle voie avec les organismes de réglementation et nous collaborerons avec l'ensemble du secteur avant de la mettre en place.
Choix de l'utilisateur	L'annonce du choix de l'utilisateur a eu un impact sur l'intérêt des écosystèmes pour l'adoption des solutions de la Privacy Sandbox. Les commentaires concernant l'annonce du choix de l'utilisateur sont mitigés, et incluent des demandes de fonctionnalités telles que des fonctionnalités de surveillance.	Avec l'approche mise à jour qui donne la priorité au choix de l'utilisateur, il reste important pour les développeurs de disposer d'alternatives aux identifiants intersites qui renforcent la confidentialité. Nous ne pouvons pas encore vous donner de détails sur la nouvelle expérience, mais nous nous attendons à une augmentation significative du trafic sans cookie dans Chrome. Cela signifie que les API Privacy Sandbox restent essentielles pour les entreprises. Nous continuerons à investir dans les technologies de la Privacy Sandbox afin d'améliorer encore plus la confidentialité et l'utilité.
UI de choix de l'utilisateur	Questions sur le calendrier des fonctionnalités de désactivation/consentement, le type d'option pour l'utilisateur envisagé et l'impact de l'interface utilisateur sur les environnements de test automatisés	Nous n'avons pas d'informations à vous communiquer sur le calendrier pour le moment. Après avoir décidé de ne pas utiliser 3PCD, nous avons voulu fournir une mise à jour de l'écosystème dès que possible. Nous vous informerons du calendrier de choix des utilisateurs dès que nous en saurons un.
Chrome Testing	Demande de maintien de la disponibilité des libellés de test Chrome pour mesurer l'adoption du marché et l'impact économique de la 3PCD après le premier semestre 2024.	Nous sommes conscients que les testeurs souhaitent continuer à utiliser des groupes de navigateurs libellés pour les tests et la coordination, même si les tests facilités par Chrome ont pris fin au premier semestre 2024. Nous évaluons les prochaines étapes concernant les libellés à la lumière de l'annonce sur le choix de l'utilisateur. En attendant, l'équipe Chrome a publié une intention d'étendre la prise en charge des groupes de navigateurs étiquetés via Chrome Milestone 132, qui s'étend jusqu'en janvier 2025.
Privacy Sandbox sur Android	La Privacy Sandbox sur Android et la Privacy Sandbox sur Chrome sont inextricablement liées, et nous ne pouvons pas évaluer correctement la Privacy Sandbox sans Android. Le parcours client type, qui implique des aspects inter-appareils et multipoint, est essentiel à la fois pour la Privacy Sandbox sur Chrome et pour la Privacy Sandbox sur Android.	Veuillez noter que la Privacy Sandbox sur Android n'entre pas dans le champ d'application des engagements de Google envers la CMA. Si vos commentaires concernent les délais et le déploiement d'Android, nous n'avons pas d'informations à vous communiquer pour le moment, si ce n'est que nous continuons de progresser sur Android, que nous considérons comme un flux de travail indépendant pour améliorer la confidentialité. Comme indiqué précédemment, la disponibilité des API Privacy Sandbox sur Android dépendra également de la fréquence à laquelle les utilisateurs mettent à jour leurs appareils, ce qui n'est pas sous le contrôle de Google.
Trafic limité en mode B	Le trafic des enchères publicitaires disponible avec le mode B a été inférieur aux prévisions.	Plusieurs raisons peuvent expliquer que les volumes d'enchères pour l'API Protected Audience (API PA) soient inférieurs aux attentes. Par exemple: - Les entreprises que nous connaissons qui ont intégré l'API PA n'ont inclus que des formats de bannière. - Les plates-formes côté vente ne lancent pas toujours une mise aux enchères. - Un navigateur peut ne pas avoir de groupes de centres d'intérêt. - Il est possible qu'il n'y ait pas d'enchères. Nous ne sommes cependant pas au courant de quiconque ayant tenté de tester l'API PA sans recevoir de trafic.
Visibilité des pannes	Visibilité sur les pannes et les problèmes affectant les API Privacy Sandbox.	Il existe une page d'état publique pour les API Privacy Sandbox qui disposent de services en dehors du navigateur. L'équipe Chrome accorde la priorité absolue à la fiabilité de notre plate-forme et de toutes les API critiques utilisées par les principaux sites et services du Web, y compris les technologies de la Privacy Sandbox. À ce jour, il n'y a eu qu'une seule interruption. Il s'agissait d'une configuration temporaire pour les tests à 1%. La configuration expérimentale impliquée dans cette panne ne sera bientôt plus nécessaire. Nous sommes donc convaincus que ce problème ne se produira plus une fois que les API seront activées normalement dans Chrome.
Étude sur les graphiques des cookies	Quelle est la position de Chrome sur la méthode CookieGraph décrite dans cet article dans le cadre de la Privacy Sandbox ?	Cet article soulève des points intéressants sur la détection et la prévalence des cookies propriétaires définis par des domaines différents de ceux visités par l'utilisateur. Comme le souligne le document, ces cookies sont extrêmement utiles pour recueillir des données analytiques et des informations sur la façon dont les utilisateurs interagissent avec un site Web. Ces données sont essentielles pour que les développeurs puissent offrir une meilleure expérience de navigation aux utilisateurs. L'argument principal de ce document est erroné, car il considère les cookies propriétaires comme un vecteur de suivi intersites. Toutefois, cela n'est vrai que si l'on considère les hypothèses très agressives décrites dans cet article: Les utilisateurs sont prêts à partager leurs informations personnelles avec le site. Les appareils disposent d'une empreinte digitale stable qui peut être utilisée pour suivre un utilisateur sur plusieurs sites. Notez qu'il s'agit de vecteurs de restauration de l'identification qui peuvent être exploités sans utiliser de cookies propriétaires (par exemple, via le partage de données côté serveur). Ils doivent être traités séparément de nos efforts actuels, qui sont axés sur les mécanismes de suivi basés sur l'état tels que les cookies tiers. Enfin, nous tenons à souligner que l'article associe les cookies d'analyse et de publicité aux cookies de suivi, et les cookies strictement nécessaires aux cookies de non-suivi, ce qui n'est pas nécessairement le cas. En effet, les analyses first party ou les services de fournisseurs partitionnés sur site, tels que les widgets de localisation de magasins, les widgets de chat ou les cookies d'équilibreur de charge, peuvent souvent être limités à un seul domaine. À l'inverse, certains cookies strictement nécessaires peuvent être le suivi intersites à des fins de lutte contre la fraude.
Modifications de l'expérience utilisateur	Les modifications apportées à l'expérience utilisateur dans Chrome 112, qui placent les commandes des cookies propriétaires dans la section "Données des sites sur l'appareil" des paramètres Chrome, peuvent rendre plus difficile le blocage de tous les cookies par les utilisateurs.	Ce changement a été effectué dans le but de séparer et d'élever les commandes des cookies tiers (ou stockage non partitionné) de tous les autres types de données de site. Les contrôles des cookies tiers sont renforcés dans le panneau "Confidentialité et sécurité", tandis que les commandes concernant les cookies propriétaires et tous les autres types de données des sites (dont les fonctionnalités critiques des sites dépendent généralement) sont regroupées sous "Données des sites sur l'appareil". Nous continuerons de recueillir des commentaires à ce sujet, mais nous pensons que la séparation actuelle offre un bon équilibre entre la visibilité des paramètres de confidentialité pertinents et la préservation d'une expérience de navigation fonctionnelle.
Facturation et paiement	Les facturations et les paiements ne sont pas entièrement testés, car les testeurs sont plus investis dans le test d'autres aspects des API Privacy Sandbox.	Les développeurs et les entreprises choisissent quand et ce qu'ils testent. Les API sont disponibles pour tous les utilisateurs depuis septembre 2023.
Tests	Tout le trafic expérimental que les DSP reçoivent des SSP n'est pas associé à un libellé. Certains DSP ont indiqué que la part d'impressions expérimentales non libellées pouvait être différente entre les groupes de traitement et de contrôle.	Chrome ne peut pas contrôler si les entreprises transfèrent les libellés dans les demandes d'enchères. Nous proposons une méthode pour obtenir une étiquette à partir du navigateur. C'est ensuite à l'écosystème de transmettre les libellés aux partenaires si ceux-ci ne peuvent pas les lire directement.
3PCD sur Android WebView	Demande d'aide pour activer l'indicateur "Test de l'abandon des cookies tiers" dans Android WebView afin de tester l'abandon.	Les cookies tiers sont bloqués par défaut dans Android WebView.
Confidentialité différentielle pour atténuer les risques lors de l'entraînement de modèles	Pourquoi la confidentialité différentielle est-elle utilisée dans l'entraînement de modèles ?	La confidentialité différentielle, combinée aux environnements d'exécution sécurisés (TEE), est essentielle à l'entraînement des modèles pour éviter les fuites de données et protéger les informations sensibles contre les menaces. Cette approche garantit que les poids du modèle ne peuvent pas révéler les données utilisateur individuelles.

Inscription et attestation

Thème des commentaires	Résumé	Réponse de Chrome
Inscription	Demande de clarification sur le fonctionnement de l'enregistrement d'attestation entre l'origine enregistrée et l'origine de la technologie publicitaire avec le sous-domaine www.	La technologie publicitaire ne devra s'intégrer que sur `https://example.com`. Lorsqu'il place son attestation dans `https://example.com/.well-known/privacy-sandbox-attestations.json`, le `https://www.example.com` est couvert, car il s'agit d'un sous-domaine.
Spécification de l'API	Suggestion d'ajouter un schéma JSON pour le fichier d'attestation au dépôt.	Nous évaluons cette suggestion et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.

Afficher des annonces et des contenus pertinents

Thèmes

Thème des commentaires	Résumé	Réponse de Chrome
Pondération des thèmes	La chose la plus importante à comprendre dans Topics est la rareté d'un signal donné. La conception actuelle doit évoluer pour permettre d'ajouter une valeur de pondération à côté de chaque sujet observé. La pondération correspond à la pondération relative d'un thème donné pour un navigateur par rapport à tous les navigateurs qui l'utilisent.	Nous aimerions mieux comprendre pourquoi la rareté d'un signal constitue le signal le plus important. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur l'utilité de ce cas d'utilisation via ce lien.
Fiabilité des sujets	Google doit fournir des garanties plus solides concernant la fiabilité de Topics au fil du temps.	Nous continuerons d'apporter des modifications à nos API en fonction des commentaires de l'écosystème. Ces modifications seront discutées publiquement avant d'être appliquées. Notre proposition de structure de gouvernance révisée fournirait des garanties supplémentaires.
Classificateur	Les sites des éditeurs sont souvent mal classés ou associés à des thèmes trop généraux pour être utiles.	Comme indiqué dans notre explication sur la classification des sujets, les sites sont classés à l'aide d'une liste de remplacement manuelle contenant les sites les plus populaires et d'un modèle de machine learning (apprentissage automatique) sur l'appareil. Chrome continue d'évaluer les options permettant aux sites de contribuer à la classification des thèmes. Toute amélioration apportée à l'utilitaire doit être évaluée au regard des risques liés à la confidentialité et aux abus. Par exemple, voici quelques-uns des risques: - les sites qui utilisent l'auto-étiquetage comme méthode pour encoder différentes significations (potentiellement sensibles) dans des sujets ; et - les sites qui attaquent des sujets afin de réduire leur utilité pour les autres (par exemple, en envoyant du spam dans les sujets de l'utilisateur avec du bruit sans signification). Le public peut inspecter ces composants, avec des outils disponibles via chrome://topics-internals ou ce colab. Grâce aux tests, nous nous attendons à ce que la classification s'améliore avec le temps. Nous vous invitons à nous faire part d'exemples de sites qui pourraient être mal catégorisés.
Question concernant l'API	Préoccupations concernant l'API Topics, qui accorde des avantages persistants et anticoncurrentiels aux SSP qui monétisent de mauvais contenus.	Comme pour les PGC, le navigateur est indépendant de l'entité à laquelle il renvoie les sujets, à condition que cette entité soit enregistrée et attestée.
(également indiqué dans les trimestres précédents) Utilité pour différents types de personnes concernées	Étant donné que le classificateur de thèmes n'utilise actuellement que le nom d'hôte de la page pour définir les thèmes correspondants, les grands sites au contenu varié contribuent à des thèmes génériques, tandis que les petits sites contribuent à des thèmes de niche plus intéressants pour la publicité.	Notre réponse est semblable à celle des trimestres précédents: Comme pour les PGC, la valeur des informations fournies par les différents sites varie. La valeur ajoutée des sites à thème spécifique est incohérente: tous les sites à thème spécifique ne disposent pas d'un contexte commercialement intéressant et ne contribuent donc pas de la même manière à la valeur. Ce sont les sites qui bénéficieront de l'API Topics. Nous avons envisagé d'effectuer une classification au niveau de la page plutôt qu'au niveau du site. Toutefois, cette classification pose un certain nombre de problèmes importants en termes de confidentialité et de sécurité.
Classificateur	Les sites de petite taille se voient souvent attribuer une classification inexacte ou aucune classification, de sorte qu'ils ne peuvent pas participer à l'échange de valeur.	En ce qui concerne les dommages présumés, les sites spécifiques potentiellement mal classés ne sont pas plus lésés que les autres, étant donné que les informations contextuelles d'un site sont toujours disponibles pour les enchères sur son site, ce qui fournirait des informations comparables à celles du bon sujet, même en cas de mauvaise classification. Les thèmes sont généralement utilisés pour collecter des informations publicitaires potentiellement utiles à partir de sites Web externes, plutôt que de leurs propres sites.
Version de la taxonomie	Comment accéder à la version de la taxonomie pour assurer la rétrocompatibilité ?	La version de la taxonomie fait partie de l'en-tête de la requête envoyée avec une requête de récupération compatible avec les sujets. Par exemple, si l'en-tête est "(1 2);v=chrome.1:2:5, ();p=P000000000", la version est chrome.1:1:2. Où chrome.1 correspond à la version de configuration, 2 à la version de la taxonomie et 5 à la version du modèle. Ceci est décrit dans la spécification et a également été ajouté à l'explication.
Données Topics	Demande de clarification sur la mise à jour des données Topics.	La mise à jour de la taxonomie n'est pas spécifiée. Cela offre aux fournisseurs de navigateurs une certaine flexibilité dans l'implémentation. Cela dit, voici les heuristiques de la mise à jour de la taxonomie de Chrome de la version 1 à la version 2: - Un seul arbre de taxonomie est géré pour les sujets des versions 1 et 2. - Le même ID de sujet représente la même signification. - L'arborescence ne fait que croître, en ajoutant de nouveaux thèmes ou des connexions, et ne diminue jamais. - Toutefois, certains sujets ou liens peuvent être "inactifs" dans une version, ce qui peut donner l'impression qu'ils ont été supprimés ou réorganisés. Exemples: - "Pickup Trucks" (Pick-up) est désormais parent intermédiaire de "Trucks, Vans & SUVs" (Camions, fourgons et SUV). - "Études en langues étrangères" a désormais "Enseignement" comme deuxième parent, et son parent d'origine "Référence" devient inactif. Impact des sujets "inactifs" : ces sujets ne seront pas utilisés pour la nouvelle classification. Toutefois, ils sont toujours pris en compte lors de l'application des blocages d'utilisateurs: si un utilisateur a bloqué un thème dans la version 1, ses enfants le resteront dans la version 2 (même si le sujet enfant apparaît sous un autre parent dans la version 2).
Classificateur	Vous souhaitez comprendre les causes et les options de correction disponibles pour les classifications erronées.	Tout d'abord, nous tenons à préciser que la détermination des thèmes d'un site par Chrome ne doit servir qu'à alimenter son algorithme Topics afin de déterminer les centres d'intérêt d'un utilisateur à des fins publicitaires. Il n'est pas développé à d'autres fins de classification plus générales. Nous nous intéressons à la justesse globale de notre modèle de classification et nous essayons d'améliorer sa précision/son rappel dans la mesure du possible, mais au niveau global plutôt qu'au niveau de la classification de chaque site. En effet, lorsqu'une mauvaise classification se produit, elle n'affecte pas le site concerné, mais réduit la qualité du signal Topics lors de la sélection d'une annonce sur d'autres sites. Lorsque vous sélectionnez des annonces sur le site mal classé, les thèmes réels du site sont déjà connus et peuvent être utilisés comme entrée pour les requêtes publicitaires. Si vous avez d'autres commentaires, cliquez ici.
Tests d'API	Les API Topics et, plus généralement, les API de la Privacy Sandbox sont-elles testables avec Chromium ?	L'API Topics n'est pas fournie avec Chromium, mais avec Chrome.
Topics Caller	Demande visant à améliorer la valeur ajoutée de Topics en exploitant les services TEE pour les technologies publicitaires afin de couvrir les coûts d'analyse avancée de manière conforme à la confidentialité.	Nous avons répondu à des commentaires similaires sur cette page. Nous avons considéré la fréquence inverse. Après avoir modélisé cette métrique, nous avons constaté qu'elle ne corrélait pas bien avec la valeur du sujet, selon la valeur fournie par les acheteurs et les vendeurs. N'hésitez pas à nous faire part de vos autres commentaires sur cette page.
Spécifications de l'API	Le paramètre de cohorte d'intérêts du navigateur peut-il bloquer l'API Topics ?	Nous avons répondu à ces commentaires sur cette page. L'API Topics est une évolution de FLoC et respecte le règlement sur les autorisations de FLoC. Comme indiqué dans l'explication : "Remarque: l'ancienne stratégie Permissions-Policy: interest-cohort=() de FLoC interdit également le calcul de thèmes."
Classement des thèmes	Lorsque nous obtenons les "5 thèmes sujets les plus populaires", devons-nous comptabiliser la fréquence des visites sur le site Web en fonction de chaque appelant éligible ou toujours en fonction de l'ensemble de l'historique des visites du navigateur ? De plus, les sujets sont-ils classés séparément pour chaque appelant ?	Elle est basée sur la fréquence d'un sous-ensemble d'historiques de navigation. Une entrée d'historique de navigation (une page) ne peut participer que si la page a au moins un appelant Topics. Pour en savoir plus sur le stockage de l'historique des thèmes, cliquez ici. Comme indiqué dans notre annonce sur les améliorations apportées à l'API Topics, le classement dépend de la fréquence, ainsi que d'un niveau de priorité binaire (pour en savoir plus, cliquez ici et ici). Toutefois, cela ne dépend pas de la fréquence des appelants. Notez que cela ne signifie pas que tous les appelants auront accès aux cinq principaux thèmes lors de la prochaine epoch. Comme indiqué dans la vidéo explicative, "Seuls les appelants ayant observé l'utilisateur visiter un site sur le thème en question au cours des trois dernières semaines peuvent recevoir ce thème". Le navigateur doit suivre les cinq premiers sujets observés par l'appelant (correspondant aux cinq premiers sujets avec les domaines de l'appelant dans la spécification). Pour nous faire part de vos commentaires supplémentaires sur ce problème, cliquez ici.

API Protected Audience (anciennement FLEDGE)

Thème des commentaires	Résumé	Réponse de Chrome
(également indiqués dans les trimestres précédents) Coûts	L'exécution de TEE dans des clouds publics est-elle plus coûteuse que dans des centres de données de technologie publicitaire sur site ?	Notre modèle de sécurité TEE actuel bénéficie des pratiques d'implémentation du cloud public (pour en savoir plus, consultez la présentation des exigences concernant les TEE dans le cloud public). Par exemple, les TEE matériels actuels ne protègent pas contre toutes les attaques physiques. Nos fournisseurs de cloud publics compatibles existants, AWS et GCP, ont conçu et implémenté des mesures d'atténuation des risques d'accès physique, y compris de la part des employés. Si certaines technologies publicitaires nous ont indiqué que l'exécution de services cloud est plus coûteuse que les centres de données de technologies publicitaires sur site, d'autres technologies publicitaires s'exécutent sur des clouds publics, que ce soit pour des raisons de coût ou d'autres avantages. Nous continuons d'évaluer les options d'extension de notre prise en charge des TEE, y compris en dehors des clouds publics. Pour ce faire, nous menons des recherches sur les centres de données sur site et nous collaborons avec l'écosystème pour explorer les solutions potentielles permettant de proposer une telle assistance. À ce stade de la recherche, nous ne pouvons pas garantir que nous trouverons une solution viable pour l'écosystème.
API PA et Google Ad Manager (GAM)	GAM ne peut pas obtenir un résultat équitable sur le marché. GAM ne diffuse pas les annonces dans les meilleurs délais, ne signale pas le nombre d'annonces diffusées à l'aide de l'API PA et ne permet pas de configurer la méthode de diffusion d'une annonce (par exemple, en désactivant l'API PA pour certains emplacements).	Réponse de Google Ad Manager: GAM s'efforce d'optimiser la latence lors de la diffusion d'annonces via l'API AP, de sorte que les revenus supplémentaires générés par la demande d'API PA compensent les coûts engendrés par la latence supplémentaire des enchères de l'API AP. Nos tests initiaux indiquent que les éditeurs bénéficient de revenus nets issus de l'API PA sur le trafic sans cookies tiers, ce qui indique que la demande supplémentaire provenant de cette API compense les coûts liés à la latence. Pour en savoir plus sur notre approche, consultez les questions fréquentes. En outre, GAM permet aux éditeurs de créer des rapports sur les annonces diffusées via l'API AP. Cela inclut les annonces diffusées lorsque GAM est un vendeur de composants, et celles diffusées via d'autres vendeurs de composants si GAM est un vendeur de premier niveau. Pour en savoir plus sur le signalement, consultez notre Centre d'aide. Enfin, GAM permet aux éditeurs d'activer ou de désactiver son utilisation de l'API PA sur leur trafic via une commande intégrée à l'interface utilisateur. Pour en savoir plus, consultez notre Centre d'aide. Nous sommes prêts à prendre en compte les commentaires concernant d'autres contrôles que les éditeurs pourraient souhaiter. Nous donnerons la priorité à toutes les demandes de fonctionnalités conformément à notre processus standard de priorisation des fonctionnalités.
API AP et GAM/AdX	Il semble que Google ait pris la position qu'il n'achètera simplement aucune impression de l'API PA pour laquelle GAM ne prend pas la décision de vente finale, tout comme AdWords n'achète que des annonces de la maison. Cela semble purement être un abus de position sur le marché, car GAM/AdX pourrait soumettre une configuration d'enchères de composants à un autre vendeur de premier niveau comme n'importe quelle autre place de marché.	Réponse du responsable de la plate-forme Google Ads: Ce n'est pas la position de Google. Les plates-formes côté acheteur de Google (Google Ads et DV360) achètent des impressions sur des places de marché autres que Google. Cela est vrai pour les impressions de l'API PA et les impressions hors API PA.
Réponse du marché	Préoccupations de Mozilla: L'API Protected Audience de Google protège davantage les annonceurs (et Google) que vous.	Nous apprécions l'évaluation de Mozilla et nous continuerons à prendre en compte ses commentaires sur les forums publics sur les normes. Le thème de cette évaluation est le fait que la mise en œuvre actuelle de l'API AP n'applique pas encore toutes les protections prévues. Notre approche de commercialisation avec l'API PA a permis de trouver le juste équilibre entre encourager l'adoption et mettre en œuvre des mesures de protection de la confidentialité dès que possible. Dans ce cadre, nous avons établi un plan d'imposition de restrictions de confidentialité au fil du temps afin de mieux faciliter les intégrations avec les API et de nous laisser le temps de recueillir plus de commentaires que nous pourrons intégrer aux futures protections (par exemple, les fonctionnalités VAST dans les cadres clôturés). Nous apprécions également les communications plus récentes de Mozilla sur sa propre approche de la confidentialité et de la publicité numérique : "Un Internet libre et ouvert ne doit pas se faire au détriment de la confidentialité" et "Améliorer la publicité en ligne grâce aux produits et à l'infrastructure".
(également indiqué dans les trimestres précédents) Résultats des enchères	Demandez à une seule mise aux enchères de renvoyer plusieurs URL de rendu avec leur score correspondant. Cela permet à la publicité native de dédupliquer plus facilement et d'éviter les problèmes d'expérience utilisateur et de latence.	Notre réponse est semblable à celle des trimestres précédents: Nous avons envisagé de partager plusieurs renderURL et leur score respectif à partir d'une même mise aux enchères de l'API PA, mais nous ne l'avons pas implémenté pour des raisons de confidentialité. Nous comprenons votre souhait d'éviter de diffuser la même annonce plusieurs fois à un utilisateur sur une même page et nous évaluons cette demande. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur l'API PA pour nous indiquer les fonctionnalités supplémentaires dont vous avez besoin pour optimiser le cas d'utilisation de la publicité native.
Performances	Préoccupations concernant la latence ayant un impact sur l'API PA	Nous avons entendu des inquiétudes concernant la latence. C'est pourquoi nous avons développé un certain nombre de fonctionnalités dans l'API PA, qui permettront aux SSP de définir des limites sur la latence des DSP et d'apporter des améliorations qui peuvent réduire la latence. Nous avons récemment mis à jour notre guide des bonnes pratiques concernant la latence, qui contient plus d'informations sur la façon de profiter de ces fonctionnalités. Nous continuons également à améliorer la latence, comme vous pouvez le voir sur cette page.
Vendeurs de premier plan	Google devrait permettre aux éditeurs de choisir d'autres vendeurs d'enchères via l'API PA de premier niveau.	L'API PA est indépendante de l'initiateur d'enchères, que la conception soit pour un seul vendeur ou pour plusieurs. Les entreprises sont libres de choisir si elles souhaitent utiliser les enchères via l'API PA et comment.
(également indiqué dans les trimestres précédents) Ciblage négatif	Demande de solution pour un cas d'utilisation où un annonceur ne souhaite pas diffuser d'annonces auprès d'une certaine audience.	Nous acceptons le ciblage par liste d'exclusion Instagram via des enchères supplémentaires (contextuelles), ce qui répond aux besoins d'un annonceur qui ne souhaite pas diffuser d'annonces auprès d'une certaine audience. Pour en savoir plus, consultez cet article explicatif et cette demande sur GitHub. Nous étudions également des solutions pour prendre en charge le ciblage par liste d'exclusion pour les enchères via l'API PA. N'hésitez pas à nous faire part de vos commentaires sur cette page.
(également indiqués pour les trimestres précédents) Publicité native	Demande de prise en charge de la fonctionnalité de frame clôturé pour la publicité native.	Nous envisageons de prendre en charge ce cas d'utilisation et discutons des solutions et des solutions de contournement possibles sur cette page.
WebView	Demander des précisions sur le scénario dans lequel IG rejoint Chrome n'était pas disponible pour les enchères exécutées sur WebView.	Nous souhaitons prendre en charge ces cas d'utilisation une fois que l'infrastructure de confidentialité sera suffisante. Nous n'avons pas d'annonces supplémentaires à faire pour le moment, mais n'hésitez pas à nous faire part de vos commentaires supplémentaires sur cette page.
IG négatifs	Demande de mise à jour du traitement des URL pour prendre en charge les IG négatifs via la fonctionnalité d'en-tête naissante.	Nous examinons cette demande et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Filtrage de la diversité	Demande de conseils sur l'implémentation du filtrage en fonction de la diversité lors de la diffusion de publicité native dans l'API AP avec plusieurs vendeurs et plusieurs enchères.	Nous traitons cette demande sur cette page. N'hésitez pas à nous faire part de vos commentaires.
(également indiqué dans les trimestres précédents) Filtres de blocage	Demande d'aide sur l'application des règles de "blocage des éditeurs" (filtres) lors de la diffusion de publicité native dans l'API AP avec multivendeur.	Vous trouverez sur cette page des conseils. N'hésitez pas à nous faire part de vos commentaires.
Restrictions	Demande d'autorisation de restrictions au niveau du domaine plutôt qu'au niveau du sous-domaine.	Les restrictions au niveau du sous-domaine ou de l'origine suivent le modèle de sécurité de base du Web. C'est donc notre conception par défaut. Nous en avons parlé plus en détail ici et ici.
Enchères de confiance	Demande d'user-agent et d'indices client associés dans les requêtes de signaux d'enchères fiables.	Nous effectuons le suivi de cette demande de fonctionnalité. N'hésitez pas à nous faire part de vos commentaires.
(également signalés au cours des trimestres précédents) Plusieurs comptes Instagram	Utilisez plusieurs IG dans la même enchère.	Cette fonctionnalité n'est pas prise en charge dans l'API PA actuellement, car cela entraînerait une modification du modèle de confidentialité sous-jacent. Pour toute discussion supplémentaire, cliquez ici.
(également indiqués dans les trimestres précédents) Performances	Transférer davantage de logique vers le client peut nuire aux performances de la page et à l'expérience utilisateur, ce qui peut avoir un impact sur les scores SEO du site Web.	Nous discutons de ce problème et nous vous invitons à nous faire part de vos commentaires sur cette page.
Mécanisme de mise aux enchères	L'API PA réduit les informations sur la dynamique des enchères (par exemple, qui participe, qui remporte chaque composant mis aux enchères, etc.), ce qui réduit la traçabilité des éditeurs et rend difficile de savoir si les accords sont respectés.	Nous avons proposé une solution pour le suivi des accords sur cette page. Nous prévoyons de modifier certains champs existants et d'en créer d'autres dans l'objet IG afin de stocker les ID de deal et de siège, et de les propager de generateBid à scoreAd ou à la sortie via les rapports au niveau des événements. Cela devrait fournir une assistance adéquate pour le cas d'utilisation de l'offre. Nous accueillons vos commentaires sur d'autres métadonnées que les technologies publicitaires considèrent comme essentielles à la dynamique des enchères et à la traçabilité pour les éditeurs. Nous encourageons les technologies publicitaires à fournir des exemples spécifiques des métadonnées auxquelles elles font référence et des parties entre lesquelles elles doivent circuler.
GAM	Inquiétudes concernant l'obligation d'utiliser GAM en tant qu'ad server de l'éditeur pour accéder à la demande AdX	Réponse fournie par Google Ad Manager: GAM n'exige pas que les éditeurs utilisent la fonctionnalité de son ad server pour accéder à la fonctionnalité d'échange.
(Également disponible au cours des trimestres précédents) Enchères par composants	Les gagnants des enchères pour les composants d'API PA seront visibles par les GAM, ce qui suscite des inquiétudes concernant l'accès inégal aux informations.	Notre réponse reste inchangée par rapport aux trimestres précédents: Réponse fournie par Google Ad Manager: "Nous accordons depuis des années une attention toute particulière à l'équité des enchères, y compris en nous assurant qu'aucun prix d'une source publicitaire non garantie d'un éditeur, y compris les prix des éléments de campagne non garantis, n'est partagé avec un autre acheteur avant qu'il ne définisse son enchère. Nous avons ensuite réaffirmé cette promesse dans nos engagements auprès de l'Autorité de la concurrence française. Pour les enchères via l'API PA, nous avons l'intention de tenir notre promesse et de ne pas partager l'enchère d'un participant aux enchères avec un autre participant aux enchères avant la fin des enchères dans les enchères multi-vendeurs. Pour être clair, nous ne partagerons pas le prix de l'enchère contextuelle avec une enchère de composant, y compris la nôtre, comme expliqué dans cette mise à jour. De plus, nous n'utilisons pas les informations sur les configurations d'enchères de composants, y compris les signaux fournis par les acheteurs aux SSP, dans le cadre de nos propres enchères. Nous serions ravis de voir des modifications apportées à l'API PA permettant aux vendeurs de composants de spécifier leurs configurations d'enchères de composants de manière à les masquer du vendeur de premier niveau."
GAM	GAM demandera-t-il un partage des revenus pour la diffusion d'enchères de premier niveau ou la création de rapports sur celles-ci si GAM n'a pas participé à la création des enchères des composants de l'API Google Ads ou des groupes intégrés ?	Réponse fournie par Google Ad Manager: Lorsque les éditeurs choisissent d'utiliser GAM comme ad server, GAM exécute les enchères de premier niveau et facture des frais de diffusion d'annonces pour ses fonctionnalités d'ad server (les mêmes frais de diffusion d'annonces qui s'appliquent en dehors des enchères de l'API PA). Toutefois, si l'annonce gagnante provient d'un vendeur de composants autre que GAM (c'est-à-dire que GAM n'a pas participé à la création des enchères de composants IG ou de l'API PA), GAM ne gère pas la facturation et ne facture pas de frais médias.
Cliquabilité	L'enregistrement des événements de clic est-il soumis à la même confidentialité différentielle ?	Pour le moment, cette fonctionnalité ne devrait pas être soumise aux restrictions "k-anon", car le nombre de clics ne sera disponible qu'en tant que browserSignal dans la fonction `generateBid()`. Il ne sera pas disponible en tant que nouvel attribut dans les rapports au niveau des événements.
Performances	Coûts de sortie élevés en raison d'une réponse inconditionnelle aux demandes d'enchères contextuelles.	Pour des raisons de confidentialité, nous ne pouvons pas vous indiquer directement les DSP qui disposent d'ID de gestion. Nous étudions cependant d'autres solutions qui pourraient fournir des insights tout en préservant la confidentialité.
Annonces natives et OutStream	Demande d'informations sur la position de Chrome concernant les annonces natives et outstream.	La position de Chrome dépend du cas d'utilisation en question. En ce qui concerne la vidéo, Chrome considère qu'il est de son devoir d'encourager l'écosystème à converger vers des solutions vidéo InStream viables à l'aide de ses API. À ce jour, la seule proposition concrète dont nous avons connaissance est la proposition de GAM. En ce qui concerne les annonces natives, nous collectons activement des commentaires ici et prévoyons de proposer bientôt plus d'étapes de découverte aux technologies publicitaires.
Surveillance en temps réel (RTM)	Le trafic étiqueté n'envoie pas de rapports RTM.	Nous sommes conscients de cette lacune et nous mettons tout en œuvre pour y remédier. Nous vous tiendrons informé de l'avancement de ce projet sur cette page.
Prise en charge de l'extension d'audience	Demande d'informations sur la compatibilité des audiences d'extension d'audience/sélectionnées par le vendeur dans l'API AP.	Nous travaillons à la résolution de ce cas d'utilisation. Nous recueillons les commentaires de l'écosystème sur ce que nous devrions créer et prendre en charge. Nous vous tiendrons informé lorsque cette fonctionnalité sera disponible. N'hésitez pas à nous envoyer vos commentaires sur cette page.
Débogage	Dans l'outil pour les développeurs de Chrome, il n'existe aucun panneau permettant de surveiller les performances détaillées de l'API PA. Par exemple, les performances globales peuvent être affectées par le nombre d'IG ou d'acheteurs.	Bien que ces commentaires portent sur les fonctionnalités de surveillance de l'interface utilisateur des outils pour les développeurs Chrome, le 7 octobre, nous avons lancé la possibilité pour les technologies publicitaires de configurer des événements personnalisés pouvant servir de base pour la surveillance et les alertes. Pour en savoir plus, cliquez ici. Nous espérons que cette mise à jour répondra à une partie importante de ces commentaires. N'hésitez pas à nous faire part de vos commentaires sur cette fonctionnalité, qu'ils concernent les points de données compatibles ou l'expérience des développeurs, dans la discussion GitHub correspondante ici.
Signaux	Questions concernant la possibilité ou non pour les DSP de s'assurer que les perBuyerSignals sont envoyés aux SSP indépendamment des résultats des enchères contextuelles.	La mise aux enchères contextuelles est supposée ne disposer que d'une seule enchère gagnante d'une seule DSP, ou mieux, pour tenter de la battre lors d'une mise aux enchères ultérieure de l'API pour les annonces personnalisées. Pour le flux de l'API PA, le SSP décide d'inviter toutes les DSP qu'il souhaite voir pour savoir si elles ont une demande (sous la forme d'une IG sur l'appareil) à envoyer. Il est tout à fait possible, et même très probable, qu'une DSP ayant perdu l'enchère contextuelle soit "re-invitée" à participer à l'enchère de l'API PA. Dans cette "nouvelle invitation", la DSP, si elle décide de l'accepter, transmettra au SSP tous les signaux que l'outil de validation des annonces souhaite s'assurer que la DSP prend en compte, le cas échéant pour cette campagne. En d'autres termes, dans l'enchère de l'API PA, la DSP peut toujours envoyer des perBuyerSignals au SSP, quel que soit ce qui s'est passé dans l'enchère contextuelle.
Signaux	Requête d'ajout de prevClicks à l'objet browserSignals transmise à `generatedBid()`.	Cette demande peut être résolue grâce à notre proposition d'accepter les signaux de clics. Nous avons annoncé cette fonctionnalité dans notre article de blog récent et dans la vidéo explicative correspondante. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur cette proposition sur cette page.
(également indiqués dans les trimestres précédents) Signaux de modélisation	Demande d'augmentation du nombre de bits des signaux de modélisation de 12 bits à 30 bits.	Nous avons répondu à ces commentaires en vous proposant une contre-proposition ici. Nous échangeons activement avec les acteurs du secteur pour connaître leur point de vue sur notre proposition. Nous évaluons actuellement les avantages pour le secteur par rapport à l'impact sur les utilisateurs de Chrome et les autres personnes concernées.
Documentation	Demande d'aide pour utiliser les serveurs clé-valeur (K/V) et les TEE.	Pour obtenir des conseils sur l'utilisation des TEE dans le contexte des clés-valeurs, consultez les détails de la conception du modèle de confiance de service de clés-valeurs.
Durée de vie des IG négatifs	Demande d'extension de la durée de vie des IG négatifs à 365 jours.	Les IG négatifs sont utilisés pour empêcher la diffusion d'annonces, mais les acteurs malveillants peuvent toujours les utiliser pour révéler des informations sur les utilisateurs, ce qui entraîne des risques de réidentification (par exemple, les acteurs malveillants peuvent simplement placer des enchères élevées avec des IG négatifs à plusieurs reprises pour savoir si un utilisateur a visité ou non certains sites). Si nous maintenons une valeur TTL de 365 jours, les acteurs malintentionnés disposeront de beaucoup plus de données sur les IG négatifs, ce qui entraînera des risques de confidentialité nettement plus importants. Par conséquent, nous ne pouvons pas donner suite à cette demande afin de protéger la confidentialité des utilisateurs.
Spécifications de l'API	Quelles valeurs peuvent être insérées pour être transmises dans perBuyerSignals ? Le vendeur peut-il définir ce montant de manière arbitraire ?	perBuyerSignals permet aux vendeurs de fournir aux acheteurs toutes les informations qu'ils souhaitent mettre à leur disposition lors des enchères. C'est à l'écosystème de décider de ce qu'il souhaite y insérer, mais nous sommes à l'écoute de toute discussion supplémentaire sur cette page.
Remplacements de macro de taille d'annonce	Je recherche des conseils sur les remplacements de macro de taille d'annonce qui ne fonctionnent pas.	Nous vous communiquerons plus d'informations prochainement.
Remplacement de la macro SSP post-enchère: usurpation de l'URL de niveau supérieur	Quels mécanismes Chrome peut-il mettre en place pour permettre aux fournisseurs de validation de valider l'URL de niveau supérieur dans le framework Privacy Sandbox ? Existe-t-il d'autres points de données ou signaux qui peuvent être utilisés dans les frames cloisonnés pour garantir l'exactitude de l'URL de premier niveau fournie par la SSP ?	Nous examinons actuellement ces commentaires supplémentaires sur cette page.
Demande de fonctionnalité	Demande de fournir une UACH à faible entropie lors des récupérations updateURL et des postbacks de rapports en temps réel.	Ces demandes sont en cours d'examen sur cette page. Nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page et cette page.
Demande de fonctionnalité	Demande d'activation de la conception de débogage consentie par le serveur de confiance lorsqu'un client donné a été déclenché pour envoyer des rapports au niveau des événements pourDebuggingOnly échantillonnés via `forDebuggingOnly.reportAdAuctionWin()` et `forDebuggingOnly.reportAdAuctionLoss()`.	Nous suivons actuellement cette demande active et nous mettrons à jour l'écosystème lorsqu'il sera disponible. Si vous avez d'autres commentaires, cliquez ici.
Utilisation de l'API	Demande d'aide sur la comptabilisation de la couverture d'utilisateurs uniques et de la couverture par impressions.	Nous étudions une proposition visant à vous expliquer comment lire les IG à partir d'un worklet de stockage partagé, sur lequel vous pourrez ensuite envoyer des rapports agrégés privés. Pour en savoir plus, cliquez ici. Nous attendons vos commentaires sur la proposition et son utilité pour l'écosystème.
Utilisation de l'API	Manque de clarté sur ce que les éditeurs doivent tester, quelles API sont importantes, lesquelles doivent être activées et ce qui va suivre.	Nous mettons tout en œuvre pour mieux soutenir les éditeurs et leur rôle dans l'écosystème.
Utilisation de l'API	Est-il possible d'ajouter des écouteurs d'événements aux événements du worklet d'enchères publicitaires ?	Cela n'est pas possible via les événements normaux, mais les événements du protocole Chrome DevTools répondront partiellement à ce cas d'utilisation. Notez que les événements réguliers sont susceptibles d'avoir un impact sur les propriétés d'isolation/de confidentialité. Pour en savoir plus, cliquez ici.
K-anonymat	Demande de clarification sur les exigences de rendu des annonces (par exemple, au moins 50 personnes auraient vu l'annonce si elle avait été autorisée à être diffusée).	La documentation pour les développeurs fournit un aperçu de nos attentes concernant les futurs développements. Il explique en particulier que le seuil initial de k-anonymat est k=10 personnes. La liste de diffusion blink-dev fournit des informations sur ce qui se passe en direct dans Chrome. Comme indiqué dans le fil de discussion de la liste de diffusion sur l'anonymat k, nous appliquons actuellement de manière expérimentale l'exigence d'anonymat k à environ 1% du trafic stable de Chrome, et jamais aux segments explicitement libellés ("Mode A" et "Mode B").
Frottement	Le masquage de données K/V TEE peut-il être temporairement supprimé ou réduit de l'obligation d'appeler tous les N fragments à une quantité qui équilibre la protection de la confidentialité avec l'utilité (c'est-à-dire, (performances/coûts K/V) ?	Ces types de requêtes ne sont traitées que pour les instances hors production où le frottement peut être contrôlé. Pour les instances de production, le masquage est toujours requis. Nous pourrons évaluer la situation une fois que nous aurons reçu des commentaires sur l'utilisation non productive.
Frottement	Demande d'ajout d'un indicateur pour désactiver le masquage du binaire K/V de débogage/non-production.	Cet indicateur est fourni avec la version 1.0.0.
Bug de l'API	L'API a cessé de fonctionner après la mise à niveau vers Chrome 126, même si elle était activée dans les paramètres.	Ce problème était lié à l'indicateur Chrome "enable-fenced-frames", qui était activé par les utilisateurs à des fins de développement. Réinitialiser cette option sur la valeur par défaut résout le problème.
Rapports	Requête d'activation de l'API de création de rapports en temps réel non dépendante du vendeur pour les acheteurs.	Cette demande est en cours d'examen ici. La solution RTM a été lancée récemment. Nous attendons avec impatience les commentaires des technologies publicitaires qui ont déjà adopté cette fonctionnalité.
Rapports	Demande de rapports tiers : alors que les DSP et les SSP reçoivent des notifications d'impression de la part de Chrome, les fournisseurs techniques de couche intermédiaire ne le font pas par défaut.	Nous examinons cette demande et n'hésitez pas à nous faire part de vos commentaires.

Services d'enchères protégés

Thème des commentaires	Résumé	Réponse de Chrome
TEEs	L'exigence de Google d'une intégration manuelle conformément aux normes techniques limite fortement le choix du fournisseur de services cloud. Les normes techniques appliquées peuvent être respectées sans avoir à se rendre au Bureau of Cloud Providers, comme Google semble le penser. Le retard tardif des fournisseurs alternatifs en 2025 (plus tôt) n'est pas acceptable, car il introduira des effets de réseau encourageant les pourboires aux solutions de Google.	Le service d'agrégation est le seul service requis pour s'exécuter dans un service TEE afin de répondre à certains cas d'utilisation des technologies publicitaires. Le service d'agrégation est compatible avec Amazon Web Services (AWS) et Google Cloud Platform (GCP). D'après les commentaires des technologies publicitaires, nous pensons que cette assistance est adéquate à ce stade. Au sujet des autres fournisseurs de cloud : Google a publié des critères détaillés pour les TEE sur les fournisseurs de cloud publics. Ils visent à s'assurer que la solution TEE répond aux objectifs de confidentialité et de sécurité de la Privacy Sandbox. Plus précisément, les serveurs TEE de la Privacy Sandbox traitent les données utilisateur intersites non chiffrées (par exemple, les données des sites de l'éditeur et de l'annonceur pour le service d'agrégation). Ils doivent être sécurisés pour répondre aux objectifs de confidentialité des utilisateurs des API. Un environnement sécurisé est également nécessaire pour s'assurer que les API continuent à protéger les informations commerciales confidentielles des entreprises (par exemple, en empêchant les autres participants aux enchères des API AP d'accéder aux données d'entreprise propriétaires d'un acheteur). À notre connaissance, il n'existe actuellement aucune technologie TEE qui protège entièrement les données utilisateur contre un opérateur potentiellement malveillant. Par conséquent, nous incluons plusieurs exigences pour valider la fiabilité du fournisseur cloud. Nous ne savons pas à quoi fait référence le "Bureau des fournisseurs de services cloud", et il ne fait pas partie des exigences. N'hésitez pas à nous faire part de vos commentaires sur les exigences. Nous continuons à évaluer la prise en charge de nouveaux fournisseurs, y compris sur la base des demandes envoyées à l'aide de la procédure définie dans l'explication. Jusqu'à présent, nous n'avons reçu qu'une seule demande de prise en charge d'Azure, que nous évaluons.
B&A	Il est difficile d'évaluer la complexité technique et la faisabilité du service d'enchères et de mise aux enchères, car la conception continue d'évoluer.	Pour répondre à ces préoccupations, nous avons fourni des explications détaillées sur GitHub expliquant la conception des enchères et des mises aux enchères, publié des calendriers de disponibilité et un plan d'action des fonctionnalités compatibles avec l'API PA. Nous aidons les technologies publicitaires qui souhaitent déployer des enchères en temps réel et recueillons les commentaires de l'écosystème sur GitHub.
B&A	Je recherche des conseils et un meilleur moyen de calculer le coût de l'utilisation du TEE pour les échanges et les achats afin de commencer à l'utiliser ou de passer à son utilisation sur l'appareil.	Nous avons récemment publié le guide de dimensionnement des instances de serveur K/V, qui comprend des outils permettant de mesurer plus précisément les coûts.
Serveur K/V	L'outil de vérification de l'annonce demande l'autorisation d'utiliser l'URL complète sur le serveur de mots clés pour effectuer la validation des annonces.	Nous évaluons actuellement la possibilité de fournir l'URL complète au serveur K/V exécuté dans un TEE à des fins de vérification des annonces. L'URL complète de la page ne sera pas disponible dans BYOS K/V.
Sécurité des enchères	Vous recherchez des fonctionnalités de sécurité des enchères pour vous assurer que les acteurs malveillants n'accèdent pas à des données sensibles ni n'agissent en tant qu'imposteurs. Quelles fonctionnalités protègent les enchères contre les attaques par rejeu ? Comment mettre en place des mesures de sécurité ?	Le modèle de sécurité actuel de B&A peut protéger l'intégrité des enchères. Les enchères et les mises aux enchères s'exécutent dans un TEE qui protège la confidentialité des signaux et du code des technologies publicitaires contre les acteurs malveillants. Dans l'architecture des enchères et mises aux enchères, une charge utile de requête d'enchères et mises aux enchères chiffrée (chiffrement de la requête) circule du client via un serveur publicitaire non approuvé au service SellerFrontEnd (SFE, exécuté par les SSP dans un TEE). Le texte chiffré de la requête contient un ID de génération basé sur le code temporel. Le SFE examine l'horodatage de la requête et rejette toute requête rejouée qui ne se situe pas dans un intervalle de +/- n secondes par rapport à l'heure du serveur. En outre, les enchères et mises aux enchères peuvent renvoyer une charge utile de réponse de taille fixe avec remplissage pour la communication entre serveurs. Ces solutions peuvent aider à atténuer les attaques par rejeu via le système lorsqu'un acteur malveillant tente de rejeuyer la même charge utile de requête pour en savoir plus sur son contenu. B&A est en train de documenter et de mettre à jour les modèles de sécurité dans les explications.
Signaux via le serveur K/V	Demande d'inclusion des perBuyerSignals envoyés via le service K/V dans la requête de signaux d'enchères fiables de Chrome.	Nous évaluons la possibilité d'inclure des informations provenant de perBuyerSignals, transférées vers un serveur K/V exécuté dans un TEE incluant une URL complète.
Serveur K/V	Demander un calendrier d'adoption plus échelonné pour les contraintes de confidentialité dans les CV et les enchères et mises aux enchères.	Nous comprenons que vous souhaitiez adopter une approche plus échelonnée concernant l'adoption de TKV. Nous vous remercions pour vos demandes spécifiques concernant les clé-valeurs et les enchères et mises aux enchères. Cependant, après un examen approfondi, nous avons décidé de ne pas assouplir les mesures de protection de la confidentialité dans ces API pour le moment. Nous pensons que ces mesures, comme le masquage, sont essentielles pour protéger la confidentialité des utilisateurs et maintenir la confiance dans la Privacy Sandbox.
Serveur K/V	Je recherche des conseils pour mettre à l'échelle le magasin de clés-valeurs via une configuration compatible.	Le guide de dimensionnement des instances de serveur K/V récemment publié peut vous aider. L'outil fournit le débit de requêtes par seconde (noté "RPS" dans la présentation) pour chaque combinaison de paramètres.
Serveur K/V	Ajoutez des informations sur le vendeur dans la requête du serveur de clés-valeurs.	Nous en discutons et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
K/V + Services d'enchères et de mise aux enchères	Demande de clarification du calendrier de sortie ou de la feuille de route pour les clés-valeurs et les enchères et mises aux enchères.	Pour les enchères au second prix et les enchères au premier prix, nous avons des étapes et des calendriers: Pour le serveur K/V associé aux enchères de l'API PA sur l'appareil (par opposition aux enchères au premier prix), le calendrier public est disponible ici. Pour savoir comment la "disponibilité générale" est définie pour les clés-valeurs, consultez la section "Plan de route", qui définit l'ensemble de fonctionnalités pour les versions bêta et disponibles généralement. Pour les questions et réponses, consultez le calendrier public ici et le plan de route ici. Nous définissons les tests à grande échelle comme des tests "entièrement stables, à grande échelle de production". Cliquez ici pour connaître l'ensemble de fonctionnalités spécifique à ce stade. Le test A/B comprend également les phases alpha et bêta. Le test à grande échelle inclura donc l'ensemble des fonctionnalités des phases précédentes. Pour les CV et les enchères et mises aux enchères, indiquez-nous si ces définitions des étapes aident à clarifier les informations qui seront disponibles et à quel moment. Si des lacunes subsistent, veuillez nous en informer. Nous serons ravis de les préciser pour vous aider à planifier.

Mesurer les annonces numériques

Attribution Reporting (et autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Réponse du marché	L'obligation pour les systèmes d'attribution concurrents de n'utiliser que des rapports au niveau des événements et des rapports récapitulatifs/agrégés dans des limites strictes constitue une restriction arbitraire de la concurrence. Il empêche le retargeting et l'attribution spécifiques à l'appareil en temps réel au niveau de l'événement, même si des mesures de protection sont en place pour garantir la conformité avec la protection des données (par exemple, la dépersonnalisation).	La conception mentionnée est basée sur les objectifs de confidentialité de l'API (par exemple, la protection des informations intersites transmises d'un site à un autre). Par exemple, ARA accepte l'attribution au niveau des événements via les rapports sur les événements. Les rapports sur les événements sont différés d'au moins une heure. Il est donc difficile d'associer le rapport au niveau des événements à l'identité de l'utilisateur sur le site de l'annonceur, à l'aide d'attaques par canal latéral temporel, comme indiqué ici. En outre, il existe d'autres méthodes d'attribution que l'ARA, comme la collecte directe d'informations auprès des utilisateurs qui fournissent sciemment des données d'identification. Nous sommes à l'écoute de vos commentaires sur les cas d'utilisation qui ne peuvent pas être réalisés avec les limites de confidentialité actuelles des API Privacy Sandbox.
Multisurfaces	Demande de confirmation pour savoir si les API ARA et Shared Storage sont compatibles avec les cas d'utilisation multisurface et où cela est attesté.	Actuellement, ARA et le stockage partagé ne sont pas compatibles avec l'attribution multisurface (entre les appareils). L'attribution entre applications et Web sur le même appareil (via ARA) est compatible.
(également indiqué dans les trimestres précédents) Multi-appareil	L'ARA est-il compatible avec les conversions multi-appareils ?	Notre réponse est semblable à celle des trimestres précédents: La multi-plateforme présente de nouveaux défis en matière de confidentialité en plus des cookies tiers, et pose également des défis de distribution de la technologie en raison de la variété d'appareils et de plates-formes qu'un utilisateur peut utiliser. Nous étudions des solutions potentielles, mais nous nous concentrons sur les cas d'utilisation critiques actuellement pris en charge par ARA. Nous n'avons pas encore de calendrier pour la prise en charge multiappareil.
Scaling	On se demande si l'API Attribution Report (ARA) est actuellement configurée et si elle peut être déployée et adaptée de manière fiable à tous les utilisateurs de Chrome.	ARA est actuellement disponible pour tous les utilisateurs de Chrome et fonctionne comme prévu. Nous continuons également de tester et de surveiller sa fiabilité et son évolutivité, car le nombre d'entreprises du secteur de l'ad tech qui testent ARA ne cesse d'augmenter. N'hésitez pas à nous faire part de vos commentaires sur l'écosystème à ce sujet via ce lien.
(Également indiqué au cours des trimestres précédents) Déduplication	Inquiétudes concernant la façon dont l'ARA propose de limiter le mécanisme d'attribution sur les appareils, de sorte que les éditeurs ne puissent pas exécuter efficacement la logique post-attribution pour les rapports récapitulatifs, y compris la déduplication de plusieurs conversions de même type pour un même clic sur une annonce.	Notre réponse n'a pas changé par rapport aux trimestres précédents: La déduplication entre les appareils et les pipelines de mesure est un défi connu et actuel auquel les technologies publicitaires sont confrontées aujourd'hui avec les cookies tiers. Avec l'ARA, les technologies publicitaires peuvent décider quand enregistrer des conversions spécifiques et ajouter des métadonnées spécifiques pour indiquer les pipelines de mesure qu'elles ont utilisés pour suivre les conversions (c'est-à-dire une partie de la clé d'agrégation), qui peuvent être comparés à d'autres pipelines de mesure. N'hésitez pas à nous faire part de vos commentaires sur l'écosystème à ce sujet via ce lien.
Suivi des conversions	Demande de possibilité de travailler avec des conversions provenant de plusieurs domaines.	Nous discutons de cette demande ici et nous accueillons les commentaires supplémentaires de l'écosystème.
Rapports	Le navigateur attend au moins deux jours, mais jusqu'à 30 jours avant d'envoyer la conversion, ce qui peut être préoccupant, étant donné que la majorité des annonceurs partenaires sont des annonceurs axés sur les performances, qui travaillent en temps quasi réel.	Les périodes de reporting par défaut pour les rapports au niveau des événements sont les suivantes: 2 jours, 7 jours et 30 jours. Avec les rapports flexibles au niveau des événements, les technologies publicitaires peuvent modifier le nombre et la durée des périodes de référence par rapport aux valeurs par défaut. Vous pouvez modifier les périodes de reporting pour qu'elles soient d'une heure minimum. Cela peut être utile pour les annonceurs axés sur les performances. N'hésitez pas à nous faire part de vos commentaires sur l'écosystème à ce sujet via ce lien.
Attribution en ligne-hors connexion	Existe-t-il des options d'implémentation de la publicité en ligne et hors connexion dans ARA, ou d'autres suggestions pour mesurer l'attribution hors connexion à la publicité en ligne ?	Il n'est actuellement pas prévu de prendre en charge les cas d'utilisation des mesures en ligne et hors connexion dans ARA. Ce type d'assistance implique des défis importants en termes de confidentialité et de sécurité. N'hésitez pas à nous faire part de vos commentaires sur les cas d'utilisation de cette fonctionnalité via ce formulaire.
Création de rapports de débogage	Comment stocker et/ou récupérer l'identifiant publicitaire de manière à ce qu'il soit accessible pour les enregistrements Chrome (source/déclencheur) pour l'attribution application/Web ?	Pour activer les rapports de débogage, la technologie publicitaire doit nous prouver qu'elle peut déjà rejoindre l'utilisateur sur l'application et le Web. Cela permet de s'assurer qu'aucune nouvelle information n'est révélée par les rapports de débogage. La technologie publicitaire peut prouver la jointure en fournissant une clé de jointure unique pour chaque utilisateur. Il peut s'agir de l'identifiant publicitaire ou d'une clé de jointure propriétaire. Si la technologie publicitaire utilise l'identifiant publicitaire, Chrome ne permet pas d'accéder de manière native à l'identifiant publicitaire à partir du navigateur. L'API s'attend à ce que chaque technologie publicitaire dispose de sa propre méthode pour transmettre l'identifiant publicitaire lors de l'enregistrement Web.
Précision des buckets	Est-il possible d'utiliser différentes stratégies de compartiment pour chaque annonceur ?	Nous vous recommandons de tester différentes approches d'ajustement du budget de contribution pour trouver celle qui convient le mieux à vos cas d'utilisation. L'ARA a été conçue dans l'intention d'être flexible et personnalisable pour répondre à divers cas d'utilisation de la technologie publicitaire. Nous vous recommandons donc de tester différentes stratégies de regroupement par annonceur ou par secteur. L'utilisation de différentes stratégies de regroupement peut être utile lorsque les annonceurs ont des valeurs de mesure différentes qu'ils souhaitent suivre et que le volume de ces valeurs est différent.
Documentation	Demande de documentation supplémentaire pour l'implémentation de l'appli<>Web pour ARA.	Nous avons publié de la documentation sur App<>Web pour ARA ici.
Performances	Le nombre de requêtes liées à l'ARA peut représenter une charge importante pour les serveurs d'un éditeur par rapport au nombre de requêtes keepalive nécessaires pour alimenter ledit site. Regrouper des événements sources dans une seule requête peut aider à réduire la charge sur un serveur. Une idée possible consiste à autoriser un tableau d'objets encodés en JSON.	Il est, dans une certaine mesure, possible de regrouper les événements sources en fonction d'une logique spécifique en utilisant la logique JavaScript en combinaison avec l'API. Nous examinons actuellement cette demande et nous invitons les membres de l'écosystème à nous envoyer leurs commentaires sur cette page.
Demande de fonctionnalité	Suggestion de solution de contournement en raison de l'absence de prise en charge de l'intégration de serveur à serveur.	Pour le moment, nous ne prévoyons pas d'implémenter la prise en charge de l'intégration de serveur à serveur dans ARA. De nombreux défis liés à la confidentialité doivent être pris en compte pour permettre l'intégration de serveur à serveur. Les commentaires de l'écosystème concernant d'autres cas d'utilisation de la prise en charge de serveur à serveur sont les bienvenus sur cette page.
Documentation	Demande d'un guide de démarrage rapide expliquant les principaux éléments d'ARA et comment se lancer avec quelques cas d'utilisation simples.	Pour obtenir un guide de démarrage rapide d'ARA, cliquez ici. Nous nous efforçons d'améliorer cette documentation cette année. Cliquez ici pour nous faire part de vos commentaires concernant des cas d'utilisation ou des scénarios spécifiques qui nécessitent des documents supplémentaires.
Utilisation de l'API	Demande de recommandations sur la mise à l'échelle des contributions pour de nombreuses petites valeurs.	Nous vous recommandons de tester différentes approches d'ajustement du budget de contribution pour trouver celle qui convient le mieux à vos cas d'utilisation. Dans le cas de nombreuses petites valeurs, nous vous recommandons de tester différentes valeurs d'épsilon pour identifier les points d'inflexion à partir desquels le bruit d'épsilon peut être acceptable pour votre cas d'utilisation. Pour en savoir plus, consultez notre article de recherche sur l'optimisation des rapports récapitulatifs dans ARA .
Configuration flexible au niveau des événements	Quand la configuration flexible au niveau des événements (plusieurs spécifications de déclencheur) sera-t-elle implémentée ?	Actuellement, la flexibilité au niveau des événements permet de personnaliser les aspects de configuration d'enregistrement suivants: le nombre de rapports pouvant être générés par source, le nombre et la durée des périodes de référence, ainsi que la cardinalité des données de déclencheur. Nous recueillons actuellement des commentaires supplémentaires de l'écosystème concernant d'autres améliorations flexibles au niveau des événements, mais nous ne prévoyons pas d'en implémenter pour le moment. Nous vous invitons à nous faire part de vos commentaires supplémentaires sur les cas d'utilisation qui pourraient bénéficier de certaines des améliorations flexibles au niveau des événements listées ici.
Traitement des buckets	Demande d'envisager de plafonner les contributions agrégées pour les buckets, ainsi que la future évolutivité et la rétrocompatibilité.	Nous examinons votre demande et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Epsilon	Que se passe-t-il avec la plage d'épsilon une fois que l'ARA passe en disponibilité générale ?	L'ARA est en disponibilité générale sur Chrome au troisième trimestre 2023. Pour le moment, nous n'avons pas l'intention de modifier la période de la valeur epsilon. Notre proposition de structure de gouvernance révisée fournirait des garanties supplémentaires en cas de modification.
Rapports	Les rapports "Trigger-unknown-error" ne contiennent pas d'attributs source dans le corps du rapport.	Comme indiqué dans les spécifications, aucun autre champ n'est obligatoire dans le corps du rapport pour trigger-unknown-error. Nous reconnaissons que le tableau décrivant les champs du corps du rapport était potentiellement trompeur, car les champs liés à la source peuvent être présents ou non, en fonction de la cause sous-jacente de l'erreur. Par exemple, une erreur interne peut se produire avant que la logique de correspondance des sources ne se produise, ce qui signifie qu'aucune donnée source ne peut être insérée dans le rapport de débogage. La documentation a été mise à jour pour clarifier ce point.
Utilisation de l'API	Lorsque vous travaillez avec deux objectifs de mesure, le nombre et la valeur, devez-vous diviser le budget de contribution et l'épsilon ?	Lorsque vous utilisez deux objectifs de mesure, nous vous recommandons de répartir le budget de contribution entre eux.
Rapports	L'ARA est-il compatible avec l'attribution multipoint ou les rapports d'assistance (également appelés rapports de contribution) ?	Pour le moment, l'ARA n'est pas compatible avec les rapports sur l'attribution multitouch ou sur les clics/impressions indirects. Pour le moment, nous n'avons pas l'intention de le faire. N'hésitez pas à nous envoyer d'autres commentaires sur les cas d'utilisation et leur priorité via ce lien.
Bug de l'API	Pour l'ARA, la documentation indique que XOR est utilisé pour combiner les pièces clés d'agrégation de la source et du déclencheur, mais dans la pratique, l'opérateur OU est utilisé. Cette divergence entraîne de la confusion et des erreurs potentielles lors de la mise en œuvre.	La documentation a été mise à jour pour indiquer qu'il s'agit d'une erreur.

Service d'agrégation

Thème des commentaires	Résumé	Réponse de Chrome
Jobs d'agrégation	Demande d'autorisation de plusieurs préfixes dans les tâches d'agrégation.	Nous examinons ces commentaires et avons publié une proposition sur cette page. N'hésitez pas à nous faire part de vos commentaires sur cette proposition via ce lien.
Demande de fonctionnalité	Demande de modification du script Terraform afin que, si service_account_token_creator_list n'est pas défini (ou est vide), la modification de la stratégie IAM du compte est ignorée.	Nous étudions ce problème ici et nous sommes à l'écoute de vos commentaires sur l'écosystème.
Utilisation de l'API	Clarification concernant le plan Terraform qui affiche toujours les modifications.	Ce problème a été résolu dans la version 2.8 d'AgS.
Utilisation de l'API	Obtenir des recommandations sur la configuration des paramètres par annonceur pour la fréquence d'agrégation avec un filtrage flexible des contributions	Le regroupement par annonceur est actuellement possible avec l'ARA. Le filtrage flexible des contributions peut être utilisé dans des cas plus avancés, lorsqu'une technologie publicitaire souhaite segmenter davantage les contributions d'un rapport en fonction de différentes fréquences. Pour en savoir plus sur le traitement par lot, cliquez ici. Pour découvrir comment utiliser les ID de filtrage avec l'API Attribution Reporting API (ARA), cliquez ici. Nous travaillons également à la rédaction d'une documentation supplémentaire sur le filtrage des ID.
Demande de fonctionnalité	Demander la prise en charge de "log_sum_exp" dans le service d'agrégation (AgS)	Nous avons contacté cette personne pour en savoir plus sur le cas d'utilisation. Nous vous tiendrons informé dès que nous aurons plus d'informations.
Demande de fonctionnalité	Demande de voir plus de journaux, d'insights et d'autres métriques chaque fois qu'il y a des problèmes sur AgS et des problèmes potentiels sur un AgS déployé.	Nous avons mis à jour notre documentation pour inclure davantage d'erreurs, de mesures d'atténuation et de descriptions. Cliquez ici pour en savoir plus. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur les erreurs, métriques, journaux, etc. qui ne sont pas documentés ou disponibles, et sur les informations qui vous seraient utiles ici.
Test de l'API	Quelle sera la valeur finale d'épsilon après la période de test ?	Pour le moment, il n'est pas prévu de modifier la fenêtre de valeur epsilon. Nous encourageons les testeurs à tester différents paramètres et à nous faire part de leurs commentaires.
Rapports	Le rapport est généré, mais le code de retour indique toujours PRIVACY_BUDGET_AUTHORIZATION_ERROR.	Pour éviter cette erreur, nous vous avons fourni des conseils sur la manière de spécifier l'origine des rapports et les rapports agrégables. Nous vous invitons à nous faire part de vos commentaires supplémentaires sur le problème, en particulier en cas d'erreurs récurrentes.
Découverte de clés	Quels sont les plans pour la proposition de découverte de clés ?	Nous n'avons pas encore défini de calendrier pour le déploiement de la proposition clé de découverte, mais nous sollicitons des commentaires de la part de l'écosystème sur cette page.
Personnalisation	Recherche des options de personnalisation disponibles pour le service d'agrégation.	Les personnalisations du service d'agrégation ne sont pas possibles dans le TEE, mais elles le sont pour certains composants en dehors du TEE. Cela est dû aux normes de confidentialité et de sécurité que nous devons respecter dans le TEE. Nous mettons à jour notre documentation pour aider les technologies publicitaires à comprendre l'architecture et les composants personnalisables. Nous ne serons pas en mesure de prendre en charge certaines personnalisations. Nous recommandons donc aux technologies publicitaires d'utiliser nos configurations standards dans la mesure du possible.
Instances ponctuelles et instances à la demande	Le système a-t-il été testé avec des instances Spot plutôt qu'avec des instances à la demande ? Y a-t-il des inconvénients spécifiques à l'utilisation d'instances Spot, en dehors de leur indisponibilité temporaire potentielle ?	Nous n'avons pas donné la priorité aux tests sur les instances ponctuelles, car nous recommandons aux technologies publicitaires d'utiliser des instances à la demande. L'inconvénient des instances ponctuelles est que la tâche peut être interrompue pendant la consommation du budget. Si le budget a été consommé et que la tâche est interrompue avant que la technologie publicitaire ne reçoive le rapport récapitulatif, elle ne pourra pas simplement réessayer la tâche, mais devra demander une récupération de budget. La récupération du budget n'est recommandée que pour les défaillances catastrophiques afin de préserver la confidentialité. Nous recommandons aux technologies publicitaires de configurer l'autoscaling pour réduire les coûts. Si vous sélectionnez 0 pour l'autoscaling, aucune instance ne sera exécutée tant qu'une tâche n'est pas demandée (notez que cela peut augmenter la latence, car les instances seront lancées au moment d'une requête).
Erreurs connues et solutions	Clarification requise concernant le job du service d'agrégation affichant le message "Erreur de service"	Ce problème a été résolu ici. Nous avons également mis à jour certains de nos messages d'erreur pour les rendre plus descriptifs. Par exemple, nous avons commencé à générer des erreurs d'autorisation/d'authentification plus spécifiques sur AWS, contrairement à ce qui se produisait auparavant, où ces erreurs étaient affichées en tant qu'erreurs internes. Nous avons mis à jour la documentation sur les codes d'erreur et les mesures d'atténuation sur cette page. Nous accueillons les commentaires supplémentaires sur les erreurs qui ne sont pas documentées ou disponibles, ainsi que sur les informations qui seraient utiles sur cette page.

API Private Aggregation

Thème du commentaire	Résumé	Réponse de Chrome
Conception de clés	Demande d'aide pour la conception de clés Private Aggregation	Bien qu'il n'existe pas de guide spécifique à l'agrégation Private Aggregation, le framework de tests de charge du service d'agrégation et le guide de gestion avancée des clés peuvent être utilisés comme ressources.
Budget de contribution	À quel niveau le budget de contribution est-il calculé et limité ?	Le budget de contribution est de 2^16 dans une fenêtre glissante de 10 minutes et de 2^20 dans une fenêtre glissante de 24 heures.

Limiter le suivi dissimulé

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

Aucun commentaire reçu ce trimestre.

Protection IP (anciennement Gnatcatcher)

Thème des commentaires	Résumé	Réponse de Chrome
Android	Comment prévoyez-vous de déployer la protection de l'adresse IP sur Android ?	Nous étudions la possibilité d'intégrer des fonctionnalités de lutte contre le suivi masqué à Android, y compris la protection de l'adresse IP, mais nous n'avons pas de plans officiels à partager pour le moment.
Utilisation de l'API	Question concernant l'existence ou l'absence d'une exception antifraude pour la protection IP	Nous nous efforçons de trouver un équilibre entre la protection des utilisateurs contre le suivi sur le Web en fonction de leur adresse IP et la réduction des perturbations sur le fonctionnement normal des serveurs, y compris l'utilisation des adresses IP pour lutter contre les utilisations abusives. Nous ne pouvons pas vous fournir plus d'informations pour le moment, mais nous espérons pouvoir vous en fournir prochainement et poursuivre la discussion avec vous.
Identification des acteurs malveillants	Inquiétudes concernant l’efficacité des mesures de sécurité traditionnelles contre les adresses IP malveillantes	La protection IP n'effectue pas le proxy pour les requêtes first party. La plupart des systèmes de détection des intrusions ne devraient donc pas être affectés. Nous prévoyons de fournir plus d'informations à l'avenir pour répondre aux problèmes de lutte contre la fraude et de plantage des sites pour les utilisateurs en mode navigation privée.
Masquage des adresses IP	Si le site de l'éditeur de presse (1P) utilise le même domaine que le site publicitaire (3P), l'adresse IP sera-t-elle masquée pour les deux ? Si ce n'est pas le cas, comment faire la distinction ?	La protection IP propose actuellement une approche basée sur une liste pour identifier le trafic tiers qui passe par les proxys. Toutefois, même si une origine figure dans cette liste, elle ne sera pas mise en proxy si elle est accessible dans un contexte propriétaire. Nous sommes en train de finaliser les détails concernant les domaines tiers spécifiques qui seront prioritaires en premier lieu et la façon dont nous définirons précisément les contextes propriétaires et tiers pour la protection de la propriété intellectuelle.
Masquage des adresses IP	Préoccupations concernant la protection des adresses IP et son impact sur les systèmes de lutte contre la fraude	Les propriétaires ne sont pas concernés par nos plans de protection de la propriété intellectuelle. Les sites tels que les forums doivent donc avoir accès aux adresses IP pour résoudre les litiges. Nous prévoyons de vous fournir des informations supplémentaires à ce sujet à l'avenir.
Masquage des adresses IP	L'adresse IP est-elle masquée dans l'en-tête des domaines concernés ?	Les utilisateurs seront affectés à une zone géographique en fonction de leur adresse IP pré-proxy qui représente leur emplacement actuel. Pour en savoir plus, cliquez ici.

Atténuation du suivi des rebonds

Thème des commentaires	Résumé	Réponse de Chrome
Spécification de l'API	Clarification nécessaire sur le comportement de Chrome concernant la navigation étendue lorsqu'un onglet est fermé.	Nous avons résolu ce problème ici et mis à jour la spécification en conséquence.
Suivi de navigation	Discussion d'une approche d'atténuation du suivi impliquant un ensemble fini de liens pour réduire l'entropie dans les requêtes intersites.	Nous continuons d'échanger sur ce sujet avec d'autres fournisseurs de navigateurs ici. Nous sommes à l'écoute de vos commentaires et de vos propositions spécifiques sur ce problème.

Privacy Budget

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

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

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

Thème du commentaire	Résumé	Réponse de Chrome
(également indiqué dans les trimestres précédents) Limite de domaines pour les ensembles de sites Web associés	Demande d'augmentation de la limite des domaines associés dans RWS	Notre réponse est similaire à celle des trimestres précédents: Pour le moment, nous ne prévoyons pas d'augmenter la limite numérique. Cette limite a été établie en fonction des considérations relatives à la confidentialité des utilisateurs, des commentaires des parties prenantes de l'écosystème dans le rapport W3C et de la prise en compte d'implémentations comparables dans d'autres navigateurs. Pour en savoir plus, consultez nos articles de blog (1, 2). Nous vous recommandons d'examiner les cas d'utilisation qui nécessitent un accès aux cookies intersites au-delà de la limite numérique et d'utiliser nos conseils pour les cas d'utilisation de l'identité, les intégrations authentifiées et les cas d'utilisation publicitaires. Si les sessions utilisateur sont liées à des actions de connexion, nous vous recommandons d'utiliser l'API Federated Credential Management (FedCM) pour maintenir son fonctionnement. N'hésitez pas à nous faire part de vos commentaires sur d'autres cas d'utilisation qui pourraient être nécessaires sur cette page.
Gestion des cookies intersites	Les cookies intersites définis par un sous-domaine ne sont pas transmis dans les requêtes ultérieures du domaine principal. Le problème persiste même avec des configurations CORS et des identifiants appropriées.	Cliquez ici pour obtenir des conseils sur l'utilisation correcte de l'API requestStorageAccessFor, qui doit spécifier l'origine complète (c'est-à-dire inclure les sous-domaines) pour que les cookies intersites soient envoyés lors des requêtes d'extraction ultérieures.
Choix de l'utilisateur	Demande d'informations supplémentaires sur requestStorageAccessFor utilisé par RWS après le déploiement du choix de l'utilisateur, en particulier sur le fonctionnement du geste utilisateur implicite ou explicite, qui permet actuellement d'accéder aux applications tierces, dans le nouveau système.	Nous nous attendons à ce que le comportement de la fonctionnalité RWS dans les deux modes de choix de l'utilisateur (c'est-à-dire, que les utilisateurs aient choisi de conserver ou de limiter leurs cookies tiers) soit cohérent avec le comportement existant/livré dans Chrome avec les cookies tiers autorisés ou bloqués avec la fonctionnalité RWS activée (paramètre "Autoriser les sites associés à voir votre activité dans le groupe"). Nous vous recommandons d'appeler d'abord hasStorageAccess pour vérifier si l'intégration a déjà accès aux cookies intersites non partitionnés avant d'appeler requestStorageAccess. La méthode hasStorageAccess renvoie la valeur "true" si l'utilisateur a choisi d'autoriser les cookies tiers. requestStorageAccessFor ne nécessite actuellement pas de geste de l'utilisateur si les cookies tiers sont autorisés. Nous avons ouvert un nouveau problème GitHub pour discuter et spécifier le comportement approprié dans ce cas. Nous accueillons les commentaires supplémentaires de l'écosystème.
Utilisation de l'API	Inquiétudes concernant le manque de clarté concernant l'utilisation des RWS à des fins "commerciales", ce qui entrave leur adoption. L'entreprise a indiqué être intéressée par le regroupement de publications pour la publicité ciblée.	L'objectif des RWS est de prendre en charge les fonctionnalités de base du site et les parcours utilisateur de base. Nous vous encourageons à utiliser nos API publicitaires dédiées pour les cas d'utilisation liés à la publicité ciblée.
Utilisation de l'API	Signalement d'un problème avec requestStorageAccess, qui permettait de définir des données localStorage, mais pas de cookies.	Le problème est dû à une faute de frappe dans l'attribut SameSite. Assurez-vous que l'orthographe est correcte et définissez-le explicitement sur "None" pour les 3PC.
Spécification de l'API	Écarts entre les schémas JSON dans le dépôt, tels que le mauvais placement du champ "contact" et des suggestions d'amélioration, y compris l'utilisation du mot clé "oneOf" pour assurer la cohérence.	Nous examinons ces commentaires et nous nous efforcerons d'apporter ces améliorations au schéma dans un avenir proche. Si vous avez d'autres commentaires, cliquez ici.
Accès tiers à RWS	Avec le consentement de l'utilisateur, autorisez une plate-forme à indiquer les domaines tiers qui auront également un tel accès aux données de l'API RWS.	Permettre aux tiers de combiner leurs propres données non partitionnées avec les données du site RWS compromettrait les protections contre le suivi intersites de la Privacy Sandbox. Nous étudions toutefois la possibilité de permettre aux tiers de gérer des données partitionnées dans un RWS et nous sollicitons vos commentaires sur la conception d'une telle solution ici.

API Fenced Frames

Thème des commentaires	Résumé	Réponse de Chrome
Question concernant l'API	Inquiétudes concernant la façon dont les cadres délimités sans accès au réseau pourraient compromettre la brand safety et la protection contre la fraude pour les annonceurs.	Nous suivons cette question dans le cadre de notre plan visant à appliquer les cadres délimités. Nous commencerons bientôt à chercher des solutions compatibles avec l'application des cadres cloisonnés. Nous les partagerons dès que les propositions seront suffisamment concrètes.
Question concernant l'API	L'API Fenced Frames est-elle toujours prévue pour 2026 ?	Comme indiqué dans notre annonce publique, les cadres délimités ne seront obligatoires qu'à partir de 2026.
Bug de l'API	Lorsque `reportEvent()` envoie avec succès des données de clic à partir d'un sous-cadre inter-origine, `setReportEventDataForAutomaticBeacons()` n'écrasera pas les données du cadre supérieur.	Nous examinons ce problème et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.

API Shared Storage

Thème des commentaires	Résumé	Réponse de Chrome
Publicité pour les applications	Il n'existe pas d'équivalent de l'API Shared Storage dans la Privacy Sandbox sur Android.	Nous évaluons les solutions sur Android en fonction des besoins des cas d'utilisation et des contraintes de la plate-forme. Nous n'avons aucune information à communiquer à ce sujet pour le moment, mais n'hésitez pas à nous faire part de vos commentaires sur ce problème.
Utilisation de l'API	Confusion concernant la nécessité d'un worklet JavaScript supplémentaire pour l'implémentation de l'API Shared Storage.	Nous étudions actuellement ces commentaires et étudions la possibilité de mettre à jour notre documentation afin d'expliquer la nécessité de scripts de Worklet supplémentaires pour l'API Share Storage.
Fiabilité insuffisante	L'API Shared Storage pourrait changer de manière significative ou être abandonnée en raison des critiques concernant la confidentialité, ce qui en ferait une base peu fiable sur laquelle s'appuyer.	Nous ne prévoyons pas de modifier de manière significative ni d'abandonner l'infrastructure de stockage partagé. Les principales modifications annoncées concernent la porte de sortie "Select URL" (Sélectionner une URL), pour laquelle des cadres clôturés seront obligatoires et les rapports au niveau des événements seront abandonnés. Toutefois, ces modifications ne prendront effet qu'en 2026 au plus tôt.

CHIPS

Thème des commentaires	Résumé	Réponse de Chrome
Cookies partitionnés	Contrairement à Firefox, Chrome ne différencie pas les clés de partition en fonction des ancêtres de frame, ce qui entraîne des incohérences.	Chrome a adopté le "bit de chaîne d'ancêtres" pour résoudre le problème de sécurité et la divergence avec le comportement de Firefox. Pour en savoir plus, consultez cet article.
Cookies partitionnés	Les iFrames intégrées avec différents niveaux d'accès au stockage partagent et écrasent le même cookie partitionné, ce qui entraîne des incohérences dans les états d'authentification.	Pour cette configuration particulière, nous vous recommandons d'utiliser des cookies non partitionnés avec une invocation de l'API Storage Access. Pour en savoir plus, cliquez ici.
Cookies partitionnés	Les bocals à cookies partitionnés seront-ils effacés lorsque les cookies tiers sont désactivés ? Existe-t-il un moyen de tester ce comportement ?	Nous n'avons pas d'informations à vous communiquer à ce sujet pour le moment. Toutefois, les développeurs peuvent tester cette fonctionnalité en supprimant manuellement les cookies partitionnés via le panneau Application> Cookies des outils pour les développeurs Chrome.

FedCM

Thème du commentaire	Résumé	Réponse de Chrome
Champ d'application de l'enregistrement du fournisseur d'identité (IdP) et sélecteur d'organisation	Question sur l'extension de l'enregistrement de l'IDP de la règle d'origine actuelle à une règle de même site. Cette modification permettrait une gestion des identités plus large et plus flexible, par exemple en permettant à la page d'accueil d'une université d'enregistrer plusieurs fournisseurs d'identité basés sur des sous-domaines sans avoir besoin d'enregistrements distincts spécifiques à l'origine. Commentaires sur l'amélioration de la débogabilité, la gestion des clients approuvés pour la médiation silencieuse, la clarification du comportement des cookies, la personnalisation du libellé du pop-up et la résolution des problèmes de délai avant expiration.	Nous prenons connaissance de ces commentaires et réfléchissons à la manière dont un sélecteur d'organisation pourrait être intégré à FedCM. Nous accueillons avec plaisir les commentaires supplémentaires de l'écosystème ici, car nous continuons à affiner cette approche.
Cookies de l'IDP	Discussion sur l'impact de l'implémentation de cookies de session de courte durée dans le cadre de la proposition d'identifiants de session liés à l'appareil (DBSC, Device Bound Session Credentials). Des inquiétudes sont soulevées concernant l'expérience utilisateur dans FedCM, où les cookies de fournisseur d'identité expirés nécessitent un modal visible par l'utilisateur pour le renouvellement.	Le DBSC proposé doit permettre le renouvellement des cookies sans intervention de l'utilisateur, ce qui garantit une expérience utilisateur continue. Pour en savoir plus sur ce problème, cliquez ici.
Spécification de l'API	Question sur l'opportunité d'utiliser "NetworkError" dans la spécification de l'API FedCM lorsque la taille du tableau "providers" n'est pas égale à 1.	Nous sommes d'accord que "TypeError" serait plus approprié dans cette situation, car il reflète une erreur de codage plutôt qu'un problème de réseau. Nous allons prendre en compte ce changement et étudier la possibilité de supprimer cette restriction dans les prochaines mises à jour à mesure que nous progresserons vers la prise en charge de plusieurs fournisseurs d'identité. Si vous avez d'autres commentaires, cliquez ici.

Lutter contre le spam et la fraude

API Private State Tokens (et autres API)

Thème du commentaire	Résumé	Réponse de Chrome
Test avant arrêt et mode B	Questions concernant l'essai d'abandon, les tests du mode B, l'arrêt potentiel des jetons de état privé (PST) et la possibilité d'une nouvelle API plus adaptée à leur cas d'utilisation de lutte contre la fraude.	Le test de l'abandon et les tests du mode B restent inchangés. Nous vous tiendrons informé des nouveautés via le blog des développeurs. Nous ne prévoyons pas d'interrompre les fichiers PST, et nous discutons du développement et des mises à jour de fonctionnalités en cours sur GitHub. Nous n'avons annoncé aucune nouvelle API, mais n'hésitez pas à nous faire part de vos commentaires sur la façon dont les fichiers PST peuvent mieux gérer les cas d'utilisation de lutte contre la fraude.
Commentaires sur l'API	Demande de possibilité de révoquer des jetons pour répondre à un cas d'utilisation de lutte contre la fraude.	Bien que l'émetteur puisse révoquer tous les jetons en modifiant les clés qu'il utilise, la révocation individuelle des jetons n'est pas possible avec l'API. En effet, l'émetteur devrait permettre à l'émetteur d'associer l'émission et l'utilisation des jetons, ce qui rompt le modèle de confidentialité PST qui empêche le suivi entre les deux événements.