Rapport trimestriel pour le 3e 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
| Feedback Theme | Résumé | Réponse Chrome |
| (également indiqué au 2e trimestre)
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). | Mise à jour T3:
Google s'est engagé envers la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se préférant par vous-même son activité, et à tenir compte de son impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, quelle que soit leur taille. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. À mesure que les tests de la Privacy Sandbox progressent, 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. Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous soutenons également la publication par la CMA d'une note sur la conception des tests afin de fournir plus d'informations aux acteurs du marché et de donner des commentaires sur les approches proposées. |
| (également indiqué au 2e trimestre)
Demandes de documentation |
Demandes de ressources supplémentaires expliquant comment gérer les tests, l'analyse et la mise en œuvre | Mise à jour T3:
Nous apprécions que les développeurs aient trouvé les ressources que nous proposons déjà utiles et nous nous engageons à en fournir davantage 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 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. |
| Compatibilité multinavigateur | D'autres fournisseurs de navigateurs adoptent les API Privacy Sandbox. | D'autres fournisseurs de navigateurs, tels qu'Apple, Mozilla et Microsoft, participent activement aux forums publics où sont abordés les principes de confidentialité et les approches basées sur les navigateurs. Nous sommes encouragés par les discussions collaboratives sur des forums tels que la dernière réunion annuelle du TPAC du W3C et les forums en cours du PATCG du W3C où nous constatons des signes de convergence. |
| Différences entre plates-formes | Demandez-lui d'aligner autant que possible les ensembles de fonctionnalités sur le Web et Android afin de réduire les ressources nécessaires à la transition. | Nous nous efforçons d'harmoniser nos approches sur Chrome et Android afin d'éviter toute confusion ou fragmentation dans l'ensemble du secteur. Les différences au niveau de notre approche seront largement dues aux différences techniques nécessaires entre les plates-formes Web et d'applications mobiles, dont les développeurs prendront déjà en compte. |
| Ressources pour tester les API Privacy Sandbox | Difficultés à allouer suffisamment de ressources
ressources pour tester les API Privacy Sandbox compte tenu des difficultés économiques actuelles. |
Google améliore continuellement la documentation et l'assistance à la disposition des testeurs afin de les simplifier et de faciliter leur adoption. Il s'agit notamment des listes de diffusion spécifiques aux API, des horaires d'ouverture et des mises à jour régulières effectuées sur developers.chrome.com. |
| Signal de désactivation de l'API Sandbox | Demande de fournir le signal "L'utilisateur a désactivé les API de bac à sable", que la technologie publicitaire et les sites Web peuvent utiliser. | Par le passé, nous avons constaté que les sites Web réagissent aux choix des utilisateurs (comme "désactiver les cookies tiers") en les invitant à modifier leurs paramètres, parfois en bloquant l'accès à des sites Web, sauf s'ils le font. Un signal de désactivation peut également être utilisé comme signal supplémentaire pour le fingerprinting. À l'heure actuelle, Google n'a pas l'intention de fournir un signal de désactivation |
| (également indiqué au 2e trimestre)
Des chronologies plus claires |
Des calendriers de mise en ligne plus clairs et détaillés | Mise à jour T3:
Comme expliqué dans la section "Modifications apportées en réponse aux commentaires" ci-dessous, Google a modifié le calendrier de la Privacy Sandbox en juillet afin de donner au marché plus de temps pour les tests préliminaires et les commentaires, et plus de temps pour les tests une fois les API Privacy Sandbox complètement lancées avant l'abandon des cookies tiers. |
| (également indiqué au 2e trimestre)
Calendrier d'abandon des cookies tiers |
Demandes visant à éviter un nouveau retard lié à l'abandon des cookies tiers | Mise à jour T3:
En juillet, Chrome a annoncé un nouveau calendrier d'abandon des cookies tiers. Cette mise à jour reflète notre engagement à agir de façon responsable, compte tenu de la complexité des technologies et de leur importance pour l'écosystème. Nous avons tenu compte des commentaires des organismes de réglementation et du secteur avant ce changement, et nous continuons à travailler en étroite collaboration avec toutes les personnes concernées. |
| Cookies propriétaires | Des restrictions concernant les cookies propriétaires sont-elles également proposées ? Si tel est le cas, vous vous posez des questions sur la stabilité à long terme, le risque de modifications imprévisibles du navigateur et le manque d'efforts d'ingénierie à ce stade. | Nous n'avons pris en compte aucune restriction concernant les cookies propriétaires. L'objectif de la Privacy Sandbox est d'abandonner les cookies tiers. |
Diffusez des annonces et des contenus pertinents
Rubriques
| Feedback Theme | Résumé | Réponse Chrome |
| (également indiqué au 2e trimestre)
Utilité pour les différents types de partenaires |
Des inquiétudes ont été soulevées concernant l'utilité des sites en fonction de leur niveau de trafic ou de la spécialisation de leur contenu. | Mise à jour T3:
Pour déterminer l'utilité de l'API, nous effectuerons des tests. Conformément au paragraphe 17.c.ii des Engagements, Google communiquera à la CMA les résultats de ces 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. |
| Confidentialité/Règles | Demande de suppression de l'exigence de filtrage par sujet par appelant. | Sur la base des commentaires de leaders d'opinion, de défenseurs de la confidentialité, d'experts en sécurité, de groupes de défense des droits numériques et d'autres acteurs de l'écosystème, Chrome a choisi cette conception pour ne donner accès aux informations qu'aux personnes qui y avaient accès. Cela s'explique, entre autres, par la limitation des fuites incrémentielles de données entre les côtés, la garantie de la transparence et l'explicabilité, l'adoption d'une approche simple à mettre en œuvre et à décrire, et la limitation du risque de fingerprinting. Les éditeurs et les tiers qui reçoivent des Topics peuvent décider eux-mêmes des informations qu'ils partageront avec les parties sur leur site. Si des tiers partagent ces informations, Chrome les encourage vivement à faire preuve de transparence envers les utilisateurs à ce sujet et à leur proposer des options de contrôle. |
| Sites dans la mauvaise catégorie | Les sites sont associés à une catégorie incorrecte, ce qui peut entraîner un ciblage inexact des annonces. | Les sites sont classés à l'aide d'une liste de remplacements élaborée manuellement, contenant les sites les plus populaires, et d'un modèle de ML sur l'appareil. Chrome continue d'évaluer les options permettant aux sites de contribuer à la classification des thèmes. Toute amélioration de l'utilitaire doit être comparée aux risques liés à la confidentialité et aux abus. Voici quelques exemples de risques:
Le public peut inspecter ces composants à l'aide d'outils disponibles via chrome://topics-internals ou ce colab. Grâce aux tests, nous nous attendons à ce que la classification s'améliore au fil du temps. De plus, nous accueillons les commentaires concernant des exemples de sites qui peuvent être mal catégorisés. |
| Conditions d'accès | Les exigences actuelles de Topics concernant l'entité DOM sur la page en tant que script ou iFrame afin d'y accéder peuvent entraîner des comportements indésirables de la part des joueurs dans l'écosystème publicitaire. | Nous avons fusionné une modification de l'explication GitHub. Nous avons l'intention de prendre en charge les thèmes Topics dans les en-têtes HTTP. |
| Taxonomie des thèmes pas assez précise | Les classifications actuelles des thèmes sont trop larges et n'incluent pas de sujets plus précis, comme les thèmes régionaux. | Les améliorations apportées à la classification constituent un effort continu, et nous nous attendons à ce qu'elle évolue en fonction des tests et des contributions de l'écosystème.
Nous recherchons activement des commentaires sur la classification qui serait la plus utile pour l'écosystème. Lorsque vous envisagez d'augmenter le nombre de thèmes ou d'inclure des sujets plus précis, vous devez prendre en compte 1) les conséquences potentielles sur la confidentialité (par exemple, un plus grand nombre de thèmes peut engendrer un risque de fingerprinting) et 2) la capacité à récupérer les thèmes précédemment observés (par exemple, avec plus de thèmes, il est peu probable qu'une technologie publicitaire ait vu le thème choisi par le passé). Ensuite, Google cherche à optimiser la capacité des appelants à récupérer les thèmes précédemment observés, en respectant les critères de filtrage existants, dans le but de garantir à la fois l'utilité et la confidentialité. |
| Nombre maximal de thèmes | Trois thèmes par site Web ne représentent pas assez d'informations pour que les annonceurs puissent y diffuser des annonces. | Les commentaires de l'écosystème, en particulier les résultats des phases d'évaluation, continueront d'influencer l'évolution de l'API. Notez que l'API Topics doit compléter d'autres signaux, tels que le contexte, afin de trouver une publicité appropriée pour le visiteur. L'annonceur peut donc accéder à d'autres informations que les thèmes. |
| (également indiqué au 2e trimestre)
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. | Mise à jour T3:
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 effacer leurs Topics en supprimant leur historique de navigation, à partir duquel les thèmes sont issus. Ces commandes sont actuellement implémentées dans le navigateur Chrome au niveau de l'appareil. Nous sommes toujours ravis de poursuivre les discussions concernant des commandes utilisateur plus avancées, telles que celles suggérées par les développeurs. Nous devons toutefois nous assurer que les nouveaux éléments sont bien calibrés pour répondre aux préoccupations soulevées et qu'ils n'entraînent pas de modifications fragmentées. |
| Impact sur le SEO | Les éditeurs qui ajustent les noms d'hôte de leur site Web pour mieux refléter Topics peuvent avoir un impact négatif sur le SEO. | Nous conseillons vivement aux sites de ne pas modifier leur nom d'hôte uniquement pour l'usage de Topics. Il est vrai qu'un site peut ainsi influencer les thèmes qui lui sont attribués. Toutefois, les avantages pour les éditeurs ne sont au mieux pas clairs, et cela pourrait nuire à l'intérêt de Topics pour l'ensemble de l'écosystème si des sites tentent de "fausser" le modèle de classification. De plus, les attributions de thèmes ne sont pas fixes. Nous nous attendons à ce que la classification continue d'évoluer au fur et à mesure des tests et des contributions. Dans le cadre de ces tests, nous vous invitons à nous faire part de vos commentaires, y compris à des exemples de sites susceptibles d'être mal catégorisés. |
| Fraude et abus | Offrez à la partie côté achat un moyen de vérifier que le sujet qu'il voit est bien généré par le navigateur. | Nous apprécions votre suggestion de proposer un mécanisme permettant aux acheteurs de technologies publicitaires de vérifier les thèmes transmis par les vendeurs lors des enchères publicitaires programmatiques. Nous encourageons l'écosystème à participer à la discussion active sur cette page. Nous nous concentrons actuellement sur d'autres améliorations prioritaires, mais nous sommes conscients qu'il pourrait s'agir d'un ajout important à l'avenir. |
| Fraude et abus | Permettez l'examen public des parties qui sont des utilisateurs légitimes des données Topics, à l'aide du même type de publication et d'examen publics auxquels ils feraient l'objet d'un ensemble propriétaire. | Nous apprécions votre suggestion et nous convenons que la responsabilité publique est un outil important pour nous aider à atteindre les objectifs de la Privacy Sandbox. Les appels d'API Topics sont par nature publics, car tout le monde peut visiter un site et observer les appels d'un domaine à l'API JavaScript. Ainsi, les individus et les organisations peuvent consulter les activités pertinentes, identifier les sites qui utilisent Topics et savoir comment. Nous pensons qu'il s'agit d'une meilleure approche que d'évaluer la "légitimité" d'un site dans le cadre des fonctionnalités de l'API Topics elle-même. |
| Impact sur les signaux propriétaires | Le signal des thèmes peut s'avérer très utile et, par conséquent, dévaloriser d'autres signaux propriétaires basés sur les centres d'intérêt. | Nous pensons que la publicité ciblée par centres d'intérêt constitue un cas d'utilisation important pour le Web, et Topics est conçu pour y répondre. Comme décrit ci-dessus, d'autres acteurs de l'écosystème ont exprimé leurs inquiétudes quant au fait que Topics ne soit pas suffisamment utile pour apporter de la valeur. Dans tous les cas, les améliorations apportées à la classification constituent un effort continu, et nous nous attendons à ce qu'elle évolue en fonction des tests et des contributions de l'écosystème. |
FLEDGE
| Feedback Theme | Résumé | Réponse Chrome |
| Enchères FLEDGE | Comment les SSP peuvent-elles mettre en forme les données envoyées à Google Ads pour définir une enchère sur une mise aux enchères FLEDGE ? | Les entreprises qui participent aux tests sont encouragées à publier des documents concernant leurs plans de test et à collaborer si nécessaire.
Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous soutenons également la publication par la CMA d'une note sur la conception des tests afin de fournir davantage d'informations aux acteurs du marché qui envisagent de participer aux essais et de donner leur avis sur les approches proposées. L'équipe Ad Manager a publié une documentation destinée aux vendeurs qui souhaitent tester FLEDGE avec des éditeurs qui utilisent Ad Manager comme ad server. Pour ce faire, cliquez ici. Vous trouverez des informations techniques supplémentaires sur cette page. |
| FLEDGE dans des Fenced Frames imbriqués | Les cadres délimités permettent d'effectuer des tests moins restrictifs, mais en restreignent davantage dans un avenir indéfini. Cette chronologie inconnue représente un défi pour l'écosystème. | Les entreprises peuvent tester FLEDGE avec Fenced Frames dès aujourd'hui. Pour faciliter l'intégration, les entreprises peuvent choisir d'implémenter FLEDGE en premier. Après avoir implémenté FLEDGE, ils peuvent tester Fenced Frames avec leur conception FLEDGE. |
| Règlement sur le traitement des données | Quelles sont les règles de traitement des données pour les groupes de centres d'intérêt / FLEDGE ? | Dans la conception de FLEDGE, toutes les données stockées dans des groupes de centres d'intérêt ou concernant les personnes et groupes de centres d'intérêt sont conservées sur l'appareil. Aucune de ces données n'est envoyée à un serveur Google.
Certaines mesures de protection de la confidentialité prévues par Chrome pour FLEDGE impliquent une interaction avec un serveur de k-anonymat géré par Google. Cette interaction est soigneusement conçue pour éviter de partager des informations sur les utilisateurs et pour fonctionner dans un environnement d'exécution sécurisé (TEE) afin de garantir la parité des informations dans l'écosystème publicitaire. \ Google s'est engagé envers la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se faisant des préférences personnelles pour ses propres activités, et à tenir compte de son impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. |
| Règles concernant l'âge | Comment Chrome s'assure-t-il que les audiences créées par FLEDGE respectent les limites d'âge ? | Les éditeurs et les annonceurs sont les mieux placés pour évaluer si les audiences qu'ils créent avec FLEDGE respectent la loi applicable. Pour mieux protéger les utilisateurs, les API Privacy Sandbox ne seront pas actives pour les utilisateurs connectés à Chrome si l'âge associé à leur compte est de moins de 18 ans, même pendant la période de test. Pour les utilisateurs déconnectés, Chrome ne collecte pas les signaux de profil qui permettraient au navigateur de déduire l'âge de l'utilisateur. |
| Services clés-valeurs FLEDGE | Informations plus claires sur ce que le service clé-valeur FLEDGE autorise, par exemple, le nombre de clés et la fréquence à laquelle elles peuvent être mises à jour. | Les entreprises qui utilisent FLEDGE peuvent disposer d'autant de clés que possible dans la RAM. Pour en savoir plus, consultez cette vidéo d'explication.
Nous cherchons une solution plus rapide pour modifier les données, et nous aimerions recevoir des suggestions en fonction de vos besoins. |
| Tests | Difficile de tester FLEDGE avec Google Ads | Consultez la documentation sur l'intégration Google Ads pour découvrir comment participer au mieux et tester la phase d'évaluation. |
| API de services d'enchères et de mise aux enchères | Quelle est la direction que prend Google concernant l'API des services d'enchères et de mise aux enchères ? Sera-t-il prioritaire ou inférieur à celui de FLEDGE sur le navigateur Chrome pour les enchères sur les appareils ? | Nous restons engagés dans la conception actuelle des enchères sur l'appareil FLEDGE. Les services d'enchères et de mise aux enchères ont été proposés pour explorer des solutions possibles pour un sous-ensemble de cas d'utilisation où la puissance de calcul ou la vitesse du réseau de l'appareil peuvent être limitées. |
| Rapports globaux | Demande d'assistance pour les rapports globaux basés sur tous les signaux disponibles pour generateBid. | Nous prévoyons de partager bientôt plus d'informations à ce sujet. |
| Annonces contextuelles | Diffuser des annonces contextuelles avec FLEDGE | Nous avons envisagé cette option. Pour les raisons expliquées dans cette discussion, nous ne recommandons pas à l'heure actuelle d'utiliser FLEDGE pour les annonces contextuelles. |
| Tester dans le monde réel | Conseils pour isoler FLEDGE des cookies tiers pour des tests en conditions réelles. | Nous étudions des moyens de fournir des populations tests.
Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs et nous soutenons la publication par la CMA d'une note sur la conception des tests afin de fournir plus d'informations aux acteurs du marché et de donner des commentaires sur les approches proposées. |
| Tester FLEDGE et l'API Attribution Reporting | Quel est le meilleur moyen d'implémenter l'API Attribution Reporting avec FLEDGE ? Est-il judicieux de séparer FLEDGE de l'attribution ou de les tester ensemble ? | À terme, nous pourrons tester FLEDGE et l'API Attribution Reporting en tant que solution intégrée. Toutefois, nous encourageons les développeurs à tester l'API Attribution Reporting de manière indépendante, puis à FLEDGE une fois l'intégration terminée. |
| Visibilité du prix des enchères | Requête d'obscurcissement du prix des enchères. | Il est possible de définir des points d'arrêt dans "generateBid()" ou "scoreAd()" pour accéder aux valeurs d'enchère dans les outils de développement. L'équipe Chrome a pris en compte le vecteur d'attaque étroit soulevé dans ces commentaires sur FLEDGE. Toutefois, les modèles de sécurité et de confidentialité de Chrome considèrent que les utilisateurs peuvent faire tout ce qu'ils veulent avec leurs informations sur leur appareil. Par conséquent, il n'existe aucun moyen possible de masquer les données d'enchères comme demandé. |
| Demandes de documentation | Documentation et exemples pour les tests dans un écosystème réel. | Nous apprécions que les développeurs aient trouvé les ressources que nous proposons déjà utiles et nous nous engageons à en fournir davantage 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 permanences publiques pour les développeurs externes afin de partager les bonnes pratiques et les démonstrations, ainsi que des sessions de questions-réponses avec les responsables produit et les responsables de l'ingénierie. Nous pourrons ainsi poser des questions en direct. |
| API Private Agrégation | Vous souhaitez en savoir plus sur l'API Private Agrégation ? | Une explication publique est disponible pour vous communiquer les dernières informations que nous sommes actuellement en mesure de partager. D'autres documents vous seront fournis au fur et à mesure du développement de cette API et de la définition des cas d'utilisation. |
| Latence des données | La récupération des données du serveur clé-valeur FLEDGE s'effectue-t-elle en temps réel ? | Comme expliqué dans un problème GitHub ouvert, il est possible que le serveur ne renvoie des données mises à jour pour des requêtes qu'en quelques minutes (et non en heures). Nous souhaitons également recueillir les commentaires des développeurs. |
| Services d'enchères et de mise aux enchères | Les prix des enchères seront-ils masqués pour les utilisateurs si des services d'enchères et de mise aux enchères sont utilisés ? | Dans le cas de l'approche d'enchères et de mise aux enchères côté serveur, l'utilisateur ne voit pas le prix de l'enchère individuelle, car la demande d'enchère est envoyée directement par le service d'enchères des SSP au service d'enchères DSP. Elle n'est donc plus disponible dans le navigateur.
Toutefois, le prix de l'enchère gagnante restera visible dans le navigateur (décrit plus en détail ci-dessus, qui concerne les demandes d'obscurcissement du prix des enchères). |
| Services d'enchères et de mise aux enchères | Comment équilibrer la charge des services d'enchères et de mise aux enchères ? | Nous ne disposons d'aucune information sur l'équilibrage de charge pour le moment, mais cette question est importante du point de vue des performances et de la confidentialité. Nous vous fournirons plus d'informations à l'avenir. |
| Limites de FLEDGE | Demande d'augmentation de la limite de durée joinAdInterestGroup de 30 à 90 jours. | Nous pensons que le délai de conservation des données de 30 jours correspond à celui d'autres API publicitaires de la Privacy Sandbox, comme la limite de 30 jours dans Attribution Reporting et la période de trois semaines dans Topics. Cette période répond à la fois aux besoins des technologies publicitaires et aux attentes des utilisateurs concernant la confidentialité.
Cependant, n'hésitez pas à nous faire part de vos commentaires, car nous continuons à traiter le problème sur cette page. |
| Stockage partagé dans FLEDGE | Est-il possible d'utiliser l'API Shared Storage dans FLEDGE ? | Nous prévoyons de prendre en charge l'API Shared Storage dans FLEDGE à l'avenir et mettons tout en œuvre pour la proposer lors d'une prochaine phase d'évaluation. |
| Contrôle de la fréquence par clics | Est-il possible de limiter la fréquence d'exposition en fonction des clics (et non des gains) dans FLEDGE ? | FLEDGE spécifie qu'un cadre cloisonné peut appeler navigateurator.leaveAdInterestGroup() (sans paramètre) pour quitter le groupe de centres d'intérêt qui a entraîné la diffusion de l'annonce. Cet appel peut être effectué la première fois qu'un clic est reçu pour éviter les enchères futures, sous la forme d'une limitation de la fréquence d'exposition. À l'heure actuelle, cette solution ne fonctionne pas pour la limitation du nombre de clics après plus d'un clic. |
| FLEDGE dans des Fenced Frames imbriqués. | Impossible de signaler les clics via les rapports sur les annonces Fenced Frame s'ils se produisent sur un cadre Fenced Frame imbriqué. | Nous avons publié une proposition pour résoudre ce problème sur cette page. |
| Mesure | Nous avons besoin d'aide pour collecter des données de latence sur les enchérisseurs lors d'une mise aux enchères FLEDGE. | Nous travaillons à la publication d’un document de mesure des performances prochainement. |
| Reporting | Comment les rapports FLEDGE sont-ils gérés ? | Les rapports FLEDGE sur les victoires, les résultats des enchères et les événements (par exemple, les clics) seront disponibles via les API FLEDGE telles que reportResult(). Pour les rapports sur la conversion d'annonce, l'intégration de l'API Attribution Reporting est indépendante de FLEDGE, mais des discussions sont en cours avec l'écosystème sur les approches possibles.
L'API Private Aggregation peut également être utilisée pour générer des rapports sur les résultats des enchères depuis les environnements d'exécution isolés. Cliquez ici pour consulter une explication. |
| Taille du groupe d'intérêt | Les technologies publicitaires peuvent-elles vérifier la taille d'un groupe de centres d'intérêt (c'est-à-dire le nombre d'utilisateurs dans le groupe) ? | L'appartenance à un groupe de centres d'intérêt est stockée par le navigateur et sur l'appareil de l'utilisateur. Elle n'est partagée ni avec le fournisseur du navigateur, ni avec personne.
Toutefois, le propriétaire d'un groupe de centres d'intérêt peut théoriquement suivre chaque appel à navigateurator.joininterestgroup(...). Le suivi de cet appel ne garantit pas la taille exacte d'un guide d'exploration (car les utilisateurs peuvent quitter un groupe à tout moment), mais il lui donne une limite supérieure et une approximation. |
| Performances | Le code Bidding JS/WebAssembly est-il compilé à chaque enchère ? | Le code d'enchères JS/WebAssembly est compilé une fois lors de chaque enchère. |
| Performances | Quelle est la portée de biddingDurationMsec ? | bidDurationMsec inclut la durée du script de compilation. Il n'inclut pas le temps de téléchargement, le temps de compilation Wasm, l'heure du réseau, le temps d'extraction du serveur de valeurs-clés ou tout autre élément antérieur à la compilation JS. |
| Fonctionnalités | Est-il possible de mettre à jour l'élément adComponent afin qu'il soit personnalisé pour l'utilisateur ? | L'élément adComponent peut être mis à jour lorsque des groupes de centres d'intérêt sont mis à jour par l'appelant, soit par l'appel de joinInterestGroup, soit lorsque Chrome appelle la mise à jour quotidienne. Cela permet à l'appelant de mettre à jour adComponent en fonction de la connaissance de l'utilisateur du site actuel ou en fonction de l'information k-anonyme, respectivement.Vous pouvez trouver la proposition d'origine de tortue endormi au niveau du produit ici, qui inclut une analyse de RTB House sur l'impact sur les métriques clés pour le cas d'utilisation des recommandations. |
| Groupe d'intérêt | Le propriétaire d'un groupe de centres d'intérêt peut-il supprimer certains utilisateurs sous certaines conditions ? | L'appartenance à un groupe de centres d'intérêt n'est stockée que dans le navigateur de l'utilisateur et ne peut être supprimée que du côté de l'utilisateur (par exemple, en effaçant les données du site).
Toutefois, il est possible pour un propriétaire de groupe de centres d'intérêt d'appeler navigateurator.leaveAdInterestGroup() (en utilisant une logique conditionnelle) si l'utilisateur revient sur une page sous le contrôle du propriétaire du groupe de centres d'intérêt. |
| Performances | Comment mesurer les performances de la fonction generateBid ? | Vous pouvez mesurer le temps de compilation et d'exécution avec biddingDurationMsec. Vous pouvez mesurer le temps de téléchargement via chrome://net-export. Dans les versions récentes de Chrome, le temps de compilation et d'exécution s'affiche dans l'onglet "Performances des outils de développement". |
| Fréquence des mises à jour des groupes de centres d'intérêt | À quelle fréquence les navigateurs seront-ils mis à jour pour le groupe de centres d'intérêt ? | Chrome tente de mettre à jour les groupes de centres d'intérêt qui n'ont pas été mis à jour au cours des dernières 24 heures lorsque navigateurator.updateAdInterestGroups() est appelé ou lorsqu'ils ont la possibilité de participer à une mise aux enchères. Pour en savoir plus, consultez cette vidéo d'explication. |
| Fournisseurs de services d'agrégation | Quand les autres fournisseurs de services cloud bénéficieront-ils du service d'agrégation ? | Nous n'avons actuellement pas d'informations précises sur les horaires, mais nous vous communiquerons plus d'informations une fois que nous les aurons fait. Pour le moment, seul AWS répond aux exigences de sécurité du service d'agrégation. |
| Calendrier des tests FLEDGE | Combien de temps FLEDGE sera-t-il testé en BYOS ? Sera-t-il suffisant pour passer du modèle BYOS au modèle TEE ? | Pour que l'écosystème dispose de suffisamment de temps pour effectuer des tests, nous ne prévoyons pas d'exiger l'utilisation des TEE avant l'abandon des cookies tiers. Nous informerons les développeurs dans les grandes lignes afin qu'ils puissent commencer les tests et l'adoption avant que cette transition n'ait lieu. Nous n'avons pas d'autres informations à vous communiquer pour le moment, mais nous vous communiquerons plus d'informations à ce sujet. Pour consulter les informations les plus récentes, cliquez ici. |
| Taille maximale des données | Quelle est la taille maximale des données pour Wasm dans la fonction d'enchères ? | Comme indiqué sur cette page, les mises à jour des groupes de centres d'intérêt ne doivent pas entraîner la création d'un groupe de centres d'intérêt supérieur à 50 Ko. Cependant, la limite de taille des données pour Wasm n'est pas encore définie. Nous vous serions donc reconnaissants de nous faire part de vos commentaires à ce sujet. |
| Signaux d'enchères | Existe-t-il une structure de données standardisée pour enchèresSignals ? | Ce point n'est pas encore défini, mais nous aimerions connaître votre avis. |
| Interroger les serveurs de technologie publicitaire | Est-il possible d'interroger les données d'un serveur de technologie publicitaire en temps réel à partir d'un serveur K/V ? | Non, le serveur K/V s'exécute selon un modèle de confiance qui applique l'option "Pas de réseau, d'accès au disque, de minuteurs ni de journalisation" pour éviter toute fuite de données utilisateur. Pour en savoir plus, consultez cette présentation du modèle de confiance. |
| Fréquence de mise à jour des composants adComponents | Il est actuellement impossible de mettre à jour le champ adComponents (actuellement dans le paramètre IG) par l'historique de navigation de l'utilisateur. | La Privacy Sandbox vise à répondre aux besoins de l'écosystème Web sans suivi intersites, ce qui implique d'empêcher l'accès à l'historique de navigation. Nous vous recommandons d'utiliser des alternatives comme Topics. |
| Résultats des enchères | Les technologies publicitaires peuvent-elles connaître les taux de réussite des enchères ? | Le résultat de la mise aux enchères est obtenu en appelant les fonctions reportResult() et reportWin() dans le code d'enchère fourni respectivement par le vendeur et l'acheteur gagnant, de sorte que chacun puisse consigner et créer des rapports sur le résultat de l'enchère. |
| (également indiqué au 2e trimestre)
Compatibilité avec le ciblage par groupes de centres d'intérêt à exclure |
API prenant en charge le ciblage de groupes de centres d'intérêt à exclure: diffusion des annonces uniquement si un utilisateur n'appartient pas à un groupe de centres d'intérêt. | Mise à jour T3:
Nous vous avons transmis une nouvelle proposition et souhaiterions recueillir vos commentaires. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Feedback Theme | Résumé | Réponse Chrome |
| Conditions requises pour la prolongation de l'expérience | Suppression des restrictions Permission-Policy pendant / pour la P.É. uniquement. | Veuillez consulter les modifications annoncées concernant l'élément Permissions-Policy lors des tests. La préoccupation sous-jacente des partenaires dont il est question par ce changement est de permettre aux DSP de tester l'API sur un plus grand nombre d'iFrames multi-origines. À l'origine, les DSP devaient se coordonner avec les éditeurs/SSP pour s'assurer que les bonnes règles d'autorisation étaient définies afin de tester l'API dans des iFrames multi-origines. Toutefois, cette modification permet aux DSP d'appeler l'API par défaut et les SSP/éditeurs peuvent désactiver l'API si nécessaire pendant la phase d'évaluation. |
| Bruit | Commentaires indiquant que le niveau de bruit est trop élevé et qu'il a une incidence sur l'utilité du rapport. | Vos commentaires concernant le bruit sont les bienvenus. Ils nous permettront de déterminer comment définir certains paramètres liés au bruit. Nous prévoyons également de publier davantage de ressources, d'outils et d'autres documents pour aider les testeurs dans ce domaine. |
| Conversions multidomaines | Comment effectuer le suivi des conversions multidomaines (par exemple, si elles ont au moins deux destinations ?) | Nous discutons actuellement de cette question et sollicitons les commentaires de nos utilisateurs. |
| Conditions de débogage | Demander aux développeurs de vérifier le budget restant pour la confidentialité lors du déploiement ou des tests du rapport récapitulatif ? | Pour en savoir plus sur cette demande de fonctionnalité, cliquez ici. |
| Règles d'utilisation de l'API | Commentaires suggérant des règles concernant les utilisateurs autorisés à utiliser une API donnée en fonction de restrictions liées, par exemple, au fingerprinting | Cette idée est très intéressante, et nous serions ravis de collaborer davantage avec d'autres fournisseurs de navigateurs ainsi qu'avec l'écosystème Web dans son ensemble. |
| Paramètre d'expiration dans le rapport sur les conversions | Demandez l'application du filtre ou de l'expiration du rapport pour une période inférieure à 24 heures. | Les délais d'expiration au niveau de l'heure constituent une source de préoccupation pour la confidentialité, car ils permettent à la technologie publicitaire de savoir exactement à quelle heure un utilisateur consulte le site de l'annonceur. L'expiration au niveau du jour permettra à la technologie publicitaire de filtrer les impressions non valides sans déterminer à quelle heure l'utilisateur a consulté le site. |
| Expiration du jeton OT | Demande d'extension de la validité des jetons OT existants afin de réduire les coûts opérationnels. | Nous sommes conscients que les jetons doivent être renouvelés, et nous nous efforçons de faciliter la tâche des développeurs et de fournir des avis supplémentaires. |
| Assistance régionale | Le service d'agrégation n'est actuellement pas compatible avec toutes les régions. | Il s'agit d'une limitation actuelle pour la version bêta. Nous prévoyons de prendre en charge d'autres régions à mesure que les tests progressent, mais nous n'avons pas encore fixé de calendrier précis. |
| Délai de création de rapports au niveau des événements | Le délai de 2 à 30 jours dans la création de rapports au niveau des événements peut s'avérer trop long pour certains cas d'utilisation. | Nous avons partagé une proposition sur cette page pour permettre aux technologies publicitaires de contrôler à quel moment les rapports au niveau des événements sont envoyés via une date d'expiration. La valeur par défaut est de 30 jours, mais vous pouvez définir une durée plus courte. |
| (également indiqué au 2e trimestre)
Attribution multitouch |
Autorisez l'attribution multitouch, telle que multi-appareil ou multi-applications. | Mise à jour T3:
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. |
| Chronologie d'intégration de FLEDGE et Attribution Reporting | Quel est le calendrier pour l'intégration de FLEDGE et de l'API Attribution Reporting ? | Nous n'avons aucune mise à jour à vous communiquer pour le moment, mais nous vous fournirons plus d'informations lorsque nous pourrons nous engager à respecter un calendrier précis. |
| Plusieurs types de déclencheurs | Demande de plus de flexibilité pour l'enregistrement des déclencheurs. | Nous avons proposé un système de déduplication pour l'API agrégée qui donnera aux technologies publicitaires plus de flexibilité pour contrôler les rapports au niveau des événements et les rapports agrégables. |
| Mesure | Demande de réception de données de mesure permettant de savoir si l'inventaire est performant. | Nous apprécions vos commentaires et souhaitons clarifier les cas d'utilisation de cette demande. |
| Expiration de la conversion | Requête pour prendre en charge l'expiration des conversions sur la balise du déclencheur au lieu de la balise source uniquement. | Nous apprécions vos commentaires et souhaitons clarifier les cas d'utilisation de cette demande. |
| Rapports groupés | Demande de mesures supplémentaires dans les rapports groupés. | Vos commentaires nous sont très utiles pour continuer à réfléchir à leur impact sur le service d'agrégation. Nous souhaitons en savoir plus sur l'approche adoptée par les technologies publicitaires concernant le traitement par lot des rapports et sur la fréquence attendue. Nous aimerions également connaître votre avis sur l'évolution de la stratégie de traitement par lot tout au long de l'année. |
| Epsilon | Quand la valeur d'epsilon sera-t-elle déterminée ? | Nous collaborons activement avec les testeurs de l'écosystème pour finaliser la valeur epsilon et son implémentation dans GA. Cette valeur sera visible publiquement, ainsi que les échanges qui ont conduit à sa décision. Si vous avez des commentaires, veuillez les publier sur cette page. |
Limiter le suivi dissimulé
User-Agent Reduction
| Feedback Theme | Résumé | Réponse Chrome |
| Dépendances de déploiement | Gérer les dépendances de déploiement de l'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. Pour voir la mise à jour, cliquez ici. |
| Tests | Demande d'extension de la phase d'évaluation de la réduction user-agent à partir de Meta. | Nous avons prolongé la phase d'évaluation et obtenu l'autorisation de supprimer les limites de trafic afin de prendre en charge des sites plus importants. Les limites de trafic souples s'appliquent à tous les sites, qu'ils soient petits ou grands. |
Hints client user-agent
| Feedback Theme | Résumé | Réponse Chrome |
| (également indiqué au 2e trimestre)
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. | Mise à jour T3:
Nous avons reçu des commentaires positifs de la part d'entreprises signalant qu'elles n'ont constaté aucun effet négatif sur leurs pipelines de lutte contre la fraude (consultez les résultats ici et ici). L'équipe continue d'enquêter sur ces problèmes potentiels avec les parties prenantes de la lutte contre la fraude et de la mesure. |
| Règles relatives aux autorisations | La règle Permission-Policy est-elle mise en cache ? | Permission-Policy n'est pas mis en cache comme expliqué dans ce problème GitHub. |
Gnatcatcher (en cours)
| Feedback Theme | Résumé | Réponse Chrome |
| Cas d'utilisation de la géolocalisation | Gnatcatcher peut empêcher les cas d'utilisation légitimes de la géolocalisation de fonctionner à l'avenir, tels que la personnalisation de contenu basée sur la géolocalisation. | Nous collaborons avec d'autres parties prenantes pour nous assurer que Chrome continue de prendre en charge les cas d'utilisation légitimes des adresses IP. |
Renforcez les limites de confidentialité intersites
Ensembles internes
| Feedback Theme | Résumé | Réponse Chrome |
| Règle | Inquiétudes concernant le fait que le FPS ne soit pas conforme aux dispositions des engagements de la CMA concernant la "Législation applicable sur la protection des données ", au motif que le RGPD n'impose pas de limite au nombre de sites dans un ensemble, alors que le FPS envisage une limite de trois. | Google s'est engagé envers la CMA à concevoir et implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se préférant par son propre activité, et à tenir compte de l'impact sur la concurrence dans la publicité numérique, les éditeurs et les annonceurs, ainsi que de l'impact sur les résultats en termes de confidentialité et du respect des principes de protection des données tels qu'ils sont définis dans la Législation applicable sur la protection des données. L'inquiétude exprimée ne révèle aucune incompatibilité avec le RGPD. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. Vous trouverez plus d'informations dans la section "Modifications apportées en réponse à des commentaires" ci-dessous. |
| Documentation | Demandez des exemples supplémentaires et mettez à jour les explications existantes. | Les exemples figurant dans nos explications sont en cours d'examen. Vous pourrez les clarifier ou les supprimer si nécessaire. |
| Partage des préférences | Proposition de définir des préférences pour les ensembles identiques. | Vos commentaires sont les bienvenus, et nous sommes en train de discuter activement de cette idée sur cette page. |
| Mesures d'application | Les processus d'application transparents présentent un risque d'abus de la part d'acteurs malintentionnés. | Nous apprécions vos commentaires et nous collaborons activement avec les parties prenantes sur GitHub (considérant les points soulevés dans ce problème et en cherchant à intégrer les suggestions soulevées dans ce problème) et sur d'autres forums pour évaluer ce risque et identifier des solutions d'atténuation potentielles. |
| Propriété commune | Proposition de déclaration de propriété commune lisible par un ordinateur. | Vos commentaires sur notre proposition sont les bienvenus. |
| Propriété des sous-domaines | Des sous-domaines distincts associés à différents responsables du traitement des données, à des règles de confidentialité différentes ou gérés par différentes entités doivent-ils faire partie du même ensemble interne ? | Suite aux commentaires que nous avons reçus, nous prévoyons de supprimer le cas d'utilisation courant des eTLD. |
| Atténuation des abus | Demandez plus d'informations sur les mesures d'atténuation des abus. | La gestion du processus est en cours d'examen, et nous vous communiquerons plus d'informations dans les mois à venir. |
| Vecteur d'attaque potentiel | Un ensemble associé trompeur pour des pages faciles à trouver peut être utilisé pour générer du trafic vers d'autres pages présentées, de façon trompeuse, comme étant indépendantes. | Nous recueillons activement des commentaires du public et recherchons des solutions pour résoudre ce problème. |
| Définir la validation | Valider l'ensemble à l'aide des règles communes consenties. | Différents membres de la communauté des normes Web et de l'écosystème dans son ensemble ont indiqué que cela n'était pas possible. |
| Limite par domaine | Demande d'augmentation du nombre de domaines associés. | Nous menons actuellement des discussions sur la limite de domaines dans le lecteur d'empreinte digitale, et nous aimerions recevoir plus de commentaires de la communauté sur le nombre de domaines associés dont elle a besoin pour ses cas d'utilisation. |
| Interaction du service sous-ensemble | Problème lié au service et à l'interaction associée avec le sous-ensemble. | Nous apprécions vos commentaires et nous nous efforçons de les rendre plus explicites dans les futures spécifications. |
| (également indiqué au 2e trimestre)
Renforcer la confidentialité |
Un trop grand nombre de sites du même ensemble peut entraîner des résultats similaires à ceux des cookies tiers. | Mise à jour T3:
La dernière proposition suggère une limite de trois domaines pour le sous-ensemble "associé" (qui n'inclut pas les ccTLD et les domaines de service). Chrome collabore activement avec l'écosystème pour déterminer si cette limite est appropriée. |
| (également indiqué au 2e trimestre)
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. | Mise à jour T3:
Il n'est plus obligatoire de faire partie d'un même ensemble de règles de confidentialité. |
API Fenced Frames
| Feedback Theme | Résumé | Réponse Chrome |
| Pourquoi un nouvel élément plutôt que des attributs dans les cadres iFrame ? | Question concernant le cadre Frenced Frame de la proposition au lieu des propositions iFrame existantes. | N'hésitez pas à nous faire part de vos commentaires et à nous faire part de vos idées pour faire converger l'état actuel des choses, comme nous l'avons vu dans cet article. |
| Observateur d'intersection dans des cadres cloisonnés | Questions concernant la visibilité des informations à l'intérieur d'un cadre cloisonné. | Cette discussion fait l'objet d'une discussion active et fait l'objet de commentaires dans ce document et sur GitHub. Nous invitons les partenaires à partager des cas d'utilisation avec nous afin de mieux comprendre comment leur proposer une assistance. |
| Compatibilité avec l'inventaire vidéo et natif | Fenced Frames est-il compatible avec l'inventaire vidéo et natif ? | En termes de capacités de lecture des vidéos, les cadres cloisonnés ne diffèrent pas des cadres iFrame. C'est pourquoi ils ne sont pas explicitement mentionnés dans la documentation publique. Si nous détectons des problèmes au niveau des annonces vidéo, n'hésitez pas à nous envoyer vos commentaires afin que nous puissions vous aider. |
| Packs Web | La diffusion / l'affichage d'annonces par les bundles Web deviendra-t-il obligatoire à l'avenir avec Fenced Frame et FLEDGE ? | L'objectif à long terme est d'accepter les Web bundles pour afficher le contenu des annonces dans un frame cloisonné. Cependant, l'implémentation actuelle de FLEDGE n'est pas compatible avec cette fonctionnalité et nécessite d'afficher une ressource HTML récupérée à partir de renduUrl. |
| Les dimensions de l'élément | Demande d'ajout d'une macro pour la hauteur et la largeur de l'espace publicitaire dans le champ "Render_url" afin que nous puissions répondre avec une création de taille appropriée | Pour en savoir plus, cliquez ici. |
API Shared Storage
| Feedback Theme | Résumé | Réponse Chrome |
| Intégration de FLEDGE | Comment le stockage partagé et FLEDGE seront-ils intégrés ? | Même si nous n'avons pas encore pris cette décision, nous souhaitons étudier cette idée si nous pouvons garantir la protection de la confidentialité. Nous encourageons les parties intéressées à envoyer des suggestions pour les cas d'utilisation potentiels que cette proposition pourrait prendre en charge dans le dépôt GitHub du stockage partagé ou dans le dépôt GitHub FLEDGE. . |
| Conservation des données | Supprimer le stockage partagé réduit l'utilité. Avez-vous envisagé l'extension de la durée de conservation ou la possibilité de supprimer des clé-valeurs individuelles ? | Nous cherchons constamment à équilibrer la confidentialité des utilisateurs et les compromis utilitaires. Nous sommes prêts à recevoir des commentaires sur les ajustements et encourageons les partenaires à envoyer d'autres commentaires et d'autres informations lorsqu'ils testent l'espace de stockage partagé. |
| Signal négatif | Signal négatif de Mozilla concernant la proposition de stockage partagé. | Nous remercions Mozilla d'avoir examiné attentivement notre proposition. Nous prévoyons de répondre à leurs commentaires dans un avenir proche. |
CHIPS
| Feedback Theme | Résumé | Réponse Chrome |
| Exigences de partitionnement | Ajout d'une exigence de comportement explicite pour l'attribut "Partitionné" sur les cookies propriétaires. | Nous en avons parlé lors d'un appel concernant la PrivacyCG et avons envoyé des remarques au sujet du problème GitHub . Nous continuons de travailler avec les navigateurs, les développeurs et les membres de la communauté des responsables de la confidentialité afin de nous aligner sur un comportement et de le spécifier. |
| Intégrations authentifiées | Les CHIPS peuvent affecter le flux de connexion SSO actuel en raison d'un partitionnement différent affectant les intégrations authentifiées. | Nous sommes au courant du cas d'utilisation des intégrations authentifiées et nous recherchons des solutions. |
| Limite de partition des cookies | Crainte que la limite actuelle de 10 cookies ne suffise pas pour certains cas d'utilisation. | Nous allons passer d'une limite du nombre de cookies à une limite de mémoire de 12 Ko. Cela nous permet de répondre aux préoccupations concernant la limite des cookies, tout en veillant à ce que les performances et l'utilisation de la mémoire du navigateur ne soient pas affectées. |
| Calendrier de la phase d'évaluation | Étendre la OT après la suppression de l'exigence de limite du nom d'hôte. | Nous avons repoussé la date limite de la phase d'évaluation suite aux commentaires de l'écosystème. |
| Limites des tests dans Chrome | Possibilité de tester CHIPS dans Firefox en raison des limitations actuelles de Chrome. | L'implémentation de Firefox est approximativement différente, Chrome a une limite de cookies inférieure et CHIPS est un mécanisme d'activation, mais Firefox est partitionné par défaut. |
| (également indiqué au 2e trimestre)
Intégrations authentifiées |
L'état de connexion est-il préservé avec les CHIPS ? | Mise à jour T3:
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. |
FedCM
| Feedback Theme | Résumé | Réponse Chrome |
| (également indiqué au 2e trimestre)
Vecteurs d'attaque potentiels |
Vecteurs d'attaque potentiels via la décoration des liens et les attaques temporelles. | Mise à jour T3:
Nous avons collaboré avec Mozilla pour trouver le moyen de traiter le problème lié à une attaque ponctuelle. Pour en savoir plus, cliquez ici. Nous sommes en train de prototyper ce changement d'architecture et nous prévoyons d'effectuer des tests au cours des prochains trimestres. |
| Fournisseurs d'identité | Sélecteur de compte: fournisseur d'identité unique. Requête d'autorisation de plusieurs fournisseurs d'identité. | Nous avons collaboré avec les fournisseurs de navigateurs et le FedID CG sur la manière d'autoriser plusieurs fournisseurs d'identité, et nous sommes parvenus à une formulation qui semble intéressante. La description de la proposition est disponible sur cette page. Nous prévoyons de développer des prototypes et de réaliser des tests au cours des prochains trimestres. |
| Problèmes connus concernant la fédération | Requête permettant d'énumérer les cas où la fédération peut rencontrer des problèmes avec l'abandon des cookies tiers. | Le FedID CG comporte une tâche qui consiste à énumérer les différents facteurs de défaillance de la fédération ici et ici. L'équipe est également en train d'élaborer une matrice de décision pour mapper les défaillances aux API Web Platform sur cette page. |
| Paramètre "nounce" | Le paramètre Nounce peut-il affecter le flux de connexion ? | Même si cela peut être considéré comme du suivi intersites, nous continuons à recueillir des données et à analyser la manière de traiter ces cas. |
| Autorisation de l'utilisateur | Associer différents tiers de confiance (RP) et le consentement de l'utilisateur pour chaque origine | Cette spécification ne peut pas contrôler la façon dont les origines au sein d'un même domaine partagent les cookies. La spécification autorise l'identifiant "idtoken" depuis l'origine du fournisseur d'identité jusqu'à l'origine du tiers assujetti à des restrictions, mais il appartient au tiers assujetti à des restrictions de choisir si l'état de connexion de l'utilisateur doit être stocké dans un cookie verrouillé sur cette origine unique ou dans un cookie partagé avec des origines appartenant au même domaine. |
| Compte IdP
portabilité |
Option permettant aux utilisateurs de migrer les IdP s'ils le souhaitent lors d'un transfert entre deux IdP. | Il semble que l'utilisateur doive effectuer cette opération directement sur la page d'inscription du nouvel IdP de son choix, et non via l'API FedCM. |
| Suppression de comptes | Révocation du IdP prenant en compte la suppression du compte auprès du IdP. | Cette demande de fonctionnalité est ouverte et en cours d'examen. |
| Revendication d'UI | Affirmations concernant les aspects de l'interface propres aux navigateurs | Pour résoudre ce problème, consultez la section Demande d'extraction. |
| Vérification du parrainage de l'IdP | Vérifications du fournisseur d'identité pour l'URL de provenance du tiers assujetti à des restrictions. | Ajout à la spécification d'une vérification obligatoire de l'URL de provenance de l'IdP. Consultez la section Demande d'extraction. |
| Processus de connexion | Demande de personnalisation des flux de connexion en fonction des préférences du tiers assujetti à des restrictions. | Nous sommes ravis de cette idée et nous en discutons activement. |
Lutter contre le spam et la fraude
API Trust Tokens
| Feedback Theme | Résumé | Réponse Chrome |
| Fraude et abus | Qu'est-ce qui permet de s'assurer qu'un bot n'a pas dupé un émetteur en lui donnant un jeton, qu'un bot n'a pas pris le contrôle d'un jeton émis à un utilisateur réel et qu'il empêche les bots d'émettre des jetons malveillants ? | Même si les bots peuvent obtenir des jetons auprès d'un émetteur, nous encourageons les émetteurs à limiter la fréquence à laquelle ils émettent des jetons et à appliquer des méthodes robustes pour émettre des jetons et mettre à jour leur logique d'émission lorsque des acteurs malveillants tentent de les contourner. Les émetteurs qui ne disposent pas d'une logique assez robuste pour émettre des jetons risquent de devenir moins fiables dans l'écosystème, car les sites Web donnent la priorité aux émetteurs plus robustes. |
| Fraude et abus | Un utilisateur de jetons de confiance peut-il spécifier qu'il n'acceptera que les jetons de confiance provenant d'entités spécifiques ? | Oui, c'est possible. La section Utilisation de jetons de confiance du guide d'explication décrit son fonctionnement. |
| Fraude et abus | Existe-t-il un moyen pour un émetteur de jetons de confiance de définir une liste d'utilisateurs utilisant des jetons et de n'autoriser personne à le faire ? | Pas pour le moment, mais notre équipe examine ce cas d'utilisation. |
| Chronologie | Quand l'API Trust Token sera-t-elle disponible pour tous ? | Dès que nous pourrons nous engager sur un calendrier, nous vous communiquerons davantage d'informations à ce sujet. |
| (également indiqué au 2e trimestre)
Coûts de maintenance |
Nous ne savons pas exactement combien de temps les versions du protocole seront compatibles. | Mise à jour T3:
Un support supplémentaire est ajouté aux API pour assurer la prise en charge de plusieurs versions simultanées afin de permettre une transition en douceur entre les versions, bien que les délais de prise en charge / d'abandon restent en cours de développement. |