Rapport trimestriel pour le 2e 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
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Des chronologies plus claires | Des calendriers de publication plus clairs et détaillés pour les technologies de la Privacy Sandbox. | Nous avons établi nos plans actuels pour le calendrier de déploiement sur le site privacysandbox.com, et nous le mettons à jour tous les mois. Celles-ci tiennent compte du temps de développement des développeurs Chrome et Web, ainsi que des commentaires de l'écosystème dans son ensemble sur le temps nécessaire pour tester et adopter les nouvelles technologies. Chaque technologie passe par plusieurs étapes, des tests à la sortie (lancement), et le calendrier de chaque étape dépend des enseignements que nous avons tirés et des découvertes à l'étape précédente. Bien que nous n'ayons pas de mises à jour engagées pour le moment, nous ne manquerons pas de mettre à jour notre calendrier public sur privacysandbox.com. |
| Utilité pour les différents types de partenaires | Inquiétudes concernant le fait que les technologies de la Privacy Sandbox favorisent les développeurs de plus grande envergure et que les sites spécialisés (plus petits) contribuent plus que les sites génériques (les plus grands). | Nous comprenons que certains développeurs s'inquiètent de l'impact des technologies de la Privacy Sandbox. Google s'est engagé envers la CMA à ne pas concevoir ni implémenter les propositions de la Privacy Sandbox d'une manière qui fausse la concurrence en se faisant des préférences propres à son activité. Elle s'engage également à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, ainsi que sur l'impact sur la confidentialité et l'expérience utilisateur. 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, nous évaluerons l'une des principales questions que nous évaluerons concernant 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 nos conceptions techniques. |
| Calendrier d'abandon des cookies tiers | Demandes visant à éviter un nouveau retard lié à l'abandon des cookies tiers | Certains acteurs nous ont indiqué qu'ils souhaitaient que Chrome abandonne sans délai les cookies tiers. De même, d'autres personnes estiment qu'il faudrait plus de temps pour tester et adopter les technologies de la Privacy Sandbox. Compte tenu de la complexité des technologies et de l'importance de bien faire les choses pour l'écosystème, nous nous engageons à agir de manière responsable. Les commentaires du secteur et des organismes de réglementation ont été essentiels à ce processus. |
| Calendrier d'abandon des cookies tiers | Requêtes visant à retarder l'abandon des cookies tiers et à accorder plus de temps pour tester les API | Certains acteurs nous ont indiqué qu'ils souhaitaient que Chrome abandonne sans délai les cookies tiers. De même, d'autres personnes estiment qu'il faudrait plus de temps pour tester et adopter les technologies de la Privacy Sandbox. Compte tenu de la complexité des technologies et de l'importance de bien faire les choses pour l'écosystème, nous nous engageons à agir de manière responsable. Les commentaires du secteur et des organismes de réglementation ont été essentiels à ce processus. |
| Demandes de documentation | Demandes de ressources supplémentaires expliquant comment gérer les tests, l'analyse et la mise en œuvre | Nous apprécions que les développeurs aient trouvé ces outils utiles et nous nous engageons à leur fournir d'autres ressources, y compris les heures de bureau des développeurs et la documentation technique, au cours des semaines et des mois à venir, afin qu'ils puissent continuer à comprendre comment les nouvelles technologies peuvent leur être utiles.
Nous avons également organisé des sessions publiques de permanence pour les développeurs externes afin de partager les bonnes pratiques et les démonstrations, ainsi que des séances de questions-réponses avec les responsables produit et les responsables de l'ingénierie pour permettre des discussions et des questions en direct. |
| Expertise du secteur | L'équipe Chrome qui collabore avec des organismes de normalisation manque d'expertise dans l'écosystème publicitaire nécessaire pour trouver le bon équilibre entre confidentialité et utilité. | Nous sommes conscients que nous avons une grande responsabilité et nous comptons sur les commentaires pour mener à bien cette mission. Nous considérons également que la confidentialité et l'efficacité sont des critères de conception essentiels. Dans l'équipe chargée de l'initiative Privacy Sandbox pour le Web, le nombre total d'années travaillées dans l'écosystème publicitaire s'élève à plusieurs centaines d'années. |
Diffusez des annonces et des contenus pertinents
Sujets
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Utilité pour les différents types de partenaires | Des inquiétudes ont été soulevées concernant la valeur ajoutée et la distribution de cette valeur sur les sites, en fonction de leur niveau de trafic ou de la spécialisation de leur contenu. | Pour déterminer l'utilité de l'API, nous effectuerons des tests. Chrome s'attend à ce que la classification et d'autres paramètres évoluent en fonction des résultats des tests. L'évolution de la taxonomie ou des paramètres peut ne pas nécessiter de modifications incompatibles avec les versions antérieures. De plus, Chrome s'attend à ce que les commentaires influencent encore l'évolution de l'API Topics après l'abandon des cookies tiers. |
| Taxonomie | Les partenaires du secteur souhaitent avoir leur mot à dire en influençant la taxonomie. | Chrome reste ouvert pour l'ajout de données à la taxonomie. Les commentaires concernant le modèle de gouvernance mis en place par l'équipe Chrome et la manière dont d'autres organismes du secteur peuvent jouer un rôle plus actif dans le développement et la maintenance de la classification à long terme sont les bienvenus. |
| Historique de navigation insuffisant | Proposition visant à mettre en avant les thèmes que l'appelant a vus au cours des semaines précédentes si l'historique de navigation de l'utilisateur n'est pas suffisant pour créer cinq thèmes pour la semaine la plus récente | Dans notre conception actuelle, ils sont choisis au hasard. Nous étudierons la corrélation avec des sujets antérieurs et déterminerons s'il est possible d'intégrer cette donnée. Toutefois, les corrélations peuvent avoir des répercussions négatives sur la confidentialité des données qui doivent être prises en compte. |
| Appel de Topics pour le compte d'un éditeur | Un fournisseur de services tiers peut-il partager des thèmes avec un éditeur ? | Oui, c'est de cette manière que Topics devrait être utilisé. |
| Vecteurs d'attaque potentiels | Identifier les sujets bruyants | En se basant sur les commentaires d'un grand nombre de personnes dans l'écosystème, Chrome a choisi de filtrer les sujets et d'introduire du bruit. Ces décisions ont été prises dans le respect de la confidentialité, afin de limiter l'accès aux informations à ceux qui n'y auraient pas accès autrement, et d'introduire un risque de déni de service pour les utilisateurs, respectivement. Nous sommes conscients que ces décisions présentent des inconvénients, tels que le vecteur d'attaque décrit ici. Cependant, selon nous, les avantages en termes de confidentialité l'emportent sur les risques potentiels. Nous sommes ouverts à toute discussion publique sur cette décision. |
| Éligibilité à la phase d'évaluation | Existe-t-il un moyen de savoir si un utilisateur est éligible à une phase d'évaluation ? | Une fonctionnalité d'évaluation peut ne pas être disponible pour un utilisateur en raison des paramètres du navigateur ou d'autres facteurs, même s'il consulte une page Web qui fournit un jeton d'essai valide et que son navigateur est inclus dans le groupe pour lequel l'essai est activé.
C'est pourquoi la détection de fonctionnalités doit toujours être utilisée pour vérifier si une phase d'évaluation est disponible avant d'essayer de l'utiliser. |
| Impacts sur les performances | Problèmes de frais généraux et de latence avec Topics | Nous demandons des commentaires concernant les approches qui permettent d'éviter les iFrames x-origin coûteux et lents, ainsi que la proposition de démêler l'API Topics de sorte que l'obtention de thèmes ne modifie pas l'état de navigation. |
| Fonctionnalité de l'API Split Topics | Mieux contrôler les trois aspects différents de l'API | Nous comprenons le cas d'utilisation et avons proposé un moyen de le résoudre dans GitHub. Nous attendons actuellement d'autres commentaires de la part de l'écosystème, qui nous permettront de savoir s'il serait judicieux de créer cette fonctionnalité. Pour consulter la discussion en cours, cliquez ici. |
| Chronologie et documentation du classificateur | Les développeurs ont demandé plus d'informations sur le classificateur. | Pour en savoir plus sur le classificateur, cliquez ici.
Vous pouvez également consulter cette page. Cliquez ici pour y accéder. |
| Commandes utilisateur et sécurité | Certains sujets peuvent servir de proxys à des groupes sensibles, et les utilisateurs ont besoin de davantage de contrôle pour éviter les résultats négatifs. | Les thèmes représentent un progrès significatif en termes de contrôle et de transparence pour les utilisateurs. Les utilisateurs pourront désactiver des thèmes, examiner ceux qui leur ont été attribués, supprimer des thèmes et identifier les entreprises qui interagissent avec leurs thèmes sur une page donnée. De plus, les utilisateurs peuvent également supprimer leur historique de navigation pour modifier leurs thèmes Topics. Nous sommes toujours ravis de poursuivre les discussions concernant les commandes utilisateur plus avancées, telles que celles suggérées par les développeurs. Toutefois, nous devons nous assurer que les problèmes soulevés dans ce bug éliminent les risques (par exemple, la suppression du thème "étude en langue étrangère", mais pas des sites Web qui ont généré le sujet depuis l'historique de navigation, ne protège pas complètement l'utilisateur). |
| Utilisation de thèmes sur des sites avec prebid.js | Est-il possible d'utiliser l'API Topics sur des sites Web avec prebid.js ? | La réponse courte est oui. Des informations supplémentaires sont disponibles sur cette page. |
| Utiliser l'API Topics dans un widget de recommandation | Pouvons-nous utiliser l'API Topics dans le widget recommandé (par exemple, Outbrain) | Nous ne limitons pas le cas d'utilisation des thèmes récupérés après l'appel de l'API (cela dépend des règles sur les données de chaque développeur). |
| Confidentialité / Règles | Questions sur la façon de filtrer les réponses par appelant si des tiers partagent leurs sujets avec tous les appelants. | En nous appuyant sur les commentaires d'un grand nombre de personnes dans l'écosystème, Chrome a choisi cette conception afin de limiter l'accès aux informations à ceux qui n'y auraient pas accès autrement. Bien entendu, les éditeurs et les tiers qui reçoivent des Topics peuvent choisir eux-mêmes les informations qu'ils partageront avec les parties sur leur site. Si les utilisateurs optent pour ce type de partage, Chrome les encourage vivement à les informer de façon transparente vis-à-vis de leurs utilisateurs et à leur proposer des options de partage. |
| Signaux de bruit | Proposer un sujet aléatoire 5% du temps peut créer trop de bruit ou de faux signal. | Le bruit est une méthode importante pour protéger la confidentialité des utilisateurs, et les niveaux de bruit par rapport à l'utilité des sujets seront étudiés par le biais de tests. |
FLEDGE
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Coordination des tests | Tester l'impact sur les performances et les revenus | Les performances de FLEDGE et la meilleure façon de faciliter les tests d'écosystème pendant les phases d'évaluation et la disponibilité générale font l'objet de discussions activement lors des réunions publiques des WICG. |
| Serveur de confiance pour FLEDGE | Quand le serveur de confiance sera-t-il disponible pour les tests ? | Nous apprécions vos commentaires et nous travaillons activement à l'élaboration d'un plan plus détaillé que nous pourrons partager pour l'utilisation des serveurs de confiance dans FLEDGE. |
| Normalisation des protocoles | Existe-t-il un protocole commun pour transmettre des données entre les SSP et les DSP, comme des étiquettes communes pour les groupes de centres d'intérêt ? | N'hésitez pas à nous faire part de vos commentaires sur la standardisation potentielle des spécifications des DSP, des SSP et de l'écosystème publicitaire dans son ensemble. À des fins de test initial, nous vous recommandons de travailler directement avec vos partenaires de test, car ils sont en train de tester différentes approches. Nous encourageons également les organisations du secteur de la publicité à collaborer avec elles pour leur permettre d'établir une normalisation si celle-ci pourrait être utile à leurs entreprises membres. |
| Limitation de la fréquence d'exposition | Contrôle de la fréquence par utilisateur dans une campagne et un groupe d'annonces. | FLEDGE prendra en charge la limitation de la fréquence d'exposition pour les enchères sur l'appareil et les campagnes contextuelles / de branding. Vous pouvez également utiliser le stockage partagé et les limites spécifiques au site pour d'autres contrôles de limitation de la fréquence d'exposition. |
| Impact de FLEDGE sur les performances | Enchérisseurs gourmands en ressources de calcul dans la mise aux enchères FLEDGE | Chrome collabore activement avec les développeurs au sujet de l'impact potentiel sur les performances du site. Chrome offre l'opportunité d'en savoir plus pendant les tests. |
| Tester FLEDGE avec d'autres fonctionnalités | Comment les rapports au niveau des événements de l'API Attribution Reporting et FLEDGE s'imbriqueront-ils ? | Ce point a été abordé lors d'un récent appel WICG/conversion-measurement-api, avec un lien vers le compte rendu détaillé ici.
Résumons la réunion : la conception actuelle des rapports sur les annonces Fenced Frames permet d'associer un ID généré dans le cadre Fenced Frame à des informations contextuelles. Les rapports au niveau des événements générés à l'intérieur du Fenced Frame peuvent donc être joints aux mêmes informations contextuelles sur le serveur (en utilisant deux jointures côté serveur au lieu d'une). |
| Comptabilisation des impressions | Quelle méthode de comptabilisation des impressions doit ou pourrait être utilisée entre les acheteurs et les vendeurs ? | L'API FLEDGE permet déjà d'aligner la méthodologie entre le vendeur et l'acheteur lors de l'enchère. Nous avons reçu des suggestions sur d'autres implémentations sans nous indiquer pourquoi notre conception actuelle ne peut pas fonctionner pour l'écosystème. |
| Affichage de plusieurs annonces | Indique si l'utilisateur peut afficher plusieurs annonces dans une mise aux enchères dans un cadre Fenced Frame donné. | Pour le moment, cela est possible grâce aux annonces individuelles (à ne pas confondre avec les enchères individuelles). Pour ce faire, toutes les annonces doivent appartenir au même groupe de centres d'intérêt. |
| Spécification des audiences définies par le vendeur (SDA) et FLEDGE | FLEDGE pourrait-il devenir un mécanisme permettant d'empêcher les acheteurs de créer des profils à partir des SDA pour les demandes d'annonces ? | FLEDGE est conçu pour éviter les fuites d'informations non pertinentes lorsque l'éditeur connaît déjà les SDA que ses visiteurs ciblent et que le ciblage porte sur un même site. S'il est important de promouvoir l'achat sur des SDA dans toutes les protections intégrées à FLEDGE, une solution peut être pour un vendeur de transmettre les libellés de SDA aux enchères sur l'appareil et une technologie publicitaire côté achat pour créer son propre groupe de centres d'intérêt dont la logique d'enchères indique "Je veux acheter Audience X". |
| Compatibilité avec des devises autres que le dollar américain | Possibilité de tester FLEDGE avec des devises autres que le dollar américain | Nous apprécions ce message et nous avons amélioré la compatibilité avec d'autres devises en plus de notre arriéré de demandes de fonctionnalités. Nous espérons que cette fonctionnalité sera disponible très prochainement. |
| Compatibilité avec le ciblage par groupes de centres d'intérêt à exclure | API compatible avec le ciblage par liste d'audience à exclure, avec diffusion d'annonces uniquement auprès des internautes qui n'appartiennent pas à un groupe d'annonces. | Discussion en cours, y compris certaines options d'assistance proposées, sur le problème GitHub |
| Plusieurs SSP dans FLEDGE | Risque de favoriser Google lors de l'implémentation d'enchères à plusieurs niveaux dans FLEDGE | Plusieurs SSP sont désormais prises en charge dans FLEDGE afin d'instaurer un climat équitable et équitable. En vertu de ces engagements, Google s'est engagé à ne pas concevoir, développer ni mettre en œuvre les propositions de la Privacy Sandbox d'une manière qui risquerait de fausser la concurrence en choisissant ses propres produits et services publicitaires. Chez Google, nous prenons cette question très au sérieux et nous sommes ouverts à tous les inquiétudes éventuelles des personnes concernées sur certains aspects de la technologie. Pour plus d'informations, cliquez ici pour documenter publiquement le mécanisme de mise aux enchères des composants. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Attribution multitouch | Éditeurs demandant de prendre en charge l'attribution multitouch | Les méthodes actuelles d'attribution multitouch nécessitent de lier de manière déterministe les impressions (et donc l'identité) d'un utilisateur sur différents sites Web. Par conséquent, cette fonctionnalité sous sa forme actuelle ne correspond pas aux objectifs de la Privacy Sandbox, qui vise à prendre en charge les principaux cas d'utilisation publicitaires sans suivi intersites. Dans certains cas, l'attribution approximative du crédit (par exemple, à l'aide de priorités aléatoires pondérées) est possible sans suivre les utilisateurs individuels. |
| Génération de bruit | Questions concernant les niveaux de bruit dans les rapports | Notre test initial permet aux développeurs de définir leur propre valeur epsilon afin de découvrir comment les rapports changent en fonction du niveau de bruit. Pour le moment, les développeurs peuvent choisir une valeur epsilon allant jusqu'à epsilon=64. Nous l'avons fait spécifiquement pour permettre aux développeurs de tester plus facilement les API et de nous faire part de leurs commentaires sur les valeurs epsilon appropriées.
Nous avons également effectué une demande publique de ce type de commentaires. |
| Coordination des tests | L'outil de test en local peut-il être utilisé pour la P.É. ? | Oui, vous pouvez utiliser l'outil de test en local pendant toute la durée de la prolongation. Vous pouvez utiliser l'outil de test local avec les rapports de débogage tant que des cookies tiers sont disponibles. |
| Ergonomie des requêtes | Activer l'interrogation de l'agrégation de clés | Nous sommes d'accord sur le fait que cette approche semble améliorer l'ergonomie des API, avec des coûts apparents liés à la confidentialité, peu voire pas du tout. Nous allons faire une proposition et voir s'il y a un large consensus sur le fait qu'elle mérite d'être soutenue. |
| Données moins précises pour les petits sites | Les sites ou les campagnes de petite taille peuvent recevoir des données moins précises. | Chrome reconnaît que les protections de la confidentialité basées sur le bruit ont un impact plus important sur de petites tranches de données. Cependant, il est possible que des méthodes telles que l'agrégation sur des périodes plus longues résolvent ce problème. Nous ne savons pas non plus 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, Chrome encourage 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é
User-Agent Reduction
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Protection contre les bots | Impact d'UA-R sur la protection contre les bots | Nous apprécions vos commentaires, et nous collectons actuellement des informations sur les approches de protection contre les bots afin d'éclairer nos futures conceptions. |
| Dépendances de déploiement | Gérer les dépendances de déploiement d'user-agent structuré (SUA) | Nous avons déployé la "Phase 4", c'est-à-dire la réduction des versions mineures auprès de 100% des utilisateurs de Chrome à partir de la version 101. Consultez la mise à jour ici. |
Hints client user-agent
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Énumérer tous les indices compatibles | Intérêt pour un moyen programmatique de connaître tous les indices compatibles pour un navigateur. | Nous vous remercions de vos commentaires et sommes en train d'évaluer la demande de fonctionnalité. Nous souhaiterions savoir s'il s'agit d'un cas d'utilisation courant. |
| Flexibilité de l'en-tête UA-CH et user-agent | UA-CH est trop normatif par rapport à la flexibilité offerte par l'en-tête user-agent, telle que définie par le document rfc7231. | Chrome considère la nature prescriptive des en-têtes UA-CH comme une amélioration importante par rapport à la flexibilité de la chaîne UA, à la fois du point de vue de l'interopérabilité entre les navigateurs à terme et de la protection de la confidentialité des utilisateurs (en empêchant l'ajout arbitraire d'identifiants à entropie élevée).
Le problème reste ouvert au cas où d'autres personnes partageraient également ce problème et voudraient vous faire part de leurs commentaires. |
| UA-CH: Préoccupations concernant la lutte contre la fraude et les abus | Certaines fonctionnalités peuvent être perdues via UA-CH: l'outil de suivi des redirections de clics et les clics frauduleux. | L'équipe étudie ces problèmes potentiels avec les personnes concernées dans la lutte contre la fraude et les mesures. |
| Performances | La latence d'obtention des indications via Critical-CH (au premier chargement de la page) pose problème. | Chrome étudie actuellement des moyens d'améliorer les performances. |
Gnatcatcher (en cours)
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Préoccupations liée à la latence | L'ajout de sauts supplémentaires peut avoir un impact sur la latence | Nous envisageons un proxy à deux sauts et étudions les moyens de trouver le bon équilibre entre confidentialité et latence des utilisateurs. Nous sommes ouverts à vos commentaires et aimerions en savoir plus sur les forums W3C. |
| Protection contre la fraude et les bots | Impact sur la fraude et la protection contre les bots, y compris dans les pays moins développés | La sécurité est une exigence fondamentale, car nous cherchons des moyens d'améliorer la confidentialité des utilisateurs de manière significative, par exemple en utilisant des adresses IP par proxy. Un proxy à deux sauts établi en partenariat avec des entreprises réputées fournit une confidentialité vérifiable des utilisateurs. Nous recherchons également de nouveaux signaux pour renforcer la confiance des utilisateurs. |
| Respect des lois locales sur la confidentialité | La création de rapports sur les données géographiques au niveau du pays complique la conformité avec des régimes locaux plus précis. | Nous avons rendu public nos principes proposés, qui incluent certaines approches potentielles qui permettraient aux sites Web de rester conformes aux exigences locales. |
Renforcez les limites de confidentialité intersites
Ensembles internes
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Utilité pour les différents types de partenaires | Impact du lecteur d'empreinte digitale pour les petits et les grands éditeurs | L'objectif principal de la Privacy Sandbox est d'améliorer la confidentialité des utilisateurs en remplaçant les pratiques actuelles par des solutions qui ne reposent pas sur des mécanismes de suivi intersites. Nous voulons que ces solutions soient aussi utiles que possible pour différents types et tailles de partenaires. N'hésitez pas à nous faire part de vos suggestions spécifiques et concrètes visant à améliorer ces solutions, et nous espérons qu'elles continueront à évoluer grâce aux discussions et aux tests de la communauté. |
| Renforcer la confidentialité | Un trop grand nombre de sites du même ensemble peut entraîner des résultats similaires à ceux des cookies tiers | Nous apprécions vos commentaires et cherchons à déterminer les limites appropriées, tout en nous efforçant d'offrir aux utilisateurs et aux développeurs un traitement ou des signaux leur permettant de comprendre quand une telle limite est atteinte. Nous n'avons pas encore de proposition précise, mais nous espérons le faire très prochainement. |
| Compatibilité de l'écosystème avec le lecteur d'empreinte digitale | Collecte d'aide et de préoccupations concernant la poursuite du développement du FPS en dehors de la Privacy CG | Bien que nous aurions préféré que la proposition d'ensembles internes reste dans la PrivacyCG, nous avons hâte de continuer à la poursuivre dans les WICG. Les nombreuses déclarations de soutien nous ont également encouragés à poursuivre la discussion sur les ensembles internes et les cas d'utilisation auxquels ils sont destinés. Google s'engage à trouver des solutions permettant au Web de se développer et de prospérer tout en protégeant et en respectant la confidentialité des utilisateurs. |
| Interopérabilité des navigateurs | Implémentation par d'autres navigateurs | Nous sommes conscients de l'importance de l'interopérabilité des navigateurs pour les développeurs et nous continuerons à collaborer avec d'autres navigateurs pour standardiser les FPS. |
| Exigence courante des règles de confidentialité | Il est impossible d'appliquer des règles de confidentialité communes à l'ensemble des produits et aux juridictions qui doivent faire partie du même ensemble. | Nos règles sont toujours en cours de définition et nous tiendrons compte de vos commentaires. |
API Fenced Frames
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Demande de documentation | Différences avec les iFrames en bac à sable | Nous apprécions vos commentaires et vos suggestions. Il y a actuellement une discussion à ce sujet sur GitHub, et nous espérons obtenir des éclaircissements finaux sur la demande afin de pouvoir ensuite l'évaluer complètement. La discussion publique est disponible sur cette page. |
| Fonctionnalités multi-API | Compatibilité par défaut avec Attribution Reporting dans Fenced Frames | Nous vous invitons à nous faire part de vos commentaires sur une proposition visant à autoriser l'API Attribution Reporting en "mode annonces opaques" pour les frames cloisonnés par défaut. Nous encourageons les développeurs qui trouveraient cette opportunité à prendre part à la discussion. |
API Shared Storage
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Limites de données | Y aura-t-il une restriction sur la quantité de données pouvant être stockées par partition ? | Oui, il y aura des limites. Pour en savoir plus, consultez la page Problèmes liés à GitHub. Nous aurons besoin de quotas de stockage. Notre proposition actuelle consiste à définir une limite de taille par entrée de 4 Ko, les clés et les valeurs seront limitées à 1 024 char16_t caractères chacun, et un nombre maximal d'entrées par origine de 10 000 entrées avec un mécanisme qui empêche le commit d'entrées supplémentaires lorsque la capacité d'une origine est pleine. Nous aimerions connaître votre avis sur les limites spécifiques proposées sur cette page. |
| Transparence pour les utilisateurs | Transparence pour les utilisateurs concernant les sources de données et l'utilisation des données | Vos commentaires nous sont très utiles, et nous pensons que cette approche mériterait d'être explorée. Plus particulièrement, nous cherchons à déterminer s'il est possible de le faire d'une manière qui offre suffisamment de transparence aux utilisateurs. |
CHIPS
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Obstacles à l'adoption | Les CHIPS doivent-ils être liés à un nom d'hôte ? (l'exigence d'absence de domaine) | Nous supprimons cette exigence de l'unité organisationnelle suite aux commentaires des participants indiquant que cette exigence a complexifié l'adoption des CHIPS.
Nous discuterons de cette exigence au sein du groupe de la communauté sur la confidentialité lors de l'incubation des normes sur cette page. |
| Cas d'utilisation des annonces CHIPS | Les CHIPS peuvent-ils être utilisés pour des cas d'utilisation d'Ads sur un seul site ? | Le suivi des utilisateurs sur un seul site est un cas d'utilisation autorisé. Nous avons mis à jour notre article pour les développeurs afin de mettre en évidence ce cas d'utilisation. |
| Intégrations authentifiées | L'état de connexion est-il préservé avec les CHIPS ? | L'état de connexion n'est pas conservé actuellement, mais il ne s'agit pas du cas d'utilisation prévu pour CHIPS. Nous sommes au courant du cas d'utilisation des intégrations authentifiées et nous recherchons des solutions. |
| Coordination des tests | D'autres actions utilisateur sont-elles nécessaires pour tester le partitionnement ? | Tant que le jeton OT est valide et présent dans les en-têtes des pages visitées, la fonctionnalité doit être disponible pour les utilisateurs, sans nécessiter d'action supplémentaire de la part de l'utilisateur. |
| Compatibilité du navigateur | Volonté de comprendre comment d'autres navigateurs ont géré les attributs des cookies partitionnés. | Chrome continue de travailler au sein des groupes de normes publiques tels que le W3C pour identifier les conceptions et les implémentations qui peuvent fonctionner sur tous les navigateurs. |
FedCM
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Vecteurs d'attaque potentiels | Vecteurs d'attaque potentiels via la décoration de liens et les attaques temporelles | Nous recueillons activement des commentaires du public et recherchons des solutions pour résoudre ce problème. |
| l'expérience utilisateur pour plusieurs IdP. | Un seul IdP peut être présenté à la fois | Nous pensons qu'il est important de prendre en charge plusieurs IdP et nous travaillons activement sur des approches pour leur faciliter la tâche. |
| Expressivité | Inquiétudes : étant donné que le navigateur effectue une partie du flux d'identité fédérée, il est difficile de saisir toutes les nuances que les IdP souhaitent présenter à leurs utilisateurs. | Nous étudions la possibilité de personnaliser les éléments du branding (par exemple, les logos ou les couleurs) et les chaînes (par exemple, "accéder à cet article" et non "Se connecter avec").
Chrome est conscient de ce compromis et va continuer à travailler avec l'écosystème pour couvrir autant de sujets que possible et le rendre aussi expressif que possible. |
| Applicabilité et interopérabilité | Inquiétudes concernant l'absence d'adoption ou d'implémentation de FedCM par d'autres navigateurs | L'équipe Chrome a également collaboré avec d'autres fournisseurs de navigateurs au sein du FedID Community Group, afin de trouver des solutions communes à ces problèmes. |
| Suggestion de suppression des exigences concernant les données à caractère personnel lors du processus d'inscription | (1) Une expérience utilisateur qui indique à l'utilisateur l'IdP qu'il choisit, sans indiquer que son adresse e-mail, sa photo et son nom seront partagés serait plus respectueux de la confidentialité
(2) L'expérience utilisateur et la sélection de revendications provenant du fournisseur d'identité (IdP) ne font pas partie des cas d'utilisation. |
Nous sommes d'accord et réfléchissons à la manière d'implémenter vos commentaires d'une manière plus conviviale, plus respectueuse de la confidentialité et plus respectueuse de l'utilisateur. |
| Interaction de l'utilisateur avec le fournisseur d'identité | Besoin d'une interaction directe entre l'utilisateur et le fournisseur d'identité en cas de dépassement d'un seuil de risque | Nous examinons activement vos commentaires. |
Network State Partitioning
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Performances | Le partitionnement de l'état du réseau peut entraîner une augmentation des connexions aux CDN utilisant de nombreuses ressources. | Nous étudions encore les caractéristiques de performances du partitionnement de l'état du réseau, y compris la mesure de différents schémas de saisie possibles. Nous n'avons pas encore pris de décision entre les compromis de performances, de sécurité et de confidentialité, et nous devons recueillir davantage de données. |
Lutter contre le spam et la fraude
API Trust Tokens
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Commentaires sur les réglementations | Inquiétudes concernant le temps et les ressources investis dans les jetons de confiance sans signal clair de la part des organismes de réglementation concernant la viabilité à long terme | Notre objectif est de concevoir des technologies qui fonctionnent pour l'écosystème, en tenant compte des commentaires du secteur et des organismes de réglementation dans le processus. Nous continuerons de consulter les organismes de réglementation du monde entier à mesure que nous développerons la Privacy Sandbox et mettrons les propositions à la disposition des développeurs, y compris les jetons de confiance. Comme pour toutes les nouvelles technologies, les entreprises doivent prendre des décisions en fonction de leur propre évaluation des exigences réglementaires. |
| Calendrier de lancement | Quand le lancement des jetons de confiance sera-t-il disponible pour tous les utilisateurs ? | Nous communiquons nos estimations actuelles par le biais de notre calendrier public sur privacysandbox.com. Dès que nous aurons pris une décision définitive concernant la date de mise à disposition générale, nous la publierons publiquement via les processus de lancement de Chrome et mettrons à jour le calendrier sur le site Web. |
| Jetons de confiance par rapport aux autres | Quel est le rôle des jetons de confiance par rapport aux autres jetons en cours de standardisation, tels que les jetons d'accès privé ? | Nous sommes engagés dans des discussions sur la normalisation, et notre objectif est de nous aligner sur d'autres initiatives autant que possible, tout en permettant les différents cas d'utilisation permis par chaque technologie. Par exemple, les jetons de confiance et les jetons d'accès privé reposent tous deux sur le protocole Privacy Pass. |
| Limites de données | Deux émetteurs maximum par page, ce qui peut limiter | Nous recherchons des options à long terme permettant aux entreprises d'utiliser leurs jetons en toute sécurité sans risquer d'aggraver l'entropie des utilisateurs, par exemple en partitionnant l'accès à l'utilisation des jetons. |
| Restrictions d'accès | Seules les origines approuvées (et validées/non falsifiées) doivent pouvoir vérifier la présence d'un jeton et utiliser l'offre. | Nous étudions des approches pour déterminer qui peut voir et utiliser les jetons. |
| Assistance relative aux appareils | Les dépendances d'exécution JavaScript limitent l'utilisation sur certains appareils. Est-il possible d'étendre cette prise en charge à d'autres types d'appareils ? | Nous pourrions en tenir compte pour le développement futur et nous aimerions connaître l'avis des développeurs sur les forums W3C. Nous avons également un problème ouvert concernant l'utilisation d'un jeton déclenché par l'en-tête HTTP pour laquelle nous invitons vos commentaires. |
| Cas d'utilisation | Les cas d'utilisation des jetons de confiance ne sont pas clairs. Manque de clarté concernant les utilisations prévues. | Notre objectif est de faciliter l'innovation dans le domaine de la lutte contre la fraude et de comprendre que chaque entreprise peut utiliser des techniques propriétaires avec des jetons de confiance. C'est pourquoi nous n'avons pas été normatifs quant aux utilisations prévues. Toutefois, nous développerons probablement notre documentation pour inclure d'autres exemples comme points de départ pour les partenaires qui envisagent de réaliser des tests ou de les adopter. |
| Couverture des jetons de confiance | La suppression de cette règle de fonctionnalité d'utilisation des jetons de confiance devrait augmenter considérablement la couverture des jetons de confiance. | Cela est pris en compte lorsque nous recueillons les commentaires de l'OT et prenons des décisions sur les prochaines étapes. |
| Confiance de l'émetteur | Pourquoi faire confiance aux sites Web qui émettent des jetons de confiance ? | Il n'existe aucune règle pour devenir émetteur. Tout le monde peut le faire. Les éditeurs ne devraient collaborer qu'avec des émetteurs de confiance. De plus, d'autres acteurs légitimes de l'écosystème publicitaire finissent par écarter (ou arrêter d'acheter) le trafic associé à des émetteurs suspects ou inconnus. |
| Services tiers intégrés | Les services intégrés tiers peuvent-ils utiliser et/ou demander des jetons de confiance ? | Oui, un service tiers intégré peut émettre et utiliser des jetons de confiance. |
| Écosystème d'émetteurs | Il est possible d'améliorer l'utilité en partageant les signaux de confiance avec d'autres entreprises. | Les jetons de confiance sont conçus pour être une primitive de bas niveau. Ils peuvent être utilisés par les émetteurs/émetteurs coopératifs pour partager des signaux de confiance/réputation. |
| Coûts de maintenance | L'implémentation cryptographique sous-jacente aux opérations Trust Token s'effectue dans BoringSSL, dont Google est le seul responsable. Comment la maintenance de la bibliothèque sera-t-elle gérée ? | Les jetons de confiance reposent sur des opérations cryptographiques standardisées (voir Protocole Privacy Pass) qui peuvent également être implémentées dans d'autres bibliothèques. Nous recommandons aux développeurs de demander, de développer et de maintenir la prise en charge de ces opérations dans les bibliothèques de leur choix. |
| Coûts de maintenance | Impossible de déterminer la durée de compatibilité des versions du protocole | Nous cherchons à établir et à documenter plus de détails sur les délais de prise en charge attendus des versions de protocole. |
| Limites des émetteurs | Si vous êtes plus loin dans la chaîne, vous ne verrez peut-être pas l'occasion d'exécuter des jetons de confiance. | Alors que de plus en plus d'organisations commencent à utiliser des jetons de confiance, nous sommes de plus en plus susceptibles d'observer ce type de dynamique de timing et nous étudions des solutions potentielles. Comme décrit précédemment, nous recherchons des options à long terme permettant aux entreprises d'utiliser des jetons en toute sécurité sans risquer une plus grande entropie des utilisateurs, ce qui réduirait l'importance de l'emplacement sur la page ou de l'ordre de chargement. |
Nouvelles solutions de lutte contre la fraude dans les incubations
| Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Signaux d'attestation d'intégrité de l'appareil | Compatibilité générale avec les signaux d'intégrité des appareils certifiés par les plates-formes et mis à disposition sur le Web | Nous continuerons à recueillir les commentaires et à poursuivre la proposition par le biais d'itérations et de conceptions publiques. |
| Signaux d'attestation d'intégrité de l'appareil | Questions concernant la quantité d'entropie de l'utilisateur pouvant être transmise par de nouveaux signaux et si certains cas d'utilisation (par exemple, lorsqu'un utilisateur se connecte à sa banque) pourraient justifier des signaux d'entropie plus élevés. | Afin de préserver la confidentialité des utilisateurs, nous nous efforçons de fournir des signaux de forte valeur avec le moins d'entropie possible des utilisateurs. |
| Signaux d'attestation d'intégrité de l'appareil | Ce signal limiterait-il l'accès des appareils plus anciens ou des plates-formes Open Source/modifiées ? | Tout nouveau signal devrait considérer l'accès universel comme un principe clé du développement, et il s'agit de questions importantes à aborder d'emblée à mesure que nous poursuivons notre développement. |
| Signaux d'attestation d'intégrité de l'appareil | Le fait que de nouveaux signaux conduisent les entreprises de sécurité et de lutte contre la fraude à s'appuyer sur le navigateur et les plates-formes étaient inquiets
|
Tout nouveau signal doit être considéré comme une donnée complémentaire et non comme une indication de la "confiance" du navigateur. Nous nous attendons à ce que les entreprises de sécurité continuent de s'appuyer sur leurs propres données, modèles et moteurs de décision propriétaires, en plus de l'attestation d'appareil. Nous espérons que tout nouveau signal améliorera les efforts de détection dans l'écosystème et rendra les fraudes plus difficiles à exécuter. |
| Signal d'âge des cookies | Concept intéressant, mais qui nécessitera probablement davantage d'informations sur les cas d'utilisation applicables. | Selon les niveaux d'intérêt, Chrome peut approfondir la conceptualisation de ce concept et l'utiliser comme un message explicatif pour les futurs commentaires de l'écosystème. |
| Serveurs de confiance pour la lutte contre la fraude | Concept intéressant, mais qui nécessitera probablement davantage d'informations sur les cas d'utilisation applicables. | Selon les niveaux d'intérêt, Chrome peut approfondir la conceptualisation de ce concept et l'utiliser comme un message explicatif pour les futurs commentaires de l'écosystème. |