Rapport de commentaires – T2 2025

Rapport trimestriel pour le deuxième 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 couvre les progrès de Google concernant les propositions de la Privacy Sandbox, les nouvelles attentes en termes de calendrier, des explications détaillées sur la façon dont Google a pris en compte les observations faites par des 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 tient régulièrement la CMA informée de l'avancement des propositions Privacy Sandbox lors de ses réunions d'état prévues conformément au paragraphe 17(b) des Engagements. L'équipe gère également la documentation pour les développeurs, qui fournit des présentations des principales fonctionnalités de publicité privée et des modifications apportées aux cookies, ainsi que des informations sur l'implémentation de l'API et l'état. Les principales nouveautés sont annoncées sur le blog des développeurs, et des informations ciblées sont envoyées aux listes de diffusion des développeurs.

Tenir compte des observations faites par des tiers

Glossaire des acronymes

ARA
API Attribution Reporting
CHIPS
Cookies ayant un état partitionné indépendant
DSP
Plate-forme côté demande
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Fournisseur d'identité
IETF
Internet Engineering Task Force
IP
Adresse IP (Internet Protocol)
openRTB
Enchères en temps réel
Prolongation
Origin Trial
API PA
API Protected Audience (anciennement FLEDGE)
PatCG
Groupe de la communauté privée sur les technologies publicitaires
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
Aveuglement volontaire concernant la propriété intellectuelle

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

Thème du commentaire Résumé Réponse Chrome
Avenir de la Privacy Sandbox Suite à l'annonce de ne pas procéder à l'introduction d'un mécanisme de choix de l'utilisateur pour les 3PC, certaines API sont plus utiles que d'autres lorsque des 3PC sont présents, et d'autres devront évoluer pour être utiles. Chrome pourrait investir dans d'autres domaines en plus des API Privacy Sandbox. Nous vous remercions pour vos commentaires et continuons d'échanger avec les parties prenantes afin d'évaluer le rôle que les API Privacy Sandbox peuvent jouer à l'avenir, ainsi que d'explorer de nouveaux domaines d'investissement futur, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Privacy Sandbox Certains participants à l'écosystème sont déçus de l'annonce de ne pas procéder à l'introduction d'un mécanisme de choix de l'utilisateur pour les 3PC, mais sont fiers du travail accompli. Ils apprécient les défis techniques au sein de la Privacy Sandbox et ont souligné la valeur de leur relation de travail collaborative avec Chrome et l'utilité de la subvention pour les tests de marché. Nous vous remercions de vos commentaires et reconnaissons que Chrome peut et doit collaborer avec les développeurs pour créer des technologies qui améliorent la confidentialité en ligne tout en préservant un Internet avec des publicités.
Partage des données du navigateur Le partage de données par le biais du navigateur est une technologie intéressante qui peut permettre de résoudre les problèmes d'inefficacité du marché et de confiance. Le navigateur a de la valeur en tant que contexte d'exécution tiers pour la collaboration. Nous vous remercions de vos commentaires et sommes d'accord pour dire que Chrome peut et doit jouer un rôle en aidant les développeurs à créer des technologies qui renforcent la confiance entre les développeurs et les utilisateurs.
Trafic Chrome Quelle est la part du trafic sans cookies sur Chrome et la part du trafic pour le mode navigation privée ? Comme l'a indiqué la CMA dans son avis d'intention de publier des engagements, le mode navigation privée n'affecte qu'une très petite partie de l'activité de navigation. Dans le Royaume-Uni et l'EEE, le mode navigation privée de Chrome représente moins de 10 % des navigations sur les appareils fonctionnant sous le système d'exploitation Android et moins de 10 % des navigations sur les appareils fonctionnant sous le système d'exploitation Windows. Ces métriques ne concernent que les navigations sur Chrome basé sur Chromium au Royaume-Uni et dans l'EEE.
Nous ne partageons pas de données sur les navigateurs qui bloquent les cookies tiers.
Les développeurs peuvent déterminer quand les cookies sont partitionnés à l'aide des en-têtes d'accès au stockage et utiliser les atténuations disponibles en conséquence.
Libellés de test Chrome Que prévoit Chrome pour le 1 % de trafic sans cookies qui a été activé pour les tests en 2024 ? Nous n'avons pas d'informations à vous communiquer pour le moment, mais nous prévoyons de les partager publiquement dès qu'elles seront disponibles.
Chrome Testing La configuration actuelle des libellés de test inclut-elle un traitement pour les scénarios où les deux cookies tiers sont disponibles et où les API Privacy Sandbox sont activées ? La configuration actuelle des libellés de test inclut un traitement pour les 3PC et les API Privacy Sandbox sous la forme du mode A.
Privacy Sandbox Certains annonceurs trouvent les API Privacy Sandbox complexes et sont apathiques en raison des exercices de préparation précédents. Ils se demandent comment quantifier l'avantage pour les premiers utilisateurs et recherchent des informations sur les effets du retargeting, de la prospection et de la mesure. Nous vous remercions de vos commentaires et comprenons vos sentiments concernant la complexité technologique et les exercices de préparation.
Concernant la compréhension des performances des technologies Privacy Sandbox actuelles, les résultats de nos tests ont indiqué que la participation de l'écosystème est un facteur essentiel pour comprendre les performances des solutions Privacy Sandbox. Les tests à faible volume n'ont pas permis de reproduire la dynamique du marché ni les incitations à utiliser les technologies à grande échelle.

Inscription et attestation

Aucun commentaire reçu ce trimestre.

Afficher des annonces et des contenus pertinents

Thèmes

Thème du commentaire Résumé Réponse Chrome
Intérêt pour les performances et l'utilité de l'API Topics avec des améliorations Les commentaires des parties prenantes côté achat indiquent que l'API Topics est un signal précieux et qu'elle génère des données de coût par impression (CPM) compétitives par rapport à celles des audiences 3PC pour les campagnes des annonceurs. Certains éditeurs considèrent que le signal de l'API Topics est de meilleure qualité que les signaux Web ouverts standards. Compte tenu de ces commentaires sur l'utilité de l'API Topics, les parties prenantes demandent des améliorations, comme l'amélioration de la fidélité et de la cohérence de la taxonomie, ainsi que l'extension des contrôles des éditeurs pour favoriser une adoption plus large. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Utilité pour
différents types de
parties prenantes		 É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 proposant des contenus variés contribuent à des thèmes génériques, tandis que les petits sites contribuent à des thèmes de niche ayant plus de valeur publicitaire. Notre réponse est similaire à celle des trimestres précédents :
Comme pour les cookies tiers, la valeur des informations fournies par les différents sites varie. La contribution des sites d'intérêt spécifique est incohérente : tous les sites d'intérêt spécifique ne proposent pas de contenu à valeur commerciale et contribuent donc moins. Il s'agit des sites qui bénéficieront de l'API Topics. Nous avons envisagé la possibilité de classer les pages plutôt que les sites, mais une telle classification pose un certain nombre de problèmes importants en termes de confidentialité et de sécurité.
Taxonomie des thèmes pas assez précise L'API Topics ne fournit pas une précision suffisante pour les éditeurs d'actualités dont le contenu est divisé en sections variées au sein d'un même domaine, ce qui peut limiter l'utilité de l'API pour le ciblage des annonces. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Amélioration du classificateur Autoriser les éditeurs à accorder à Chrome l'autorisation de classer les thèmes en fonction du contenu des pages (par exemple, l'en-tête et le corps). Nous examinons cette demande et vous invitons à nous faire part de vos commentaires ici.
Règle Demande de clarification concernant les consignes relatives à l'utilisation de l'API Topics en association avec des informations tierces. L'utilisation conjointe de l'API Topics et des cookies tiers ne pose aucun problème, car l'API Topics fournit un sous-ensemble des fonctionnalités des cookies tiers.
En-tête "Observer-Browse-Topics" Demande de clarification sur l'implémentation de l'en-tête "Observe-Browse-Topics", en particulier pour savoir si le fait de renvoyer l'en-tête en continu pourrait poser problème. Le renvoi continu de l'en-tête Observe-Browse-Topics: ?1 n'entraînera aucun problème technique.
Le navigateur gère ce signal de manière efficace, en notant simplement que la visite de la page est éligible au calcul des thèmes, sans provoquer de duplication ni d'erreurs. Bien que cela ne soit pas obligatoire sur chaque page, l'envoyer en tant qu'en-tête standard sur tous les documents de premier niveau est une stratégie simple et valide.
Catégories de taxonomie Demande de mise à jour de la dernière taxonomie Topics avec de nouveaux thèmes. Nous examinons cette demande et vous invitons à nous faire part de vos commentaires supplémentaires sur l'écosystème ici.
Valeurs nulles Demande de conseils pour améliorer les performances de l'API Topics et comprendre les raisons des réponses nulles, telles que le filtrage ou la sensibilité. Pour plus de clarté, les réponses null ou vides de l'API Topics sont une fonctionnalité de confidentialité attendue, et non une erreur.
Une réponse null peut être due aux raisons suivantes :
• Règles de confidentialité : il existe 5 % de chances aléatoires d'obtenir une réponse null, ou votre script n'a pas "observé" l'utilisateur sur des sites liés à ce thème.
• État de l'utilisateur : historique de navigation insuffisant, utilisation du mode navigation privée ou l'utilisateur a désactivé les paramètres de confidentialité des annonces dans Chrome.
• Erreurs techniques : les sites d'éditeurs doivent envoyer l'en-tête Observe-Browse-Topics: ?1, et tous les iFrames appelants nécessitent l'autorisation allow="Browse-topics".
Pour examiner le problème, utilisez la page de débogage chrome://topics-internals pour voir les thèmes calculés par votre navigateur et pourquoi.
Bien que les fonctionnalités de confidentialité empêchent un taux de remplissage de 100 %, vous pouvez améliorer les performances en :
• travaillant avec les éditeurs : assurez-vous que vos partenaires envoient correctement l'en-tête Observe-Browse-Topics: ?1 sur leurs sites.
• Vérifier votre code : si vous utilisez des iFrames, vérifiez que la règle allow="Browse-topics" est en place.

API Protected Audience

Thème du commentaire Résumé Réponse Chrome
L'adoption de l'API PA est freinée par le coût et la complexité Les utilisateurs qui ont adopté l'API Protected Audience (PA API) la dépriorisent ou la rétablissent, en invoquant les coûts opérationnels, le manque de demande des annonceurs et le faible volume d'inventaire des plates-formes d'échange.
Certains commentaires ont souligné les avantages potentiels de l'API PA, comme sa capacité à fournir des audiences durables et une couverture supérieure grâce à un taux de correspondance élevé.		 Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Fonctionnalité multiplate-forme La fonctionnalité multiplate-forme doit être prise en charge en utilisant l'API PA sur toutes les plates-formes pour débloquer de meilleures capacités de remarketing et de ciblage d'audience. Google doit permettre d'accéder aux groupes d'intérêt enregistrés dans Chrome lors de la diffusion d'annonces dans des environnements natifs ou dans une WebView, et les groupes d'intérêt enregistrés dans Android doivent être disponibles dans les enchères Chrome. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
directFromSellerSignals En limitant la quantité d'informations disponibles dans l'enchère contextuelle, les participants aux enchères sont toujours redirigés vers le serveur publicitaire de Google. Un éditeur doit d'abord appeler tous ses partenaires d'échange, puis Google Ad Manager (GAM) pour exécuter l'enchère contextuelle et enfin autoriser GAM à appeler les enchères IG. Sans connaître le résultat de l'enchère contextuelle en temps réel, aucun concurrent ne peut orchestrer une décision de haut niveau de manière équitable.

La fonctionnalité directFromSellerSignals de l'API PA peut manquer de transparence concernant les informations sur les enchères, ce qui peut empêcher l'accès aux données nécessaires. Google doit supprimer directFromSellerSignals ou le mettre à jour pour qu'il ne puisse pas être utilisé pour masquer le prix de compensation des enchères de l'ad server. Par exemple, le prix contextuel peut être transmis via Chrome dans un champ transparent, immuable et signé auquel tous les participants aux enchères (et l'éditeur) peuvent accéder et qu'ils peuvent vérifier.		 Notre réponse reste la même que lors des trimestres précédents :
Réponse de Chrome :
Les informations transmises à runAdAuction() ne sont pas censées provenir du vendeur, sauf si celui-ci appelle runAdAuction() depuis sa propre iFrame. Dans une enchère multiseller, il devient impossible de demander à tous les vendeurs de créer le frame appelant runAdAuction(). directFromSellerSignals a résolu ce problème en chargeant le contenu à partir d'un bundle de sous-ressources chargé à partir de l'origine d'un vendeur. Cela garantit que l'authenticité et l'intégrité des informations transmises à une enchère à partir des configurations d'enchères du vendeur ne peuvent pas être manipulées. Si les éditeurs souhaitent utiliser l'API PA pour comprendre les informations que leurs fournisseurs de technologie transmettent aux enchères PA, ils peuvent demander cette fonctionnalité à ces fournisseurs.
Réponse de Google Ad Manager :
Nous nous efforçons depuis des années de garantir l'équité des enchères. Nous nous sommes notamment engagés à ne partager avec aucun acheteur le prix d'une source publicitaire non garantie d'un éditeur, y compris le prix d'un élément de campagne non garanti, avant qu'il n'enchérisse lors de l'enchère. Nous avons ensuite réaffirmé cet engagement dans nos engagements envers l'Autorité de la concurrence française.
Pour les enchères Protected Audience, nous avons l'intention de tenir notre promesse en utilisant directFromSellerSignals et en ne partageant l'enchère d'aucun participant aux enchères avec un autre participant avant la fin des enchères multivendeurs. Pour être clair, nous ne partagerons pas non plus le prix de l'enchère contextuelle avec notre propre enchère par composant, comme expliqué dans cette mise à jour.
Rapports Demande d'ajout d'une entité d'analyse/de reporting pour activer le reporting centralisé. Nous discutons de cette demande ici et nous serions ravis de recevoir d'autres commentaires.
k-anonymat sur buyerReportingId Possibilité d'ignorer les enchères en fonction de la k-anonymité de "buyerReportingId" pour faciliter la sélection d'audience et les obligations de reporting avec les fournisseurs de données tiers. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Débogage amélioré dans le script generateBid Demande d'un mécanisme permettant d'identifier rapidement l'étape ou le "point d'arrêt" spécifique du script generateBid où le processus échoue. Nous sommes conscients de l'utilisation souhaitée des mesures en temps réel comme mécanisme de définition de points d'arrêt pour les enchères sur l'appareil. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Écouteurs d'événements pour surveiller l'état runAdAuction Proposition d'ajouter la prise en charge des écouteurs d'événements à la fonction navigator.runAdAuction de l'API PA afin d'améliorer la surveillance du cycle de vie des enchères publicitaires. Nous examinons cette demande et vous invitons à nous faire part de vos commentaires supplémentaires sur l'écosystème ici.
Utilisation de l'API Demande de clarification sur la façon dont l'API PA et l'API Attribution Reporting (ARA) peuvent prendre en charge les cas d'utilisation de la publicité sur le Web en l'absence de cookies tiers, en particulier pour les utilisateurs qui ont désactivé les cookies tiers, mais pas les API Privacy Sandbox, et dans les scénarios impliquant des synchronisations de cookies et des WebView ayant échoué. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Latence La latence associée à l'API PA peut freiner l'adoption, car les éditeurs peuvent choisir de la désactiver si la latence est trop élevée. Nous avons apporté plusieurs améliorations à la latence sur l'appareil au cours des derniers trimestres. La création et la mise à l'échelle des services d'enchères et de mise aux enchères (B&A) se poursuivent si nécessaire. Notre guide des bonnes pratiques concernant la latence a été mis à jour pour inclure plus d'informations sur la façon de tirer parti de ces fonctionnalités. Nous étudions également le développement de nouvelles améliorations de la latence, dont certaines sont consultables ici.
Comportement de journalisation dans B&A (test vs production) Clarification concernant les différences de comportement de journalisation entre les modes test et production pour les services d'enchères et de mise aux enchères. Plus précisément, la disponibilité des journaux cloud et l'impact du mode production sur la journalisation. Tout d'abord, il est important de faire la distinction entre les versions de production et de non-production et le paramètre TEST_MODE distinct, qui active simplement une clé de chiffrement de test codée en dur. L'explication ci-dessous se concentre sur les types de compilation.
Dans les compilations non_prod, les serveurs B&A disposent d'un niveau de verbosité configurable pour la journalisation. Ces journaux détaillés sont écrits dans les flux stdout/stderr standards. Sur Google Cloud, ils sont accessibles via l'interface de journalisation native. Sur Amazon Web Services, ils se trouvent dans les journaux de la console associée.
Pour les versions de production, le comportement de journalisation est plus limité. Le niveau de verbosité est fixe et ne peut pas être modifié. Bien que certains journaux non liés à la confidentialité, tels que les messages de démarrage du serveur et la plupart des erreurs de plantage, soient toujours imprimés sur stdout/stderr, aucun journal spécifique aux requêtes n'est disponible via ce canal. Les seuls journaux par requête d'une version de production concernent les requêtes contenant un jeton de débogage consenti. Ils sont exportés exclusivement via OpenTelemetry. Il est important d'utiliser le débogage consenti avec parcimonie, car un trafic important peut dégrader les performances du serveur et entraîner des échecs de vérification de l'état.
Concernant les métriques, elles sont toutes exportées via OpenTelemetry. Les métriques non sensibles en termes de confidentialité sont toujours exportées telles quelles, sans "bruit". À l'inverse, les métriques sensibles à la confidentialité sont toujours "bruyantes" lorsqu'elles sont exportées à partir d'un serveur exécuté en mode production. La configuration de télémétrie spécifique détermine si ces métriques sensibles à la confidentialité sont exportées avec ou sans bruit, ou les deux.
Inclure le chemin d'accès complet à la page dans les signaux d'enchères fiables pour la brand safety Demande de mise à jour de l'API PA pour inclure le chemin d'URL complet de la page de premier niveau, en plus du nom d'hôte, dans la requête d'extraction pour trustedBiddingSignals.
Le principal cas d'utilisation consiste à activer des contrôles plus précis de la brand safety. Les annonceurs ont souvent besoin d'empêcher la diffusion d'annonces dans des sections spécifiques d'un domaine (par exemple, news-site.com/politics), tout en étant à l'aise avec le domaine en général. Ces listes de blocage pouvant contenir des millions d'entrées, elles doivent être évaluées côté serveur. La spécification actuelle, qui n'envoie que le nom d'hôte, empêche le serveur trustedBiddingSignals d'effectuer cette évaluation nécessaire au niveau du chemin d'accès, ce qui limite les capacités de sécurité de la marque.		 Nous discutons actuellement de ce problème ici, après de longues discussions précédentes, que vous pouvez consulter ici. Nous serons ravis de recevoir d'autres commentaires.
Toutefois, nous tenons à préciser que nous n'envisageons d'ajouter ces informations que lorsque la récupération de trustedBiddingSignals est effectuée sur un serveur s'exécutant dans un environnement d'exécution sécurisé (TEE).

Protected Auction (services d'enchères et de mise aux enchères)

Thème du commentaire Résumé Réponse Chrome
Tester la disponibilité Informations sur la disponibilité de Key/Value (KV) v2 pour les tests dans les environnements Chrome et B&A. KV v2 est disponible à la fois dans B&A et dans Chrome. Pour en savoir plus, cliquez ici.
Implémentation du serveur KV Demande de clarification sur l'utilisation du serveur KV, en particulier concernant le mappage des URL de rendu des créations aux données de requête, la nécessité d'une coordination entre les SSP et les DSP pour définir les paramètres dans l'URL de rendu, et la disponibilité de la documentation décrivant la coordination requise et le stockage des données en mode KV. Le service KV utilise renderURL comme clé. Si l'URL est nouvelle, elle est stockée. Si elle existe, sa valeur est renvoyée pour être utilisée dans scoreAd. Le format de retour dépend de la configuration : "Bring Your Own Server" (BYOS) autorise n'importe quelle valeur, tandis que le service Trusted KV nécessite une fonction définie par l'utilisateur.
Bien que cela ne soit pas toujours nécessaire, la coordination avec les DSP est essentielle pour les fonctionnalités telles que le remplacement de macros (par exemple, ${AD_WIDTH}) dans l'URL de rendu, ce qui permet de personnaliser et de valider les annonces de manière dynamique.
Nous vous recommandons de commencer par un test simple avec une seule DSP pour déterminer le niveau de coordination nécessaire. Nous sommes également en train de mettre à jour notre documentation sur les paires clé/valeur. Nous la partagerons publiquement dès qu'elle sera disponible.
BYOS pour B&A Pourquoi B&A ne propose-t-il pas de mode BYOS semblable à celui de KV ? Les enchères et les mises aux enchères nécessitent un TEE, ce qui empêche l'utilisation d'un modèle BYOS, car elles gèrent des combinaisons de données très sensibles qui nécessitent l'application de mécanismes de confidentialité, comme expliqué ci-dessous.
Pour les DSP :
B&A traite le contexte de l'éditeur (potentiellement l'URL complète si elle est explicitement envoyée par le vendeur via auctionSignals / perBuyerSignals) combiné à des données IG utilisateur détaillées. L'environnement d'exécution sécurisé est essentiel pour traiter cette combinaison de manière sécurisée et éviter une éventuelle réidentification de l'utilisateur. Dans KV BYOS, l'URL complète ne peut pas être envoyée.
Pour les SSP :
Le simple fait de connaître la combinaison des groupes d'identité participants (et de leurs DSP propriétaires) dans une enchère peut générer une signature d'identification. C'est là qu'intervient la solution de chaffing, qui nécessite l'utilisation d'un TEE.
Par conséquent, le traitement sécurisé de ces signaux sensibles combinés et l'application de mécanismes de confidentialité nécessitent l'environnement contrôlé et attesté d'un TEE.

Mesurer les annonces numériques

Attribution Reporting (et autres API)

Thème du commentaire Résumé Réponse Chrome
Règlement sur le bruit L'implémentation de l'ARA a été utile pour certains acteurs du marché, et Google devrait continuer à fournir des rapports au niveau des événements. Google devrait envisager d'assouplir le règlement sur le bruit dans les scénarios où l'ARA et les PC tiers sont disponibles. Les annonceurs axés sur les performances utilisent de plus en plus l'implémentation actuelle du champ "value" de l'événement flexible ARA. Une règle moins restrictive concernant le bruit permettrait de réduire les retards et les rapports inexacts. Ce mécanisme est un élément fondamental de la conception de l'ARA, qui vise à protéger la confidentialité des utilisateurs en empêchant le suivi individuel. Nous tenons compte des commentaires concernant les difficultés de reporting causées par le bruit. Nous continuons d'évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, ainsi que les améliorations potentielles, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Feuille de route et support à long terme Demander une feuille de route produit pour ARA, ainsi qu'une confirmation de l'investissement et de l'assistance à long terme suite à l'annonce de ne pas procéder à l'introduction d'un mécanisme de choix de l'utilisateur pour les cookies tiers. L'équipe Privacy Sandbox collabore avec l'écosystème pour comprendre le rôle que joueront les API Privacy Sandbox à l'avenir et évaluer les futurs investissements.
Mesure multi-environnements (application vers Web) Demande d'une solution impliquant l'utilisation d'ARA pour faciliter la mesure cross-environnement, offrant un flux de données plus propre et plus fiable, améliorant la capacité à connecter les interactions utilisateur sur différentes plates-formes. ARA prend déjà en charge les applications vers le Web sur le même appareil. Pour en savoir plus sur la solution de mesure cross-app et Web, cliquez ici et ici.
Attribution cross-navigateur Une approche unifiée et cross-browser de l'ARA permettrait d'améliorer considérablement la capacité à mesurer le ROI sur le Web ouvert et de fournir une alternative stable avant d'éventuels changements réglementaires. Chrome devrait collaborer avec l'équipe Safari sur une solution de ce type. Nous explorons déjà une API interopérable avec d'autres fournisseurs de navigateurs dans les groupes PATCG et PATWG du W3C. Étant donné que ce travail est préliminaire, les partenaires sont invités à consulter notre page de progression.
Mesure multi-appareil/hors connexion L'impossibilité de prendre en charge la mesure des conversions multi-appareils dans ARA constitue une limite importante. Il est également très important de mesurer les conversions en ligne vers hors connexion. Le navigateur pourrait jouer un rôle dans la collaboration avec les fournisseurs de mesure. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Attribution multitouch Demande visant à autoriser les annonceurs à utiliser les données Privacy Sandbox comme "vérité terrain" impartiale pour valider et calibrer leurs modèles d'attribution existants. Pour ce faire, vous pouvez utiliser les données fournies par le navigateur de l'ARA comme signal de calibration fiable, ce qui permet de créer une référence fiable. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Mesure du trafic sans consentement/désactivée Une solution respectueuse de la confidentialité, telle que l'attribution privée interopérable, permettrait de mesurer le trafic sans consentement. Cela permettrait de mieux comprendre les performances des campagnes en incluant les données des utilisateurs qui ont désactivé le suivi. Cela comblerait un manque important dans la mesure créé par les exigences de consentement. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Attribution de serveur à serveur Demande d'autorisation pour les ad techs disposant d'une infrastructure côté serveur sophistiquée afin de s'intégrer à l'ARA de manière plus flexible, en tenant compte des cas d'utilisation difficiles à gérer uniquement côté client, tout en préservant la confidentialité des utilisateurs. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.
Enregistrement multidomaine Demande de clarification sur les limites et les mises en garde lors de l'enregistrement de plusieurs domaines avec ARA, en particulier en ce qui concerne le service d'agrégation et l'attribution cross-origin. Vous trouverez ci-dessous les principales limites lorsque vous utilisez ARA avec plusieurs domaines :
• L'attribution est limitée à une seule origine. Vous ne pouvez pas faire correspondre un clic provenant de l'un de vos domaines à une conversion sur un autre. L'attribution est mise en bac à sable à la même origine pour la source et le déclencheur.
• Le service d'agrégation n'est pas compatible avec le traitement par lot multi-origines. Les rapports de différentes origines doivent être regroupés et traités séparément. Nous cherchons des moyens de le prendre en charge à l'avenir.
En bref, bien que plusieurs domaines puissent être enregistrés sous une même entité, toutes les fonctions ARA, telles que l'attribution et l'agrégation, doivent actuellement être gérées par origine.

Service d'agrégation

Aucun commentaire reçu ce trimestre.

API Private Aggregation

Thème du commentaire Résumé Réponse Chrome
Limites et niveaux de bruit Préoccupations concernant les limites de taille des clés d'agrégation et des valeurs d'agrégation dans l'API Private Aggregation. La taille des clés et des valeurs d'agrégation a été choisie pour offrir une grande précision tout en limitant les coûts de réseau et de stockage. Nous vous recommandons également d'utiliser le hachage lorsque vous attribuez des clés pour maximiser la flexibilité.
Bien que d'autres facteurs protègent les données utilisateur, l'ajout de bruit est un élément important des protections de confidentialité de l'API Private Aggregation.
Nous prenons en compte vos commentaires et continuerons d'évaluer les choix de paramètres appropriés, tout en tenant compte du rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 indiquant que l'approche actuelle consistant à offrir aux utilisateurs le choix des cookies tiers dans Chrome sera maintenue.
Confidentialité vs utilité L'approche de la Privacy Sandbox peut donner la priorité à la confidentialité plutôt qu'à l'utilité, ce qui peut entraver l'adoption. Suggestion visant à autoriser un partage plus précis des données avec le consentement de l'utilisateur pour améliorer la mesure et la personnalisation des annonces. La taille des clés et des valeurs d'agrégation a été choisie pour offrir une grande précision tout en limitant les coûts de réseau et de stockage. Nous vous recommandons également d'utiliser le hachage lorsque vous attribuez des clés pour maximiser la flexibilité.
Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google du avril 2025 indiquant que l'approche actuelle consistant à offrir aux utilisateurs le choix des cookies tiers dans Chrome sera maintenue.

Limiter le suivi dissimulé

Réduction de l'user-agent/User-Agent Client Hints

Thème du commentaire Résumé Réponse Chrome
Détection de spam Si la première requête d'un site Web qui utilise un système de détection du spam repose sur des indications du client, il est possible que le système de suivi ou de détection ne parvienne pas à identifier ni à catégoriser correctement la requête. Les cas d'utilisation qui nécessitent d'avoir accès aux hints client user-agent (UA-CH) lors de la première requête doivent utiliser les hints client critiques.
Commentaires sur l'API Envisagez d'abandonner Sec-CH-USA-Wow64, car il n'est plus pertinent pour le Web moderne. Nous examinons cette demande et vous invitons à nous faire part de vos commentaires ici. Nous avons également reçu des commentaires indiquant qu'il serait utile d'étendre wow64 au-delà de Windows.

Protection de l'adresse IP (anciennement Gnatcatcher)

Thème du commentaire Résumé Réponse Chrome
Commandes Demande d'activation/de désactivation de la protection de l'adresse IP pour que les sites l'utilisent de manière sélective en dehors du mode navigation privée. Nous vous remercions de vos commentaires et vous invitons à nous faire part d'autres informations sur ce problème ici.
Faute Les jetons de révélation probabiliste (PRT) qui génèrent une valeur NULL empêcheront-ils l'identification de l'auteur lorsque la police demandera la divulgation de l'adresse IP pour faute sur la plate-forme ? Si un domaine est utilisé exclusivement pour la détection des fraudes et des utilisations abusives, il est peu probable qu'il soit inclus dans la liste des domaines masqués (MDL, Masked Domain List). Il ne sera donc pas concerné par la protection de l'adresse IP. Par conséquent, les TRP ne seraient pas nécessaires pour ces domaines.
Si un domaine est inclus dans la MDL, les TRP sont actuellement le seul moyen de connaître l'adresse IP d'origine d'une requête proxy. Les PRT étant spécifiquement conçus pour l'analyse agrégée et non pour l'identification individuelle, il est vrai que les PRT ne contiennent pas d'adresse IP dans la plupart des cas. Nous pensons que l'impact sera limité dans le scénario décrit, car la protection de l'adresse IP ne s'applique qu'au contexte tiers. Cela signifie que les éditeurs continueront de recevoir des adresses IP non masquées pour les interactions directes, comme les utilisateurs qui visitent le site d'une plate-forme en ligne.
Lutte contre la fraude Quelles sont les spécificités des mesures antifraude de Google pour la protection de la propriété intellectuelle, y compris les détails sur la limitation du taux d'accès aux proxys et l'émission de jetons d'authentification ? Quels sont les cas d'utilisation spécifiques des jetons de protection des ressources ? Nous confirmons que les jetons d'authentification et la limitation du débit dans IP Protection sont conçus pour empêcher les robots de commettre des fraudes publicitaires en accédant de manière excessive aux proxys, comme indiqué dans la stratégie anti-fraude et anti-spam. D'autres cas d'utilisation des TRP sont décrits dans la documentation explicative sur les TRP, disponible ici.
Mode navigation privée La protection de l'adresse IP en mode navigation privée est-elle toujours prévue pour le troisième trimestre ? Aucune modification n'est actuellement prévue concernant le calendrier du troisième trimestre pour le lancement de la protection de la propriété intellectuelle en mode navigation privée.

Mesures d'atténuation du suivi des rebonds

Thème du commentaire Résumé Réponse Chrome
Commentaires sur l'API Chrome devrait bloquer l'accès aux cookies/au stockage plutôt que de les partitionner lors de l'application des mesures d'atténuation du suivi du rebond (BTM), en citant le comportement inattendu et la confusion causée par la méthode de "partitionnement" de Safari. Nous accueillons favorablement cette suggestion. Actuellement, BTM n'implique pas de partitionnement des cookies/du stockage, mais les supprime après un délai de grâce. Si des conceptions ultérieures de BTM impliquent une action immédiate sur les cookies, nous avons l'intention de privilégier le blocage des cookies plutôt que leur partitionnement.

Renforcer les limites de confidentialité intersites

Aucun commentaire reçu ce trimestre.

API Fenced Frames

Aucun commentaire reçu ce trimestre.

API Shared Storage

Thème du commentaire Résumé Réponse Chrome
Demande de fonctionnalité d'API Demande d'ajout des vues et des clics sur les annonces dans le stockage partagé. Nous prenons en compte ces commentaires pour évaluer le rôle que joueront les API Privacy Sandbox à l'avenir, à la lumière de l'annonce de Google en avril 2025 concernant le maintien de l'approche actuelle pour offrir aux utilisateurs le choix des cookies tiers dans Chrome.

CHIPS

Thème du commentaire Résumé Réponse Chrome
Question sur l'API Demande de clarification sur la façon dont les paramètres de cookies tiers de Chrome interagissent avec CHIPS, en particulier pour savoir si les cookies non partitionnés sont convertis en cookies partitionnés lorsque les cookies tiers sont désactivés, et si les cookies partitionnés restent actifs. Les cookies non partitionnés ne seront pas stockés, récupérés ni envoyés dans un contexte tiers lorsque les cookies tiers seront désactivés. Toutefois, les cookies partitionnés continueront d'être stockés, récupérés et envoyés dans un contexte tiers, car leur fonctionnalité n'est pas affectée par les paramètres du navigateur qui désactivent les cookies tiers.
Problème de confidentialité Crainte qu'une partie intégrée avec un identifiant persistant, comme pour l'authentification unique, puisse toujours permettre aux parties intégrantes et intégrées d'obtenir un identifiant numérique global, même avec des cookies partitionnés. Bien qu'une partie intégrée puisse disposer d'un identifiant persistant, cet identifiant, lorsqu'il est stocké dans un cookie partitionné, n'est accessible que sur le site où le cookie a été défini par l'intégration. La jointure multisite de cet identifiant nécessiterait une action de connexion, qui permet déjà l'échange d'un identifiant sous la forme d'un jeton d'authentification, même sans l'utilisation de cookies partitionnés.

FedCM

Thème du commentaire Résumé Réponse Chrome
Utilisation de l'API Échec de la médiation silencieuse pour les utilisateurs disposant de plusieurs comptes sans erreur spécifique. Le comportement de médiation silencieuse est une fonctionnalité de conception, car il est destiné à un cas très spécifique avec un seul compte disponible. Nous vous recommandons plutôt d'utiliser la médiation "facultative", dans laquelle FedCM revient à présenter à l'utilisateur un sélecteur de compte si la médiation silencieuse n'est pas possible.
Utilisation de l'API navigator.credentials.get renvoie des erreurs génériques, ce qui empêche la capture de motifs de refus spécifiques tels que la fermeture par l'utilisateur ou les périodes de refroidissement. L'impossibilité pour les développeurs de faire la distinction entre la fermeture de la boîte de dialogue FedCM par l'utilisateur, une erreur réseau ou une "période de refroidissement" de FedCM en raison de la fermeture précédente de la boîte de dialogue par l'utilisateur est également une fonctionnalité prévue, destinée à préserver la confidentialité de l'utilisateur. Le problème est qu'une telle fonctionnalité permettrait aux sites Web de déduire l'état de connexion de l'utilisateur sur différents fournisseurs d'identité (IdP).
Se connecter Nous avons observé un comportement incohérent de sélection de compte lorsque plusieurs comptes étaient connectés. Il n'est pas clair si l'impossibilité intermittente de sélectionner un compte spécifique dans un scénario de connexion à plusieurs comptes est un bug intermittent dans FedCM ou un problème lié au système de test. Nous collaborons avec le signalant pour résoudre ce problème et lui avons demandé de nous fournir plus de détails afin de mieux le comprendre.
Utilisation de l'API Si l'utilisateur ferme la boîte de dialogue lors de l'autorisation avec FedCM, le fait qu'il soit en état de refroidissement n'est pas signalé par une erreur détectable. Oui, ce serait le cas et cela générerait le code d'erreur générique afin de préserver la confidentialité des utilisateurs.
Utilisation de l'API Pourquoi FedCM passe-t-il en période de silence de 10 minutes après une "réauthentification automatique" réussie ? Étant donné que la réauthentification automatique se produit sans action initiée par l'utilisateur, si l'utilisateur souhaite revenir sur le site Web, mais se connecter avec un autre compte, il a besoin d'une période pendant laquelle FedCM ne le réauthentifie pas automatiquement. La "période de silence" permet aux utilisateurs de se connecter manuellement à l'aide d'un autre compte. Pour en savoir plus sur cette "période de silence", consultez cet article de blog.
Lightweight FedCM Craintes que la proposition Lightweight FedCM n'introduise une complexité supplémentaire pour les IdP en raison de la nécessité de prendre en charge deux implémentations incompatibles (FedCM et Lightweight FedCM). Lightweight FedCM est compatible avec FedCM traditionnel. Les IdP peuvent choisir la méthode d'implémentation à utiliser et ne seront pas tenus de prendre en charge les deux.
Lightweight FedCM est un mécanisme push pour FedCM. Si un IdP choisit d'utiliser cette fonctionnalité, il peut transmettre les informations de compte au navigateur lorsque l'utilisateur se connecte. Ainsi, lorsqu'une partie de confiance (RP) appelle FedCM, le compte est récupéré à partir du navigateur, au lieu du point de terminaison des comptes de l'IdP.
Lightweight FedCM Préoccupations concernant l'exposition des données utilisateur personnelles telles que le nom, l'adresse e-mail et la photo de profil au RP dans la proposition Lightweight FedCM. La proposition pour Lightweight FedCM a été mise à jour depuis la réception de ces commentaires, afin de supprimer le nom, l'adresse e-mail et l'image de profil de la réponse de la méthode.
Lightweight FedCM La gestion de plusieurs comptes connectés semble trop rigide dans la proposition Lightweight FedCM. La proposition ne prend actuellement pas en charge les durées de vie de session individuelles ni les états de connexion nuancés par compte. L'expiration est actuellement liée au fournisseur d'identité dans l'objet credentials. Nous avons noté l'expiration par compte comme une question ouverte et nous tiendrons compte de ces commentaires pour les futurs développements.
Lightweight FedCM La distinction entre "connecté" et "disponible pour la sélection" n'est pas clairement définie, ce qui pourrait avoir un impact sur l'expérience utilisateur pour la proposition Lightweight FedCM. Pour le moment, nous ne sommes pas en mesure de déterminer si un compte est connecté ou déconnecté dans l'interface utilisateur FedCM. Les comptes déconnectés ne doivent pas être listés.
Si un compte est déconnecté et listé, et qu'un utilisateur sélectionne le compte qui n'est pas activement connecté, l'API Continuation peut être utilisée pour que l'utilisateur se reconnecte.
Utilisation de l'API Incohérence entre le champ given_name dans getUserInfo et son utilisation dans l'UI FedCM. Ce problème a été discuté plus en détail avec Mozilla ici, afin de s'accorder sur la façon dont given_name doit être traité dans getUserInfo.
Utilisation de l'API Tous les champs utilisés dans l'UI à partir de IdentityProviderAccount ne sont pas fournis à getUserInfo, en particulier tel et username, ce qui suggère un besoin de synchronisation. La discussion avec Mozilla et d'autres membres du groupe de la communauté FedID progresse sur la question de la réconciliation des champs de IdentityProviderAccount qui sont envoyés à getUserInfo..
Enterprise FedCM Demande de prise en charge de FedCM pour les cas d'utilisation d'IdP Enterprise. Le problème clé est la nécessité d'un mécanisme fiable permettant aux IdP de signaler aux navigateurs que les administrateurs ont donné leur consentement préalable pour autoriser l'utilisateur à accéder à des RP spécifiques qui ne peuvent pas être imitées ni utilisées de manière abusive par les outils de suivi Web. Ce point a été abordé lors de la réunion du 22 avril du groupe de travail FedID (vous trouverez les notes de la réunion ici). Des combinaisons d'extensions de navigateur et de règles d'entreprise (pour les appareils gérés) ont été proposées comme solutions potentielles. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur ce problème ici.

Lutter contre le spam et la fraude

API Private State Token (et autres API)

Aucun commentaire reçu ce trimestre.