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

Rapport sur les commentaires – T1 2025

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

Google a préparé ce rapport trimestriel dans le cadre de ses engagements envers l'Autorité britannique de la concurrence et des marchés (CMA) en vertu des paragraphes 12, 17(c)(ii) et 32(a). Ce rapport présente les progrès de Google concernant les propositions de la Privacy Sandbox, les attentes en termes de calendrier, des explications détaillées sur la façon dont Google a pris en compte les observations de tiers, ainsi qu'un résumé des interactions entre Google et la CMA, y compris les commentaires de la CMA et l'approche de Google pour y répondre.

Google a tenu la CMA au courant de l'avancement des propositions de la Privacy Sandbox lors de ses réunions d'état régulières, conformément au paragraphe 17(b) des Engagements. L'équipe gère également la documentation destinée aux développeurs, qui fournit des informations sur les principales fonctionnalités de publicité privée et les modifications apportées aux cookies, ainsi que sur l'implémentation de l'API et des informations d'état. Les informations clés sont publiées sur le blog des développeurs, et des informations ciblées sont envoyées aux listes de diffusion des développeurs individuels.

Glossaire des acronymes

ARA: API Attribution Reporting
CHIPS: Cookies ayant un état partitionné indépendant
DSP: Plate-forme côté demande
FedCM: Gestion des identifiants fédérés
IAB: Interactive Advertising Bureau
IDP: Fournisseur d'identité
IETF: Internet Engineering Task Force
IP: Adresse IP
openRTB: Enchères en temps réel
Prolongation: Essai Origin
API PA: API Protected Audience (anciennement FLEDGE)
PatCG: Groupe de la communauté sur les technologies publicitaires privées
RP: Partie de confiance
RWS: Ensembles de sites Web associés (anciennement "Ensembles internes")
SSP: Plate-forme côté offre
UA: Chaîne user-agent
UA-CH: Hints client User-Agent
W3C: World Wide Web Consortium
WIPB: Blanchement volontaire des adresses IP

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

Thème des commentaires	Résumé	Réponse de Chrome
Choix de l'utilisateur	On ne sait pas à quoi ressemblera la nouvelle approche de Google pour renforcer le choix des utilisateurs, ni comment elle sera présentée aux utilisateurs, ni les taux d'acceptation/de refus attendus. Des informations supplémentaires sont nécessaires pour distinguer cela de l'abandon des cookies tiers.	En avril 2025, Google a publié un article de blog sur les Étapes suivantes pour Privacy Sandbox et les protections contre le suivi dans Chrome, dans lequel il a annoncé qu'il maintenait l'approche actuelle consistant à proposer aux utilisateurs des cookies tiers dans Chrome et qu'il ne déploierait pas de nouvelle invite autonome pour les cookies tiers. Nous vous tiendrons informé au fur et à mesure.
Fingerprinting	Google n'a partagé aucune information avec les éditeurs ni les marketeurs sur la façon dont ils peuvent s'appuyer sur des alternatives aux systèmes publicitaires de Google sans utiliser l'identité des consommateurs comme clé de correspondance commune (empreinte numérique).	Nous avons mis en avant plusieurs systèmes publicitaires autres que Google qui proposent des solutions aux éditeurs et aux marketeurs, qui sont en partie basées sur les API de la Privacy Sandbox. Cela inclut les systèmes publicitaires autres que Google sur les marchés et les canaux. Pour en savoir plus et consulter des études de cas, cliquez ici et accédez à la section "Ressources pour les entreprises" de privacysandbox.com.
Privacy Sandbox	Les API Privacy Sandbox remplaceraient les ingrédients de données Internet par les propres produits finis de Google. Étant donné que la solution de Google est une API, elle offre un accès à un produit qu'il possède et contrôle, et qui est soumis à des conditions d'utilisation que Google peut modifier à sa discrétion. Cela ne remplace pas les composants utilisés par d'autres pour fabriquer leurs propres produits finis.	Les API Privacy Sandbox ont été développées et implémentées après un engagement important auprès des organismes de réglementation et d'un large éventail d'acteurs de l'écosystème. Comme pour les autres technologies de plate-forme, les API Privacy Sandbox doivent tenir compte du fait qu'elles seront utilisées comme composants dans les produits finis d'autres personnes. Nous encourageons les efforts de l'écosystème visant à développer des technologies supplémentaires compatibles avec les API Privacy Sandbox.
Choix de l'utilisateur	Demande d'informations pour savoir si l'approche mise à jour de Google concernant les PGC sur Chrome répondra à certaines exigences réglementaires, ce qui pourrait avoir un impact sur l'expérience des personnes concernées sur la plate-forme de gestion du consentement.	En avril 2025, Google a publié un article de blog sur les Étapes suivantes pour Privacy Sandbox et les protections contre le suivi dans Chrome, dans lequel il a annoncé qu'il maintenait l'approche actuelle consistant à proposer aux utilisateurs des cookies tiers dans Chrome et qu'il ne déploierait pas de nouvelle invite autonome pour les cookies tiers. Nous vous tiendrons informé au fur et à mesure.
Calendrier et adoption de la Privacy Sandbox	Les technologies publicitaires ont suspendu les tests des API Privacy Sandbox et cherchent des raisons plus solides de réinvestir dans ces technologies pour leurs activités produit et marketing. Leurs décisions de réinvestissement sont fortement influencées par le besoin de plus de clarté sur le calendrier du choix de l'utilisateur, ainsi que par les préoccupations concernant la latence de l'API Protected Audience (API PA) et la feuille de route des acquisitions et cessions. De plus, nous sommes préoccupés par l'examen des engagements de la CMA à venir, en particulier concernant le rôle de Google en tant que principal moteur des technologies Privacy Sandbox sans s'appuyer sur des identifiants tiers, et l'orientation future globale de l'initiative pour éclairer les stratégies d'investissement.	En avril 2025, Google a publié un article de blog sur les prochaines étapes pour Privacy Sandbox et les protections contre le suivi dans Chrome, dans lequel il a annoncé qu'il maintenait l'approche actuelle consistant à proposer aux utilisateurs des cookies tiers dans Chrome et qu'il ne déploierait pas de nouvelle invite autonome pour les cookies tiers. Nous vous tiendrons informés au fur et à mesure. Les enchères de l'API Chrome PA sont 35% plus rapides d'une année à l'autre. De plus, nous avons constaté une augmentation significative de l'utilisation des enchères parallèles, ce qui offre un avantage encore plus important à ces enchères. Pour consulter notre feuille de route actuelle concernant les acquisitions et les cessions, cliquez ici.
Calendrier de la Privacy Sandbox	Qu'est-ce qui a été modifié sur la page "Calendrier de la Privacy Sandbox" ?	Une présentation de l'API Topics a récemment été ajoutée à la page "Chronologie de la Privacy Sandbox".
Privacy Sandbox	Existe-t-il des articles de recherche sur la confidentialité par rapport à l'utilité pour mieux comprendre l'impact de la Privacy Sandbox sur les revenus ?	Vous trouverez des études de cas sur le marché pertinentes qui répondent à ces questions sur cette page et les résultats des tests des API Privacy Sandbox sur cette page.
Adoption de Privacy Sandbox	Un utilisateur précoce a signalé des difficultés initiales avec les API Privacy Sandbox en raison de l'adoption lente par les grandes entreprises, ce qui a affecté les lancements de tests. Toutefois, l'approche collaborative de l'équipe Privacy Sandbox et sa réactivité aux commentaires ont été appréciées.	Nous vous remercions de vos commentaires. Nous nous engageons à collaborer avec les premiers utilisateurs. Nous continuerons à interagir avec l'écosystème et à recueillir des commentaires afin d'évaluer le rôle des technologies Privacy Sandbox dans son accompagnement.
Tests Chrome	Inquiétude quant à la possibilité de poursuivre efficacement les tests de la Privacy Sandbox après la suppression des libellés de test, qui met en évidence une différence significative de qualité du trafic entre Chrome avec les cookies tiers désactivés (Mode B) et les utilisateurs qui ont personnellement désactivé les cookies tiers dans les paramètres de Chrome.	Notre réponse est semblable à celle des trimestres précédents: L'équipe Privacy Sandbox comprend que les entreprises souhaitent continuer à utiliser les libellés d'abandon des cookies. La procédure permettant de prolonger la disponibilité des libellés est semblable à celle permettant de prolonger un essai d'origine. La prise en charge des libellés a été étendue à plusieurs reprises. Nous envisageons de proposer une extension de la prise en charge des libellés d'abandon des cookies. Nous vous tiendrons informé sur blink-dev dès que possible.

Inscription et attestation

Aucun commentaire reçu ce trimestre.

Afficher des publicités et des contenus pertinents

Thèmes

Thème des commentaires	Résumé	Réponse de Chrome
Activation/Désactivation	La confirmation de Google selon laquelle la recherche Google n'utilisera pas la décision d'un site de désactiver l'API Topics comme signal de classement empêchera-t-elle Google d'utiliser la décision d'un site d'activer l'API Topics comme signal de classement ?	Notre réponse est similaire à celle des trimestres précédents: L'équipe Privacy Sandbox n'a pas coordonné ni demandé à l'organisation chargée de la recherche d'utiliser le classement des pages pour inciter les sites Web à adopter l'API Topics. La recherche Google n'utilisera pas la décision d'un site d'utiliser (ou non) l'API Topics comme signal de classement.
Observabilité de l'utilisation	Demander un mécanisme d'observabilité pour un SSP ou une technologie publicitaire générale afin de voir si leur implémentation de l'API Topics est utilisée sur le Web.	Nous évaluons la prise en charge de cette fonctionnalité et nous accueillons les commentaires supplémentaires de l'écosystème si cette fonctionnalité est une priorité.
Confidentialité	Questions sur le consentement et le risque de réidentification	Nous discutons actuellement de ce problème sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.

API Protected Audience

Thème des commentaires	Résumé	Réponse de Chrome
API PA et GAM/AdX	Google n'envoie aucune demande GAM/AdX à un éditeur qui souhaite s'appuyer sur un ad server d'éditeur concurrent. Google devrait permettre aux éditeurs concurrents de choisir d'autres vendeurs d'enchères via l'API PA de niveau supérieur pour contrôler les enchères finales. Les informations de l'API PA seront disponibles pour GAM, mais limitées pour les SSP concurrents. Par conséquent, les éditeurs ne peuvent pas comparer les performances de la demande provenant de l'API PA dans GAM, par exemple à partir d'AdX ou des SSP intégrés à l'API PA.	Réponse de Chrome: La norme de l'API PA est conçue pour être flexible et permet à différentes parties d'exécuter l'enchère de premier niveau. Ce choix dépend des implémentations et fonctionnalités spécifiques proposées par l'ad server de l'éditeur (GAM ou autre) et par les autres entreprises participantes à l'écosystème. La conception axée sur la confidentialité de l'API PA limite les rapports détaillés pour tous les participants de manière cohérente. Les données spécifiques signalées par l'enchère de l'API Protected Audience sont soumises aux mêmes règles et limites de confidentialité définies par l'API pour tous les participants, y compris les SSP. Les éditeurs utilisent les rapports globaux et respectueux de la confidentialité de l'API PA pour évaluer les performances. Cela permet d'évaluer la contribution globale de la demande provenant de l'API PA et de la comparer à d'autres canaux de demande, conformément aux principes de confidentialité par conception de l'API. Réponse fournie par Google Ad Manager: Les éditeurs ne sont pas tenus d'utiliser la fonctionnalité de serveur d'annonces de GAM pour accéder à la demande Ad Exchange. De plus, l'API PA est indépendante de l'entité qui lance une mise aux enchères, que la conception soit pour un seul vendeur ou pour plusieurs.
Top Level Seller	Le vendeur de premier niveau (VPP) a accès à des informations auxquelles aucun des autres vendeurs de composants n'a accès, ce qui suscite des inquiétudes concernant l'accès inégal aux informations. Bien que n'importe quelle entité puisse être le TLS, les éditeurs doivent utiliser GAM comme serveur d'annonces pour accéder à la demande AdX. Cela incite les éditeurs à utiliser GAM comme serveur d'annonces, ce qui donne à Google un avantage concurrentiel.	Réponse de Chrome: La conception de l'API PA ne dicte pas quelle entité peut agir en tant que TLS. Le rôle TLS nécessite de coordonner les enchères et d'accéder aux informations sur les enchères associées conformément à la structure de l'API. 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 engageant à ne pas partager le prix de l'une des sources publicitaires non garanties d'un éditeur, y compris le prix des éléments de campagne non garantis, avec un autre acheteur avant qu'il ne définisse son enchère. Nous avons ensuite réaffirmé cet engagement 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. De plus, comme indiqué ci-dessus, GAM n'exige pas que les éditeurs utilisent sa fonctionnalité d'ad server pour accéder à la demande AdX. Enfin, comme indiqué précédemment dans le rapport Google du 2e et 3e trimestre 2024, les plates-formes côté acheteur de Google (Google Ads, anciennement AdWords, et DV360) achètent des impressions sur des places de marché autres que Google, y compris via l'API PA.
API PA et GAM/AdX	Il est difficile pour les éditeurs de comprendre l'activation de l'API PA sur 100% de l'inventaire, car le libellé de l'option n'indique pas clairement l'objectif. Pour les SSP, dont le principal moyen d'accéder à l'inventaire est souvent une mise aux enchères multiniveaux avec GAM en tant que TLS, il n'existe en fait aucun moyen de mener des tests ni de monétiser via l'API PA sans être soumis à GAM.	Réponse de Chrome: La norme de l'API PA définit les rôles techniques (comme le vendeur TLS et le vendeur de composants) et le processus d'enchères, ce qui permet de choisir les plates-formes qui remplissent ces rôles. Les activités opérationnelles (configuration, coordination et accords, par exemple) sont gérées par les parties implémentatrices (éditeurs, SSP, fournisseurs TLS) pour faciliter la participation à l'aide du framework d'API PA. Réponse fournie par Google Ad Manager: Comme indiqué dans notre Centre d'aide, Ad Manager offre aux éditeurs un contrôle permettant d'activer les tests avec des vendeurs de composants autres que Google, tels que d'autres SSP, sur la totalité de l'inventaire d'un éditeur où l'API est disponible à l'utilisation (en ignorant tout échantillonnage ou tout débit limité que GAM pourrait appliquer). Si un éditeur active cette option, chaque fois qu'un vendeur de composants autre que Google fournit une configuration d'enchères, GAM tentera d'exécuter une mise aux enchères de premier niveau avec l'enchère de composant fournie, à condition que l'éditeur ait obtenu le consentement de l'utilisateur nécessaire pour ce faire. GAM indique clairement aux éditeurs que cette option peut avoir un impact sur les performances afin qu'ils puissent prendre une décision éclairée.
Côté serveur ou sur l'appareil	Les solutions côté serveur, telles que les enchères et les mises aux enchères, peuvent résoudre le problème de la gestion du trafic tout en préservant la confidentialité. Les solutions côté serveur sont le seul moyen viable d'avancer, et Google devrait abandonner les solutions sur l'appareil.	La Privacy Sandbox vise à prendre en charge à la fois les solutions d'enchères côté serveur (services d'enchères et de mise aux enchères) et les solutions d'enchères sur l'appareil, en proposant des options pour répondre aux différents besoins et cas d'utilisation de la technologie publicitaire.
Sécurité des enchères	Les attaques sur les enchères via l'API PA sont fondamentalement disqualifiantes pour les enchères sur l'appareil. Ce problème n'est pas considéré comme résolu par les personnes concernées, qui continuent de demander des garanties techniques pour s'assurer que les enchères via l'API PA ne sont pas falsifiées, ainsi qu'un mode débogage exhaustif pour détecter les incidents en temps réel et déboguer efficacement.	La Privacy Sandbox s'attache à garantir l'intégrité des enchères de l'API PA, y compris en atténuant les attaques potentielles. La conception de l'API intègre des mesures d'intégrité. Nous sommes à l'écoute de toute discussion technique sur des questions spécifiques. Nous avons présenté et discuté d'une liste détaillée des attaques potentielles sur l'API PA et de nos mesures d'atténuation lors de la réunion du groupe communautaire de lutte contre la fraude du W3C en mai 2024. N'hésitez pas à nous faire part de vos commentaires sur les attaques potentielles sur les enchères de l'API PA qui vous inquiètent.
Trafic sans cookie	Sera-t-il possible d'activer l'API PA uniquement sur le trafic sans cookie à des fins de test ou à d'autres fins ?	Les technologies publicitaires peuvent déterminer si des cookies tiers sont présents ou non. Pour en savoir plus, cliquez ici.
ID de siège	Concernant la proposition d'ID de siège, la connaissance de l'ID de siège est essentielle pour la plupart des demandes d'enchères, ce qui pose problème si l'ID de siège est associé à l'enregistrement de la création. De plus, s'applique-t-il uniquement à l'annonce principale ou également aux annonces de composants ?	La proposition BuyerAndSellerReportingId répond à la question concernant l'absence de l'ID de siège de l'acheteur lors de l'enregistrement de la création pour l'annonce principale. Cet identifiant vise à communiquer l'ID de siège de l'acheteur au vendeur. Nous évaluons la compatibilité avec les annonces de composants.
Surveillance et création de rapports	Demande de fonctionnalité pour la surveillance en temps réel (RTM) afin d'(1) envoyer des rapports RTM pour les enchères annulées et (2) de créer de nouveaux buckets remplis par le navigateur pour indiquer clairement le type d'annulation.	RTM ne semble pas être une solution adaptée pour examiner le taux de participation. En tant qu'API de surveillance à faible latence, RTM est conçue pour détecter les pannes critiques, soudaines et temporaires. En revanche, le taux de participation ne nécessite pas de rapports à faible latence et ne s'agit pas d'une interruption temporaire soudaine et critique. Les questions concernant les taux de participation sont le plus efficacement traitées par les vendeurs avec lesquels les acheteurs collaborent, et non par les acheteurs qui effectuent des recherches via le navigateur. De plus, comme les enchères annulées sont extrêmement courantes, si le navigateur générait des rapports RTM à partir de chaque enchère annulée, il pourrait étouffer les rapports RTM pour les pannes réelles.
Documentation Clarification	Signalement d'un écart de documentation dans l'explication de l'API PA, qui indique que le nonce doit être une chaîne UUID, mais qui renvoie en réalité une promesse.	Pour obtenir des précisions, consultez cette page.
Contexte figé	Lorsque vous travaillez avec un contexte figé, quelles options sont disponibles pour résoudre les problèmes et défis liés aux (1) regroupements, (2) bibliothèques externes et (3) types de données non compatibles ?	Vous trouverez la réponse à cette question sur cette page.
Caractéristiques techniques	L'API Private Aggregation a ajouté une opération contributeToHistogramOnEvent générique. Par conséquent, la définition de l'API PA est devenue une opération surchargée, et les opérations de l'IDL Web "ne doivent pas être surchargées entre les interfaces, les interfaces partielles [...]". Cette définition n'est donc plus valide.	Ce problème met en évidence une incohérence temporaire entre l'API PA et les spécifications d'agrégation privée pendant que nous fusionnons des modifications similaires dans les deux. Nous avons fusionné une demande d'extraction pour résoudre ce problème.
Groupes de centres d'intérêt	Demande de conseils sur la méthode recommandée et économe en ressources pour mettre fin à la participation aux enchères d'un groupe d'intérêt (GI) lorsqu'une campagne s'arrête.	Voici quelques suggestions: Nous pensons que le mécanisme le moins lent, le moins permanent, mais aussi le moins libérateur de ressources consiste à utiliser les signaux d'enchères en temps réel pour indiquer à `generateBid()` de cesser d'enchérir. La deuxième option qui utilise moins de ressources consiste à définir une priorité négative pour cet IG dans la réponse des signaux d'enchères en temps réel, car cela empêcherait même l'appel de `generateBid()`. La troisième option, qui utilise encore moins de ressources, consiste à supprimer les annonces de l'IG. Les IG sans annonces n'appellent pas leur `generateBid()`. La quatrième option, qui utilise encore moins de ressources, consiste à supprimer le `biddingLogicURL` de l'IG. À ce stade, l'IG peut toujours être mis à jour/rejoint afin de le réactiver. Les autres options concernent la sortie de l'IG, soit via `leaveAdInterestGroup()` ou `clearOriginJoinedAdInterestGroups()`, soit lorsque l'IG expire. Comme indiqué ci-dessus, les différentes options ont des implications différentes en termes de latence et de consommation de ressources. Les technologies publicitaires peuvent choisir l'option qui offre le meilleur compromis pour leurs cas d'utilisation spécifiques.
Audiences	Demande d'un mécanisme permettant d'exécuter des opérations logiques sur les audiences créées (par exemple, la possibilité de cibler une intersection entre les audiences A et B)	Avec l'API PA, vous pouvez désormais exécuter des opérations logiques sur les audiences du même site. Les opérations logiques sur les audiences de différents sites ne sont pas acceptées pour des raisons de confidentialité, comme expliqué dans notre modèle de confidentialité. Nous continuons de mener des recherches dans ce domaine et nous vous tiendrons informés au fur et à mesure.
Demande de fonctionnalité	Proposition visant à supprimer la restriction concernant les enchères supplémentaires nécessitant que le TLS soit connu à l'avance.	Nous discutons actuellement de cette proposition sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Nouvelle approche concernant les applications tierces sur Chrome	Les API Privacy Sandbox telles que l'API PA resteront-elles généralement disponibles pour tous les utilisateurs de Chrome Stable, ou ne seront-elles disponibles que pour les utilisateurs qui ont refusé les cookies tiers ?	Nous ne souhaitons pas que la décision d'un utilisateur de refuser les cookies tiers ait un impact sur la disponibilité des API Privacy Sandbox dans Chrome stable.
Signalisation améliorée	Prévoyez-vous d'ajouter une fonctionnalité indiquant si le TLS a l'intention d'exécuter une mise aux enchères d'API PA ?	Nous évaluons la prise en charge de cette fonctionnalité. Nous vous communiquerons plus d'informations sur le calendrier dès qu'elles seront disponibles. N'hésitez pas à nous faire part de vos commentaires sur cette demande.
ID de l'accord	Inquiétude concernant l'exigence de serveur KV dans la proposition d'ID de transaction, qui pourrait s'avérer être un processus côté serveur coûteux et long.	La proposition d'ID d'accord permet aux SSP d'interroger les métadonnées des ID d'accord sélectionnés à partir du serveur de clés-valeurs lors des enchères PA, de sorte qu'ils n'aient pas besoin de précharger toutes les métadonnées liées à l'accord sur l'appareil. Cette proposition est en cours de développement en réponse aux demandes des SSP. N'hésitez pas à nous faire part de vos commentaires sur l'écosystème ici. Nous sommes conscients que la configuration du serveur de paires clé-valeur nécessite un certain travail, mais nous pensons que cela représente un avantage net pour les entreprises de technologie publicitaire. Nous restons à l'écoute de vos commentaires et suggestions pour faciliter ce processus.
Limitation de la fréquence d'exposition entre les comptes Instagram	Demande de limitation du nombre d'expositions cross-IG via l'API PA.	La limite de la fréquence d'exposition inter-IG présente des caractéristiques de confidentialité difficiles à gérer, pour lesquelles nous n'avons pas trouvé de solution. Nous sommes à l'écoute des commentaires supplémentaires de l'écosystème si cette fonctionnalité est une priorité.
Rapports sur les ID d'accord et d'utilisateur	Demande de possibilité d'obtenir les ID de contrat ou de siège dans les rapports agrégables.	Les fonctionnalités d'ID de reporting sur lesquelles nous travaillons ici permettront de générer des rapports sur les ID de contrat et de siège. selectedBuyerAndSellerReportingId est fourni à reportResult(). Le moyen le plus simple de le signaler est donc de créer des rapports au niveau des événements (c'est-à-dire en encodant l'ID de l'accord dans l'URL transmise à sendReportTo()). Si des rapports agrégés devaient être utilisés, cela peut également être fait. La fonctionnalité d'ID de rapport est actuellement disponible pour 10% du trafic du canal stable de Chrome. Nous envisageons de lancer cette fonctionnalité à 100%.
Groupes de centres d'intérêt	Utilisez le même ordre de priorité pour la sélection et l'évaluation des IG, et utilisez cet ordre de priorité dans tous les modes d'évaluation.	Nous en discutons actuellement sur cette page et nous serons ravis de recevoir d'autres commentaires.
Groupes de centres d'intérêt	Suggestion d'utiliser l'activation et la délégation d'audience pour accroître l'adoption de l'API Privacy Sandbox.	Nous sommes au courant de cette demande de la part de plusieurs personnes concernées et nous recherchons une solution. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème.
Groupes de centres d'intérêt	Difficultés liées à la création d'identifiants d'utilisateur pour l'API PA, en particulier concernant la délégation et la propriété lorsque vous agissez pour plusieurs achats ou pour le compte d'éditeurs.	Nous avons reçu la demande de plusieurs personnes concernées de prendre en charge des délégations IG plus avancées. Nous voyons la valeur ajoutée des SSP dans ce processus. Nous menons des recherches pour trouver la meilleure solution permettant à différentes parties de participer au processus d'extension d'audience. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème.
Performances côté client	Demande d'aide pour faciliter le stockage en cache côté client des signaux d'enchères approuvés afin d'optimiser les coûts d'infrastructure et la latence.	Nous en discutons actuellement sur cette page et nous serons ravis de recevoir d'autres commentaires.

Enchères protégées (services d'enchères et de mise aux enchères)

Thème des commentaires	Résumé	Réponse de Chrome
Services K/V	Comment les requêtes du navigateur au serveur KV du vendeur sont-elles groupées ? Pour un vendeur, à quoi ressemblera la requête du navigateur : une requête GET ou POST ? De plus, des précisions sont nécessaires concernant les exigences de k-anonymat.	Pour la version 1, Chrome envoie une requête GET au service KV du vendeur pour extraire `trustedScoringSignalsURL` avec les signaux dans les paramètres de requête de la requête. Les paramètres incluent `hostname`, `renderUrls`, `adComponentRenderUrls` et `experimentGroupId`. Nous testons actuellement certaines extensions pour envoyer des informations supplémentaires à des fins d'analyse des créations, mais cette fonctionnalité n'a pas encore été lancée. Lorsque vous définissez `maxTrustedScoringSignalsURLLength` sur 0, Chrome peut potentiellement regrouper tous les signaux dans une seule requête (ce qui peut dépasser toute limite de longueur d'URL sur son serveur), mais ce n'est pas garanti. Chrome choisit actuellement d'inclure les requêtes dans le même lot si elles sont prêtes à être envoyées dans un délai de 10 ms les unes par rapport aux autres. Nous étudions actuellement comment optimiser ce processus. Lorsque vous travaillez avec des signaux de notation approuvés, n'oubliez pas que Chrome respecte les en-têtes de mise en cache. Les en-têtes tels que l'en-tête `Stale-While-Revalidate` "Cache-Control" peuvent réduire la latence moyenne en permettant à Chrome d'utiliser la copie mise en cache (et de mettre à jour le cache pour la prochaine mise aux enchères), ce qui supprime efficacement la récupération des signaux du chemin critique. Enfin, concernant le k-anonymat, la section spécifique de l'explication semble obsolète. Au départ, nous voulions exiger que les URL des signaux approuvés soient k-anonymes, mais cette exigence a été abandonnée. Nous allons supprimer cette phrase de la vidéo explicative.
Services d'enchères et de mise aux enchères	La mise à niveau vers la dernière version de B&A prend beaucoup de temps. Une durée de compilation plus rapide ou des images prédéfinies seraient bénéfiques.	Les technologies publicitaires peuvent créer les binaires elles-mêmes et les valider à l'aide des hachages fournis. Nous envisageons d'étudier la possibilité de fournir des artefacts précompilés ou d'améliorer les temps de compilation à l'avenir.
Requête de fonctionnalité de l'API	Demande de compatibilité macOS pour les scripts de compilation, les images de conteneur et les outils d'invocation des services d'enchères et de mise aux enchères (B&A) afin de faciliter le développement et les tests locaux.	Nous acceptons actuellement amd64, ce qui est suffisant pour le déploiement sur les plates-formes cloud compatibles (GCP et AWS). Nous pourrons envisager de prendre en charge d'autres architectures à l'avenir.
AWS	La création de rôles IAM est-elle obligatoire pour les builds de production ?	Oui, les rôles IAM sont nécessaires pour obtenir les autorisations appropriées et communiquer avec les coordinateurs. Les clés sont utilisées pour déchiffrer le texte chiffré ProtectedAudienceInput généré sur l'appareil, comme indiqué ici. De plus, ces rôles sont nécessaires pour transmettre l'attestation de serveur/TEE des builds de production à ces mêmes coordinateurs. Pour en savoir plus, consultez notre guide en libre-service.
Fanions B&A	Demande de publication des définitions des indicateurs d'enchères et de mise aux enchères dans la documentation, car aujourd'hui, ces définitions se trouvent dans le code Terraform, les fichiers cc et les fichiers proto. Toutefois, les technologies publicitaires bénéficieraient d'une documentation sur ces indicateurs, qui les utiliserait comme source de vérité pour comprendre comment personnaliser les déploiements.	Nous étudions la possibilité de documenter les descriptions des indicateurs Terraform. N'hésitez pas à nous envoyer vos commentaires supplémentaires sur cette page.
Service d'enchères AWS	Je recherche des conseils concernant le service d'enchères sur AWS, ainsi que le comportement et la configuration de journalisation par défaut.	Pour déboguer vos services d'enchères dans le TEE (tel que le service d'enchères), nous vous recommandons d'utiliser le débogage avec autorisation de la technologie publicitaire. Vous pouvez ainsi activer la journalisation détaillée et capturer les données de requête/réponse pour vos requêtes de test spécifiques directement depuis votre client afin de faciliter le débogage.
Documentation sur le K/V TEE	Demande de précisions concernant le début de l'application de la TKV, comme indiqué sur le site de développement.	Nous vous préviendrons suffisamment à l'avance avant d'exiger l'utilisation de TEE. En attendant, vous pouvez continuer à utiliser votre propre serveur pour les signaux clé-valeur en temps réel.
Tests et analyses de la version bêta et de l'application	L'analyse et les tests des tests A/B restent coûteux et ne semblent pas prêts à être mis en production.	Nous avons besoin d'informations supplémentaires sur l'analyse des coûts et les facteurs qui ont conduit à l'évaluation de la préparation à la production pour pouvoir examiner la question plus en détail.
Optimisation de serveur de confiance	Proposition de fusion des paramètres spécifiques aux vendeurs de composants en un seul paramètre inputsPerSeller, en utilisant une chaîne JSON pour sa valeur.	Nous examinons cette proposition et nous vous invitons à nous faire part de vos commentaires supplémentaires sur cette page.
Sécurité	Comment les risques de sécurité liés aux clés de chiffrement v2 sont-ils atténués grâce à l'utilisation de l'analyse et de l'évaluation ?	Il est possible d'empêcher les appels externes à TKV. Cette fonctionnalité est entièrement prise en charge et configurable sur GCP. Pour AWS, une assistance supplémentaire doit être développée en raison de l'abandon d'AWS App Mesh, qui permettait auparavant cette fonctionnalité. N'hésitez pas à nous faire part de vos commentaires supplémentaires en cliquant ici.
Services d'enchères et de mise aux enchères	Demande de clarification sur le message/les communications concernant la valeur du streaming HTTP pour l'optimisation des enchères et des mises aux enchères.	La Privacy Sandbox prend en charge les fonctionnalités de streaming pour transférer les données d'enchères et de mise aux enchères afin d'améliorer la latence pour les technologies publicitaires qui choisissent de l'utiliser. Il s'agit d'une optimisation des performances facultative en cas de mode mixte.
Prebid	Demande d'informations sur la contribution à la bibliothèque Open Source Prebid pour activer les fonctionnalités d'enchères et d'enchères de l'API PA pour l'écosystème.	En mars 2025, Chrome a lancé l'optimisation par défaut Prebid dans la version stable, comme indiqué dans la feuille de route publique des enchères et des mises aux enchères (voir mars 2025).
Lissage du trafic	Demande de mécanismes permettant de consigner les signaux contextuels reçus par les enchères et les mises aux enchères afin de mieux comprendre quand les IG sont activés et d'améliorer leur logique d'enchères dans les réponses contextuelles. Cela permet une meilleure utilisation des ressources réseau pour éviter le "trafic inutile" (également appelé "mise en forme du trafic").	Nous discutons actuellement d'une proposition ici et nous sommes à l'écoute de vos commentaires supplémentaires.
Documentation Clarification	Clarification nécessaire concernant l'erreur "Le proxy de service/Vsock n'est pas accessible" détectée lors de la configuration de l'intégration des tests B&A.	Cela est dû aux exigences de mémoire minimales.La présentation de la configuration AWS a été mise à jour pour refléter cette exigence.

Mesurer les annonces numériques

Attribution Reporting (et autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Données en temps réel	L'absence de données en temps réel affecte tous les acteurs du secteur. Le retard des données en temps réel est un problème sérieux pour les annonceurs. Les acheteurs se tournent vers les plates-formes qui utilisent Google Analytics, car c'est le seul endroit où ils peuvent prouver qu'ils touchent des audiences.	Les retards de données en temps réel qui font partie de l'API Attribution Reporting (ARA) sont implémentés en tant que mécanismes de protection de la confidentialité afin de réduire la capacité des technologies publicitaires à utiliser les rapports au niveau des événements pour suivre les utilisateurs sur plusieurs sites. Toutefois, ARA offre une flexibilité dans la diffusion des rapports d'attribution, en permettant aux rapports au niveau des événements d'avoir une période de référence minimale d'une heure et en permettant aux rapports agrégables d'être envoyés instantanément aux technologies publicitaires sans délai.
Utilisation de l'API	Demande de confirmation concernant la configuration correcte d'un flux d'attribution multi-application Web, en particulier lorsque vous utilisez l'attribution Web-Web et Web-application en parallèle.	Lorsque vous diffusez des campagnes Web-to-Web et Web-to-App en parallèle, la technologie publicitaire ne doit choisir qu'une seule plate-forme pour enregistrer chaque source ou déclencheur afin d'éviter les double-comptages. Dans la mesure du possible, nous vous recommandons d'utiliser le système d'exploitation (OS), car il peut effectuer une attribution Web-Web et Web-application, à condition que les sources Web et les déclencheurs aient été correctement délégués. Pour ce faire, répondez avec l'en-tête Attribution-Reporting-Register-OS-Source pour les sources et l'en-tête Attribution-Reporting-Register-OS-Trigger pour les déclencheurs. L'en-tête Attribution-Reporting-Support permet de déterminer si la fonctionnalité est prise en charge au niveau de Chrome et/ou d'Android. L'en-tête Attribution-Reporting-Info est utile lorsqu'aucun en-tête Attribution-Reporting-Support n'est présent dans la requête. Dans ce cas, le navigateur prend la décision d'enregistrement de la plate-forme en fonction de la disponibilité de la plate-forme sur l'appareil de l'utilisateur.
Spécification de l'API	Demande de clarification concernant l'en-tête de requête HTTP Attribution-Reporting-Support défini par l'API Attribution Reporting et si l'en-tête doit contenir à la fois des clés Web et OS, quelle que soit la plate-forme.	Le en-tête Attribution-Reporting-Support est soumis à l'ajout de paramètres "GREASE" par le navigateur pour s'assurer que les serveurs utilisent un analyseur d'en-tête structuré conforme aux spécifications. Pour cet en-tête, seules les clés de dictionnaire structuré doivent être interprétées. Les valeurs et les paramètres ne sont actuellement pas utilisés. Pour obtenir un exemple, cliquez ici.
Rapports basés sur les PGC	Demander des conseils pour résoudre les écarts de mesure entre l'ARA et les 3PC dans les campagnes publicitaires.	L'API Attribution Reporting prend en charge deux types de rapports de débogage qui peuvent être utilisés pour résoudre les problèmes et déboguer les écarts. Les rapports de débogage "attribution-success" permettent de comparer facilement les résultats de l'ARA à ceux d'autres technologies de mesure. Les rapports de débogage de type "verbose" permettent d'obtenir plus d'informations et de résoudre les problèmes potentiels liés aux enregistrements d'attribution.
Utilisation de l'API	Lors des tests de l'ARA, certains problèmes ont été détectés: des rapports peu détaillés entraînant des données bruyantes et une optimisation des campagnes peu flexible, des seuils élevés excluant les petits annonceurs, et des difficultés à comparer les campagnes en raison d'indicateurs clés de performance incohérents.	L'API Attribution Reporting offre une flexibilité grâce à plusieurs paramètres que les technologies publicitaires peuvent personnaliser pour répondre à leurs cas d'utilisation de mesure spécifiques. Les rapports au niveau des événements sont flexibles. Ils permettent aux technologies publicitaires de personnaliser leurs périodes de référence, le nombre de rapports qu'elles peuvent recevoir et les données de déclencheur qu'elles souhaitent mesurer. Cela peut modifier l'impact du bruit sur leurs données et leur permettre de répondre à différents cas d'utilisation. De même, les technologies publicitaires peuvent personnaliser leurs configurations de différentes manières dans les rapports agrégables, comme le nombre de dimensions qu'elles suivent, leur fréquence de traitement par lot et leur utilisation du budget de contribution pour modifier l'impact du bruit et obtenir différents cas d'utilisation.
Spécification de l'API	Question concernant la dépendance de l'ARA sur des tiers, en particulier pour savoir si elle reste en phase de test nécessitant ces tiers.	L'ARA est activé indépendamment des PGC, mais ils doivent être activés pour permettre aux rapports de débogage de transition de l'ARA de comparer les résultats de l'ARA avec les résultats d'attribution basés sur les cookies.
Utilisation de l'API	Requête concernant l'enregistrement de sources pour l'attribution d'une application au Web sur d'anciennes versions d'Android (11, 12 et 13) à l'aide d'ARA.	ARA est actuellement compatible avec Android S et les versions ultérieures (12 et versions ultérieures).
Utilisation de l'API	Demander les taux d'acceptation de l'ARA et les détails de distribution	Notre réponse n'a pas changé depuis les trimestres précédents: "Nous ne prévoyons pas de partager ces informations avec l'écosystème. Les développeurs sont invités à appeler les API où ils ont déployé du code aujourd'hui pour estimer la disponibilité des API Privacy Sandbox."
Disponibilité de l'API	Lorsque l'ARA est activé, les 3PC sont-ils activés ou désactivés ?	Lorsque l'ARA est activé dans le navigateur des utilisateurs, cela n'a aucun effet sur leurs paramètres de cookies. Il est possible que l'ARA soit activé et que les cookies soient activés ou désactivés pour l'utilisateur.
Rapports	Existe-t-il une liste prédéfinie de valeurs que nous pouvons recevoir dans l'en-tête "Attribution-reporting-support" ?	Comme indiqué dans nos consignes, la valeur est un dictionnaire d'en-tête structuré, dont la seule sémantique définie actuellement est la présence ou l'absence des clés d'OS et Web. Toutes les autres parties de l'en-tête doivent être ignorées. En d'autres termes, l'analyse nécessite d'utiliser un analyseur d'en-tête structuré, et non une simple mise en correspondance de chaînes.

Service d'agrégation

Thème des commentaires	Résumé	Réponse de Chrome
Demande de fonctionnalité	Requêtes de fonctionnalités pour le service d'agrégation: Intégrations de serveur à serveur, mesure inter-appareils, simplification de l'attribution multipoint et des rapports sur la contribution, attribution omnicanal et prise en charge des boucles d'optimisation avancées du ML (par exemple, Entraînement de modèle privé).	Nous évaluons ces demandes et vous communiquerons plus d'informations dès que possible. Nous invitons l'écosystème à nous faire part de ses commentaires pour nous indiquer si ces demandes sont prioritaires.
Demande de fonctionnalité	Demande de définir le paramètre EBS delete_on_termination sur "True" dans l'environnement Terraform afin de réduire les inquiétudes concernant la réinitialisation lors de la mise à jour du serviceset d'agrégation.	Nous examinons cette demande et vous communiquerons plus d'informations dès qu'elles seront disponibles. N'hésitez pas à nous faire part de vos commentaires sur l'écosystème pour nous indiquer si cette demande est prioritaire sur cette page.
Documentation Clarification	Demander des conseils sur ce qui peut être modifié (par exemple, les seuils de surveillance) et ce qui doit rester inchangé.	Nous envisageons de publier des documents et des conseils supplémentaires sur les personnalisations disponibles pour le service d'agrégation.
Déploiement	Demande de clarification concernant l'échec du nouveau déploiement à la commande bazel.	Le déploiement peut échouer en raison de la version de Bazel utilisée dans l'environnement. La documentation sera ajustée pour couvrir le débogage des échecs Terraform et indiquer la version de Bazel requise.

API Private Aggregation

Thème des commentaires	Résumé	Réponse de Chrome
Utilisation de l'API	Demande d'aide concernant certains défis d'implémentation, tels que la perte potentielle de données en raison des limites signalées du stockage partagé, les difficultés liées à une cardinalité élevée nécessitant des listes d'autorisation complexes du service d'agrégation (suggestions de caractères génériques) et le ralentissement des tests causé par la règle "pas de doublons" du service d'agrégation.	Concernant les limites de Shared Storage, la limite de 20 contributions (détaillée ici) s'applique par exécution, et non par mois. De plus, les appelants d'API peuvent remplacer cette limite. Cette limite vise à gérer le coût du traitement des rapports dans le service d'agrégation, et non à limiter l'outil de création de rapports. Concernant les requêtes avec caractères génériques, nous évaluons cette demande et vous communiquerons plus d'informations dès qu'elles seront disponibles. Concernant la règle "Pas de doublons", afin de permettre les tests, nous acceptons temporairement le mode débogage pour contourner cette règle. Pour en savoir plus, cliquez ici .
Filtrer l'ID et les buckets	Est-il possible de demander au service d'agrégation le même bucket avec deux ID de filtrage différents dans deux exécutions d'agrégation distinctes ? Autrement dit, l'ID de filtrage peut-il servir de partitionnement supplémentaire des domaines ?	Oui, cette fonctionnalité est disponible. Lors d'une agrégation, seules les contributions dont l'ID de filtrage correspond à la liste des paramètres de la tâche seront traitées. Les autres pourront être traitées dans une ou plusieurs exécutions distinctes.
Attribution multitouch	Demandes de clarification concernant l'implémentation de l'attribution multipoint (MTA) : 1) Le nombre de contributions est-il limité si la valeur d'agrégation ne dépasse pas 2^16 ? 2) Le nombre de clés d'agrégation (buckets) uniques pouvant être stockées pour un contexte donné est-il limité ? 3) Comment le service d'agrégation traite-t-il les rapports récapitulatifs lorsque chaque user-agent (navigateur) dispose d'une clé d'agrégation unique, comme c'est probablement le cas dans un MTA ?	1) Nous avons mis en place des limites de contribution par défaut, mais l'appelant de l'API peut les remplacer, comme expliqué dans cet article. Les limites ont pour but d'aider les appelants d'API à gérer le coût du traitement des rapports dans le service d'agrégation. 2) Il n'existe aucune limite de ce type, bien que les technologies publicitaires doivent tenir compte de la granularité des clés d'agrégation pour améliorer le rapport signal/bruit, comme expliqué plus en détail ici. 3) Veuillez consulter ces consignes, en particulier les consignes sur le rapport signal/bruit abordées ci-dessus sous l'élément 2).

Limiter le suivi dissimulé

Réduction user-agent/Hints client user-agent

Thème des commentaires	Résumé	Réponse de Chrome
Demande de fonctionnalité	Demande d'ajout de Sec-CH-UA-Robot aux indicateurs client User-Agent (UA-CH), car il permettrait aux serveurs d'identifier le trafic automatisé pour l'adaptation du contenu, la sécurité et l'analyse.	Il s'agit d'un cas d'utilisation important qui est discuté dans d'autres groupes de normalisation (cliquez ici pour en savoir plus). Nous recommandons aux personnes intéressées de participer en envoyant leurs commentaires. Toutefois, nous pensons que UA-CH n'est peut-être pas la solution appropriée, car les en-têtes de requête HTTP peuvent être facilement manipulés par le trafic automatisé.

Protection IP (anciennement Gnatcatcher)

Thème des commentaires	Résumé	Réponse de Chrome
Confidentialité des adresses IP	Laisser les adresses IP disponibles pour Google est contraire aux objectifs de confidentialité déclarés. Même si Google affirme anonymiser les données via la protection des adresses IP, les utilisateurs doivent être connectés à Chrome pour utiliser cette fonctionnalité. Google apprend donc toujours leur identité.	La connexion permet de lutter contre la fraude et les utilisations abusives, en limitant principalement l'accès aux proxys. De plus, pour protéger la confidentialité des utilisateurs dans le cadre de l'exigence d'authentification, notre conception de jeton est signée en mode aveugle, ce qui signifie que le jeton émis lors de la connexion est différent du jeton utilisé lors du proxying. Par conséquent, les jetons émis ne peuvent pas être associés à l'identité Google d'un utilisateur par la suite. Cela signifie que Google ne sait pas qui est l'utilisateur lorsque son trafic est mis en proxy en mode navigation privée, malgré l'exigence d'authentification pour des raisons de lutte contre la fraude.
Confidentialité des adresses IP	L'utilisation d'adresses IP est un pas dans la mauvaise direction. Ils ne peuvent pas être supprimés du navigateur, comme les cookies, et les utilisateurs ne disposent pas des mêmes commandes de transparence que pour les cookies. Si les cookies disparaissent, le secteur passera aux adresses IP comme solution de remplacement, privilégiant la préservation de soi à la confidentialité.	En tant que plate-forme, Chrome vise à fournir aux utilisateurs des fonctionnalités qui améliorent leur expérience de navigation sur le Web. Pour les utilisateurs de Chrome qui choisissent de naviguer en mode navigation privée, cela signifie que nous renforçons la protection contre le suivi intersites en limitant la disponibilité des informations sur l'adresse IP dans les contextes tiers.
Liste des domaines masqués	Quels sont les critères de sélection de la liste de domaines masqués (MDL) ?	Chrome a développé des critères pour identifier les domaines qui doivent figurer dans la liste MDL et qui doivent donc recevoir des adresses IP masquées dans un contexte tiers. Google s'est associé à Disconnect.me, un leader de la confidentialité sur Internet qui collabore également avec d'autres navigateurs Web. Chrome utilisera Disconnect.me pour identifier les domaines qui correspondent aux critères établis par Chrome. De plus, Chrome a développé une méthodologie permettant d'identifier les fonctions JavaScript couramment utilisées qui fournissent des résultats cohérents à partir d'API Web stables et à entropie élevée, et qui peuvent donc être utilisées pour créer des identifiants probabilistes à entropie élevée. Ces fonctions sont ensuite détectées lorsqu'elles sont chargées sur des sites Web dans un contexte tiers. Une liste de domaines qui diffusent des scripts présentant ces caractéristiques est alors créée et devient partie intégrante de la liste MDL. Ils sont donc mis en proxy. Le pipeline de détection qui recherche ces modèles d'utilisation abusive des API tient compte de tous les domaines, y compris ceux de Google.
Prévention des fraudes	Commentaires sur les jetons de révélation probabiliste (PRT, Probabilistic Reveal Tokens) indiquant que le délai de révélation de 24 heures et les taux de révélation proposés entravent la détection des fraudes en temps réel. Demander des délais plus courts (1 heure) et des tarifs plus élevés (au moins à deux chiffres). D'autres suggestions consistent à activer des tarifs différenciés en fonction des signaux de risque (VPN, navigateurs automatisés) et à autoriser la divulgation ciblée de jetons spécifiques.	La plupart des développeurs avec lesquels nous avons discuté fournissent des rapports toutes les heures à leurs clients et plusieurs mettent à jour les listes de blocage d'adresses IP tout au long de la journée. Un délai plus court permet des mises à jour plus fréquentes. Si le délai est inférieur à une heure, la mesure de l'IVT est réactivée dans les statistiques horaires, mais la probabilité de réidentification des utilisateurs est également plus élevée. Nous sommes prêts à examiner la possibilité de réduire les délais et de modifier le taux de révélation en fonction des études sur l'écosystème et des commentaires des personnes concernées. N'hésitez pas à nous faire part de vos commentaires sur cette page.
Liste des domaines masqués	Question concernant l'inclusion d'un domaine dans la liste MDL alors qu'il n'a pas de cas d'utilisation publicitaire. Inquiétude que cela puisse permettre de créer des profils basés sur les adresses IP grâce au "pontage IP".	Nous sommes conscients de l'importance d'implémenter un processus d'appel pour notre approche basée sur des listes. Les appels permettent aux entreprises de prétendre que leur domaine figurant sur la liste MDL ne répond pas aux critères d'inclusion et doit être supprimé, ce qui leur permet de continuer à recevoir les adresses IP d'origine des utilisateurs dans un contexte tiers en mode navigation privée. Nous avons lancé la procédure d'appel afin de laisser aux propriétaires de domaines suffisamment de temps pour faire appel et recevoir une décision avant le lancement de la protection IP en mode navigation privée dans Chrome stable. Pour en savoir plus sur la procédure d'appel, cliquez ici.
Liste des domaines masqués	Les éditeurs étudient les conséquences de l'inclusion de leurs partenaires dans la MDL. Il a été rassuré par les dispositions GeoIP de la vidéo d'explication sur la protection des adresses IP.	Chrome reconnaît l'importance de prendre en charge les cas d'utilisation basés sur la géolocalisation. Le proxy attribue des adresses IP qui représentent la position approximative de l'utilisateur, y compris son pays. Pour en savoir plus, consultez la présentation de la géolocalisation par adresse IP.
Liste des domaines masqués	Question concernant le MDL : le ciblage au niveau du pays est-il toujours disponible ?	Chrome reconnaît l'importance de prendre en charge les cas d'utilisation basés sur la géolocalisation. Le proxy attribue des adresses IP qui représentent la position approximative de l'utilisateur, y compris son pays. Pour en savoir plus, consultez la présentation de la géolocalisation par adresse IP.
Détection de fraudes	Inquiétudes concernant l'impact de la protection des adresses IP sur les systèmes de détection de fraude. Les utilisateurs verront-ils des adresses IP de proxy ou un en-tête ? Les SSP et les DSP verront-ils la même adresse IP de proxy pour une utilisation donnée ? Les incohérences peuvent affecter la détection des fraudes et OpenRTB.	Les utilisateurs qui naviguent en mode navigation privée avec la protection de l'adresse IP activée et qui envoient des requêtes à des domaines figurant dans la liste de blocage des domaines (MDL) recevront une adresse IP de proxy basée sur un flux géographique défini. Les organisations peuvent demander que les PRT soient transmis en tant qu'en-tête supplémentaire sur le trafic proxy, où un petit échantillon d'adresses IP d'origine peut être révélé après un délai. Nous pensons que de nombreux SSP transmettent leur adresse IP proxy dans les demandes d'enchères côté serveur à leurs partenaires côté demande, mais il n'est pas garanti que les DSP gagnantes voient la même adresse IP proxy au moment de l'impression.
Détection de fraudes	Questions sur la fréquence de mise à jour du fichier de géolocalisation des adresses IP, le calendrier de mise à jour des informations sur le signalement des comportements frauduleux et des PRT, et la façon dont la technologie publicitaire doit détecter les activités frauduleuses.	La vidéo d'explication sur les PRT est en ligne, tout comme la liste des adresses IP de proxy et des régions géographiques associées. Nous vous recommandons de consulter régulièrement ce fichier pour vérifier les mises à jour et les modifications, car les adresses IP changent au fil du temps. L'adresse e-mail publique permettant de signaler un abus sera annoncée à l'approche du lancement.
Géolocalisation	Demande de liste publique des adresses IP utilisées pour les proxys.	Le fichier mappant les adresses IP à des zones géographiques approximatives pour la protection des adresses IP est disponible ici. Veuillez noter que ce fichier est mis à jour régulièrement.
Utilisation de l'API	Affirmation selon laquelle la protection IP semble être activée par défaut et que les utilisateurs n'ont pas la possibilité de la désactiver.	La protection de l'adresse IP sera disponible pour les utilisateurs en mode navigation privée dans Chrome, sur les plates-formes Android et ordinateur. Les utilisateurs pourront désactiver IP Protection. Pour les versions de Chrome gérées par l'entreprise, la protection des adresses IP peut être activée, mais elle est désactivée par défaut.
Utilisation de l'API	Requête concernant la disponibilité d'un indicateur expérimental permettant d'activer et de tester la protection des adresses IP dans les versions Canary et bêta de Chrome.	Actuellement, aucun indicateur de test n'est disponible pour tester la fonctionnalité de protection des adresses IP dans son intégralité. Les tests fonctionnels que nous effectuons ne concernent que le trafic de proxy vers les domaines Google.
Confidentialité des adresses IP	Comment fonctionnent les paramètres d'invite de tiers lorsque le navigateur passe en mode navigation privée ?	Les cookies tiers sont bloqués par défaut en mode navigation privée.
Mode navigation privée	Je souhaite savoir si la protection des adresses IP fonctionne en mode navigation privée lorsque l'utilisateur n'est pas connecté à Chrome.	La protection de l'adresse IP n'est pas active si l'utilisateur ne s'est pas connecté à Chrome avant de lancer le mode navigation privée. Cela permet de lutter contre la fraude et les utilisations abusives, en limitant l'accès aux proxys. La protection des adresses IP utilise l'authentification client pour limiter la capacité des acteurs malintentionnés à exploiter les proxys pour amplifier les attaques sur les services du MDL. Par conséquent, la protection de l'adresse IP n'est disponible que pour les utilisateurs qui se sont authentifiés avec le compte Google avec lequel ils sont connectés dans le navigateur Chrome avant d'ouvrir une nouvelle fenêtre de navigation privée.
Mode navigation privée	Requêtes visant à évaluer l'impact de la protection des adresses IP avant son lancement, y compris: (1) Proposition d'utiliser un indicateur d'état du navigateur ou des rapports d'API agrégables pour quantifier l'utilisation du mode Incognito ; (2) Envoi d'un en-tête de protection des adresses IP pendant une période avant d'activer la fonctionnalité ; et (3) Diffusion de la fonctionnalité auprès d'un petit pourcentage connu du trafic à des fins d'extrapolation.	Nous comprenons que l'écosystème souhaite pouvoir comprendre et mesurer l'ampleur et l'impact de la protection des droits d'auteur. Toutefois, Chrome s'efforce de rendre la navigation privée de l'utilisateur en mode navigation privée. Chrome ne propose aucune méthode pour détecter les utilisateurs qui naviguent en mode navigation privée. Il a également pris des mesures pour limiter les autres signaux susceptibles de révéler le mode de navigation de l'utilisateur. Nous étudions des moyens de faciliter ces tests sans nuire à la confidentialité des utilisateurs qui naviguent en mode navigation privée. Nous accueillons avec plaisir les commentaires supplémentaires de l'écosystème.

Mesures d'atténuation du suivi des rebonds

Thème des commentaires	Résumé	Réponse de Chrome
Conformité	Le refus de Google d'autoriser l'utilisation de la technique de mitigation du suivi des rebonds (BTM) conforme à la législation sur la protection des données n'a aucune base légale et rend le processus d'appel de la Privacy Sandbox sans objet.	Comme nous l'avons expliqué dans notre précédent rapport, l'état de conformité n'a aucun lien avec l'application de la fonctionnalité de monétisation des données. Google ne prend aucune décision concernant la conformité lors de l'implémentation de la fonctionnalité de monétisation des données. Comme les autres mesures de protection de la confidentialité de Chrome, le BTM vise à renforcer le contrôle des utilisateurs sur le partage de leurs données et la façon dont il se fait. Le processus d'appel géré par un tiers mentionné dans le rapport du CMA sur les trimestres 2 et 3 est spécifique aux domaines dans lesquels Google prend des décisions concernant l'inclusion ou l'exclusion d'entreprises individuelles dans des listes.
Conformité	Discussion sur la façon dont les navigateurs garantissent le respect des actions consenties légalement dans le contexte du RGPD, en soulignant les scénarios dans lesquels les navigateurs peuvent supprimer des actions (telles que les redirections ou le paramétrage des cookies) auxquelles les utilisateurs ont explicitement consenti, créant ainsi un conflit entre le consentement légal et les paramètres de confidentialité du navigateur.	Le navigateur n'a pas connaissance de la nature de la relation entre un utilisateur et un site Web. De plus, avec le comportement actuel du suivi des conversions après clic, il existe déjà des solutions permettant à un utilisateur de donner un consentement explicite au suivi des rebonds à partir d'un site donné. Pour en savoir plus sur la conformité, consultez nos questions fréquentes sur la conformité en matière de confidentialité.
Sites à double usage	Vous souhaitez savoir si les transitions depuis WebView ou l'application vers le Web (Chrome) seront considérées comme des "sites à double usage" dans le cadre du BTM ?	Le navigateur ne peut pas déterminer si une chaîne de rebond a commencé via une transition depuis une WebView ou une application. Par conséquent, le BTM ne traite pas ces flux de manière spéciale. Il interprète plutôt le flux comme un rebond intersites à partir de "about:blank" et suit le comportement standard.

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

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

Thème des commentaires	Résumé	Réponse de Chrome
Utilisation de l'API	Préoccupations concernant le risque d'abus de la fonctionnalité RWS en association avec la protection de l'adresse IP. L'exposition des adresses IP aux organisations d'un ensemble RWS pourrait inciter les organisations à rejoindre plusieurs ensembles RWS afin d'accéder aux données d'adresses IP portables pour suivre les utilisateurs en mode navigation privée.	Les exigences définies pour les sites associés, les sites de service et les ensembles dans leur ensemble, appliquées par des validations automatisées, réduisent toute incitation potentielle à tenter de rejoindre plusieurs ensembles. Joindre l'activité des utilisateurs entre des ensembles via des adresses IP nécessite d'inclure un domaine MDL dans un ensemble, ce qui nécessite une coordination entre le propriétaire de l'ensemble et le propriétaire du domaine. Ce même risque s'applique aux sites uniques (c'est-à-dire sans RWS) qui coordonnent des domaines MDL. Pour en savoir plus, cliquez ici.

API Fenced Frames

Thème des commentaires	Résumé	Réponse de Chrome
Publicité native	Les commentaires indiquent que les cadres délimités, tels qu'ils sont actuellement conçus, sont incompatibles avec le modèle économique de la publicité native, qui exige que les annonces s'adaptent de manière flexible au contenu environnant.	Nous continuons d'évaluer les besoins de l'écosystème et l'offre actuelle de cadres avec clôture. Dans tous les cas, comme indiqué précédemment, les cadres imbriqués seront obligatoires au plus tôt en 2026.

API Shared Storage

Thème des commentaires	Résumé	Réponse de Chrome
Bug de l'API	Signalez que Chrome consigne une erreur lorsque le mécanisme de budgétisation de l'API Shared Storage empêche l'exécution de l'opération selectURL, même si ce comportement est normal. Demandez à Chrome de rétrograder le niveau de journalisation de l'erreur à un avertissement ou à une information, car l'appelant ne peut pas agir sur l'erreur.	Ce changement a été implémenté et inclus dans Chrome M134, disponible depuis le 4 mars 2025.

CHIPS

Thème des commentaires	Résumé	Réponse de Chrome
Documentation sur l'API	Clarification nécessaire concernant les protections de sécurité offertes par les cookies partitionnés par rapport aux cookies SameSite=Lax/Strict. Suggestion : la documentation devrait indiquer explicitement que les cookies partitionnés ne fournissent pas le même niveau de protection contre les attaques XSS et CSRF que les cookies SameSite=Lax/Strict.	Nous allons mettre à jour la vidéo explicative et la spécification pour clarifier la sémantique et les protections offertes par les cookies partitionnés.

FedCM

Thème des commentaires	Résumé	Réponse de Chrome
UI et sécurité	L'interface utilisateur de FedCM est trop semblable à la précédente connexion en un seul geste de Google. Il est difficile de quantifier les performances de FedCM en raison de l'absence de suivi passif de la présentation. Nous vous recommandons d'utiliser un langage plus clair dans la documentation concernant PKCE.	Nous échangeons activement avec les personnes concernées pour répondre à leurs commentaires. Nous discutons actuellement de différentes façons de fournir de meilleures métriques aux IdP afin de leur permettre de suivre les performances de FedCM, ainsi que d'éventuelles améliorations pour répondre à de nouveaux cas d'utilisation de FedCM liés aux abonnements.
Utilisation de l'API	Lorsqu'un utilisateur actualise la page et appelle navigator.credentials.get pour se connecter, une fenêtre pop-up s'affiche, et l'utilisateur doit cliquer pour continuer, ce qui entraîne un retard qui affecte l'expérience utilisateur. Les parties de confiance (RP) peuvent-elles mettre en cache le jeton renvoyé par navigator.credentials.get pour améliorer l'expérience utilisateur ?	Les RP peuvent utiliser leurs propres cookies pour stocker le jeton. Les RP peuvent ensuite vérifier leurs propres cookies pour déterminer si un utilisateur est connecté avant d'appeler navigator.credentials.get. Pour en savoir plus, cliquez ici.
Sélection multi-IDP	Comment le navigateur affiche-t-il les options de connexion pour plusieurs fournisseurs d'identité (IdP) dans FedCM ?	La documentation destinée aux développeurs contient des informations sur l'affichage de plusieurs IdP. Les personnes concernées peuvent tester cette fonctionnalité en activant le flag fedcm-multi-idp dans chrome://flags.
Navigateurs et IdP	Un navigateur, tel que Chrome, peut-il lui-même jouer le rôle d'IDP ? Les navigateurs peuvent utiliser les données de compte et de profil stockées comme source d'authentification fiable.	Étant donné que les navigateurs peuvent être modifiés (par exemple, via des extensions), aucune affirmation de validation d'adresse e-mail effectuée directement par le navigateur ne peut être fiable sans validation supplémentaire sur le serveur. Par conséquent, une solution purement basée sur le client n'est pas recommandée. Pour en savoir plus sur ce problème, cliquez ici.
Spécification de l'API	Discussion sur la question de savoir si le paramètre de l'algorithme IdentityCredential.disconnect() doit être obligatoire ou facultatif.	Ce problème est désormais résolu. Pour en savoir plus, cliquez ici.
Sécurité des API	Problèmes liés à la fuite de jetons dans le processus de connexion FedCM si un RP présente une faille XSS. Un pirate informatique peut exécuter navigator.credentials.get dans du code malveillant pour obtenir le jeton.	FedCM ne crée pas de nouveaux risques XSS. Ces risques sont inhérents aux applications Web et aux protocoles d'authentification existants. Pour atténuer ces risques, les RP doivent vérifier la revendication aud dans les jetons d'ID et n'accepter que les assertions émises dans leur propre origine. Comme indiqué ici, il existe aujourd'hui des bonnes pratiques largement établies pour sécuriser cet échange de jetons, qui peuvent être utilisées avec FedCM. De plus, l'API Storage Access peut être utilisée avec FedCM, et les appels de l'API Storage Access sont automatiquement accordés lorsqu'un appel FedCM précédent a été effectué. Cela devrait activer le flux de redirection intégré décrit dans le problème GitHub.
Spécification de l'API	Le champ client_metadata_endpoint est obligatoire dans la réponse du point de terminaison de configuration pour FedCM. Un objet vide est une réponse valide, et Chromium ignore silencieusement une réponse 404, ce qui suggère que le point de terminaison est traité comme facultatif dans la pratique.	Nous sommes d'accord pour que la spécification soit modifiée pour refléter ce point et que le champ client_metadata_endpoint soit défini comme facultatif.
Utilisation de l'API	Questions concernant la difficulté de tester les implémentations FedCM en raison d'interfaces utilisateur contrôlées par le navigateur qui ne sont pas accessibles via le DOM.	Nous acceptons les API d'automatisation du navigateur pour les tests de régression, ce qui peut résoudre ces problèmes. Pour en savoir plus sur ces API, cliquez ici.
Spécification de l'API	Le paramètre login_url, qui est une partie obligatoire de la réponse du point de terminaison de configuration, n'a pas été documenté dans la section 3.2 de la spécification.	Nous avons mis à jour la documentation pour inclure le paramètre login_url dans la section 3.2.
Spécification de l'API	Préoccupation concernant un vecteur de suivi potentiel dans FedCM. Un fournisseur d'identité peut insérer des ID en tant que paramètres de chemin d'accès dans les points de terminaison spécifiés dans la réponse du point de terminaison de configuration (accounts_endpoint, client_metadata_endpoint) et utiliser ces ID pour mettre en corrélation les requêtes de compte et de métadonnées client.	Bien que nous n'ayons pas de preuve que les IdP insèrent des ID dans ces points de terminaison, nous étudions activement des mesures d'atténuation pour résoudre ce problème ici.

Lutter contre le spam et la fraude

API Private State Tokens (et autres API)