Rapport trimestriel pour le 4e trimestre 2022 résumant les commentaires reçus par l'écosystème sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Dans le cadre de ses engagements envers la CMA, Google a accepté de fournir publiquement des rapports trimestriels sur le processus d'engagement des parties prenantes pour ses propositions de la Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des Engagements). Ces rapports récapitulatifs des commentaires de la Privacy Sandbox sont générés en regroupant les commentaires reçus par Chrome à partir des différentes sources, comme indiqué dans la présentation des commentaires, y compris, mais sans s'y limiter, les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les acteurs du secteur et les forums sur les normes Web. Chrome se félicite des commentaires reçus de l'écosystème et recherche activement des moyens d'intégrer les enseignements tirés dans les décisions de conception.
Les thèmes de commentaires sont classés par prévalence par API. Pour ce faire, nous regroupons les commentaires reçus par l'équipe Chrome sur un thème donné et les classons par ordre décroissant de quantité. Les thèmes de commentaires courants ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquemment posées par les équipes internes de Google et dans des formulaires publics.
Plus précisément, les comptes-rendus des réunions des organes standards Web ont été examinés et, en vue de recueillir des commentaires directs, les enregistrements 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 public ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation afin de déterminer la prévalence relative des thèmes émergents pour chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles apportées aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifiquement pour cet exercice de reporting public. Compte tenu de l'intérêt 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.
Il est possible que les commentaires reçus après la fin de la période de référence en cours ne soient pas encore pris en compte dans la réponse Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Federated Credential Management
- Lecteur d'empreinte digitale
- Ensembles internes
- IAB
- l'Interactive Advertising Bureau
- IdP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- ML
- Adresse IP (Internet Protocol)
- openRTB
- Enchères en temps réel
- Prolongation
- Phase d'évaluation
- PatCG
- Groupe de la communauté des 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
- Consortium World Wide Web
- En cours
- Aveugle délibéré des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (également indiqué au 3e 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 spécialisés (plus petits) contribuent plus que les sites génériques (plus grands) | Notre réponse n'a pas changé par rapport au troisième trimestre: "Google s'est engagé envers la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se faisant prévaloir de son propre activité, et à tenir compte de son 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 progressent, l'une des principales questions que nous évaluerons sera les performances des nouvelles technologies pour différents types de personnes concernées. Les commentaires sont essentiels à cet égard, en particulier les commentaires spécifiques et exploitables qui peuvent nous aider à améliorer davantage nos conceptions techniques. Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous soutenons également la publication par la CMA d'une note sur la conception des tests afin de fournir plus d'informations aux acteurs du marché et de donner des commentaires sur les approches proposées. |
| (Également indiqué au 3e trimestre) Demandes de documentation |
Demandes de ressources supplémentaires expliquant comment gérer les tests, l'analyse et la mise en œuvre | Mise à jour du 4e trimestre: Nous apprécions les développeurs qui ont trouvé notre contenu actuel utile et nous nous engageons à fournir davantage de contenus pour leur permettre de comprendre comment les nouvelles technologies peuvent leur être utiles. Au cours du dernier trimestre, nous avons ajouté une section "Actualités et actualités " sur privacysandbox.com et nous avons publié un rapport détaillé sur la façon dont la Privacy Sandbox peut contribuer à améliorer la pertinence des annonces à l'avenir. Nous avons également organisé des sessions publiques de permanence 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 les responsables de l'ingénierie pour permettre des échanges et poser des questions en direct. |
| Core Web Vitals | Quel est l'impact de la latence de l'API Privacy Sandbox sur les Signaux Web essentiels ? | Réduire au maximum la latence est l'un des objectifs de conception clés des API Privacy Sandbox. Nous nous attendons actuellement à ce que la latence des API ait un impact minimal sur les signaux Web essentiels d'un site, car la majorité des API sont appelées après le rendu initial du site Web. Nous continuons de surveiller et d'apporter des améliorations afin de réduire davantage la latence pour chacune des API, et nous encourageons la poursuite des tests et des commentaires. La latence dans le processus d'enchères en temps réel est traitée dans la section FLEDGE sous "Performances des enchères FLEDGE" |
| Interopérabilité | Préoccupations 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 mettons à leur place de nouvelles technologies conçues pour répondre à des cas d'utilisation spécifiques. Les propositions de la Privacy Sandbox améliorent la confidentialité en limitant les données qui quittent l'appareil d'un utilisateur. Elles n'imposent pas de restrictions techniques sur la capacité d'un site Web à partager ou traiter des données une fois qu'elles sont collectées à partir du navigateur. Par conséquent, les technologies n'empêchent 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 capacité des utilisateurs à autoriser le partage de leurs données par d'autres moyens. Par souci 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 ne prendra plus en charge les cookies tiers, nos engagements stipulent également clairement que Google n'utilisera pas d'autres données à caractère personnel, telles que l'historique de navigation Chrome synchronisé, pour suivre les utilisateurs à des fins de ciblage ou de mesure de la publicité numérique. |
Diffusez des annonces et des contenus pertinents
Rubriques
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Impact sur le classement dans les résultats de recherche Google | Demandez si la compatibilité d'un site 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é l'utilisation du classement des pages pour inciter les sites Web à adopter l'API Topics, ni demandé à celle-ci de l'utiliser. 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 une 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 l'utilité pour divers partenaires. | Actuellement, l'historique de navigation d'un utilisateur est classé à l'aide des noms d'hôte d'un site Web. Chrome continue d'évaluer des options pour prendre en compte les métadonnées au niveau de la page (telles que tout ou partie de l'URL et/ou du contenu de la page) dans la classification Topics. Toute amélioration de l'utilitaire doit être comparée aux risques liés à la confidentialité et aux abus. Par exemple, concernant les métadonnées en particulier, voici quelques-uns des risques: - Sites modifiant les métadonnées au niveau d'une page pour encoder différentes significations (et potentiellement sensibles) en sujets ; - Sites qui modifient les métadonnées au niveau des pages pour donner une fausse image de leurs métadonnées dans le but d'en tirer un profit financier ; - Sites qui modifient les métadonnées au niveau de la page de manière dynamique afin de procéder au suivi intersites |
| (également enregistré au 3e trimestre) Impact sur les signaux propriétaires |
Le signal des thèmes peut s'avérer très utile et, par conséquent, dévaloriser d'autres signaux propriétaires basés sur les centres d'intérêt. | Notre réponse n'a pas changé par rapport au troisième trimestre: "Nous pensons que la publicité ciblée par centres d'intérêt constitue un cas d'utilisation important pour le Web, et Topics est conçu pour y répondre. Comme décrit [dans notre rapport du 3e trimestre], d'autres acteurs de l'écosystème ont exprimé leurs inquiétudes quant au fait que Topics ne soit pas suffisamment utile pour apporter de la valeur. Dans tous les cas, les améliorations apportées à la classification constituent un effort continu, et nous nous attendons à ce qu'elle évolue en fonction des tests et des contributions des écosystèmes." |
| Mise à jour de la taxonomie | Comment la liste de classification sera-t-elle mise à jour ? | Nous recherchons activement des commentaires sur la taxonomie qui serait la plus utile pour l'écosystème. La classification incluse dans la proposition initiale de l'API Topics a été conçue pour permettre des tests fonctionnels. Chrome étudie actuellement différentes 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 futures itérations. |
| Performances du classificateur régional Topics | Le classificateur de thèmes n'est pas 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, il est possible d'élargir la liste de remplacement des thèmes. D'après notre analyse, cela permettra d'accroître la couverture mondiale et d'améliorer la précision. En résumé, la classification de l'API Topics comporte deux composants pertinents: (1) une liste de remplacement 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 élargissant la liste de remplacement (1), nous pouvons améliorer les performances de classification pour les régions dans lesquelles le classificateur n'est peut-être pas assez performant. |
| epoch d'une semaine | L'intervalle d'une semaine est trop long pour les utilisateurs cherchant à prendre des décisions à plus court terme. | Nous cherchons activement à déterminer la durée d'epoch appropriée, et nous aimerions nous faire part de vos commentaires sur ce qui serait une meilleure epoch pour l'écosystème. |
| Récupération d'en-tête HTTP | Inquiétudes concernant le manque d'informations concernant la récupération de l'en-tête HTTP des sujets | Des travaux d'analyse sont en cours pour les en-têtes et fetch(). D'autres informations sont également disponibles sur cette page. Nous avons également ajouté des informations "SkipObservation" à la section explicative. |
| L'objectif de Topics est uniquement d'aider les annonceurs, pas les utilisateurs | L'approche Topics/Privacy Sandbox semble être axée sur le secteur. Les avantages pour les utilisateurs ne sont pas aussi évidents que pour le secteur. | Nous pensons que l'avantage pour les utilisateurs est que Topics prend en charge les annonces par centres d'intérêt qui permettent de garder le Web sans frais et ouvert. De plus, nous pensons que cela améliore nettement la confidentialité par rapport aux cookies tiers. Supprimer les cookies tiers sans solutions viables peut avoir un impact négatif sur les éditeurs et entraîner de moins bonnes approches qui sont moins confidentielles, ne sont pas transparentes, et ne peuvent pas être réinitialisables ni contrôlés par les utilisateurs de manière réaliste. 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 W3C Technical Architecture Group a récemment publié sa vue initiale sur l'API Topics. Nous allons y répondre publiquement. À ce stade, comme Google a reçu des questions de la part de l'écosystème Google sur l'impact potentiel de cet examen pour le développement et le lancement de l'API Topics, nous souhaitons réaffirmer notre intention de la rendre disponible dans la version stable de Chrome cette année. Bien que Google apprécie la contribution du W3C Technical Architecture Group, il est primordial de poursuivre ses efforts pour développer et tester Topics en collaboration avec la CMA et l'écosystème. |
| Fuite de données | Risque de divulgation de Topics vers d'autres sites sans autorisation | En raison de la conception de l'API Topics, il est très peu probable que les données d'un seul éditeur (voire d'un plus 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 des règles d'autorisation. |
| Absence d'annonceurs pour les tests | Les éditeurs craignent de ne pas être actuellement en mesure de démontrer l'intérêt de Topics aux annonceurs. | Au cours du second semestre 2023, nous prévoyons de mettre à disposition toutes les API liées aux annonces pour les tests d'intégration et de permettre aux annonceurs d'analyser l'intérêt de Topics au sein de l'écosystème. 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. Nous encourageons les membres de l'écosystème à partager leurs 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 | Il est possible d'utiliser Topics dans la logique d'enchères de FLEDGE. Un guide d'intégration est également en cours de développement, avec des informations supplémentaires sur l'implémentation. |
| Classement personnalisé des appelants de sujets | Autoriser la personnalisation du classement en fonction de l'appelant | Le problème avec le classement des thèmes personnalisés ou les valeurs pour chaque technologie publicitaire est que cela pourrait 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és pour les appelants des thèmes | Autorisez les appelants à fournir une liste de thèmes prioritaires classés que l'API Topics renvoie en fonction de l'éligibilité. | Nous discutons plus en détail de cette idée et nous aimerions recevoir des informations supplémentaires. |
FLEDGE
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Google Ad Manager | c'est-à-dire que Google Ad Manager n'est pas le décideur final pour les enchères FLEDGE, et qu'il privilégie les tags Google Publisher Tag et Google Ad Manager. | FLEDGE permet à chaque éditeur de choisir la structure de l'enchère, y compris les vendeurs de premier niveau et les vendeurs de composants. Chaque acheteur et chaque vendeur participant à la mise aux enchères d'un composant sait qui est le vendeur de premier niveau, et peut choisir d'enchérir ou non. |
| Pas assez de participants pour tester FLEDGE | Demande visant à encourager davantage d'entreprises à tester FLEDGE, par exemple en améliorant la fonctionnalité de l'API et en décourageant les alternatives intrusives liées à la confidentialité telles que le fingerprinting | La Privacy Sandbox s'effectue par étapes, en étroite collaboration avec les directives de la CMA et de l'ICO, et les tests fonctionnels de FLEDGE ont démontré la stabilité et les capacités nécessaires. Google continue d'encourager l'écosystème à tester les API Sandbox, en publiant récemment sa documentation Maximiser la pertinence des annonces pour montrer comment FLEDGE et d'autres API peuvent aider à répondre aux cas d'utilisation essentiels du secteur publicitaire après l'abandon des cookies tiers. D'autres parties de la Privacy Sandbox prennent déjà en charge les mesures d'atténuation pour couvrir le suivi (voir UA-CH, protection de l'adresse IP et mesures d'atténuation du suivi des rebonds) et continueront de s'améliorer avec le temps. L'objectif de Google n'est pas de faire de FLEDGE la seule solution de ciblage viable, mais de collaborer avec les acteurs du secteur et les organismes de réglementation pour exploiter les meilleures technologies publicitaires protégeant la confidentialité dans le navigateur Chrome. |
| Cas d'utilisation du machine learning | D'autres conseils sur la façon dont les cas d'utilisation du machine learning permettent d'entraîner les algorithmes d'enchères aux enchères seront disponibles dans FLEDGE et Attribution Reporting | Nous savons qu'il est nécessaire d'aider les testeurs à trouver les moyens les plus efficaces d'appliquer les technologies de la Privacy Sandbox. Nous avons commencé à publier des conseils spécifiquement liés à l'utilisation des différents aspects des API Privacy Sandbox en tant qu'entrées pour le machine learning. L'article le plus récent, Maximiser la pertinence des annonces, explique comment le secteur publicitaire peut exploiter ces signaux pour le machine learning, et nous prévoyons de continuer à publier ces conseils à l'avenir. |
| Interroger le serveur de clés-valeurs FLEDGE | Pourquoi le serveur K/V est-il interrogeable publiquement ? | Le serveur K/V vise à fournir des signaux en temps réel aux enchères FLEDGE. Par conséquent, le serveur K/V doit être accessible à partir de l'endroit où s'exécutent les enchères FLEDGE, c'est-à-dire sur les appareils des utilisateurs, ce qui nécessite qu'il soit accessible au public. Une valeur stockée sur le serveur de K/V ne peut être récupérée que par une partie qui dispose déjà de sa clé. Par conséquent, si une technologie publicitaire ne fournit les clés qu'aux navigateurs qui font partie du groupe de centres d'intérêt et n'utilise pas de clés qui peuvent être devinées de manière aléatoire, seuls les navigateurs qui ont besoin de la valeur pour exécuter leur enchère pourront la récupérer. |
| Comment effectuer un ciblage par date/heure ? | Prise en charge des 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 fournir la date et l'heure actuelles. Ces derniers doivent pouvoir communiquer 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 le cadre de leur réponse contextuelle dans les signaux par acheteur, qu'un 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'autres solutions. | Les utilisateurs ont la possibilité de désactiver les API Ads dans Chrome. Pour des annonces spécifiques, la technologie publicitaire pertinente est la mieux placée pour contrôler quelles créations sont diffusées et comment elles sont sélectionnées. |
| Des chronologies plus claires | Demande d'informations sur la disponibilité des protections de la confidentialité dans FLEDGE, comme l'utilisation de Fenced Frames. | Nous prévoyons de publier des calendriers plus détaillés au cours du premier trimestre. |
| Confusion dans les rapports | Demande de précisions sur le fonctionnement des rapports FLEDGE avec d'autres API, telles que Fenced Frames et Private Agrégation. | Nous prévoyons de publier des explications sur l'interaction entre l'API Private Aggregation, FLEDGE et Fenced Frames 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 problèmes 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 l'intégration simplifiée dans ARA. Nous prévoyons de vous envoyer des informations et des explications à ce sujet au premier trimestre. |
| Performances des enchères FLEDGE | Rapports de 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, ainsi que des suggestions pour améliorer les performances de FLEDGE. En parallèle, nous avons ajouté des outils au navigateur qui permettent aux développeurs de mieux identifier ce qui ralentit les enchères. De plus, nous avons systématiquement traité les principales sources de latence observées. Parmi les récentes améliorations apportées figurent les délais d'expiration pour les enchères lentes, une technique de filtrage des enchères rapides, un moyen de réutiliser les worklets FLEDGE pour éviter de payer des coûts de démarrage, ainsi que des travaux continus pour permettre à la demande d'annonce contextuelle de s'exécuter en parallèle avec le temps de démarrage de FLEDGE et les récupérations réseau. L'optimisation de la latence devrait se poursuivre, en tant que conversation continue entre les développeurs Chrome et les testeurs FLEDGE sur la base de leur expérience réelle de l'utilisation de l'API. |
| Limite de mémoire pour la taille des groupes de centres d'intérêt | Demande d'augmentation de la limite de 50 Ko pour la taille d'un groupe de centres d'intérêt unique. | Nous examinons attentivement votre demande et souhaitons savoir quelles valeurs limites conviennent. |
| Combiner les données diffusées par FLEDGE avec le cookie propriétaire | FLEDGE permettra-t-il l'intégration avec les données first party d'un annonceur ? | FLEDGE a été conçu pour permettre la publicité à l'aide des données first party dont un annonceur dispose déjà. Toutefois, FLEDGE n'a pas l'intention d'aider un annonceur à apprendre le comportement de navigation d'une personne sur un site Web autre que son propre site. Associer le comportement de navigation hors site aux données first party va à l'encontre des objectifs de la Privacy Sandbox. Nous prévoyons de partager des guides d'intégration avec plus de détails sur la façon dont FLEDGE permettra l'intégration avec les données first party dans les semaines à venir. |
| Valeur k-anonymat | Comment la valeur "K" pour "k-anon" sera-t-elle déterminée et publiée ? | La valeur "K" est en cours de finalisation et nous vous communiquerons d'autres informations au fur et à mesure de l'évolution de nos plans. Nous souhaitons en savoir plus sur la façon dont une valeur k inconnue peut entraver la préparation et la portée de l'entraînement du modèle de ML par FLEDGE. N'hésitez pas à nous faire part de commentaires supplémentaires à ce sujet. |
| Compatibilité avec plusieurs SSP | Comment plusieurs SSP seront-elles prises en charge dans FLEDGE ? | FLEDGE est compatible avec les enchères multivendeurs, comme indiqué dans cette proposition. |
| Visibilité de la logique d'enchères | Inquiétudes concernant le fait que la logique d'enchères des DSP ne soit pas exposée dans JavaScript | Avec la logique d'enchères de conception actuelle, d'autres personnes peuvent accéder à JavaScript, mais n'hésitez pas à nous faire part de plus de commentaires sur les raisons pour lesquelles cela pourrait constituer une préoccupation pour les DSP. |
| prebid.js | Quand suivrez-vous la prise en charge de prebid.js dans FLEDGE ? | Seules les versions 7.14 et ultérieures de Prebid.js sont compatibles avec le module FLEDGE. Tous 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 (UDF) seront-elles compatibles avec FLEDGE ? Ces fonctions peuvent être programmées par les utilisateurs finaux pour étendre les fonctionnalités de l'API. | Vidéo explicative disponible ici. Ces éléments étant encore en cours d'élaboration, nous aimerions recevoir des commentaires supplémentaires sur les cas d'utilisation. |
| Assouplissement de la contrainte d'origine commune sur les ressources des groupes de centres d'intérêt | Requête d'assouplissement de la contrainte de même origine sur les ressources des groupes de centres d'intérêt afin d'activer certains cas d'utilisation de technologies publicitaires | 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 pirates informatiques, comme expliqué ici. |
| Propriété des groupes d'intérêts | Requête pour limiter si une technologie publicitaire peut utiliser joinInterestGroup pour les mêmes groupes de centres d'intérêt sur plusieurs sites | Nous nous concentrons sur la façon dont les audiences sont utilisées, et non sur la façon dont elles sont créées. Pour discuter des approches possibles, cliquez ici et nous aimerions que vous nous fassiez part d'autres commentaires. |
| Expiration de la clé de serveur de valeurs-clés | 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 attendons vos commentaires sur cette page. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Trafic lors de la phase d'évaluation | Le trafic actuel de la phase d'évaluation n'est pas suffisant pour effectuer des tests d'utilité. | Les phases d'évaluation en cours permettent aux joueurs de l'écosystème d'effectuer des tests fonctionnels afin de s'assurer que l'API fonctionne comme prévu. Nous sommes conscients que de plus grandes quantités de trafic seront nécessaires pour effectuer des tests d'utilité une fois que le développement des différentes API de la Privacy Sandbox sera plus mature. Le calendrier de test actuel prévoit que cela se produise lors de la disponibilité générale (c'est-à-dire lorsque les technologies correspondant aux cas d'utilisation seront lancées et disponibles pour 100% du trafic Chrome) au 3e trimestre 2023 (consultez notre calendrier à jour sur privacysandbox.com). N'hésitez pas à nous envoyer des commentaires supplémentaires sur les tests de cas d'utilisation qui nécessitent davantage de trafic. |
| Chevauchement des fonctionnalités de différentes API de mesure de la Privacy Sandbox | Le chevauchement de plusieurs approches de mesure via la Privacy Sandbox augmentera la complexité liée à l'utilisation de l'API Attribution Reporting et de l'API Private Aggregation, par exemple. | Nous travaillons à l'élaboration d'une documentation plus pertinente afin de clarifier les différents cas d'utilisation des API. Nous vous invitons à nous faire part de tout commentaire supplémentaire sur les points qui manquent d'explications. Par exemple, l'API Attribution Reporting est spécifiquement conçue pour permettre la mesure des conversions, tandis que l'API Private Aggregation et le stockage partagé sont des API à usage général destinées à prendre en charge un plus large éventail de cas d'utilisation de mesures intersites. |
| Réessayer la demande de rapport ayant échoué | Clarification sur le nombre de tentatives d'une 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, une nouvelle tentative est effectuée au bout de cinq minutes. Après le second échec, une nouvelle tentative est effectuée au bout de 15 minutes. Passé ce délai, le rapport n'est plus envoyé. |
| Délai de création des rapports | Quel est le délai attendu pour la création des rapports ? | Nous souhaitons recevoir davantage de commentaires de la part de l'écosystème sur les retards de création des rapports à mesure que nous recueillons des données afin d'évaluer ces retards en parallèle. |
| Précharger les pages | L'attribution ARA fonctionnera-t-elle sur les pages de prérendu ? | L'enregistrement de l'attribution est différé sur les pages de prérendu jusqu'à l'activation (clic ou affichage réel). Cela signifie que nous différerons le ping de la requête "attributionsrc". |
| Mesurer le conversion lift | Mesurer le conversion lift avec des tests AB sur le même domaine | Les sites Web peuvent mesurer le conversion lift avec des tests A/B sur le même domaine via les rapports sur l'attribution. Ils peuvent encoder leurs paramètres A/B en tant que clés à l'aide de l'API globale, puis recevoir des rapports récapitulatifs sur les valeurs de conversion associées à ces ensembles de clés. |
| (Également enregistré au troisième trimestre) Conversions multidomaines | Effectuer le suivi des conversions sur plusieurs domaines (avec deux destinations ou plus, par exemple) | Mise à jour du 4e trimestre: Nous avons publié une proposition visant à supprimer la restriction de destination de la page de destination, qui permet de suivre les conversations sur plusieurs domaines. Cette proposition a été mise en œuvre. |
| (également indiqué au 3e trimestre) Paramètre d'expiration dans le rapport sur les conversions |
Demande d'ajout du filtre ou de l'expiration du rapport pour un délai inférieur à 24 heures | Mise à jour du 4e trimestre: Nous avons partagé cette demande d'extraction , qui va dissocier les périodes d'expiration et de création de rapports afin de réduire le compromis entre le délai de création des rapports et l'expiration des conversions. Cette fonctionnalité est désormais disponible dans M110. |
| Fraude et abus | Demande des annonceurs et des marketeurs de pouvoir décomposer et agréger les données en fonction des sites des éditeurs sur lesquels leurs annonces sont diffusées, ce qui permettrait de mieux comprendre les pratiques publicitaires frauduleuses potentielles. | Nous examinons activement ces commentaires sur cette page , et nous aimerions recevoir des informations supplémentaires. |
| (Également signalé au 3e trimestre) Délai de création de rapports au niveau des événements | Le délai de 2 à 30 jours dans la création de rapports au niveau des événements peut s'avérer trop long pour certains cas d'utilisation. | Les rapports au niveau des événements ont des périodes de référence par défaut de 2, 7 et 30 jours. Vous pouvez le modifier à l'aide du paramètre "expiry". Les technologies publicitaires peuvent configurer l'expiration, avec un délai minimal d'un jour, pour obtenir des rapports potentiels en moins de deux jours. Comme mécanisme de protection de la confidentialité, nous limitons la précision des délais d'expiration à un jour, car des rapports plus précis peuvent entraîner des attaques temporelles. En outre, nous autorisons la définition de paramètres "d'expiration" indépendants pour les rapports globaux et au niveau des événements. reportez-vous à cet article. De plus, Google Ads ne bénéficiera d'aucune période de référence spéciale que les autres technologies publicitaires n'obtiennent pas via l'API Attribution Reporting. |
| Exigences relatives à l'origine des rapports identiques | Demande de suppression de l'exigence d'une origine de l'enregistrement de la source identique à celle de l'enregistrement de la conversion | Pour résoudre ce cas d'utilisation, nous proposons d'utiliser des redirections HTTP pour déléguer l'enregistrement. N'hésitez pas à nous faire part de tout commentaire supplémentaire sur ces nouvelles consignes. |
| Suivi des conversions | Nécessité de déterminer 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 source. En utilisant les deux, il sera techniquement possible d'attribuer une conversion qui s'est produite au cours de la période de X jours indépendamment de celle qui s'est produite après X. |
| Simulation du bruit | Demandez à pouvoir simuler les différents volumes de conversions par bucket afin de comprendre l'impact sur les annonceurs ayant 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. |
| Rapports sur mobile | Le rapport est-il quand même envoyé lorsque Chrome s'exécute en arrière-plan sur les appareils mobiles ? | Pour le moment, même sur mobile, le rapport n'est pas envoyé lorsque Chrome est en arrière-plan. Ce comportement est susceptible de changer lorsque l'API s'intégrera à la Privacy Sandbox sur Android. reportez-vous à cet article. Notez que la Privacy Sandbox 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 préférentiel aux données de l'API Attribution Reporting ou des autres API Privacy Sandbox. Ce problème est également traité dans la section "Commentaires généraux" de la section "Interopérabilité", qui fournit des informations plus détaillées sur les engagements de Google. Deuxièmement, concernant la différence entre les sites de grande et de petite taille, Google reconnaît que les mesures de protection de la confidentialité basées sur le bruit peuvent avoir un impact plus important sur des tranches de données plus petites. Il existe cependant quelques solutions. Par exemple, des méthodes telles que l'agrégation sur de plus longues périodes permettent de résoudre ce problème. Toutefois, nous ne parvenons pas à déterminer si les conclusions basées sur de très petits segments de données (comme un ou deux achats) sont pertinentes pour les annonceurs. Pendant la phase d'évaluation, Google a encouragé les testeurs à profiter de la possibilité de tester un large éventail de paramètres de confidentialité et de bruit afin de 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 Chrome |
|---|---|---|
| Retarder la réduction user-agent jusqu'à ce que l'écosystème Web soit mieux préparé | Nous n'avons pas assez de temps pour nous adapter aux prochaines modifications apportées à la réduction user-agent. | Nous prenons en compte ces commentaires dans le rapport complet, sous "Préoccupations des partenaires", dans la section intitulée "Interactions de Google avec la CMA". |
| Retarder la réduction user-agent jusqu'à ce que l'écosystème Web soit mieux préparé | Demande pour retarder le déploiement de la réduction user-agent jusqu'au déploiement de Structured User-Agents (SUA) | L'équipe Google Ads a proposé d'ajouter le user-agent structuré (voir la spécification) à OpenRTB en octobre 2021. Cet ajout a été intégré dans la mise à jour des spécifications 2.6 publiée en avril 2022. Nous avons des preuves que la SUA est déployée et disponible aujourd'hui, comme l'illustre l'article de blog Scientia Mobile qui explique comment utiliser UA-CH et l'API WURFL pour créer une SUA. |
###
Hints client user-agent
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Testez UA-CH avec d'autres techniques de suivi anti-couvert | Conseils pour tester simultanément toutes les API et techniques de fingerprinting de la Privacy Sandbox proposées dans une approche globale | Notre plan de test a été conçu de façon à refléter les délais asynchrones de développement de certaines mesures de protection contre les empreintes digitales, par opposition aux autres propositions de bac à sable. Il répond à la réalité que certaines mesures de protection contre les empreintes digitales (par exemple, le budget dédié à la confidentialité, la protection de la propriété intellectuelle et les mesures d'atténuation du suivi des rebonds) seront pleinement développées et prêtes à être lancées en disponibilité générale uniquement après l'abandon des cookies tiers. Bien que ces mesures de protection contre les empreintes digitales ne soient pas incluses dans les tests quantitatifs, elles feront l'objet d'une évaluation qualitative basée sur les faits disponibles au moment de l'arrêt. |
| (également disponible au deuxième trimestre) Performances |
Inquiétudes concernant la latence d'obtention des indices via Critical-CH (lors du premier chargement de la page) | Consultez la section UA-CH dédiée ci-dessous |
| Commentaires insuffisants | Les retours de l'écosystème sur le changement UA-CH peuvent ne pas être suffisants, ce qui suscite des craintes quant au manque de sensibilisation de l'écosystème. | Nous avons partagé de manière proactive nos projets pour assurer un déploiement prudent qui minimise les perturbations. Les plans de réduction des user-agents et de l'API UA-CH ont été présentés le 18 mars 2022 au W3C Anti-Fraud Community Group, ainsi qu'au Web Payments Working Group et Web Payments Security Interest Group le 20 janvier 2022. Aucune préoccupation majeure n'a été soulevée pendant ou après les présentations. Google a interagi de manière proactive avec plus de 100 opérateurs de sites afin de recueillir leurs commentaires. De plus, Google a également utilisé les canaux Blink-Dev pour communiquer publiquement le déploiement de la réduction des user-agents en fonction des commentaires des acteurs de l'écosystème. |
| Durée | Inquiétudes concernant le calendrier de déploiement et la préparation du secteur | Consultez la section UA-CH dédiée ci-dessous |
| État de la plate-forme Chrome | Demande de mise à jour de la page d'état chrome pour UA-CH | L'entrée "chromestatus" a été remplacée le 19 décembre par "Signaux mixtes". |
Protection de l'adresse IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Activer ou désactiver la fonctionnalité | Est-il possible d'activer ou de désactiver la confidentialité des adresses IP ? | Notre objectif est d'assurer la protection de l'adresse IP à tous les utilisateurs. Dans cette optique, nous évaluons actuellement les options de choix des utilisateurs pour la protection de l'adresse IP. |
| Cas d'utilisation des adresses IP pour les données first party | Est-il possible d'utiliser des adresses IP pour regrouper les parcours utilisateur sur plusieurs domaines propriétaires après la protection de l'adresse IP ? | Comme annoncé précédemment, la protection de l'adresse IP sera d'abord axée sur le suivi dans un contexte tiers, ce qui signifie que les domaines propriétaires ne seront pas affectés. |
| Cas d'utilisation de l'AdTech | Comment les entreprises peuvent-elles mettre en place des mesures de lutte contre la fraude avec la protection de l'adresse IP ? | Nous savons que l'adresse IP est un indicateur des efforts de lutte contre la fraude sur le Web. Dans le cadre de nos engagements envers la CMA (paragraphe 20), nous avons déclaré que nous n'appliquerions pas la protection de la propriété intellectuelle sans prendre des mesures raisonnables pour permettre aux sites Web de mener des actions de lutte 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 et les capacités de détection de la lutte contre la fraude, afin de pouvoir investir davantage dans des technologies protégeant la confidentialité qui aident les entreprises à préserver la sécurité sur le Web. Nous vous encourageons à donner votre avis et à faire part de nouvelles propositions visant à répondre aux besoins des entreprises de sécurité et de lutte contre la fraude, même si les signaux évoluent au fil du temps. |
| Fraude et abus | La protection des adresses IP inclut-elle une protection contre le déni de service (DoS) ? | Nous nous engageons à améliorer la confidentialité tout en assurant la sécurité du Web. La protection contre les attaques par déni de service constitue un cas d'utilisation important dans la lutte contre les utilisations abusives. Nous espérons minimiser l'impact sur les protections DoS à travers la conception de la protection de l'adresse IP elle-même et de nouvelles solutions de lutte contre les utilisations abusives. La protection de l'adresse IP étant initialement axée sur les services intégrés tiers, certaines personnes concernées ont indiqué qu'elle devrait avoir un impact limité sur la protection DoS des sites propriétaires. Cependant, nous continuerons de demander l'avis du public afin d'évaluer les risques associés aux cas d'utilisation DoS, en particulier pour les services tiers intégrés. En parallèle, nous étudions les commentaires abusifs et les mécanismes de blocage des clients qui permettraient à un site ou à un service de bloquer un utilisateur indésirable, sans l'identifier. |
| Filtrage du contenu | Filtrer le contenu avec la protection IP | Les entreprises ont des besoins différents en termes de filtrage du contenu et de personnalisation de l'expérience utilisateur. Actuellement, ces cas d'utilisation ne reposent pas sur les adresses IP et ne devrait donc pas être affecté par la protection de l'adresse IP. Par exemple, un éditeur qui souhaite adapter son contenu 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 précédentes interactions avec l'éditeur. Autre exemple : un partenaire ad tech qui se concentre sur la diffusion de la bonne annonce auprès de la bonne personne peut intégrer FLEDGE et Topics pour obtenir des résultats publicitaires semblables à ceux qu'il utilise aujourd'hui avec des cookies tiers ou d'autres technologies de suivi intersites. Nous envisageons également de développer de nouvelles fonctionnalités de protection de la confidentialité, telles que la géolocalisation approximative, afin d'optimiser le filtrage du contenu lorsque les mécanismes existants peuvent s'avérer insuffisants. N'hésitez pas à nous faire part d'autres commentaires sur les cas d'utilisation du filtrage de contenu susceptibles d'être affectés par la protection de l'adresse IP. |
| (également indiqué au 3e trimestre) Cas d'utilisation de la géolocalisation |
La protection de l'adresse IP peut empêcher les cas d'utilisation légitimes de la géolocalisation de fonctionner à l'avenir, tels que la personnalisation de contenu basée sur 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. Pour connaître l'avis de votre écosystème sur la précision de la géolocalisation par IP, cliquez ici. |
Privacy Budget
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Documentation plus claire | Davantage d'exemples pour permettre aux partenaires d'anticiper les limites applicables une fois le budget dédié à la confidentialité mis en œuvre | La proposition de budget pour la confidentialité est toujours en cours de discussion et n'a été appliquée par aucun navigateur. La date la plus proche de la disponibilité ajustée correspond à la date la plus proche à laquelle le budget Privacy Budget peut être appliqué. Cela ne se produira pas avant la suppression des cookies tiers en 2024. Nous n'avons pas d'autres documents à vous transmettre pour le moment. Nous vous communiquerons des informations supplémentaires sur la proposition lorsqu'elle sera finalisée. En attendant, nous invitons les personnes concernées à faire part de leurs commentaires qui pourraient nous aider à élaborer la proposition. |
Renforcez les limites de confidentialité intersites
Ensembles internes
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également indiqué au 3e trimestre) Limite par domaine | Demande d'augmentation du nombre de domaines associés | Mise à jour du 4e trimestre: Nous avons publié le FPS pour les tests locaux, y compris un processus d'envoi fictif sur GitHub et un indicateur permettant de tester rSA et rSAFor localement. Nous avons également organisé deux réunions ouvertes pour les développeurs sur le lecteur d'empreinte digitale, afin de continuer à répondre aux questions sur les cas d'utilisation pour le sous-ensemble associé. Nous encourageons les développeurs à tester la fonctionnalité FPS afin de nous faire part de leurs commentaires sur l'impact potentiel de la limite du domaine pour le sous-ensemble associé sur la facilité d'utilisation du lecteur d'empreinte digitale pour leurs cas d'utilisation. Nous avons clarifié dans les appels des WICG que Chrome s'engage à fournir une solution utilisable qui tient également compte de la confidentialité des utilisateurs. À cet égard, nous aimerions connaître les commentaires de la communauté sur les cas d'utilisation spécifiques susceptibles d'être concernés par la limite du domaine. L'équipe pourra ainsi trouver des solutions pour résoudre ces problèmes tout en continuant à protéger la confidentialité des utilisateurs. |
| Demande d'informations supplémentaires 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 consentement ? | Nous avons publié des consignes concernant l'envoi d'ensembles internes sur cette page le 2 décembre 2022. Comme expliqué dans les consignes concernant l'envoi d'informations, toute gestion du changement définie doit suivre et respecter 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 | Préoccupations concernant l'exploitation des formations d'ensembles internes | Nous cherchons des moyens d'étendre les vérifications techniques pour les types de sous-ensembles et nous recherchons activement des commentaires supplémentaires de la part de la communauté sur cette page. |
| Cas d'utilisation des annonces | Questions concernant l'utilisation d'ensembles internes pour prendre en charge le ciblage des annonces | Notre objectif n'est pas de prendre en charge les cas d'utilisation du ciblage Ads pour les ensembles internes. Nous vous recommandons d'utiliser les API Ads disponibles pour ces cas d'utilisation. |
| (Également indiqué au 3e trimestre) Règlement | Inquiétudes concernant le fait que le SPF n'est pas conforme aux engagements de la CMA concernant la "législation applicable sur la protection des données", au motif que le RGPD n'impose pas de limite au nombre de sites dans un ensemble alors que le FPS prévoie une limite de trois | Notre réponse n'a pas changé par rapport au troisième trimestre: "Google continue de s'engager auprès de la CMA pour concevoir et implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se faisant passer pour sa propre activité, et à tenir compte de l'impact sur la concurrence dans le domaine de la publicité numérique, des éditeurs et des annonceurs, ainsi que de l'impact sur la confidentialité et le respect des principes de protection des données tels qu'ils sont définis dans la Législation applicable sur la protection des données. L'inquiétude exprimée 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 par le RGPD | En plus des commentaires fournis par l'écosystème sur la proposition d'adopter les "Ensembles validés par le RGPD", Chrome craint les limites suivantes de cette proposition alternative:
Depuis que cette alternative a été introduite, Chrome a mis à jour la proposition d'ensembles internes et publié les consignes d'envoi pour la création d'ensembles. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Restrictions liées aux cadres cloisonnés pendant la prolongation | Quelles sont les restrictions actuelles concernant les Fenced Frames pour la période d'évaluation ? | Nous travaillons sur la documentation sur les restrictions et l'état de l'implémentation, et nous prévoyons de la partager au cours du 1er trimestre 2023. |
| Plusieurs annonces dans un seul Fenced Frame | Demande d'affichage de plusieurs annonceurs dans un cadre Fenced Frame lors d'une enchère | Cette demande n'est pas encore développée activement, mais n'hésitez pas à nous envoyer des commentaires supplémentaires si les acteurs de l'écosystème considèrent cette fonctionnalité comme importante. |
| Packs Web | Quelles sont les conditions requises et l'assistance prévue pour les packs Web avec Fenced Frames ? | Nous ne sommes pas encore en mesure de vous dire si cette exigence sera exigée à l'avenir. Tout changement sera annoncé à l'avance et ne sera pas appliqué avant l'abandon des cookies tiers. Veuillez consulter cette vidéo d'explication pour connaître l'état actuel. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Stockage partagé pour les technologies publicitaires | Incertitude concernant l'utilisation du stockage partagé pour les cas d'utilisation de l'ad tech | L'API Shared Storage et Private Agrégation peut être utilisée pour différents types de mesures nécessitant des mesures du stockage sur plusieurs sites. Pour consulter des exemples, cliquez ici. Nous considérons que les DSP et les fournisseurs de solutions de mesure seront les principaux intégrateurs pour les cas d'utilisation publicitaires. |
CHIPs
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également indiqué au 3e trimestre) Exigences 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 nos discussions sur GitHub et les appels PrivacyCG, nous avons constaté que les cookies partitionnés définis sur les cookies propriétaires utilisent une clé de partitionnement de (A,A), où "A" est le site de premier niveau. Nous documenterons ce comportement dans la vidéo explicative et dans la spécification. |
| Gestion des cookies | Existe-t-il des outils pour gérer/contrôler les cookies propriétaires ou tiers ? | Vous pouvez utiliser les outils pour les développeurs Chrome et NetLog pour tester les sites avec le blocage des cookies tiers activé. Ces deux outils signalent lorsque les cookies sont bloqués en raison de la configuration de l'utilisateur. N'hésitez pas à nous faire part de vos commentaires sur le type de sites Web d'audit supplémentaires qui pourraient leur être utiles. |
FedCM
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Le fournisseur d'identité a besoin de connaître le tiers assujetti à des restrictions pour autoriser une session | Problème lorsqu'un utilisateur tente de se connecter au fournisseur d'identité Feide depuis deux tiers assujettis à des restrictions | Pour consulter des solutions à ce problème, cliquez ici. |
| Interopérabilité | Inquiétudes concernant l'impact de FedCM sur la relation entre les utilisateurs et les sites Web auxquels ils se connectent à l'aide de FedCM, et l'"interopérabilité" entre les sites Web | FedCM souhaite continuer à prendre en charge les services d'identité fédérée qui s'appuient actuellement sur des cookies tiers une fois ces cookies supprimés de Chrome. FedCM ne devrait être qu'une option parmi d'autres pour ces services. Les fournisseurs d'identité (IdP) et les tiers de confiance (RP) sont libres d'utiliser d'autres technologies qui pourraient mieux répondre à leurs besoins. Il semble que les préoccupations concernant la relation utilisateur-RP et l'"interopérabilité" soient dues à un malentendu de la proposition FedCM. La FedCM laisse le choix aux IdP de décider quelles informations partager avec un tiers assujetti à des restrictions et sous quelle forme, une fois que l'utilisateur a choisi de se connecter au site de ce tiers. FedCM n'exige pas des fournisseurs d'identité qu'ils "créent un identifiant pseudonyme unique pour chaque [RP] auprès duquel l'utilisateur s'authentifie". FedCM permet à chaque fournisseur d'identité de choisir de partager ou non l'identifiant réel de l'utilisateur, une version spécifique de cet identifiant pour chaque site ou une autre version de ces informations. (La spécification FedCM identifie la corrélation intersites comme un risque pour la confidentialité associé à l'API et aborde les identifiants dirigés (par site) comme des solutions possibles. Toutefois, la décision d'utiliser ou non des identifiants dirigés revient aux IdP, et non au navigateur.) FedCM offre également déjà aux utilisateurs un choix en matière d'identité. Par exemple, si un utilisateur possède plusieurs identités avec le même IdP (un profil professionnel et un profil personnel, par exemple), FedCM lui permet de sélectionner celle qu'il souhaite utiliser pour se connecter au site du tiers assujetti à des restrictions. En outre, chaque tiers assujetti à des restrictions décide lui-même des IdP qui doivent prendre en charge son site. L'un des aspects de cette décision concerne le mécanisme sur lequel s'appuie un IdP, qu'il s'agisse de FedCM ou d'une autre technologie. Là encore, le navigateur n'impose pas ces choix aux tiers assujettis à des restrictions ou aux fournisseurs d'identité. |
Lutter contre le spam et la fraude
API Private State Token
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Gérer les bots | Que se passe-t-il si l'émetteur découvre que des jetons d'état privés ont été envoyés à des bots ? | Pour éviter que les jetons envoyés aux bots ne restent longtemps dans l'écosystème, les émetteurs doivent alterner régulièrement les clés qu'ils utilisent pour signer les jetons, de sorte que les anciens jetons émis selon une logique d'émission potentiellement défaillante expirent et que les sites utilisent de nouveaux jetons avec une logique d'émission mise à jour. |
| Envois de formulaires pour un même site | Des jetons d'état privés pourraient-ils être utilisés pour les envois de formulaires sur un même site impliquant une navigation sur toute la page (c'est-à-dire, Content-Type: application/x-www-form-urlcoded) plutôt qu'une requête provenant des API fetch/XMLHttpRequest ? | Cela n'est actuellement pas pris en charge dans la première version des jetons d'état privés. Les commentaires de l'écosystème sont les bienvenus 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 échangés auprès de l'émetteur. Celui-ci crée ensuite un enregistrement d'utilisation qui peut contenir le jeton lui-même ou une valeur signée dérivée de celui-ci. 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 proposent des normes différentes pour interpréter leurs enregistrements d'utilisation. |