Rapport trimestriel du 4e trimestre 2022 récapitulant les commentaires de l'écosystème reçus sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.
Les thèmes des commentaires sont classés en fonction de leur prévalence par API. Pour ce faire, nous prenons la quantité de commentaires que l'équipe Chrome a reçus sur un thème donné et l'organisons par ordre décroissant. Les thèmes courants des commentaires ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquentes soulevées par les équipes internes de Google et les formulaires publics.
Plus précisément, les comptes rendus des réunions des organismes de normalisation du Web ont été examinés. Pour les commentaires directs, les enregistrements de Google des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires publics ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation pour déterminer la prévalence relative des thèmes émergents en lien avec chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifique aux fins de cet exercice de rapport public. En raison de l'objectif actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Fledge et Attribution Reporting.
Les commentaires reçus après la fin de la période de création de rapports en cours n'ont peut-être pas encore fait l'objet d'une réponse de Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Gestion des identifiants fédérés
- Lecteur d'empreinte digitale
- Ensembles propriétaires
- IAB
- Interactive Advertising Bureau
- IDP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- IP
- Adresse IP
- openRTB
- Enchères en temps réel
- Prolongation
- Essai Origin
- PatCG
- Groupe de la communauté sur les technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client User-Agent
- W3C
- World Wide Web Consortium
- WIPB
- Blanchement volontaire des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également indiqué au troisième trimestre) Utilité pour différents types de personnes concernées |
Inquiétudes concernant le fait que les technologies de la Privacy Sandbox favorisent les grands développeurs et que les sites de niche (plus petits) contribuent davantage que les sites génériques (plus grands) | Notre réponse n'a pas changé depuis la question 3: "Google s'est engagé auprès de la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en favorisant ses propres activités, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, quelle que soit leur taille. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. À mesure que les tests de la Privacy Sandbox avancent, l'une des questions clés que nous allons évaluer est la performance des nouvelles technologies pour différents types d'acteurs. À cet égard, les commentaires sont essentiels, en particulier ceux qui sont spécifiques et exploitables, qui peuvent nous aider à améliorer davantage les conceptions techniques. Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous encourageons la CMA à publier une note sur la conception des tests afin de fournir plus d'informations aux participants au marché et de leur donner l'occasion de commenter les approches proposées." |
| (également signalé au troisième trimestre) Demandes de documentation |
Demandes de ressources supplémentaires expliquant comment gérer les tests, l'analyse et l'implémentation | Mise à jour du 4e trimestre: Nous sommes ravis que les développeurs aient trouvé notre documentation actuelle utile. Nous nous engageons à en fournir davantage pour qu'ils puissent comprendre comment les nouvelles technologies peuvent les aider. Au cours du dernier trimestre, nous avons ajouté une section "Actualités et nouveautés " sur privacysandbox.com et publié un examen approfondi de la façon dont la Privacy Sandbox peut contribuer à améliorer la pertinence des annonces à l'avenir. Nous avons également organisé des permanences publiques pour les développeurs afin de partager des bonnes pratiques et des démonstrations, ainsi que des sessions de questions/réponses avec les responsables produit et d'ingénierie pour permettre des discussions et des questions en direct. |
| Core Web Vitals | Quel est l'impact de la latence des API Privacy Sandbox sur les Core Web Vitals ? | Limiter la latence au minimum est un objectif de conception clé des API Privacy Sandbox. Nous nous attendons actuellement à ce que la latence des API ait un impact minimal sur les Core Web Vitals d'un site, car la majorité des API sont appelées après l'affichage initial du site Web. Nous continuons de surveiller et d'apporter des améliorations pour réduire davantage la latence de chacune des API. Nous vous encourageons à continuer à effectuer des tests et à nous envoyer vos commentaires. La latence dans le processus d'enchères en temps réel est abordée dans la section FLEDGE sous "Performances des enchères FLEDGE". |
| Interopérabilité | Questions concernant l'interopérabilité avec d'autres solutions potentielles | L'objectif de la Privacy Sandbox est de protéger les utilisateurs contre le suivi intersites tout en répondant aux besoins de l'écosystème Web. Pour ce faire, nous abandonnons les anciennes technologies de navigateur qui permettent ce suivi intersites, comme les cookies tiers, et proposons à la place de nouvelles technologies conçues pour prendre en charge des cas d'utilisation spécifiques. Les propositions de la Privacy Sandbox renforcent la confidentialité en limitant les données qui quittent l'appareil d'un utilisateur. Les propositions ne limitent pas techniquement la capacité d'un site Web à partager ou à traiter les données collectées à partir du navigateur. Les technologies n'empêchent donc pas les entreprises de conclure des accords de "gestion des données" ou toute autre relation contractuelle similaire. De même, elles ne limitent pas la possibilité pour les utilisateurs d'accepter de partager leurs données par d'autres moyens. Pour plus de clarté, Google s'engage à appliquer les technologies de la Privacy Sandbox de la même manière à tous les sites Web, y compris aux produits et services Google. Une fois que Chrome aura cessé de prendre en charge les cookies tiers, Google s'engage également à ne pas utiliser d'autres données à caractère personnel, telles que l'historique de navigation Chrome synchronisé des utilisateurs, pour suivre les utilisateurs à des fins de ciblage ou de mesure de la publicité numérique. |
Afficher des publicités et des contenus pertinents
Thèmes
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Impact sur le classement dans la recherche Google | Demande de savoir si la compatibilité d'un site Web avec l'API Topics sera utilisée comme signal potentiel pour le classement des résultats de recherche Google | Certains sites Web peuvent choisir de désactiver l'API Topics. 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. Google a confirmé à la CMA que la recherche Google n'utiliserait pas la décision d'un site de désactiver l'API Topics comme signal de classement. |
| Classificateur de thèmes | Ajoutez l'URL et le contenu de la page en plus du nom d'hôte pour déterminer le sujet d'une page Web afin d'améliorer son utilité pour les différentes personnes concernées. | L'historique de navigation d'un utilisateur est actuellement classé en fonction des noms d'hôtes d'un site Web. Chrome continue d'évaluer les options permettant de prendre en compte les métadonnées au niveau de la page (telles que l'ensemble ou certains composants de l'URL et/ou du contenu de la page) dans la classification par thèmes. Toute amélioration de l'utilité doit être mise en balance avec les risques liés à la confidentialité et aux utilisations abusives. Par exemple, en ce qui concerne les métadonnées en particulier, voici quelques-uns des risques: - Les sites qui modifient les métadonnées au niveau de la page pour encoder des significations différentes (et potentiellement sensibles) dans les sujets ; - Les sites qui modifient les métadonnées au niveau de la page pour présenter leurs sujets de manière trompeuse dans un but lucratif ; - Les sites qui modifient les métadonnées au niveau de la page de manière dynamique pour suivre les utilisateurs sur plusieurs sites |
| (Également signalé au troisième trimestre) Impact sur les signaux first party |
Le signal "Topics" peut être très utile et, par conséquent, dévaloriser les autres signaux propriétaires basés sur les centres d'intérêt. | Notre réponse n'a pas changé depuis la question 3: "Nous pensons que la publicité ciblée par centres d'intérêt est un cas d'utilisation important pour le Web, et Topics est conçu pour prendre en charge ce cas d'utilisation. Comme indiqué dans notre rapport du troisième trimestre, d'autres acteurs de l'écosystème ont exprimé leur inquiétude quant à la pertinence de Topics. Dans tous les cas, l'amélioration de la taxonomie est un effort continu, et nous nous attendons à ce qu'elle évolue avec les tests et les commentaires de l'écosystème." |
| Mettre à jour la taxonomie | Comment la liste des taxonomies sera-t-elle mise à jour ? | Nous recherchons activement vos commentaires sur la taxonomie la plus utile pour l'écosystème. La taxonomie incluse dans la proposition initiale de l'API Topics était conçue pour permettre les tests fonctionnels. Chrome envisage activement plusieurs approches pour mettre à jour la taxonomie. Par exemple, Chrome peut utiliser une notion de valeur commerciale pour chaque sujet afin de déterminer la catégorie à inclure dans les prochaines itérations. |
| Performances du classificateur régional des thèmes | Classificateur de thèmes peu performant dans les domaines régionaux | L'amélioration du classificateur est un effort continu. D'après les commentaires que nous avons reçus, nous envisageons d'étendre la liste de forçage de Topics. Notre analyse montre que cela augmentera la couverture mondiale et améliorera la précision. Pour expliquer, la classification de l'API Topics comporte deux composants pertinents: (1) une liste de forçage contenant les 10 000 sites les plus populaires et leurs thèmes, et (2) un modèle de ML sur l'appareil qui classe les noms d'hôte en thèmes. En développant la liste de forçage (1), nous pouvons améliorer les performances de classification pour les régions dans lesquelles le classificateur peut être moins performant. |
| Époque d'une semaine | L'époque d'une semaine est trop longue pour les utilisateurs qui souhaitent prendre des décisions à court terme. | Nous étudions actuellement la durée appropriée de l'épopée et nous serions ravis de recevoir d'autres commentaires sur la durée qui serait la plus adaptée à l'écosystème. |
| Récupération de l'en-tête HTTP | Inquiétude concernant le manque d'informations sur la récupération des sujets dans l'en-tête HTTP | Des travaux sont en cours pour les en-têtes et fetch(). Vous trouverez également des informations sur cette page. Nous avons également ajouté des informations sur skipObservation à la vidéo explicative. |
| Les thèmes visent uniquement à aider les annonceurs, et non les utilisateurs. | Topics/Privacy Sandbox semble être une approche axée sur le secteur. Les avantages pour les utilisateurs ne sont pas aussi clairs que ceux pour le secteur. | Nous pensons que Topics présente un avantage pour les utilisateurs, car il permet de diffuser des annonces ciblées par centres d'intérêt qui préservent la sans frais et l'ouverture du Web. Nous pensons également qu'il améliore considérablement la confidentialité par rapport aux cookies tiers. Supprimer les cookies tiers sans proposer d'alternatives viables peut avoir un impact négatif sur les éditeurs et entraîner des approches plus mauvaises, moins respectueuses de la confidentialité, moins transparentes et qui ne peuvent pas être réinitialisées ni contrôlées par les utilisateurs. De nombreuses entreprises testent activement les API Topics et Sandbox. Nous nous engageons à fournir les outils nécessaires pour améliorer la confidentialité et soutenir le Web. Le Technical Architecture Group du W3C a récemment publié son point de vue initial sur l'API Topics, auquel nous répondrons publiquement. À ce stade, Google a reçu des questions de l'écosystème concernant les conséquences potentielles de cet examen sur le développement et le lancement de l'API Topics. Nous souhaitons donc confirmer notre intention de la rendre disponible dans Chrome Stable cette année. Bien que Google apprécie les commentaires du groupe d'architecture technique du W3C, il considère qu'il est d'une importance capitale de poursuivre les efforts de développement et de test de Topics en consultation avec la CMA et l'écosystème. |
| Fuite de données | Inquiétude concernant la fuite de thèmes vers d'autres sites sans autorisation | La conception de l'API Topics rend très peu probable que les données d'un seul éditeur (ou même d'un petit groupe d'éditeurs) puissent être divulguées de quelque manière que ce soit. Les sites Web des éditeurs ont également un contrôle total sur l'API Topics et peuvent interdire l'accès à cette API via une règle d'autorisation. |
| Manque d'annonceurs pour les tests | Les éditeurs craignent de ne pas pouvoir démontrer la valeur de Topics aux annonceurs. | Au second semestre 2023, nous prévoyons de rendre toutes les API liées aux annonces disponibles pour les tests d'intégration et d'analyser l'écosystème de la valeur de Topics pour les annonceurs. Les tests et la publication des résultats seront supervisés par la CMA, qui examinera les données, l'analyse et la méthodologie. L'écosystème est invité à partager ses commentaires avec Google et la CMA. |
| Topics et FLEDGE | Demande d'informations sur l'utilisation de Topics dans la logique d'enchères de FLEDGE | Vous pouvez utiliser les thèmes dans la logique d'enchères de FLEDGE. Un guide d'intégration est également en cours d'élaboration et inclura des informations supplémentaires sur l'implémentation. |
| Classement personnalisé pour l'appelant de thèmes | Autoriser les classements à être personnalisés par l'appelant | Le problème avec le classement ou les valeurs des thèmes personnalisés pour chaque technologie publicitaire est qu'ils peuvent devenir un mécanisme par lequel une technologie publicitaire peut influencer les thèmes renvoyés, et donc un vecteur d'empreinte digitale. |
| Liste de priorité des appelants pour les sujets | Autorisez les appelants à fournir une liste de thèmes classés par priorité que l'API Topics renverra en fonction de l'éligibilité. | Nous étudions actuellement cette idée plus en détail et nous sommes à l'écoute de vos commentaires. |
FLEDGE
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Google Ad Manager | Inquiétude concernant le fait que Google Ad Manager soit le décideur final pour les enchères FLEDGE et qu'il favoriserait les tags Google Publisher et Google Ad Manager. | FLEDGE permet à chaque éditeur de choisir la structure des enchères, y compris les vendeurs de composants et de niveau supérieur. Chaque acheteur et vendeur participant à une mise aux enchères de composants sait qui est le vendeur de premier niveau et peut choisir de définir ou non une enchère. |
| Nombre de participants insuffisant pour tester FLEDGE | Demande visant à encourager davantage d'entreprises à tester FLEDGE, par exemple en améliorant les fonctionnalités de l'API et en décourageant les alternatives intrusives pour la confidentialité telles que l'empreinte digitale | Privacy Sandbox avance par étapes, en partenariat étroit avec la CMA et l'ICO, et les tests fonctionnels de FLEDGE ont démontré la stabilité et les fonctionnalités nécessaires. Google continue d'encourager l'écosystème à tester les API Sandbox. Il a récemment publié la documentation Maximiser la pertinence des annonces pour montrer comment FLEDGE et d'autres API peuvent aider à prendre en charge des cas d'utilisation essentiels pour le secteur de la publicité après l'abandon des cookies tiers. D'autres éléments de la Privacy Sandbox sont déjà compatibles avec des mesures d'atténuation du suivi (voir UA-CH, Protection de l'adresse IP et Atténuation du suivi des rebonds). Ils continueront de s'améliorer au fil du temps. L'objectif de Google n'est pas de faire de FLEDGE la seule solution de ciblage viable. Nous restons engagés à travailler en partenariat avec les acteurs du secteur et les autorités de régulation pour promouvoir les meilleures technologies publicitaires protégeant la confidentialité dans le navigateur Chrome. |
| Cas d'utilisation du machine learning | Plus d'informations sur les cas d'utilisation du machine learning pour entraîner des algorithmes d'enchères seront disponibles dans FLEDGE et les rapports sur l'attribution | Nous sommes conscients de la nécessité d'aider les testeurs à trouver les moyens les plus utiles d'appliquer les technologies de la Privacy Sandbox. Nous avons commencé à publier des consignes spécifiques à l'utilisation des différents aspects des API Privacy Sandbox comme entrées pour le machine learning. Le plus récent, Maximiser la pertinence des annonces, explique comment le secteur de la publicité peut utiliser ces signaux pour le machine learning. Nous prévoyons de continuer à publier de telles recommandations à l'avenir. |
| Interroger le serveur de clés-valeurs (K/V) FLEDGE | Pourquoi le serveur de clés-valeurs est-il accessible en public ? | Le serveur de clés-valeurs vise à fournir des signaux en temps réel aux enchères FLEDGE. Par conséquent, le serveur de clés-valeurs doit être accessible à partir de l'emplacement où ces enchères FLEDGE sont exécutées, à savoir sur les appareils des utilisateurs. Il doit donc être accessible au public. Une valeur stockée sur le serveur de clés-valeurs ne peut être récupérée que par un tiers qui dispose déjà de la clé. Par conséquent, si une technologie publicitaire ne donne les clés qu'aux navigateurs appartenant à l'API Interest Group et n'utilise pas de clés pouvant être devinées de manière aléatoire, seuls les navigateurs qui ont besoin de la valeur pour exécuter leur mise aux enchères pourront la récupérer. |
| Comment cibler une date/une heure ? | Compatibilité avec les objets de date dans la fonction de logique d'enchères. | Vous disposez pour cela de plusieurs méthodes. Les acheteurs peuvent demander à leur vendeur de leur indiquer la date et l'heure actuelles. Les vendeurs doivent pouvoir fournir facilement ces informations à tous les acheteurs. Les acheteurs peuvent également fournir la date et l'heure dans leur réponse clé-valeur en temps réel. Enfin, les acheteurs peuvent fournir la date et l'heure dans leur réponse contextuelle dans les signaux par acheteur, que le vendeur peut transmettre au script generateBid de l'acheteur. |
| Préférences utilisateur | Possibilité pour les utilisateurs de choisir de bloquer les créations par annonceur lorsqu'elles sont diffusées via FLEDGE ou d'opter pour des solutions alternatives. | Les utilisateurs peuvent désactiver les API Ads dans Chrome. Pour les annonces spécifiques, la technologie publicitaire concernée est la partie la mieux placée pour contrôler les créations diffusées ou la manière dont elles sont sélectionnées. |
| Des délais plus clairs | Demandez plus d'informations sur la disponibilité des protections de la confidentialité dans FLEDGE, comme l'obligation d'utiliser des cadres clôturés. | Nous prévoyons de publier un calendrier plus détaillé au cours du premier trimestre. |
| Signaler une confusion | Demande d'informations plus claires sur le fonctionnement des rapports FLEDGE avec d'autres API telles que Fenced Frames et l'API Private Aggregation. | Nous prévoyons de publier une vidéo expliquant l'interaction entre l'API Private Aggregation, FLEDGE et les cadres verrouillés dans les semaines à venir. |
| Enchères en temps réel et FLEDGE | Conseils sur l'intégration de FLEDGE aux enchères en temps réel standards. | Les deux principaux facteurs qui compliquent la capacité d'une technologie publicitaire à effectuer des enchères en temps réel sont l'accès aux données au niveau des événements et une intégration plus facile à l'ARA. Nous prévoyons de vous envoyer des informations et des explications à ce sujet au premier trimestre. |
| Performances des enchères FLEDGE | Rapport des testeurs indiquant que les enchères FLEDGE présentent une latence élevée | Nous apprécions les rapports des testeurs qui partagent leurs résultats et leurs cas d'utilisation. Nous avons également partagé quelques suggestions pour améliorer les performances de FLEDGE. En parallèle, nous avons ajouté des outils au navigateur permettant aux développeurs de mieux diagnostiquer les causes de la lenteur des enchères et nous avons systématiquement traité les principales sources de latence observées. Parmi les améliorations récentes figurent les temps de pause pour les enchères lentes, une technique de filtrage rapide des enchérisseurs, un moyen de réutiliser les worklets FLEDGE pour éviter de payer des coûts de démarrage et des travaux en cours pour permettre à la demande d'annonces contextuelles de s'exécuter en parallèle avec le temps de démarrage de FLEDGE et les récupérations réseau. Nous nous attendons à ce que l'optimisation de la latence continue d'être un sujet de discussion entre les développeurs Chrome et les testeurs FLEDGE, en fonction de leur expérience réelle avec l'API. |
| Limite de mémoire pour la taille des groupes de centres d'intérêt | Demande d'augmentation de la limite de taille d'un seul groupe de centres d'intérêt de 50 ko. | Nous examinons actuellement votre demande et demandons votre avis sur la valeur de limite qui fonctionne. |
| Combiner les données diffusées par FLEDGE avec le cookie first party | FLEDGE sera-t-il compatible avec l'intégration des données first party d'un annonceur ? | FLEDGE a été conçu pour prendre en charge la publicité à l'aide des données first party dont dispose déjà un annonceur. Toutefois, FLEDGE n'a pas pour but d'aider un annonceur à connaître le comportement de navigation d'une personne sur un site Web autre que le sien. Associer le comportement de navigation hors site aux données first party est contraire aux objectifs de la Privacy Sandbox. Nous prévoyons de publier des guides d'intégration dans les semaines à venir pour vous expliquer plus en détail comment FLEDGE permettra d'intégrer les données first party. |
| Valeur k-anonymat | Comment la valeur "K" pour "k-anon" sera-t-elle déterminée et sera-t-elle publiée ? | La valeur "K" est toujours en cours de finalisation. Nous vous communiquerons plus d'informations au fur et à mesure de l'avancement de nos plans. Nous aimerions en savoir plus sur la façon dont une valeur k inconnue peut entraver la préparation à FLEDGE et la définition du champ d'application de l'entraînement du modèle de ML. N'hésitez pas à nous envoyer d'autres commentaires à ce sujet. |
| Compatibilité avec plusieurs SSP | Comment FLEDGE prend-il en charge plusieurs SSP ? | FLEDGE est compatible avec les enchères multivendeurs, comme indiqué dans cette proposition. |
| Visibilité de la logique d'enchères | Inquiétude concernant l'exposition de la logique d'enchères de la DSP en JavaScript | Avec la logique d'enchères de conception actuelle, JavaScript peut être accessible par d'autres personnes. Toutefois, nous serions ravis de recevoir d'autres commentaires sur les raisons pour lesquelles cela pourrait être source d'inquiétude pour les DSP. |
| prebid.js | Quand prebid.js sera-t-il compatible avec FLEDGE ? | Seules les versions 7.14 et ultérieures de Prebid.js sont compatibles avec le module FLEDGE. Les éditeurs intéressés par les tests doivent ajouter le module FLEDGE et mettre à niveau leur instance Prebid. |
| Fonctions définies par l'utilisateur dans FLEDGE | Comment les fonctions définies par l'utilisateur seront-elles prises en charge dans FLEDGE ? Il s'agit de fonctions pouvant être programmées par les utilisateurs finaux pour étendre les fonctionnalités de l'API. | Pour en savoir plus, consultez cette page. Ce point est encore en cours d'élaboration. Nous vous invitons donc à nous envoyer d'autres commentaires sur les cas d'utilisation. |
| Assouplissement de la contrainte de même origine sur les ressources des groupes de centres d'intérêt | Demande d'assouplissement de la contrainte de même origine sur les ressources des groupes d'intérêt pour permettre certains cas d'utilisation de la technologie publicitaire | Dans l'implémentation actuelle de FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl et trustedBiddingSignalsUrl doivent avoir la même origine que le propriétaire du groupe de centres d'intérêt.Cette contrainte permet d'empêcher certains exploits par des pirates informatiques, comme expliqué ici. |
| Ownership | Demande de limiter la possibilité pour une technologie publicitaire d'utiliser joinInterestGroup pour les mêmes groupes d'intérêt sur différents sites | Nous nous concentrons sur la façon dont les audiences sont utilisées, et non sur leur création. Nous discutons des approches potentielles et nous sommes à l'écoute de vos commentaires. |
| Expiration de la clé du serveur Key Value | Discussion sur la suppression des clés de serveur une fois que les groupes de centres d'intérêt correspondants ont expiré | Nous étudions des moyens de gérer l'expiration des clés et nous souhaitons recueillir vos commentaires. |
Mesurer les annonces numériques
Attribution Reporting (et d'autres API)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Trafic des phases d'évaluation Origin | Le trafic actuel de l'essai Origin n'est pas suffisant pour effectuer des tests d'utilité. | Les essais Origin actuels sont destinés aux acteurs de l'écosystème à effectuer des tests fonctionnels afin de s'assurer que l'API fonctionne comme prévu. Nous sommes conscients que des volumes de trafic plus importants seront nécessaires pour effectuer des tests d'utilité une fois que le développement des différentes API Privacy Sandbox sera plus avancé. Selon le calendrier actuel des tests, cela devrait se produire d'ici le troisième trimestre 2023 (date de disponibilité générale, c'est-à-dire lorsque les technologies des cas d'utilisation seront lancées et disponibles pour 100% du trafic Chrome) (consultez notre calendrier à jour sur privacysandbox.com). Nous sommes à l'écoute de vos commentaires supplémentaires sur les tests de cas d'utilisation qui nécessitent un trafic supplémentaire. |
| chevauchement des fonctionnalités des différentes API de mesure de la Privacy Sandbox | Les inquiétudes concernant le chevauchement de plusieurs approches de mesure via la Privacy Sandbox vont augmenter la complexité, par exemple avec l'API Attribution Reporting et l'API Private Aggregation. | Nous mettons tout en œuvre pour améliorer la documentation afin de clarifier les différents cas d'utilisation des API. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur les aspects qui nécessitent des explications. Par exemple, l'API Attribution Reporting est conçue spécifiquement pour prendre en charge la mesure des conversions, tandis que l'API Private Aggregation et Shared Storage sont des API à usage général destinées à prendre en charge un plus large éventail de cas d'utilisation de la mesure intersites. |
| Réessayer la demande de rapport ayant échoué | Clarification sur le nombre de tentatives de demande de rapport en cas d'échec. | Nous avons publié des conseils à ce sujet. En résumé, les rapports ne sont envoyés que lorsque le navigateur est en cours d'exécution/en ligne. Après le premier échec d'envoi, le rapport est renvoyé au bout de cinq minutes. Après le deuxième échec, le rapport est relancé au bout de 15 minutes. Passé ce délai, le rapport n'est pas envoyé. |
| Délai de création des rapports | Quel est le délai de création des rapports prévu ? | Nous souhaitons recevoir davantage de commentaires de la part de l'écosystème sur les retards de création de rapports qu'il rencontre, car nous recueillons des données pour évaluer ces retards plus en détail en parallèle. |
| Précharger des pages | L'attribution ARA fonctionnera-t-elle sur les pages prérendues ? | L'enregistrement de l'attribution est différé sur les pages prérendues jusqu'à l'activation (clic ou visionnage réels). Cela signifie que nous allons différer le ping de la requête "attributionsrc". |
| Mesurer le conversion lift | Mesurer le conversion lift avec des tests A/B sur le même domaine | Les sites Web peuvent mesurer l'impact sur les conversions à l'aide de tests A/B sur le même domaine grâce aux rapports sur l'attribution. Ils peuvent encoder leurs paramètres A/B en tant que clés à l'aide de l'API agrégation, puis recevoir des rapports récapitulatifs sur les valeurs de conversion par ces buckets de clés. |
| (également indiqué au troisième trimestre) Conversions multidomaines | Suivre les conversions multidomaines, par exemple avec deux destinations ou plus | Mise à jour du 4e trimestre: Nous avons publié une proposition visant à supprimer la restriction de destination de la page de destination, ce qui permet de suivre les conversations interdomaines. Cette proposition a été implémentée. |
| (également signalé au troisième trimestre) Paramètre d'expiration dans le rapport sur les conversions |
Demande d'activation du filtre de rapport / de l'expiration de moins de 24 heures | Mise à jour du 4e trimestre: Nous avons partagé cette pull request , qui dissociera les périodes d'expiration et de création de rapports afin de réduire le compromis entre le délai de création de rapports et l'expiration des conversions. Cette fonctionnalité est désormais disponible dans M110. |
| Fraude et abus | Demandes des annonceurs et des marketeurs pour pouvoir segmenter et agréger les données en fonction des sites d'éditeurs sur lesquels leurs annonces sont diffusées, ce qui leur donnerait également plus d'informations sur les pratiques publicitaires potentiellement frauduleuses | Nous discutons activement de ces commentaires sur cette page et nous sommes à l'écoute de vos commentaires supplémentaires. |
| (Signalé également au troisième trimestre) Retard de création de rapports au niveau des événements | Le délai de 2 à 30 jours pour les rapports au niveau des événements peut être trop long pour certains cas d'utilisation. | Les périodes de référence des rapports au niveau des événements sont de 2, 7 et 30 jours par défaut. Vous pouvez modifier cette valeur à l'aide du paramètre "expiry". Les technologies publicitaires peuvent configurer l'expiration, avec un minimum d'un jour, pour obtenir des rapports potentiels en moins de deux jours. Nous limitons la précision des expirations à une journée afin de protéger la confidentialité, car des rapports plus précis pourraient entraîner des attaques par cassage de chiffrement. De plus, nous vous permettons de définir des paramètres d'expiration indépendants pour les rapports au niveau des événements et les rapports agrégés. reportez-vous à cet article. De plus, Google Ads ne recevra pas de périodes de reporting spéciales que les autres technologies publicitaires ne reçoivent pas via l'API Attribution Reporting. |
| Exigence d'une même origine de création de rapports | Demande de suppression de l'exigence selon laquelle l'origine de l'enregistrement de la source doit être identique à celle de l'enregistrement de la conversion | Pour résoudre ce cas d'utilisation, nous vous proposons d'utiliser des redirections HTTP pour déléguer l'enregistrement. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur les nouvelles consignes. |
| Suivi des conversions | Distinguer si la conversion s'est produite avant ou après certaines heures définies par l'annonceur | L'API Attribution Reporting permet de définir une période d'expiration et une priorité pour l'attribution de la source. En utilisant les deux, il sera techniquement possible d'attribuer une conversion qui s'est produite dans un délai de X jours séparément d'une conversion qui s'est produite après X. |
| Simulation de bruit | Demande de pouvoir simuler le volume de conversions différent par bucket afin de comprendre l'impact sur les annonceurs qui enregistrent moins de conversions | Nous prévoyons d'ajouter des moyens de simuler cela dans les futures versions de Noise Lab. N'hésitez pas à nous faire part de vos commentaires supplémentaires. |
| Créer des rapports sur mobile | Le rapport sera-t-il toujours envoyé lorsque Chrome s'exécute en arrière-plan sur mobile ? | Pour le moment, même sur mobile, le rapport n'est pas envoyé lorsque Chrome est en arrière-plan. Cela est susceptible de changer lorsque l'API sera intégrée à la Privacy Sandbox sur Android. reportez-vous à cet article. Notez que la Privacy Sandbox sur Android ne fait pas partie des engagements acceptés par la CMA. |
| Disponibilité des données | Inquiétudes concernant l'accès supplémentaire de Google aux données via les API Privacy Sandbox | Tout d'abord, Google Ads ne bénéficie d'aucun accès privilégié aux données de l'API Attribution Reporting ni d'autres API Privacy Sandbox. Ce problème est également abordé dans la section "Commentaires généraux" sous "Interopérabilité", qui fournit plus d'informations sur les engagements de Google. Deuxièmement, concernant la différence entre les sites plus importants et les plus petits, Google reconnaît que les protections de la confidentialité basées sur le bruit peuvent avoir un impact plus important sur les tranches de données plus petites. Toutefois, il existe des solutions possibles: par exemple, des méthodes telles que l'agrégation sur de plus longues périodes de temps permettraient de résoudre ce problème. Cela dit, il reste à déterminer si les conclusions basées sur de très petites tranches de données (comme un ou deux achats) sont pertinentes pour les annonceurs. Lors du test de l'origine, Google a encouragé les testeurs à profiter de la possibilité de tester un large éventail de paramètres de confidentialité et de bruit afin de pouvoir fournir des commentaires plus spécifiques sur ce problème. |
Limiter le suivi dissimulé
Réduction user-agent
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Retarder la réduction de l'User-Agent jusqu'à ce que l'écosystème Web soit plus prêt | Nous n'avons pas suffisamment de temps pour nous adapter aux changements à venir concernant la réduction des User-Agent. | Nous répondons à ces commentaires dans le rapport complet, sous "Concerns of stakeholders" (Concerns des personnes concernées) dans la section "Google's interaction with the CMA" (Interaction de Google avec la CMA). |
| Retarder la réduction de l'User-Agent jusqu'à ce que l'écosystème Web soit plus prêt | Demande de retarder le déploiement de la réduction de l'user-agent jusqu'au déploiement des user-agents structurés | L'équipe Google Ads a proposé l'ajout d'un User-Agent structuré (voir la spécification) à OpenRTB en octobre 2021. Il a été intégré à la mise à jour de la spécification 2.6 publiée en avril 2022. Nous avons des preuves que les UAP sont déployées et disponibles aujourd'hui, comme le montre l'article de blog de Scientia Mobile expliquant comment utiliser UA-CH et l'API WURFL pour créer une UAP. |
###
User-Agent Client Hints
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Tester UA-CH avec d'autres techniques de suivi anti-caché | Conseils pour tester toutes les API de la Privacy Sandbox et les techniques d'empreinte digitale proposées ensemble dans une approche globale | Notre plan de test a été conçu pour refléter les délais asynchrones de développement de certaines des mesures anti-empreinte par rapport au reste des propositions de Sandbox. Il tient compte du fait que certaines mesures anti-empreinte (par exemple, le budget de confidentialité, la protection des adresses IP et les mesures d'atténuation du suivi des rebonds) ne seront entièrement développées et prêtes à être lancées en disponibilité générale qu'après l'abandon des cookies tiers. Même si ces mesures anti-empreinte ne seront pas incluses dans les tests quantitatifs, elles seront soumises à une évaluation qualitative basée sur les faits disponibles au moment de l'arrêt. |
| (également indiqué au T2) Performances |
Préoccupations concernant la latence d'obtention d'indices via Critical-CH (au premier chargement de page) | Consultez la section dédiée à UA-CH ci-dessous. |
| Commentaires insuffisants | Les commentaires de l'écosystème concernant le changement UA-CH peuvent ne pas être suffisants, ce qui peut susciter des inquiétudes quant au manque de sensibilisation de l'écosystème. | Nous avons communiqué de manière proactive nos plans pour assurer un déploiement minutieux qui minimise les perturbations. Les plans de réduction de l'user-agent et de l'API UA-CH ont été présentés au groupe de la communauté W3C sur la lutte contre la fraude le 18 mars 2022, ainsi qu'au groupe de travail sur les paiements Web et au groupe d'intérêt sur la sécurité des paiements Web le 20 janvier 2022. Aucune préoccupation importante n'a été soulevée pendant ou après les présentations. Google a contacté de manière proactive plus de 100 opérateurs de sites pour obtenir leurs commentaires. De plus, Google a également utilisé les canaux Blink-Dev pour communiquer publiquement le déploiement de la réduction de l'agent utilisateur en fonction des commentaires des personnes concernées par l'écosystème. |
| Durée | Questions soulevées concernant le calendrier de déploiement et la préparation du secteur | Consultez la section dédiée à UA-CH ci-dessous. |
| État de la plate-forme Chrome | Demande de mise à jour de la page chromestatus pour UA-CH | L'entrée chromestatus a été mise à jour le 19 décembre pour indiquer "Signaux mitigés". |
Protection IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Activer ou désactiver | La confidentialité des adresses IP est-elle activée ou désactivée ? | Notre objectif est de proposer la Protection IP à tous les utilisateurs. C'est pourquoi nous évaluons actuellement les options de protection des droits d'auteur proposées aux utilisateurs. |
| Cas d'utilisation de l'adresse IP pour les données first party | Est-il possible d'utiliser des adresses IP pour assembler les parcours utilisateur sur les domaines first party après la protection des adresses IP ? | Comme indiqué dans notre publication précédente, la protection des adresses IP se concentrera d'abord sur le suivi dans le contexte tiers, ce qui signifie que les domaines propriétaires ne seront pas concernés. |
| Cas d'utilisation de la technologie publicitaire | Comment les entreprises peuvent-elles mettre en place des mesures antifraude avec la protection de l'adresse IP ? | Nous reconnaissons l'importance de l'adresse IP comme signal pour les mesures antifraude sur le Web d'aujourd'hui. Conformément à nos engagements envers la CMA (paragraphe 20), nous avons indiqué que nous n'implémenterions pas la protection des adresses IP sans faire des efforts raisonnables pour aider les sites Web à lutter contre le spam et la fraude. L'une de nos principales priorités est de comprendre l'impact de la protection de la propriété intellectuelle sur les cas d'utilisation de la lutte contre la fraude et les fonctionnalités de détection, afin de pouvoir investir davantage dans les technologies protégeant la confidentialité qui aident les entreprises à préserver la sécurité du Web. Nous encourageons les commentaires et les suggestions de nouvelles propositions visant à répondre aux besoins des entreprises de sécurité et de lutte contre la fraude, même si les signaux changent au fil du temps. |
| Fraude et abus | La protection IP inclut-elle la protection contre le déni de service (DoS) ? | Nous nous engageons à améliorer la confidentialité tout en protégeant le Web. La protection contre les attaques par déni de service est un cas d'utilisation important à prendre en compte pour lutter contre les utilisations abusives. Nous espérons réduire l'impact des protections DoS grâce à la conception de la protection IP elle-même et à de nouvelles solutions anti-abus. La protection IP étant initialement axée sur les services intégrés tiers, certains partenaires ont indiqué qu'elle devrait avoir un impact limité sur la protection DoS des sites propriétaires. Toutefois, nous continuerons à solliciter vos commentaires pour évaluer les risques liés aux cas d'utilisation des attaques DoS, en particulier pour les services intégrés tiers. En parallèle, nous étudions des mécanismes de signalement d'abus et de blocage des clients qui permettraient à un site ou à un service de bloquer un utilisateur qui envoie du spam, sans l'identifier. |
| Filtrage du contenu | Filtrage du contenu avec la protection IP | Les besoins des entreprises en termes de filtrage de contenu et de personnalisation de l'expérience utilisateur sont différents. De nombreux cas d'utilisation de ce type ne reposent pas actuellement sur des adresses IP et ne devraient donc pas être affectés par la protection des adresses IP. Par exemple, un éditeur qui souhaite adapter ses contenus et générer plus d'engagement peut utiliser des cookies propriétaires ou des cookies tiers partitionnés (CHIP) pour comprendre les centres d'intérêt d'un utilisateur et ses interactions précédentes avec l'éditeur. Un partenaire de technologie publicitaire axé sur la diffusion de la bonne annonce auprès de l'utilisateur approprié peut également intégrer FLEDGE et Topics, par exemple, pour obtenir des résultats publicitaires similaires à ceux qu'il obtient aujourd'hui avec les cookies tiers ou d'autres technologies de suivi intersites. Nous étudions également la possibilité d'intégrer de nouvelles fonctionnalités protégeant la confidentialité à la protection IP, comme la géolocalisation approximative, afin de mieux prendre en charge le filtrage de contenu lorsque les mécanismes existants peuvent être insuffisants. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur les cas d'utilisation du filtrage de contenu susceptibles d'être affectés par la protection IP. |
| (également signalé au troisième trimestre) Cas d'utilisation de la géolocalisation |
La protection des adresses IP peut empêcher à l'avenir les cas d'utilisation légitimes de la géolocalisation, comme la personnalisation de contenu en fonction de la géolocalisation. | Mise à jour du 4e trimestre: Nous collaborons avec les personnes concernées pour nous assurer que Chrome continue de prendre en charge les cas d'utilisation légitimes des adresses IP. Cliquez ici pour nous faire part de vos commentaires sur la précision de la géolocalisation par adresse IP. |
Privacy Budget
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Documentation plus claire | Plus d'exemples pour que les personnes concernées puissent anticiper les limites qui pourraient être imposées une fois Privacy Budget implémenté | La proposition de budget de confidentialité est toujours en cours de discussion et n'a été implémentée par aucun navigateur. La date de disponibilité à l'échelle la plus précoce représente la date la plus précoce à laquelle le budget de confidentialité peut être appliqué. Cela ne se produira pas avant la suppression des cookies tiers en 2024. Nous n'avons pas d'autres documents à vous communiquer pour le moment. Nous vous communiquerons plus d'informations sur la proposition lorsque celle-ci sera finalisée. En attendant, nous invitons les personnes concernées à nous faire part de leurs commentaires qui pourraient nous aider à développer la proposition. |
Prévention du suivi intersites pour améliorer la confidentialité
Ensembles propriétaires
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également signalé au troisième trimestre) Limite de domaine | Demande d'augmentation du nombre de domaines associés | Mise à jour du 4e trimestre: Nous avons publié FPS pour les tests locaux, y compris un processus d'envoi d'un ensemble fictif sur GitHub et un indicateur permettant de tester rSA et rSAFor en local. Nous avons également organisé deux réunions ouvertes pour les développeurs sur les FPS afin de continuer à répondre aux questions concernant les cas d'utilisation du sous-ensemble associé. Nous encourageons les développeurs à tester la fonctionnalité FPS afin de nous faire part de leurs commentaires sur l'impact de la limite de domaine du sous-ensemble associé sur l'usabilité de FPS pour leurs cas d'utilisation. Nous avons précisé lors des appels du groupe WICG que Chrome s'engage à fournir une solution utilisable qui tient également compte des intérêts de confidentialité des utilisateurs. Dans ce contexte, nous voudrions connaître l'avis de la communauté sur les cas d'utilisation spécifiques qui pourraient être affectés par la limite de domaines, afin que l'équipe puisse envisager des solutions pour y répondre tout en continuant à protéger la confidentialité des utilisateurs. |
| Demander plus d'informations sur les mesures d'atténuation des abus | Que se passe-t-il si un domaine est ajouté à un ensemble auquel il n'a pas donné son autorisation ? | Nous avons publié des consignes d'envoi pour les ensembles propriétaires ici le 2 décembre 2022. Comme indiqué dans les consignes d'envoi, toute gestion des modifications définie suivra et respectera un processus de validation sur GitHub, y compris la validation de la propriété, ce qui devrait atténuer ce risque. |
| Atténuation des abus | Inquiétude concernant l'exploitation des ensembles propriétaires | Nous cherchons à étendre les vérifications techniques pour les types de sous-ensembles et nous sollicitons activement les commentaires de la communauté ici. |
| Cas d'utilisation des annonces | Questions sur l'utilisation des ensembles first party pour le ciblage des annonces | Nous ne cherchons pas à prendre en charge les cas d'utilisation du ciblage Ads pour les ensembles first party. Nous vous recommandons d'utiliser les API Ads disponibles pour ces cas d'utilisation. |
| (également signalé au T3) Règle | Concernte concernant la non-conformité de la FPS avec les engagements de la CMA concernant la "législation applicable en matière de protection des données", car le RGPD n'impose pas de limite au nombre de sites dans un ensemble, alors que la FPS envisage une limite de trois | Notre réponse n'a pas changé depuis la question 3: "Google s'engage auprès de la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en favorisant son propre activité, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, les éditeurs et les annonceurs, ainsi que l'impact sur les résultats en termes de confidentialité et le respect des principes de protection des données tels qu'ils sont définis dans la législation applicable en matière de protection des données. Le problème soulevé ne révèle aucune incompatibilité avec le RGPD. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements." |
| Proposition alternative | Ensembles validés pour le RGPD | En plus des commentaires fournis par l'écosystème sur la proposition d'adopter des "ensembles validés conformes au RGPD", Chrome a des inquiétudes concernant les limites suivantes de cette autre proposition:
Depuis que cette alternative a été proposée, Chrome a mis à jour la proposition d'ensembles propriétaires et publié des consignes d'envoi pour créer des ensembles. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Restrictions liées aux cadres clôturés pendant l'OT | Quelles sont les restrictions actuelles concernant les cadres délimités pour la période d'évaluation Origin ? | Nous préparons une documentation sur les restrictions et l'état de leur implémentation. Nous prévoyons de la partager au cours du premier trimestre 2023. |
| Plusieurs annonces dans un même cadre délimité | Demande d'affichage de plusieurs annonceurs dans un même cadre clôturé lors d'une même mise aux enchères | Pour le moment, cette demande n'est pas en cours de développement, mais nous sommes à l'écoute de vos commentaires supplémentaires si les acteurs de l'écosystème considèrent cette fonctionnalité comme importante. |
| Web Bundles | Quelles sont les exigences et l'assistance prévues pour les bundles Web avec des cadres clôturés ? | Nous ne sommes pas en mesure de vous indiquer si cette exigence sera appliquée à l'avenir. Tout changement sera annoncé à l'avance et ne sera pas appliqué avant l'abandon des cookies tiers. Pour connaître l'état actuel, consultez cette vidéo explicative. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Stockage partagé pour l'Ad Tech | Incertitude concernant l'utilisation du stockage partagé pour les cas d'utilisation de la technologie publicitaire | Les API Shared Storage et Private Aggregation peuvent être utilisées pour différents types de mesures nécessitant une mesure du stockage intersites. Vous trouverez quelques exemples sur cette page. Nous prévoyons que les fournisseurs de solutions DSP et de mesure seront les principaux intégrateurs des cas d'utilisation des annonces. |
CHIPs
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (Signalé également au 3e trimestre) Exigence de partitionnement | Ajout d'une exigence de comportement explicite pour l'attribut "Partitionné" sur les cookies propriétaires. | Mise à jour du 4e trimestre: Après des discussions sur GitHub et des appels à PrivacyCG, nous avons convenu que les cookies partitionnés définis sur les cookies propriétaires utiliseraient une clé de partition (A,A), où "A" est le site de premier niveau. Nous allons documenter ce comportement dans la vidéo explicative et la spécification. |
| Gestion des cookies | Existe-t-il des outils permettant de gérer/gérer les cookies propriétaires ou tiers ? | Vous pouvez utiliser Chrome DevTools et NetLog pour tester des sites avec le blocage des cookies tiers activé. Les deux outils signalent les cas où des cookies sont bloqués en raison de la configuration de l'utilisateur. N'hésitez pas à nous faire part de vos commentaires sur les types de vérifications supplémentaires que vous aimeriez voir. |
FedCM
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Le fournisseur d'identité doit connaître le RP pour autoriser une session | Problème lorsqu'un utilisateur tente de se connecter à l'IDP Feide à partir de deux RP différents | Nous étudions des solutions potentielles à ce problème. |
| Interopérabilité | Questions concernant l'impact de FedCM sur la relation entre les utilisateurs et les sites Web auxquels ils se connectent à l'aide de FedCM, ainsi que sur l'interopérabilité entre les sites Web | FedCM vise à continuer à prendre en charge les services d'identité fédérée qui dépendent actuellement de cookies tiers une fois que ces cookies seront supprimés de Chrome. Nous nous attendons à ce que FedCM ne soit qu'une option disponible pour ces services. Les fournisseurs d'identité (IdP) et les parties de confiance (RP) sont libres d'utiliser d'autres technologies qui peuvent mieux répondre à leurs besoins. Il semble que les préoccupations concernant la relation utilisateur-RP et l'interopérabilité proviennent d'une mauvaise compréhension de la proposition FedCM. Le FedCM laisse aux IdP le soin de décider quelles informations partager avec un RP et sous quelle forme, une fois que l'utilisateur a choisi de se connecter au site de ce RP. La gestion fédérée des identités n'exige pas des IdP de "créer un identifiant pseudonyme unique pour chaque [RP] avec lequel l'utilisateur s'authentifie". Au lieu de cela, FedCM permet à chaque IdP de choisir de partager l'identifiant réel de l'utilisateur, une version de cet identifiant par site ou une autre version de ces informations. (La spécification FedCM identifie la corrélation intersites comme un risque de confidentialité associé à l'API et évoque les identifiants dirigés (par site) comme une solution possible. Toutefois, la décision d'utiliser des identifiants dirigés est laissée aux IdP, et non imposée par le navigateur.) Le FedCM permet également aux utilisateurs de choisir leur identité. Par exemple, si un utilisateur possède plusieurs identités avec le même IdP (par exemple, un profil professionnel et un profil personnel), FedCM lui permet de sélectionner celle qu'il souhaite utiliser pour se connecter au site du RP. En outre, chaque RP décide lui-même des IdP à prendre en charge sur son site. Un aspect de cette décision consiste à examiner le mécanisme sur lequel s'appuie un IdP, qu'il s'agisse de FedCM ou d'une autre technologie. Encore une fois, le navigateur ne dicte pas ces choix pour les RP ni les IdP. |
Lutter contre le spam et la fraude
API Private State Token
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Gérer les bots | Que se passe-t-il si l'émetteur découvre que des jetons d'état privés ont été émis à des bots ? | Pour éviter que les jetons émis pour les bots ne restent dans l'écosystème pendant une longue période, les émetteurs doivent faire tourner régulièrement les clés qu'ils utilisent pour signer les jetons afin que les anciens jetons émis avec une logique d'émission potentiellement défectueuse expirent et que les sites utilisent des jetons plus récents avec une logique d'émission mise à jour. |
| Envois de formulaires sur le même site | Les jetons de l'état privé peuvent-ils être utilisés pour l'envoi de formulaires sur le même site impliquant une navigation sur une page entière (c'est-à-dire "Content-Type: application/x-www-form-urlencoded") plutôt qu'une requête provenant des API fetch/XMLHttpRequest ? | Cette fonctionnalité n'est actuellement pas disponible dans la première version des jetons d'état privés. Nous accueillons les commentaires de l'écosystème si ce cas d'utilisation est très demandé. |
| Validation côté serveur | Questions sur la possibilité de valider les jetons d'état privés côté serveur | Les jetons sont utilisés auprès de l'émetteur, qui crée ensuite un enregistrement d'utilisation pouvant contenir le jeton lui-même ou une valeur signée dérivée du jeton. Les serveurs peuvent utiliser cet enregistrement d'utilisation pour vérifier l'authenticité du jeton. Nous nous attendons à ce que les différents écosystèmes d'émetteurs élaborent des normes différentes pour interpréter leurs enregistrements d'utilisation. |