Rapport trimestriel du 2e trimestre 2022 résumant les commentaires de l'écosystème reçus sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.
Les thèmes des commentaires sont classés en fonction de leur prévalence par API. Pour ce faire, nous prenons la quantité de commentaires que l'équipe Chrome a reçus sur un thème donné et l'organisons par ordre décroissant. Les thèmes courants des commentaires ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquentes soulevées par les équipes internes de Google et les formulaires publics.
Plus précisément, les comptes rendus des réunions des organismes de normalisation du Web ont été examinés. Pour les commentaires directs, les enregistrements de Google des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires publics ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation pour déterminer la prévalence relative des thèmes émergents en lien avec chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifique aux fins de cet exercice de rapport public. En raison de l'objectif actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Fledge et Attribution Reporting.
Les commentaires reçus après la fin de la période de création de rapports en cours n'ont peut-être pas encore fait l'objet d'une réponse de Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Gestion des identifiants fédérés
- Lecteur d'empreinte digitale
- Ensembles propriétaires
- IAB
- Interactive Advertising Bureau
- IDP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- IP
- Adresse IP
- openRTB
- Enchères en temps réel
- Prolongation
- Essai Origin
- PatCG
- Groupe de la communauté sur les technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client User-Agent
- W3C
- World Wide Web Consortium
- WIPB
- Blanchement volontaire des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Des délais plus clairs | Calendriers de publication plus clairs et détaillés pour les technologies de la Privacy Sandbox. | Nous avons indiqué nos plans actuels concernant le calendrier de déploiement sur privacysandbox.com et nous le mettons à jour tous les mois. Ces dates tiennent compte du temps de développement pour les développeurs Chrome et Web, ainsi que des commentaires que nous avons reçus de l'écosystème plus large sur le temps nécessaire pour tester et adopter les nouvelles technologies. Chaque technologie passe par plusieurs étapes, du test à la publication (lancement), et le calendrier de chaque étape est déterminé en fonction de ce que nous apprenons et découvrons à l'étape précédente. Nous n'avons pas encore de date de sortie précise, mais nous vous tiendrons informés dès que nous en saurons plus sur privacysandbox.com. |
| Utilité pour différents types d'acteurs | Inquiétudes concernant les technologies de la Privacy Sandbox qui favoriseraient les grands développeurs et les sites de niche (plus petits) qui contribueraient plus que les sites génériques (plus grands). | Nous comprenons que certains développeurs s'inquiètent de l'impact des technologies de la Privacy Sandbox. Google s'est engagé auprès de la CMA à ne pas concevoir ni implémenter les propositions de la Privacy Sandbox de manière à fausser la concurrence en favorisant son propre activité, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, ainsi que l'impact sur les résultats en termes de confidentialité et l'expérience utilisateur. Nous continuons à travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements.
À mesure que les tests de la Privacy Sandbox avancent, l'une des questions clés que nous allons évaluer est la performance des nouvelles technologies pour différents types d'acteurs. Les commentaires sont essentiels à cet égard, en particulier ceux qui sont spécifiques et exploitables, et qui peuvent nous aider à améliorer davantage les conceptions techniques. |
| Calendrier d'abandon des cookies tiers | Demandes visant à éviter tout retard supplémentaire dans l'abandon des cookies tiers | Certains acteurs souhaitent que Chrome abandonne immédiatement les cookies tiers, tandis que d'autres estiment qu'il faut plus de temps pour tester et adopter les technologies de la Privacy Sandbox. Nous nous engageons à agir de manière responsable compte tenu de la complexité des technologies et de l'importance de bien faire les choses pour l'écosystème. Les commentaires du secteur et des organismes de réglementation ont été essentiels à ce processus. |
| Calendrier d'abandon des cookies tiers | Demandes de retarder l'abandon des cookies tiers et de disposer de plus de temps pour tester les API. | Certains acteurs souhaitent que Chrome abandonne immédiatement les cookies tiers, tandis que d'autres estiment qu'il faut plus de temps pour tester et adopter les technologies de la Privacy Sandbox. Nous nous engageons à agir de manière responsable compte tenu de la complexité des technologies et de l'importance de bien faire les choses pour l'écosystème. 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 l'implémentation. | Nous sommes ravis que les développeurs aient trouvé nos ressources actuelles utiles. Nous nous engageons à fournir davantage de ressources, y compris des permanences et de la documentation technique, au cours des semaines et des mois à venir afin que les développeurs puissent continuer à comprendre comment les nouvelles technologies peuvent leur être utiles.
Nous avons également organisé des permanences publiques pour les développeurs externes afin de partager des bonnes pratiques et des démonstrations, ainsi que des sessions de questions/réponses avec les responsables produit et ingénierie pour permettre des discussions et des questions en direct. |
| Expertise sectorielle | L'équipe Chrome qui interagit avec les organismes de normalisation ne dispose pas de l'expertise nécessaire dans l'écosystème publicitaire pour équilibrer correctement la confidentialité et l'utilité. | Nous sommes conscients que nous avons une grande responsabilité et nous avons besoin de commentaires spécifiques pour y parvenir. Nous considérons également la confidentialité et l'efficacité comme des critères de conception essentiels et nécessaires. L'équipe qui travaille sur la Privacy Sandbox pour le Web compte des centaines d'années d'expérience dans l'écosystème publicitaire. |
Afficher des publicités et des contenus pertinents
Thèmes
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Utilité pour différents types d'acteurs | Des inquiétudes ont été soulevées concernant la valeur créée et la distribution de cette valeur pour les sites en fonction de leur niveau de trafic ou du niveau de spécialisation de leur contenu. | L'utilité de l'API sera évaluée par le biais de tests. Chrome s'attend à ce que la taxonomie et d'autres paramètres évoluent en fonction des résultats des tests. L'évolution de la taxonomie ou des paramètres ne nécessite pas nécessairement de modifications incompatibles avec les versions antérieures. De plus, Chrome s'attend à ce que les commentaires continuent d'influencer l'évolution de l'API Topics après l'abandon des cookies tiers. |
| Taxonomie | Les partenaires du secteur souhaitent avoir leur mot à dire sur la taxonomie. | Chrome reste ouvert aux commentaires sur la taxonomie. Chrome est très intéressé par les commentaires sur le modèle de gouvernance permettant de modifier la taxonomie, et par les discussions sur la façon dont d'autres organismes du secteur peuvent jouer un rôle plus actif dans le développement et la maintenance de la taxonomie à long terme. |
| Manque d'historique de navigation | Proposition de présenter les thèmes que l'appelant a vus au cours des semaines précédentes si l'utilisateur ne dispose pas d'un historique de navigation suffisant pour créer cinq thèmes pour la semaine la plus récente | Dans notre conception actuelle, ils sont choisis au hasard. Nous allons examiner la corrélation avec les sujets précédents et déterminer si nous pouvons l'intégrer. Toutefois, les corrélations peuvent avoir des conséquences négatives sur la confidentialité, ce qui doit être pris en compte. |
| Appeler Topics pour le compte d'un éditeur | Un fournisseur de services tiers peut-il partager des thèmes avec un éditeur ? | Oui, c'est l'une des utilisations prévues pour Topics. |
| Vecteurs d'attaque potentiels | Identifier les sujets bruyants | Sur la base des commentaires de nombreux membres de l'écosystème, Chrome a choisi de filtrer les sujets et d'introduire du bruit. Ces décisions ont été prises dans un souci de confidentialité : limiter l'accès aux informations à ceux qui n'y auraient pas eu accès autrement et introduire une négation plausible pour les utilisateurs, respectivement. Nous sommes conscients que ces décisions présentent des inconvénients, comme le vecteur d'attaque décrit ici. Toutefois, nous estimons que les avantages en termes de confidentialité l'emportent sur les risques potentiels. Nous encourageons le débat public sur cette décision. |
| Éligibilité à l'essai Origin | Existe-t-il un moyen de détecter si un utilisateur est éligible à un essai Origin ? | Il est possible qu'une fonctionnalité de test d'origine ne soit pas disponible pour un utilisateur en raison des paramètres de son navigateur ou d'autres facteurs, même s'il accède à une page Web qui fournit un jeton de test valide et que son navigateur est inclus dans le groupe pour lequel le test est activé.
C'est pourquoi vous devez toujours utiliser la détection de fonctionnalités pour vérifier si une fonctionnalité de test d'origine est disponible avant de tenter de l'utiliser. |
| Impacts sur les performances | Problèmes de surcharge et de latence avec Topics | Nous demandons votre avis sur les approches permettant d'éviter les iFrames cross-origin coûteux et lents, et sur la proposition de démêler l'API Topics afin que l'obtention de thèmes ne modifie pas l'état de navigation. |
| Fonctionnalités de l'API Topics divisée | Fournir un contrôle plus précis sur les trois différents aspects de l'API | Nous comprenons le cas d'utilisation et avons proposé une solution possible sur GitHub. Nous attendons actuellement d'autres commentaires de l'écosystème pour savoir si nous devons développer cette fonctionnalité. Pour en savoir plus, consultez cette discussion. |
| Calendrier et documentation du classificateur | Les développeurs ont demandé plus d'informations sur le classificateur. | Pour en savoir plus sur le classificateur, cliquez ici.
et ici. Et ici. |
| Commandes utilisateur et sécurité | Certains thèmes peuvent être des proxys pour des groupes sensibles, et les utilisateurs ont besoin de plus de contrôles pour éviter les résultats négatifs. | Les thèmes représentent un progrès important en termes de contrôle et de transparence pour les utilisateurs. Les utilisateurs pourront désactiver les thèmes, consulter les thèmes qui leur ont été attribués, les supprimer et identifier les entreprises qui interagissent avec leurs thèmes sur une page donnée. De plus, les utilisateurs peuvent également modifier leurs sujets en supprimant leur historique de navigation. Nous sommes ravis de poursuivre la discussion sur les commandes utilisateur plus avancées, telles que celles suggérées par les développeurs. Toutefois, nous devons nous assurer que les risques soulevés par ce bug sont effectivement éliminés (par exemple, supprimer uniquement le thème "Étude de langues étrangères", mais pas les sites Web qui ont généré le thème à partir de l'historique de navigation, ne protège pas entièrement l'utilisateur). |
| Utilisation des thèmes sur les sites avec prebid.js | L'API Topics peut-elle être utilisée sur des sites Web avec prebid.js ? | La réponse est oui. Pour en savoir plus, cliquez ici. |
| Utiliser l'API Topics dans un widget de recommandations | Pouvons-nous utiliser l'API Topics dans le widget "Recommandations" (par exemple, Outbrain) ? | Nous ne limitons pas le cas d'utilisation des sujets récupérés après l'appel de l'API (cela dépend des règles de données de chaque développeur). |
| Confidentialité / Règles | Questions sur l'objectif du filtrage des réponses par appelant si certains tiers partagent leurs sujets avec toute personne qui appelle. | Sur la base des commentaires de nombreux membres de l'écosystème, Chrome a choisi cette conception pour limiter l'accès aux informations à ceux qui n'y auraient pas eu accès autrement. Bien entendu, les éditeurs et les tiers qui reçoivent des thèmes peuvent décider eux-mêmes des informations qu'ils partageront avec les parties sur leur site. S'ils le font, Chrome les encourage vivement à en informer leurs utilisateurs et à leur proposer des commandes. |
| Signaux bruyants | Envoyer un sujet aléatoire 5% du temps peut créer trop de bruit / faux signaux. | Le bruit est une méthode importante pour protéger la confidentialité des utilisateurs. Les niveaux de bruit par rapport à l'utilité des sujets seront explorés par le biais de tests. |
FLEDGE
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Tester la coordination | Tester l'impact sur les performances et les revenus | Les performances de FLEDGE et la manière dont nous pouvons mieux soutenir les tests de l'écosystème lors des essais Origin et de la disponibilité générale sont actuellement en discussion lors des réunions publiques du WICG. |
| Serveur de confiance pour FLEDGE | Quand le serveur de confiance sera-t-il disponible pour les tests ? | Nous vous remercions de ces commentaires et nous travaillons activement sur un plan plus détaillé que nous pourrons partager sur l'utilisation de serveurs approuvés dans FLEDGE. |
| Standardisation des protocoles | Existe-t-il un protocole commun pour transmettre des données entre les SSP et les DSP, comme des libellés communs pour les groupes de centres d'intérêt ? | Nous accueillons les commentaires des DSP, des SSP et de l'écosystème publicitaire plus large sur la possible standardisation de la spécification. Pour les tests initiaux, nous vous recommandons de travailler directement avec vos partenaires de test, car ils expérimentent différentes approches. Nous encourageons également les organisations professionnelles du secteur publicitaire à s'exprimer et prévoyons de continuer à travailler avec elles pour créer une standardisation si cela est utile pour leurs entreprises membres. |
| Limitation de la fréquence d'exposition | Contrôles de la fréquence par utilisateur dans une campagne et un groupe d'annonces. | FLEDGE sera également compatible avec la limitation de la fréquence d'exposition pour les enchères sur l'appareil et les campagnes contextuelles / de branding. Le stockage partagé et les plafonds spécifiques au site peuvent également être utilisés pour contrôler davantage la limite de la fréquence d'exposition. |
| Impact de FLEDGE sur les performances | Enchères FLEDGE pour les enchérisseurs à forte intensité de calcul | Chrome discute activement avec les développeurs de l'impact potentiel sur les performances des sites. Chrome est ravi de pouvoir en apprendre davantage lors des tests. |
| Tester FLEDGE avec d'autres fonctionnalités | Comment les rapports au niveau des événements de l'API Attribution Reporting et de FLEDGE s'imbriqueront-ils ? | Ce point a été abordé lors d'un appel récent de la WICG/API de mesure des conversions. Vous trouverez un lien vers les minutes détaillées ici.
Voici un résumé de la réunion : la conception actuelle des rapports sur les annonces dans les cadres délimités permet d'associer un ID généré dans le cadre délimité à des informations contextuelles. Les rapports au niveau de l'événement générés dans le cadre clôturé pourront donc être joints aux mêmes informations contextuelles sur le serveur (à l'aide de deux jointures côté serveur au lieu d'une). |
| Comptabilisation des impressions | Quelle méthode de comptabilisation des impressions doit ou peut ê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 des enchères. Nous avons reçu des suggestions d'implémentations alternatives sans commentaires sur les raisons pour lesquelles notre conception actuelle ne peut pas fonctionner pour l'écosystème. |
| Afficher plusieurs annonces | Indique si vous pouvez diffuser plusieurs annonces dans une même enchère dans un cadre clôturé donné. | Pour le moment, cela est possible via les annonces de composants (à ne pas confondre avec les enchères de composants). 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 de la SDA sur les demandes d'annonces ? | FLEDGE est conçu pour éviter les fuites d'informations non pertinentes lorsque l'éditeur sait déjà dans quelles SDA se trouvent ses visiteurs et que le ciblage est du même site. S'il est important de prendre en charge les achats sur les SDA dans toutes les protections intégrées à FLEDGE, une solution consiste à ce qu'un vendeur transmette des libellés SDA aux enchères sur l'appareil et qu'une technologie publicitaire côté acheteur crée son propre groupe d'intérêt dont la logique d'enchères indique "Je souhaite acheter l'audience X". |
| Accepter d'autres devises que le dollar américain | Possibilité de tester FLEDGE avec d'autres devises que l'USD | Nous vous remercions de nous avoir signalé ce problème. Nous avons ajouté la prise en charge d'autres devises à notre liste de demandes de fonctionnalités. Nous espérons que cette fonctionnalité sera disponible très bientôt. |
| Compatibilité avec le ciblage par exclusion des groupes d'intérêt | Une API compatible avec le ciblage IG négatif: diffusion d'annonces uniquement si un utilisateur n'appartient pas à une IG. | Discussion en cours, y compris certaines options proposées pour la prise en charge, dans le problème GitHub. |
| Plusieurs SSP dans FLEDGE | Risque de favoriser Google lors de l'implémentation d'enchères multiniveaux dans FLEDGE | La prise en charge de plusieurs SSP dans FLEDGE a été ajoutée afin de garantir un terrain de jeu équitable. Google s'est engagé, dans le cadre des engagements, à ne pas concevoir, développer ni implémenter les propositions de la Privacy Sandbox de manière à fausser la concurrence en s'octroyant des préférences pour ses produits et services publicitaires. Google prend cela très au sérieux et est très à l'écoute des inquiétudes que les personnes concernées peuvent avoir concernant des aspects spécifiques de la technologie. Pour en savoir plus, consultez la documentation publique sur le mécanisme d'enchères de composants de Chrome sur cette page. |
Mesurer les annonces numériques
Attribution Reporting (et d'autres API)
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Attribution multitouch | Éditeurs demandant l'assistance pour l'attribution multipoint | Les méthodes actuelles d'attribution multipoint 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 des annonces sans suivi intersites. Dans certains cas, il est possible d'approximer l'attribution des crédits (par exemple, en utilisant des priorités pondérées et aléatoires) 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 d'épsilon afin de voir comment les rapports changent en fonction du niveau de bruit. Pour le moment, les développeurs peuvent choisir une valeur epsilon jusqu'à epsilon=64. Nous avons fait cela spécifiquement pour permettre aux développeurs de tester plus facilement les API et de nous fournir des commentaires sur les valeurs d'épsilon appropriées.
Nous avons également lancé une demande publique pour obtenir de tels commentaires. |
| Tester la coordination | L'outil de test local peut-il être utilisé pour l'OT ? | Oui, l'outil de test local peut être utilisé pendant toute la durée de l'OT. L'outil de test local peut être utilisé avec les rapports de débogage tant que les cookies tiers sont disponibles. |
| Ergonomie des requêtes | Activer les requêtes agrégées de clés | Nous sommes d'accord que cela semble améliorer l'ergonomie des API avec peu ou pas de coût apparent en termes de confidentialité. Nous ferons une proposition et verrons s'il existe un large consensus pour la soutenir. |
| Données moins précises pour les petits sites | Les sites ou campagnes de petite envergure peuvent recevoir des données moins précises. | Chrome reconnaît que les mesures de protection de la confidentialité basées sur le bruit ont un impact plus important sur les tranches de données plus petites. Toutefois, il est possible que des méthodes telles que l'agrégation sur de plus longues périodes résolvent ce problème. Il n'est pas non plus clair 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 de l'origine, Chrome encourage les testeurs à profiter de la possibilité de tester un large éventail de paramètres de confidentialité et de bruit afin de pouvoir fournir des commentaires plus spécifiques sur ce problème. |
Limiter le suivi dissimulé
Réduction user-agent
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Protection contre les bots | Impact de UA-R sur la protection contre les robots | Nous vous remercions de ces commentaires. Nous sommes en train de recueillir des informations sur les approches de protection contre les robots afin de les intégrer à nos futures conceptions. |
| Dépendances de déploiement | Résoudre les dépendances de déploiement des user-agents structurés | Nous avons déployé la "phase 4", c'est-à-dire la réduction de la version mineure, auprès de 100% des utilisateurs de Chrome dans les versions 101 et ultérieures. En savoir plus |
User Agent Client Hints
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Énumérer toutes les suggestions compatibles | Intérêt d'avoir un moyen programmatique de connaître toutes les suggestions compatibles pour un navigateur. | Nous vous remercions de vos commentaires. Nous évaluons actuellement la demande de fonctionnalité. Nous aimerions savoir s'il s'agit d'un cas d'utilisation courant. |
| Flexibilité de l'en-tête UA-CH par rapport à l'en-tête User-Agent | UA-CH est trop contraignant par rapport à la flexibilité offerte par l'en-tête User-Agent, tel que défini par la RFC 7231. | 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 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 utilisateurs rencontreraient le même problème et souhaiteraient nous faire part de leurs commentaires. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | Certaines fonctionnalités peuvent être perdues avec UA-CH: le suivi des redirections de clics et les clics frauduleux. | L'équipe étudie ces problèmes potentiels avec les personnes concernées par la lutte contre la fraude et les mesures. |
| Performances | Des inquiétudes subsistent quant à la latence d'obtention d'indices via Critical-CH (au premier chargement de page). | Chrome étudie des moyens d'améliorer les performances. |
Gnatcatcher (en cours)
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Problèmes de latence | L'ajout d'un ou de plusieurs sauts supplémentaires peut avoir un impact sur la latence. | Nous envisageons d'utiliser un proxy à deux sauts et d'explorer des moyens de trouver le bon équilibre entre la confidentialité des utilisateurs et la latence. Nous sommes à l'écoute de vos commentaires et nous aimerions poursuivre la discussion sur les forums du W3C. |
| Protection contre la fraude et les bots | Impacts sur la protection contre la fraude et les bots, y compris dans les pays moins développés | La sécurité est une exigence fondamentale, car nous cherchons à améliorer la confidentialité des utilisateurs de manière significative, par exemple en proxyant les adresses IP. Un proxy à deux sauts en partenariat avec des entreprises réputées garantit la confidentialité des utilisateurs. Nous étudions également des idées de nouveaux signaux pour gagner la confiance des utilisateurs. |
| Respect des lois locales sur la confidentialité | Les rapports sur les données géographiques au niveau du pays rendent la conformité avec les régimes locaux plus détaillés difficile | Nous avons publié publiquement nos principes proposés, qui incluent des approches potentielles permettant aux sites Web de rester conformes aux exigences locales. |
Prévention du suivi intersites pour améliorer la confidentialité
Ensembles propriétaires
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Utilité pour différents types d'acteurs | Impact des FPS sur les petits et 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 dépendent pas de mécanismes de suivi intersites. Nous souhaitons que ces solutions soient aussi utiles que possible pour différents types et tailles d'acteurs. Nous sommes à l'écoute de vos commentaires spécifiques et pratiques sur la façon dont ces solutions peuvent être améliorées. Nous nous attendons à ce qu'elles continuent d'évoluer grâce aux discussions et aux tests de la communauté. |
| Améliorer la confidentialité | Si vous incluez trop de sites dans un même ensemble, vous risquez d'obtenir des résultats similaires à ceux des cookies tiers. | Nous vous remercions de ces commentaires et évaluons si des limites appropriées sont possibles, tout en essayant de fournir aux utilisateurs et aux développeurs des traitements ou des signaux leur permettant de comprendre quand une telle limite est atteinte. Nous n'avons pas encore de proposition spécifique à vous communiquer, mais nous espérons pouvoir le faire très bientôt. |
| Prise en charge des FPS par l'écosystème | Recueil de commentaires et d'inquiétudes concernant la poursuite du développement de FPS en dehors du CG sur la confidentialité | Nous aurions préféré que la proposition sur les ensembles first party reste dans le PrivacyCG, mais nous avons hâte de la poursuivre dans le WICG. Nous avons également été encouragés par les nombreux messages d'encouragement à poursuivre la discussion sur les ensembles propriétaires et les cas d'utilisation auxquels ils sont destinés. Google s'engage à trouver des solutions qui permettent au Web de continuer à se développer et à 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 de collaborer avec d'autres navigateurs pour poursuivre la standardisation des FPS. |
| Exigences courantes concernant les règles de confidentialité | Il est impossible de maintenir des règles de confidentialité communes pour tous les produits et les juridictions qui doivent faire partie du même ensemble. | Chrome est toujours en train de définir les exigences de nos règles et tiendra compte de ces commentaires. |
API Fenced Frames
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Demande de documentation | Différences avec les iFrames en bac à sable | Merci pour vos commentaires et suggestions. Une discussion est actuellement en cours sur GitHub, où nous espérons obtenir des précisions sur la demande afin de pouvoir l'évaluer complètement. La discussion publique est disponible sur cette page. |
| Fonctionnalités multi-API | Compatibilité par défaut avec les rapports sur l'attribution dans les cadres délimités | Nous demandons votre avis sur une proposition visant à autoriser l'API Attribution Reporting en mode "annonces opaques" pour les cadres clôturés par défaut. Nous encourageons les développeurs qui le souhaitent à participer à la discussion. |
API Shared Storage
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Limites de données | La quantité de données pouvant être stockées par partition sera-t-elle limitée ? | Oui, il y aura des limites. Pour en savoir plus, consultez ce problème sur GitHub. Nous aurons besoin de quotas de stockage. Notre proposition actuelle consiste à fixer une limite de taille de 4 ko par entrée. Les clés et les valeurs seront limitées à 1 024 caractères char16_t chacune, et la limite d'entrées par origine sera de 10 000 entrées, avec un mécanisme qui empêche l'enregistrement d'entrées supplémentaires lorsque la capacité d'une origine est saturée. Nous sollicitons activement vos commentaires sur les limites spécifiques proposées ici. |
| Transparence pour les utilisateurs | Transparence pour les utilisateurs concernant les sources de données par rapport à l'utilisation des données | Nous vous remercions de vos commentaires. Nous pensons que cette approche est prometteuse et mérite d'être explorée. Nous évaluons en particulier s'il est possible de le faire de manière à offrir une transparence suffisante aux utilisateurs. |
CHIPS
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Entraves à l'adoption | Les chips doivent-ils être liés au nom d'hôte ? (exigence de non-domaine) | Nous supprimons cette exigence de l'OT, car les participants nous ont fait part de leur inquiétude quant à sa complexité et à son impact négatif sur l'adoption de CHIPS.
Nous discuterons de cette exigence dans le groupe de la communauté sur la confidentialité dans le cadre de l'incubation des normes ici. |
| Cas d'utilisation des annonces pour CHIPS | Les chips peuvent-ils être utilisés pour les cas d'utilisation Ads sur un seul site ? | Le suivi des utilisateurs sur un site est un cas d'utilisation autorisé. Nous avons mis à jour notre article pour les développeurs afin de mettre en avant ce cas d'utilisation. |
| Intégrations authentifiées | L'état de connexion est-il préservé avec CHIPS ? | L'état de connexion n'est actuellement pas conservé, mais ce n'est pas le cas d'utilisation prévu pour CHIPS. Nous sommes au courant du cas d'utilisation des implémentations authentifiées et nous travaillons à trouver des solutions. |
| Tester la coordination | Des actions supplémentaires de la part des utilisateurs sont-elles requises pour tester la partitionnement ? | Tant que le jeton OT est valide et présent dans les en-têtes des pages consultées, la fonctionnalité doit être disponible pour les utilisateurs, sans qu'aucune action supplémentaire ne soit requise de leur part. |
| Compatibilité du navigateur | Intérêt à comprendre comment d'autres navigateurs ont géré les attributs de cookie partitionnés. | Chrome continue de travailler avec des groupes de normes publiques tels que le W3C pour identifier les conceptions et les implémentations qui peuvent fonctionner dans tous les navigateurs. |
FedCM
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Vecteurs d'attaque potentiels | Vecteurs d'attaque potentiels via la décoration de liens et les attaques par synchronisation | Nous recueillons activement les commentaires du public et étudions les solutions possibles pour résoudre ce problème. |
| UX permettant d'utiliser plusieurs IDP | Vous ne pouvez présenter qu'une seule IDP à la fois. | Nous souhaitons prendre en charge plusieurs IDP et nous travaillons activement à des approches permettant de |
| Expressivité | Inquiétude concernant le fait que, comme le navigateur génère une partie du flux d'identité fédérée, il est difficile de capturer toutes les nuances que les IDP souhaitent présenter à leurs utilisateurs. | Chrome explore la possibilité d'inclure des personnalisations de branding (logos, couleurs, etc.) et de chaînes (par exemple, "Accéder à cet article" au lieu de "Se connecter avec").
Chrome est conscient de ce compromis et continuera de travailler avec l'écosystème pour couvrir le plus de terrain possible et le rendre aussi expressif que possible. |
| Applicabilité et interopérabilité | Inquiétude concernant l'adoption ou l'implémentation de FedCM par d'autres navigateurs. | Chrome a également travaillé avec d'autres fournisseurs de navigateurs pour trouver des solutions communes à la fédération au sein du groupe de la communauté FedID. |
| Suggestion de suppression des exigences concernant les données à caractère personnel dans le parcours d'inscription | (1) Une expérience utilisateur qui indique à l'utilisateur l'IDP qu'il choisit, sans signaler que son adresse e-mail, sa photo et son nom seront partagés serait plus respectueuse de la confidentialité.
(2) L'expérience utilisateur et la sélection des revendications du fournisseur d'identité sont peu détaillées dans les cas d'utilisation de l'inscription |
Nous sommes d'accord et nous étudions comment mettre en œuvre ces commentaires de manière plus conviviale et respectueuse de la confidentialité. |
| Interaction de l'utilisateur avec l'IDP | Nécessité d'une interaction directe entre l'utilisateur et l'IDP si un seuil de risque est dépassé | Nous étudions activement ces commentaires. |
Network State Partitioning
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Performances | Le partitionnement de l'état du réseau peut entraîner une augmentation des connexions aux CDN qui consomment beaucoup de ressources. | Nous étudions toujours les caractéristiques de performances du partitionnement de l'état du réseau, y compris en mesurant les différents schémas de clé possibles. Nous n'avons pas encore pris de décision concernant les compromis entre les performances, la sécurité et la confidentialité, et nous devons collecter plus de données. |
Lutter contre le spam et la fraude
API Trust Tokens
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Commentaires sur les réglementations | Inquiétudes concernant l'investissement de temps et de ressources dans les jetons de confiance sans signal clair des autorités réglementaires sur leur viabilité à long terme | Notre objectif est de créer une technologie qui fonctionne pour l'écosystème. Les commentaires du secteur et des organismes de réglementation sont donc essentiels au processus. Nous continuerons de consulter les autorités de réglementation du monde entier pendant 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 leurs décisions en fonction de leur propre évaluation des exigences réglementaires. |
| Calendrier de lancement | Quand les jetons de confiance seront-ils lancés en disponibilité générale ? | Nous fournissons nos estimations actuelles de disponibilité dans notre calendrier public sur privacysandbox.com. Dès que nous aurons pris une décision définitive sur la date de disponibilité en version GA, nous l'annoncerons publiquement via les processus de publication de Chrome et mettrons à jour le calendrier sur le site Web. |
| Trust Tokens par rapport aux autres | Quel est le rôle des jetons de confiance compte tenu des autres jetons en cours de normalisation, tels que les jetons d'accès privés ? | Nous menons des discussions de normalisation et notre objectif est de nous aligner autant que possible sur les autres efforts, tout en permettant les différents cas d'utilisation de 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 pour l'utilisation des jetons par page (peut être limitatif) | Nous recherchons des options à long terme qui nous permettraient d'autoriser les entreprises à utiliser des jetons en toute sécurité sans risquer d'augmenter l'entropie des utilisateurs, par exemple en partitionnant l'accès aux échanges de jetons. |
| Restrictions d'accès | Seules les origines approuvées (et avec un référent validé/non falsifié) doivent pouvoir vérifier la présence d'un jeton et l'utiliser. | Nous étudions les différentes options pour déterminer qui peut voir et utiliser les jetons. |
| Vérifier si l'appareil est compatible | Les dépendances d'exécution JavaScript limitent l'utilisation sur certains appareils. La prise en charge de la technologie TT peut-elle être étendue à d'autres types d'appareils ? | C'est une option que nous pourrions envisager pour de futurs développements. Nous aimerions également recueillir plus de commentaires des développeurs sur ce sujet sur les forums du W3C. Nous avons également un problème ouvert concernant l'utilisation d'un jeton déclenché par un en-tête HTTP. Nous vous invitons à nous faire part de vos commentaires à ce sujet. |
| Cas d'utilisation | Les cas d'utilisation appropriés des Trust Tokens ne sont pas clairs. Manque de clarté sur les utilisations prévues. | Notre objectif est de faciliter l'innovation dans le domaine de la lutte contre la fraude. Nous sommes conscients que chaque entreprise peut utiliser des techniques propriétaires avec des jetons de confiance. C'est pourquoi nous n'avons pas été prescriptifs concernant l'utilisation prévue. Toutefois, nous allons probablement élargir notre documentation pour inclure davantage d'exemples à titre de point de départ pour les partenaires qui envisagent de tester ou d'adopter cette fonctionnalité. |
| Couverture des jetons de confiance | La suppression de cette règle de fonctionnalité "redemption-trust-token" devrait considérablement augmenter la couverture des jetons de confiance. | Nous tiendrons compte de cette information lorsque nous recueillerons les commentaires de l'équipe d'assistance technique et prendrons des décisions concernant les prochaines étapes. |
| Confiance de l'émetteur | Pourquoi devrions-nous faire confiance aux sites Web qui ont émis des jetons de confiance ? | Il n'existe aucune consigne pour devenir émetteur. Tout le monde peut le faire. Les éditeurs ne devraient travailler qu'avec des émetteurs de confiance. De plus, d'autres acteurs légitimes de l'écosystème publicitaire finiront par réduire (ou cesser d'acheter) le trafic associé à des émetteurs suspects ou inconnus. |
| Services intégrés tiers | Les services intégrés tiers peuvent-ils utiliser et/ou demander des jetons de confiance ? | Oui, un service intégré tiers peut émettre et utiliser des jetons de confiance. |
| Écosystème des émetteurs | Les signaux de confiance peuvent être partagés avec d'autres entreprises pour une meilleure utilité. | Les jetons de confiance sont conçus comme des primitives de bas niveau et peuvent être utilisés par les émetteurs/utilisateurs participants pour partager des signaux de confiance/de réputation. |
| Coûts de maintenance | L'implémentation cryptographique sous-jacente aux opérations de jeton de confiance se trouve 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 le protocole Privacy Pass) qui peuvent également être implémentées dans d'autres bibliothèques. Nous recommandons aux développeurs de demander/développer/gérer la prise en charge de ces opérations dans les bibliothèques de leur choix. |
| Coûts de maintenance | Il n'est pas clair pendant combien de temps les versions du protocole seront prises en charge. | Nous étudions la possibilité de développer et de documenter des informations plus spécifiques sur les délais de prise en charge prévus pour les versions de protocole. |
| Limites de l'émetteur | Si vous êtes plus loin dans la chaîne, vous n'aurez peut-être pas l'occasion d'exécuter des Trust Tokens. | À mesure que de plus en plus d'organisations commencent à utiliser des jetons de confiance, nous pourrions observer de plus en plus souvent ces types de dynamiques temporelles. Nous étudions des solutions potentielles. Comme indiqué précédemment, nous recherchons des options à long terme qui nous permettraient d'autoriser les entreprises à utiliser des jetons en toute sécurité sans risquer d'augmenter l'entropie utilisateur, 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 en incubation
| Thème des commentaires
(Classement par prévalence) |
Résumé des questions et des préoccupations | Réponse de Chrome |
| Signaux d'attestation de l'intégrité de l'appareil | Prise en charge générale et forte de la recherche de signaux d'intégrité de l'appareil attestés par les plates-formes et mis à la disposition du Web | Nous continuerons de recueillir des commentaires et de poursuivre la proposition via une conception et une itération publiques. |
| Signaux d'attestation de l'intégrité de l'appareil | Questions sur la quantité d'entropie utilisateur pouvant être transmise via de nouveaux signaux et sur la possibilité que certains cas d'utilisation (par exemple, un utilisateur qui se connecte à sa banque) justifient des signaux d'entropie plus élevés. | Nous privilégions les signaux à forte valeur avec le moins d'entropie utilisateur possible pour préserver la confidentialité des utilisateurs. |
| Signaux d'attestation de l'intégrité de l'appareil | Ce signal limiterait-il l'accès aux appareils plus anciens ou aux plates-formes Open Source/modifiées ? | Tout nouveau signal doit considérer l'accès universel comme un principe clé du développement. Il s'agit de questions importantes à aborder dès le départ, alors que nous continuons l'incubation. |
| Signaux d'attestation de l'intégrité de l'appareil | Nous nous sommes demandés si les nouveaux signaux pourraient amener les entreprises de sécurité et de lutte contre la fraude à s'appuyer trop sur le navigateur et les plates-formes.
|
Tout nouveau signal doit être considéré comme des données supplémentaires et non comme une indication de "confiance" de la part 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 utilisant l'attestation d'appareil comme entrée supplémentaire. Nous espérons que ces nouveaux signaux amélioreront les efforts de détection dans l'ensemble de l'écosystème et rendront la fraude plus difficile à exécuter. |
| Signal d'âge des cookies | Concept intéressant, mais qui nécessite probablement un examen plus approfondi des cas d'utilisation applicables. | En fonction du niveau d'intérêt, Chrome peut poursuivre l'idéation de ce concept et le transformer en vidéo explicative pour recueillir des commentaires sur l'écosystème. |
| Serveurs de confiance pour la lutte contre la fraude | Concept intéressant, mais qui nécessite probablement un examen plus approfondi des cas d'utilisation applicables. | En fonction du niveau d'intérêt, Chrome peut poursuivre l'idéation de ce concept et le transformer en vidéo explicative pour recueillir des commentaires sur l'écosystème. |