Rapport trimestriel du 1er trimestre 2023 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 | Résumé | Réponse de Chrome |
|---|---|---|
| Tests et essais | Pertinence des tests pour éclairer l'évaluation de la CMA si les API Privacy Sandbox ne sont pas finalisées au début du test | Le développement des API Privacy Sandbox progresse rapidement.
Elles sont déjà disponibles en phase d'évaluation dans Origin pour les tests et seront disponibles pour 100% du trafic cet été. De plus, nous avons clarifié les délais pour certaines fonctionnalités (telles que les rapports au niveau des événements FLEDGE, le rendu FLEDGE avec des iFrame) qui ne seront pas concernées avant 2026. Nous encourageons l'écosystème à tester les API et à fournir des commentaires à la CMA en fonction de ce sur quoi les testeurs s'attendent à s'appuyer une fois que les cookies tiers seront abandonnés. Cela peut contribuer à leur évaluation de l'impact probable de l'abandon des cookies tiers. |
| Contrôle utilisateur | Consignes claires à l'écosystème sur les conséquences des API Privacy Sandbox sur les commandes utilisateur | Nous ne sommes pas en mesure de vous fournir des conseils juridiques sur les contrôles utilisateur que l'écosystème peut utiliser. En parallèle, Chrome teste l'affichage des commandes utilisateur de la Privacy Sandbox (appelées "Confidentialité des annonces améliorée") auprès d'un très faible pourcentage d'utilisateurs, dans le cadre de nos efforts continus pour améliorer les technologies de la Privacy Sandbox. Les mises à jour incluent un langage et des mises en page plus clairs et plus utiles. Une fois que Chrome a évalué ces améliorations et décidé de les étendre à une population plus large, il peut partager plus d'informations avec l'écosystème. |
| Fuite de données | Risque de fuite de données first party vers Google et d'autres parties en cas de piratage du navigateur | Notre explication sur FLEDGE montre clairement que les données d'une technologie publicitaire ne sont partagées qu'avec cette même technologie publicitaire (avec ses worklets ou ses serveurs de confiance) ou lorsqu'elles sont explicitement partagées par cette technologie publicitaire (par exemple, lorsqu'un acheteur montre à un vendeur l'URL de l'annonce qu'il souhaite diffuser). La seule exception est que la vérification de l'anonymat k doit être effectuée par un serveur centralisé mondial, un domaine auquel nous continuons de consacrer des ressources importantes. Consultez l'explication de l'anonymat k pour en savoir plus sur notre approche de la confidentialité. En outre, nous sommes prêts à vous fournir plus d'informations sur le fonctionnement des protections de technologie publicitaire utilisées dans la conception du serveur d'anonymat k. |
| Forum de discussion supplémentaire | Demande d'un forum supplémentaire au W3C pour que les acteurs non techniques de l'écosystème puissent partager leurs commentaires | Le formulaire de commentaires sur la Privacy Sandbox est adapté aux commentaires généraux et spécifiques, techniques et non techniques. Le groupe d'activités du W3C pour l'amélioration de la publicité en ligne est un forum de discussion via des appels hebdomadaires et un dépôt GitHub. La page Feedback (Commentaires) de la Privacy Sandbox explique d'autres mécanismes permettant de nous faire part de vos commentaires et de participer à des discussions. Chrome continue également d'organiser des événements tels que des permanences publiques pour faciliter les questions et le partage de contenus. De plus, Chrome a organisé ou participé à plus d'une douzaine d'événements du secteur au cours du dernier trimestre. |
| Clarification sur le calendrier | Clarification sur la date exacte de disponibilité générale au 3e trimestre 2023 | Selon le calendrier publié sur PrivacySandbox.com, le déploiement de la disponibilité générale devrait commencer avec la sortie de la version 115 de Chrome. |
| reCAPTCHA | Impact des API Sandbox sur le cas d'utilisation de la détection de spam de reCATPCHA | Nous recevons régulièrement des commentaires de reCAPTCHA pour nous assurer que les propositions de la Privacy Sandbox n'ont pas d'impact significatif sur la sécurité du Web ni sur la fraude. Il élabore son propre plan pour se préparer et s'adapter à l'abandon des cookies tiers. Il est donc le mieux placé pour répondre à cette question. |
| Extensions Chrome | Les technologies de la Privacy Sandbox, telles que les mesures de lutte contre le suivi dissimulé (ACT), s'appliqueront-elles aux extensions Chrome ? | Nous n'avons pas annoncé si la loi ACT peut s'appliquer aux extensions Chrome. Toutefois, si une technologie recueille des informations sur un utilisateur de manière clandestine, cela ne correspond pas à nos principes de confidentialité. |
Afficher des annonces et des contenus pertinents
Thèmes
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Revue de conception TAG | Le TAG a publié une première analyse de la conception de Topics. | Nous restons engagés envers Topics et avons partagé des informations à ce sujet sur la page des dernières informations et dans cet article. Nous avons répondu point par point à l'examen de la TAG et partagé notre vision d'ensemble ici. L'API Topics restera dans la collection d'API que l'écosystème publicitaire devrait tester en 2023. Nous espérons que les commentaires des tests et l'expérience des implémentateurs seront des contributions précieuses pour les futurs efforts visant à développer des normes inter-navigateurs dans ce domaine. Nous avons hâte de continuer à collaborer avec l'écosystème pour faciliter une transition possible où l'API Topics pourrait être une norme convenue avec une compatibilité multinavigateur. |
| Approche concernant les sujets | Prise en charge de l'approche ouverte de Chrome pour le développement de l'API Topics | Nous vous remercions de votre avis et nous avons hâte de continuer à collaborer avec le groupe du secteur pour développer une API Topics qui apporte de la valeur à l'écosystème dans son ensemble. |
| (Signalé également au troisième trimestre 2022) La taxonomie des thèmes n'est pas assez détaillée. |
La taxonomie des thèmes généraux n'inclut pas les thèmes plus précis, y compris ceux spécifiques à une région. | Mise à jour du 1er trimestre: Nous continuons d'améliorer la taxonomie. Au cours du 2e trimestre, nous annoncerons une nouvelle taxonomie pour l'API Topics. Pour créer cette nouvelle taxonomie, nous avons travaillé en étroite collaboration avec des entreprises de l'ensemble de l'écosystème. Nous recherchons activement des commentaires sur la taxonomie la plus utile pour l'écosystème. Pour déterminer si vous devez augmenter le nombre de thèmes ou en inclure des plus précis, vous devez prendre en compte plusieurs éléments, dont : 1) les conséquences potentielles sur la confidentialité (un plus grand nombre de thèmes peut entraîner un risque d'empreinte digitale) et 2) la possibilité de récupérer des thèmes précédemment observés (par exemple, avec un plus grand nombre de thèmes, il est moins probable qu'une technologie publicitaire ait vu le thème choisi par le passé). |
| (également signalé au 4e trimestre 2022) Impact sur les signaux first party |
Le signal Topics peut être très utile et, par conséquent, dévaloriser les autres signaux first party basés sur les centres d'intérêt. | Nous pensons que la publicité ciblée par centres d'intérêt est un cas d'utilisation important pour le Web, et Topics est conçu pour prendre en charge ce cas d'utilisation. Nous comprenons que certains grands éditeurs craignent que Topics ait un impact négatif sur leurs stratégies de données first party. Nous avons hâte de tester l'écosystème, ce qui nous permettra d'obtenir des insights sur l'impact de Topics sur les éditeurs. |
| Cas d'utilisation des thèmes non liés aux annonces | Utilisation de Topics à d'autres fins que l'affichage de publicités ciblées par centres d'intérêt | Topics est conçu pour répondre au cas d'utilisation de la publicité ciblée par centres d'intérêt, qui, selon nous, est un cas d'utilisation essentiel pour le Web libre et ouvert. Nous recueillons actuellement des commentaires sur d'autres cas d'utilisation et les évaluons. |
| État d'activation par défaut | Impacts de la législation régionale sur le consentement par défaut pour Topics | Il n'est pas de notre ressort de commenter des avis juridiques. |
| (également signalé au 3e trimestre 2022) Sites mal catégorisés |
Cible des annonces lorsque des thèmes sont mal catégorisés pour un site donné | Informations du premier trimestre: Au cours du deuxième trimestre, nous annoncerons un classificateur mis à jour pour l'API Topics. Nous avons hâte de collaborer avec l'écosystème à ce sujet. En réponse aux commentaires actuels, les sites sont classés à l'aide d'une liste de forçage créée par des humains, 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'utilité doit être mise en balance avec les risques liés à la confidentialité et aux utilisations abusives. Par exemple, voici quelques-uns des risques: les sites qui utilisent l'auto-étiquetage pour encoder différentes significations (potentiellement sensibles) dans des sujets ; les sites qui dénigrent leurs sujets à des fins lucratives ; les sites qui attaquent des sujets afin de les rendre moins utiles pour les autres (par exemple, en envoyant du spam dans les sujets de l'utilisateur). Le public peut inspecter ces composants, avec des 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. Nous sommes à l'écoute de vos commentaires sur des exemples de sites qui pourraient être mal catégorisés. |
| Classificateur de sujets | Demande de renvoyer des informations supplémentaires indiquant les raisons pour lesquelles "Aucun sujet" est renvoyé à l'appelant à des fins de débogage | Nous comprenons et apprécions que les outils de débogage soient utiles aux développeurs lorsqu'ils s'efforcent d'intégrer l'API Topics à leurs systèmes. Toutefois, en divulguant des informations supplémentaires (par exemple, la raison pour laquelle aucun thème n'a été renvoyé), nous pouvons partager par inadvertance des informations qui permettent aux parties de découvrir des détails supplémentaires (par exemple, si un utilisateur est en mode navigation privée, s'il a désactivé l'API, etc.) au-delà de ce qui est prévu, ce qui nuit à la confidentialité des utilisateurs. Bien que nous ne prévoyons pas de fournir d'outils de débogage supplémentaires pour le moment, nous sommes à l'écoute de vos commentaires sur les outils qui vous seraient utiles. |
| Récupération des informations privées (PIR) | Demande d'adoption de la récupération des informations privées pour l'API Topics | Nous avons déjà étudié l'utilisation de la technologie PIR et partagé les compromis ici. |
| Flux d'enchères | Les thèmes seront-ils représentés distinctement des audiences définies par le vendeur dans le flux d'enchères ? | L'API Topics est une proposition de la Privacy Sandbox développée par Chrome. Elle est distincte de la proposition Audiences définies par le vendeur de l'IAB Tech Lab. Nous nous attendons à ce que les deux soient représentés distinctement dans le flux d'enchères. Découvrez comment les thèmes seront représentés dans les demandes d'enchères OpenRTB. |
API Protected Audience (anciennement FLEDGE)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Disponibilité des fonctionnalités FLEDGE | Clarification des délais de test et d'implémentation des fonctionnalités FLEDGE telles que l'application de Fenced Frames, l'anonymat k, etc. | Nous avons partagé l'état de diverses fonctionnalités FLEDGE à portée limitée et la date à laquelle elles seront compatibles. N'hésitez pas à nous faire part de vos commentaires sur cette annonce pour nous aider à développer FLEDGE. |
| Restrictions de rendu des produits | Demande d'assouplissement des restrictions concernant les annonces composées de plusieurs éléments pour les cadres délimités FLEDGE | Comme nous l'avons annoncé en février, l'utilisation des cadres délimités restera facultative jusqu'en 2026 au moins, et le comportement des iframes sera compatible avec les urn-iframes. Nous sommes à votre disposition pour discuter de ce sujet. |
| Problèmes d'évolutivité | Performances de FLEDGE à mesure que l'utilisation augmente | Nous suivons activement les commentaires et nous étudions le contexte pour pouvoir proposer des solutions concrètes. La première étape a consisté à séparer les commentaires en deux catégories:
|
| (également signalé au 3e trimestre 2022) Visibilité de la logique d'enchères |
Inquiétude concernant l'exposition de la logique d'enchères de la DSP en JavaScript | Mise à jour du premier trimestre: Nous avons partagé une proposition qui limiterait la capacité des pirates informatiques à demander des données au serveur de manière exploratoire (navigation forcée). Nous invitons les acteurs de l'écosystème à nous faire part de leurs commentaires ou à soutenir cette proposition. |
| Difficultés de test | Possibilité pour les DSP plus petites de tester correctement FLEDGE et d'atténuer le risque que les annonceurs ne s'intéressent qu'aux tests avec les DSP plus grandes | Nous nous engageons à travailler avec les petites DSP et nous encourageons vivement les tests étendus auprès des DSP et des annonceurs de toutes tailles à mesure que FLEDGE passe à la disponibilité générale. Nous aimerions savoir comment nous pouvons les aider au mieux à tester FLEDGE avec d'autres acteurs de l'écosystème. Nous sommes également à l'écoute de vos idées et de vos efforts pour inciter les annonceurs à tester FLEDGE avec des DSP plus petites. |
| Remarketing dynamique | Le remarketing dynamique sera-t-il toujours possible avec FLEDGE après l'abandon des cookies tiers ? | Nous réfléchissons à une réponse à cette question et invitons les acteurs de l'écosystème à partager des insights supplémentaires sur la façon dont ils prévoient d'utiliser le remarketing dynamique. |
| Fraude/Abus | Comment l'écosystème peut-il réduire les risques et empêcher les acteurs malveillants ou les acheteurs de se présenter comme une audience souhaitable ? | Nous avons hâte de collaborer davantage avec les acteurs de l'écosystème sur la fraude et les utilisations abusives, et nous attendons vos commentaires à ce sujet. |
| Préférences utilisateur | Procédure d'enregistrement des préférences utilisateur et d'utilisation dans la sélection des annonces | Pour les annonces spécifiques, la technologie publicitaire pertinente est la partie la mieux placée pour contrôler les créations diffusées ou la manière dont elles sont sélectionnées. |
| Proposition de test quantitatif | Pour que les tests quantitatifs soient équitables, doivent-ils être effectués sur du trafic sans cookies tiers ou avec des SSP qui n'utilisent que FLEDGE ? Comment éviter le mélange des signaux provenant des cookies tiers ? | Nous vous remercions de ces commentaires et collaborons avec la CMA pour concevoir des tests qui fourniront une image fiable de l'impact de l'abandon des cookies tiers et de l'introduction des propositions de la Privacy Sandbox sur l'écosystème. Nous vous encourageons à partager directement vos commentaires supplémentaires sur la proposition de tests quantitatifs de la CMA. |
| Documentation plus claire | Demande de documentation plus claire sur la configuration des enchères | Nous espérons publier un article de blog avec une présentation supplémentaire du reporting sur les enchères FLEDGE dans les semaines à venir. |
| Parallélisation | Le service d'enchères et de mise aux enchères sera-t-il compatible avec la parallélisation ? | Une technologie publicitaire utilisant des serveurs d'enchères peut démarrer plusieurs serveurs pouvant diffuser des résultats en parallèle. |
| Atténuation des abus | Le serveur d'anonymat k FLEDGE utilisant des jetons d'état privé suffira-t-il à assurer la confidentialité des utilisateurs ? | La motivation du k-anonymat est moins axée sur le microciblage que sur la mise en place d'une protection pendant la phase intermédiaire où FLEDGE permet de créer des rapports au niveau des événements. Nous avons partagé d'autres réflexions et nous accueillons vos commentaires supplémentaires. |
| Conflit de modules ES | Demande de suppression de generateBid en tant que fonction globale, car elle entre en conflit avec le module ES |
Nous examinons cette demande et nous serons ravis de recevoir d'autres commentaires. |
| Enchères de composants | Demande d'un meilleur contrôle des éditeurs sur les conceptions des enchères | Plan d'enchères et d'enchères pour prendre en charge les enchères de composants, comme dans Chrome sur l'appareil. |
| Chronologie des enchères et des mises aux enchères | Clarification du calendrier pour les technologies publicitaires souhaitant tester les serveurs d'enchères et de mise aux enchères | Nous venons de mettre à jour la vidéo explicative sur les tests A/B et la section"Calendrier" pour inclure des définitions claires des calendriers des différentes phases des tests A/B Chrome, après avoir aligné les informations avec celles de la CMA. |
| Schéma de contrôle du délai avant expiration | Amélioration du schéma de contrôle du délai avant expiration actuellement disponible pour FLEDGE | C'est une proposition intéressante. Nous l'ajouterons à la file d'attente des propositions à étudier et nous vous tiendrons informé de nos avancées. |
| Flux d'enchères de la création | Possibilité d'examiner et de filtrer une enchère gagnante en fonction de la création | C'est une proposition intéressante. Nous l'ajouterons à la file d'attente des propositions à étudier et nous vous tiendrons informé de nos avancées. |
reportWin |
Proposition de fournir des informations supplémentaires sur l'enchère ayant le score le plus élevé d'un propriétaire de groupe d'intérêts autre que le gagnant dans la fonction reportWin |
C'est une proposition intéressante. Nous envisageons d'ajouter des signaux supplémentaires dans les rapports agrégables. N'hésitez pas à nous faire part de vos commentaires supplémentaires ici. |
| Types d'événement | Standardisation des types d'événements dans les API de mesure lors de l'intégration avec FLEDGE | C'est une proposition intéressante. Nous l'ajouterons à la file d'attente des propositions à étudier et nous vous tiendrons informé de nos avancées. Cela nécessitera une coordination avec nos efforts plus larges dans ce domaine, car cela affecterait d'autres API Privacy Sandbox au-delà de FLEDGE. N'hésitez pas à nous envoyer vos commentaires supplémentaires ici. |
| Solutions à long terme pour les rapports au niveau des événements | Intérêt à conserver certaines données telles que highestScoringOtherBid même après l'abandon des cookies tiers |
Comme indiqué dans notre article de blog de février, les rapports sur les enchères remportées au niveau des événements seront disponibles jusqu'en "2026 au moins". Nous ne pouvons pas vous fournir d'informations supplémentaires pour le moment, mais nous serons ravis de recevoir d'autres commentaires sur l'importance de conserver certaines données après l'abandon des cookies tiers. |
| Limite des groupes de centres d'intérêt | Quelle est la limite du nombre de groupes de centres d'intérêt auxquels une origine peut ajouter un seul navigateur ? | Chrome autorise jusqu'à 1 000 centres d'intérêt par propriétaire et jusqu'à 1 000 propriétaires de centres d'intérêt. Il s'agit de garde-corps, qui ne doivent pas être touchés en fonctionnement normal. |
| Signaux au niveau des événements | Acceptation d'une proposition visant à disposer de signaux au niveau des événements pour generateBid et reportWin, qui pourraient être utilisés dans l'entraînement de machine learning |
Nous avons partagé notre décision concernant les signaux conçus par le navigateur et les signaux définis par la technologie publicitaire ici. N'hésitez pas à nous faire part de vos commentaires supplémentaires. |
| Script d'enchères | Incluez l'ID utilisateur dans l'URL du script d'enchères. | Cela ne sera pas possible, car FLEDGE exige en outre que le tuple du propriétaire du groupe de centres d'intérêt, l'URL du script d'enchères et la création affichée doivent être k-anonymes pour qu'une annonce puisse être diffusée. |
| Application du k-anonymat | Le k-anonymat est-il appliqué à la paire (componentAd, size) ? | Oui, c'est le cas. Consultez turtledove/issues/312. |
| Exigences concernant les services d'enchères et de mise aux enchères | Comment les services d'enchères et de mise aux enchères permettent-ils aux participants d'intégrer FLEDGE sur l'appareil et d'autres services d'enchères et de mise aux enchères ? | Nous sommes encore en train de finaliser la conception et nous serions ravis de recevoir vos commentaires supplémentaires ici. |
| Attribution post-vue | L'attribution post-vue sera-t-elle prise en charge ? | Actuellement, nous n'avons aucune définition standard de la visibilité et nous nous appuyons sur la création elle-même pour marquer un événement de visionnage. Consultez turtledove/issues/452. |
| Le ciblage par similarités | La Privacy Sandbox peut-elle prendre en charge le ciblage par similarité ? | Nous discutons du cas d'utilisation ici et nous accueillons vos commentaires supplémentaires. |
| API de surveillance en temps réel | Proposition d'une approche de surveillance FLEDGE en temps réel | Nous examinons cette proposition et nous accueillons vos commentaires supplémentaires ici. |
| Rapports FLEDGE | reportWin et reportResult doivent être effectués dans un ordre aléatoire pour éviter les rapports excessifs ou insuffisants. |
reportResult() doit être exécutée en premier par le vendeur avant reportWin() par l'acheteur afin que les signaux du vendeur de reportResult() puissent être inclus dans reportWin(). Pour en savoir plus, consultez cette vidéo. |
| Serveurs clé-valeur (K/V) personnalisés | Les serveurs K/V personnalisés seront-ils compatibles à l'avenir ? | Nous discutons de cette question ici et nous serons ravis de recevoir vos commentaires supplémentaires. |
| Enchères de niveau supérieur | Faut-il être l'ad server pour exécuter les mécanismes d'enchères de premier niveau ? | L'API FLEDGE ne spécifie pas la partie qui doit l'appeler. Il n'y a aucune exigence en ce sens dans la conception de FLEDGE. N'importe qui peut exécuter les enchères FLEDGE (y compris les enchères multivendeurs). Comme indiqué dans le rapport du 4e trimestre 2022, FLEDGE permet à chaque éditeur de choisir la structure des enchères, y compris le choix des vendeurs de niveau supérieur et des composants. |
| Champ d'application de l'API | FLEDGE a-t-il l'intention de travailler avec des données first party ? | Nous publierons du contenu au deuxième trimestre 2023 pour préciser que les données first party peuvent effectivement être utilisées avec FLEDGE pour : 1) utiliser une logique pour déterminer l'appartenance à un groupe de centres d'intérêt et 2) alimenter des signaux d'enchères utilisateur à utiliser lors de la génération ultérieure de la logique d'enchères. |
| Groupes de centres d'intérêt multidomaines | Possibilité de créer des groupes de centres d'intérêt interdomaines | Toutes les informations disponibles au moment de l'ajout d'un navigateur à un groupe de centres d'intérêt peuvent être utilisées pour informer cette audience. Lorsque les cookies tiers seront progressivement abandonnés, la disponibilité des données intersites pour orienter la création de groupes de centres d'intérêt sera limitée. |
| Logique d'enchères côté client | Portage de la logique d'enchères côté serveur existante vers le côté client | Nous aimerions en savoir plus sur les aspects difficiles ou manquants du processus de portage. Nous serons ravis de recevoir vos commentaires ou vos insights supplémentaires. |
| Valeurs du serveur K/V | Les valeurs du serveur K/V doivent-elles être de type chaîne ? | La valeur doit être une chaîne, mais elle peut stocker des objets au format JSON ou dans un protocole de tampon et les sérialiser en chaîne. |
| Liste de blocage des annonceurs | Quels signaux sont appropriés pour fournir un acheteur pour une liste de blocage d'annonceurs ? | L'emplacement approprié se trouve dans auctionSignals ou perBuyerSignals. |
| Unité d'enchères | Compatibilité avec différentes unités d'enchères, telles que le CPI et le CPM | Nous aimerions en savoir plus sur la raison pour laquelle cela est nécessaire compte tenu de la conception actuelle et nous aimerions recevoir d'autres commentaires. |
| Logique d'enchères | Le navigateur ou le serveur publicitaire détermine-t-il le gagnant d'une mise aux enchères ? | Toute sélection de gagnants est exécutée dans l'environnement de simulation, et toutes les décisions sont prises par le code du vendeur. Le navigateur fournit simplement un environnement fermé et privé dans lequel le code de l'acheteur et du vendeur s'exécute. |
| Permissions-Policy | La stratégie d'autorisations FLEDGE actuelle continuera-t-elle d'être appliquée après la fin de la phase d'évaluation de l'origine ? | Pour le test Origin, les listes d'autorisation par défaut actuelles des deux fonctionnalités sont temporaires et seront modifiées. Nous aimerions savoir combien de temps les technologies publicitaires auront besoin pour se préparer au changement avant que nous commencions à l'appliquer. |
| Contrainte de taille des signaux | Les requêtes de signaux d'enchères fiables sont regroupées sur plusieurs groupes d'intérêts avec le même trustedBiddingSignalsUrl. La limite de taille de 2 Mo est une contrainte. |
La contrainte existe pour les appelants sur l'appareil afin d'éviter de surcharger les ressources de l'appareil. Les appelants d'un serveur d'enchères et de mise aux enchères auront une contrainte plus souple. |
| Signaux de reporting | Ajout d'un signal supplémentaire, "script-errors", pour permettre de récupérer le nombre d'erreurs côté client par propriétaire de groupe d'intérêts et par computeBid ou reportWin / reportResult. |
Nous examinons les problèmes de confidentialité potentiels liés à cette proposition et invitons les acteurs de l'écosystème à partager des informations supplémentaires sur la nécessité de cette mesure. |
| Taille de la fenêtre K-Anon | Augmenter la taille de la fenêtre K-Anon au-delà de la limite actuelle de sept jours. | Nous étudions cette question et attendons actuellement (et nous accueillons) des commentaires supplémentaires de l'écosystème. |
| Performances de l'appareil | Comment FLEDGE gère-t-il les performances de l'appareil si l'utilisateur appartient à un grand nombre de groupes de centres d'intérêt ? | FLEDGE propose plusieurs options de délai avant expiration, de hiérarchisation et de limite pour les SSP et les DSP, qui donnent aux technologies publicitaires un contrôle précis dans les situations où les performances de l'appareil peuvent être l'une des raisons de limiter la participation aux enchères lorsque l'appareil fait partie d'un grand nombre de groupes de centres d'intérêt. |
| Tests des services d'enchères et de mise aux enchères | Demander aux acteurs de l'écosystème d'utiliser leur propre serveur pendant la phase de test afin de disposer de plus de journaux disponibles pour le débogage | B&A permet aux utilisateurs de lancer et d'étendre les serveurs à partir de fournisseurs cloud approuvés. Pour préserver la confidentialité des utilisateurs, nous imposons que l'exécution soit effectuée dans un environnement d'exécution sécurisé (TEE). Nous allons bientôt publier une vidéo expliquant le débogage du TEE B&A et nous développons des fonctionnalités pour le prendre en charge. Nous souhaitons recueillir d'autres commentaires à ce sujet. |
| Exigences réglementaires | FLEDGE collaborera-t-il avec des fournisseurs de services cloud dans différents pays pour faciliter la conformité avec les exigences réglementaires locales ? | Nous sommes toujours à l'écoute de suggestions concernant d'autres fournisseurs de services cloud, mais nous prévoyons actuellement de prendre en charge au moins GCP et AWS lorsque l'abandon des cookies tiers sera appliqué. Pour en savoir plus, consultez cette vidéo. |
Mesurer les annonces numériques
Attribution Reporting (et d'autres API)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Analyse des données sur l'impact du bruit | Conseils pour effectuer une analyse des données sur l'impact du bruit | Nous avons partagé une documentation supplémentaire sur le bruit et les décisions de conception qui peuvent être utilisées pour modifier l'impact du bruit sur les données de technologie publicitaire. Un guide plus détaillé est également disponible. |
| Création de rapports "Null" | Clarification concernant l'implémentation des rapports sur les valeurs nulles | Nous travaillons actuellement sur une proposition d'implémentation de rapports nuls et nous vous communiquerons plus d'informations prochainement. L'implémentation de rapports nuls nous permettra de réduire les délais de création des rapports sans compromettre la confidentialité. |
| Niveau de bruit | Ajustement du niveau de bruit en fonction de la durée de la période d'attribution | Nous accueillons cette proposition et nous envisageons de l'ajouter aux spécifications. N'hésitez pas à nous envoyer d'autres commentaires ici. |
| Taille des données du déclencheur | Pourquoi la taille des données de déclencheur est-elle limitée à trois bits ? | La taille est limitée à trois bits et huit valeurs distinctes pour s'assurer que la quantité d'informations intersites/contextuelles sur un utilisateur est limitée. Nous invitons les acteurs de l'écosystème à envoyer leurs commentaires pour savoir si la paramétrisation actuelle des rapports au niveau des événements est pertinente. |
| Déclencheurs de création de rapports au niveau des événements | Autoriser la priorisation dans une clé de déduplication | Nous étudions des solutions à ce problème et nous sommes à l'écoute de vos commentaires. |
| Compatibilité avec le débogage | Clarifications sur le débogage après l'abandon des cookies tiers | Nous aimerions proposer le débogage après l'abandon des cookies tiers et nous réfléchissons aux options possibles. Nous sommes à la recherche de commentaires et d'idées supplémentaires. |
| Alternatives aux conversions après clic | Demande d'informations supplémentaires sur les alternatives aux conversions après clic | Nous encourageons l'écosystème à utiliser l'API Attribution Reporting comme système de mesure privé durable pour les cas d'utilisation de mesure des conversions applicables. D'autres alternatives existent, et les fournisseurs de technologies publicitaires devront choisir la solution appropriée en fonction de leurs besoins en termes de confidentialité et d'utilité. |
| Cas d'utilisation de la facturation | Clarification sur l'étendue de la prise en charge des cas d'utilisation de la facturation basée sur les conversions par Attribution Reporting | Nous nous efforçons de publier un article public pour clarifier le champ d'application de l'API Attribution Reporting pour la facturation. L'API Attribution Reporting n'était initialement pas conçue pour prendre en charge directement la facturation au CPA. Elle prend en charge la facturation au CPC et au CPM, qui est la structure de facturation utilisée par la majorité des technologies publicitaires. Nous pourrons peut-être prendre en charge cette fonctionnalité à l'avenir si nous recevons d'autres commentaires sur l'écosystème. |
| Prise en charge des cas d'utilisation | Documentation sur les cas d'utilisation de l'API de mesure | Nous nous efforçons de clarifier la documentation pour toutes les surfaces de reporting de la Privacy Sandbox. |
| Qualité des clics | Demande d'ajout d'un signal pour distinguer les clics intentionnels et non intentionnels sur une annonce | Nous examinons votre demande et nous serons ravis de recevoir d'autres informations. |
| Solution de mesure | Compatibilité avec plusieurs DSP pour les solutions de mesure | Les fournisseurs de solutions de mesure peuvent utiliser l'API Attribution Reporting pour déduplicer les données entre plusieurs DSP. De plus, nous proposons de prendre en charge une liste d'URL dans attributionsrc, ce qui permettra aux DSP de prendre plus facilement en charge les requêtes de l'API Attribution Reporting des fournisseurs de solutions de mesure. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur la proposition ci-dessus. |
| Création de rapports au niveau des événements | Demande de disponibilité du nombre de jours avant l'envoi du rapport | Cette requête peut déjà être calculée par les technologies publicitaires à l'aide des informations actuellement disponibles. Nous n'avons reçu aucun autre commentaire de l'écosystème concernant cette demande, mais nous sommes ouverts aux commentaires à ce sujet. |
source_registration_time |
Ajoutez source_registration_time dans les rapports sur l'attribution au niveau des événements. |
Nous examinons cette demande et nous serions ravis de recevoir d'autres commentaires pour savoir si les acteurs de l'écosystème trouvent cette fonctionnalité utile. |
| Mode navigation privée | Les solutions de mesure seront-elles disponibles lorsque l'utilisateur est en mode navigation privée ? | Non, les solutions de mesure ne sont pas disponibles lorsqu'un utilisateur est en mode navigation privée. Les cookies tiers sont désactivés par défaut en mode navigation privée. |
| Data clean rooms | Les API de mesure seront-elles compatibles avec les salles blanches ? | Une data clean room typique est un environnement dans lequel des données d'identifiant individuel provenant de différentes sources sont importées dans une base de données pour exécuter des analyses basées sur la fusion de ces données sous-jacentes. Les deux frameworks de mesure des API Privacy Sandbox sont les rapports au niveau des événements et les rapports récapitulatifs. Les rapports au niveau des événements contiennent un ID d'événement fourni par la technologie publicitaire qui peut être utilisé dans une salle blanche de données, mais les informations associées côté conversion seront limitées et bruyantes. Les rapports cumulables chiffrés ne peuvent pas être utilisés directement dans une salle blanche, mais les résultats récapitulatifs fournis par le service d'agrégation peuvent être utilisés comme entrée pour les analyses que vous effectuez ou comme informations supplémentaires. |
Service d'agrégation
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également signalé au 4e trimestre 2022) Délais de génération des rapports |
Quel est le délai de création des rapports prévu ? | Mise à jour du 1er trimestre 2023: Suite aux commentaires de nos partenaires, nous avons partagé des propositions visant à réduire le délai et à atténuer son impact. Les deux propositions ont été acceptées par les technologies publicitaires lors des appels du groupe de travail WICG. |
| Règle "Pas de doublons" | Comment gérer un "rapport agrégable différé" si des rapports agrégables, qui ont le même ID partagé, ont déjà été traités ? | Nous avons partagé une proposition concernant l'ajout d'un délai de rapport supplémentaire aux informations partagées des rapports agrégables et la définition de l'ID partagé pour le service d'agrégation afin de répondre partiellement à l'impact de la perte de délai sur l'API agrégative. N'hésitez pas à nous faire part de vos commentaires sur la proposition. |
| Traitement des données | Demande d'activation de la prise en charge de plusieurs passes de données tout en respectant la confidentialité différentielle, à l'aide du budget de confidentialité | Nous étudions la possibilité d'utiliser une méthode plus flexible pour utiliser le budget de confidentialité afin de permettre ce cas d'utilisation. Nous vous invitons à nous envoyer d'autres commentaires. |
| (Également signalé au 2e trimestre 2022) Ergonomie des requêtes | Activez l'agrégation des requêtes de clés. | Mise à jour du 1er trimestre 2023: La demande de fonctionnalité est toujours à l'étude, mais nous n'avons aucune proposition à partager pour le moment. |
| Limites des phases d'évaluation Origin | Clarifier le champ d'application du service d'agrégation, comme la règle "Pas de doublons", qui n'est pas actuellement appliquée dans le test d'origine. | Nous envisageons de mettre à jour notre documentation pour clarifier ce qui sera disponible dans la phase d'évaluation de l'origine et dans la version GA. |
API Private Aggregation
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Budget de contribution à Private Aggregation | Le budget de contribution de niveau 1 est trop restrictif. | Chaque appel à l'API Private Aggregation est appelé "contribution". Pour protéger la confidentialité des utilisateurs, le nombre de contributions pouvant être collectées auprès d'un individu est limité. Lorsque vous additionnez toutes les valeurs agrégables pour toutes les clés d'agrégation, la somme doit être inférieure au budget de contribution. Dans la conception actuelle, nous définissons une limite sur les contributions pour une origine de rapports spécifique au cours des 24 dernières heures environ (en tant que fenêtre glissante). Il s'agit du budget de contribution de niveau 1 mentionné dans les commentaires. Nous recommandons aux développeurs d'ajuster les valeurs qu'ils contribuent en fonction du volume attendu (c'est-à-dire de ne pas utiliser uniquement la valeur 1). Il peut donc être judicieux d'utiliser une valeur plus faible pour les événements les plus courants afin d'éviter d'épuiser le budget. Nous recherchons actuellement des commentaires sur le budget de contribution de l'API Private Aggregation, à la fois sur la limite numérique et la portée. Nous envisageons de passer du champ d'application par origine à par site, et de déplacer la limite existante vers une période de dix minutes avec une limite quotidienne plus élevée. |
Limiter le suivi dissimulé
Réduction user-agent/User-Agent Client-Hints
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Adoption de UA-R | Parmi les 10 000 sites les plus populaires au Royaume-Uni, seuls 1% d'entre eux qui utilisent la publicité programmatique envoient des indices client HTTP. Les DSP qui n'ont pas migré peuvent avoir un impact sur les fonctionnalités de lutte contre la fraude. | Après avoir effectué une analyse sur le même ensemble de données, nous avons constaté que si vous tenez compte de l'utilisation d'UA-CH à l'aide de la balise HTML <meta> et des API JavaScript, le nombre de sites utilisant UA-CH est nettement supérieur au chiffre de 1% indiqué dans les commentaires. Compte tenu de ces éléments et d'autres faits, y compris les commentaires de l'écosystème, nous sommes confiants quant au déploiement progressif de la phase 6 de la réduction de l'UA, conformément au calendrier publié, tout en tenant la CMA au courant. Nous notons que les sites ont eu près de deux ans pour se préparer à la transition. Un essai de l'abandon est toujours disponible pour les sites qui estiment ne pas être prêts. |
| Conseils pour d'autres facteurs de forme | Demande d'ajout de facteurs de forme supplémentaires pour UA-CH (TV, VR, etc.) | Nous accueillons cette proposition et nous étudions la possibilité de l'intégrer à la conception. N'hésitez pas à nous faire part de vos commentaires supplémentaires. |
| Tests automatiques | Demande de résolution du bug UA-CH dans Chrome headless avant le déploiement de la phase 6 de UAR | Le bug en question a été corrigé. |
| Compatibilité avec UA-CH sur iOS | Un site qui s'appuie sur des informations UA précises pour les cas d'utilisation des annonces indique que Chrome sur iOS n'est pas compatible. | Pour les navigateurs iOS autres que Safari (y compris Chrome sur iOS), le projet WebKit devra prendre en charge UA-CH avant qu'ils ne puissent être activés (car ils contrôlent la pile réseau). |
Protection IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également signalé au 4e trimestre) Cas d'utilisation de la géolocalisation | La protection des adresses IP peut empêcher les cas d'utilisation légitime de la géolocalisation de fonctionner à l'avenir, comme la personnalisation de contenu basée sur la géolocalisation. | Notre réponse n'a pas changé depuis le 4e trimestre 2022: "Nous collaborons avec les personnes concernées pour nous assurer que Chrome continue de prendre en charge les cas d'utilisation légitimes des adresses IP. Nous recherchons des commentaires de l'écosystème sur la précision de la géolocalisation par adresse IP." |
| Conformité réglementaire | Si la population d'une région est inférieure à un million, le seuil actuel de 1 million pour la protection des adresses IP empêcherait les sites Web d'utiliser des adresses IP pour se conformer aux réglementations. | Nous collaborons avec les personnes concernées pour nous assurer que Chrome continue de prendre en charge les cas d'utilisation légitimes des adresses IP. Nous recherchons des commentaires de l'écosystème sur la conformité réglementaire en matière de protection de la propriété intellectuelle. |
| Atténuation des abus | Les parties peuvent contourner la protection IP en partageant des adresses IP non masquées avec d'autres personnes. | Nous sommes conscients du risque que la proposition actuelle de protection des adresses IP ne permette pas techniquement aux parties de partager des adresses IP non masquées avec d'autres personnes. Nous travaillons sur des mesures d'atténuation qui éviteront ce risque d'abus. Nous vous invitons à nous faire part de vos commentaires et à discuter de la proposition au fur et à mesure de son itération. Plus précisément, nous aimerions connaître les cas d'utilisation dans lesquels les parties estiment devoir partager des adresses IP non masquées avec d'autres parties. |
| Blocage de réseau | Les parties peuvent contourner le blocage du réseau à l'aide de proxys de protection des adresses IP. | L'entité effectuant le blocage devra désactiver la protection IP pour ce scénario. Nous avons répondu au problème et nous serons ravis de recevoir d'autres commentaires. |
| Listes de blocs d'adresses IP concernées par la proposition de protection des adresses IP | De nombreuses entreprises de technologie publicitaire utilisent une liste de blocage de base d'adresses IP, comme la liste d'adresses IP du centre de données TAG, pour éviter de définir des enchères sur un inventaire publicitaire très susceptible d'être frauduleux (ou du moins non monétisable). Si une technologie publicitaire est également un traceur et qu'elle peut être soumise à la proposition de protection des adresses IP, cette entreprise risque de ne plus pouvoir effectuer de vérification de base des annonces avant d'acheter un inventaire publicitaire. | Nous vous invitons à envoyer plus de commentaires et à discuter de la proposition de protection de la propriété intellectuelle sur les problèmes et solutions potentiels. Une option consiste à appliquer des listes similaires à la protection des adresses IP, de sorte que nous ne proxyons pas les clients provenant d'adresses IP signalées précédemment. |
Prévention du suivi intersites pour améliorer la confidentialité
Ensembles propriétaires
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également signalé au 4e trimestre) Limite de domaines | Demande d'augmentation du nombre de domaines associés | Notre réponse n'a pas changé depuis le 4e trimestre 2022: "Nous avons précisé lors des appels du groupe de travail WICG que Chrome s'engage à fournir une solution utilisable qui tient également compte des intérêts de confidentialité des utilisateurs. Dans ce sens, nous aurions besoin de commentaires de la part de la communauté sur les cas d'utilisation spécifiques qui pourraient être affectés par la limite de domaines, afin que l'équipe puisse envisager des solutions pour répondre à ces cas d'utilisation tout en continuant à protéger la confidentialité des utilisateurs." |
| Envoi d'un FPS alternatif | Proposition d'une autre méthode pour envoyer des listes globales pour les FPS | Pour le moment, nous nous préparons à déployer des ensembles propriétaires (FPS) dans Chrome et avons configuré un dépôt GitHub centralisé pour accepter les envois d'ensembles. Comme nous espérons que les FPS combleront une lacune par rapport aux solutions de plates-formes Web existantes en vue de l'abandon des cookies tiers, nous nous attendons à apprendre d'eux comment les FPS sont exploités par les auteurs de sites. À mesure que la liste des ensembles augmente au fil du temps et que l'écosystème s'adapte à un monde post-cookies tiers, nous pouvons également faire évoluer le processus jusqu'au point où nous pouvons envisager d'autres schémas décentralisés tels que celui proposé. Avec le processus actuel, nous prévoyons d'instaurer des durées de vie définies, ce qui nous permettra d'évoluer le processus d'intégration au fil du temps. Nous pourrons revenir sur cette idée une fois le processus d'envoi finalisé. |
| Modération des dépôts | Mise en place d'une modération communautaire du dépôt de soumissions de FPS pour éviter les abus. Les acteurs malveillants peuvent facilement submerger le processus qui utilise des origines de carte de crédit jetable pour proposer des ensembles, et un volume de requêtes écrasant peut affecter les opérations pour les propositions d'ensembles légitimes. | Nous essayons de rendre les vérifications aussi objectives que possible en nous appuyant sur des vérifications techniques. Nous pensons qu'il s'agit de l'approche la plus évolutive pour le processus d'envoi. Conformément à cet objectif, nous nous efforcerons également de nous assurer que le processus est résistant aux envois de spam et de comptes jetables. |
| Sous-ensembles associés | FPS pourra-t-il prendre en charge les cas d'utilisation des flux de fournisseurs/SaaS tiers via des sous-ensembles associés ? | Les flux de fournisseurs tiers / SaaS ne sont pas un cas d'utilisation actuellement considéré comme faisant partie du champ d'application des ensembles propriétaires. N'hésitez pas à nous envoyer d'autres commentaires sur la façon dont les cookies intersites sont utilisés pour ces cas d'utilisation. |
| Intégration de FPS et CHIPS | Demande d'intégration de FPS + CHIPS afin de prendre en charge des cas d'utilisation tels que les tests A/B | Nous discutons de ce cas d'utilisation et envisageons également de l'examiner plus en détail lors d'un appel WICG. N'hésitez pas à nous envoyer d'autres commentaires ici. |
| RGPD | Proposition d'un nouveau sous-ensemble de FPS à modéliser d'après les concepts du RGPD | Nous avons discuté de cette proposition en interne et l'avons comparée aux autres commentaires reçus ainsi qu'à nos objectifs en matière de confidentialité. Nous vous avons fourni une réponse expliquant pourquoi nous ne poursuivrons pas cette proposition pour le moment. |
| Mémoire | Changement attendu de la taille de la mémoire du navigateur lors de l'intégration de la liste des FPS | Les navigateurs ont déjà stocké ce type de listes avec un impact minimal sur la mémoire, comme la liste de protection contre le suivi de Disconnect. Bien que la liste des ensembles propriétaires soit copiée localement sur chaque client Chrome, nous continuerons de surveiller la taille des fichiers et sommes convaincus que nous pourrons optimiser l'espace mémoire. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Limites des cadres clôturés | Clarifications sur les limites imposées par Fenced Frames | En mars, nous avons mis à jour notre explication sur les cadres délimités, qui fournit des informations sur ses fonctionnalités. Nous sommes à l'écoute de vos commentaires supplémentaires. |
| Développer les informations d'accès | Demande d'étendre l'accès aux informations sur les cadres voisins | Nous souhaitons mieux comprendre pourquoi cette exigence est imposée par l'écosystème et nous sommes à l'écoute de tout commentaire supplémentaire. |
| Cadres cloisonnés et iFrames | Questions concernant la parité des fonctionnalités entre les cadres délimités et les iFrames | Toutes les API et tous les rapports de la Privacy Sandbox disponibles seront disponibles pour les iFrames et les FencedFrames de la même manière. |
| Redimensionner des cadres cloisonnés | La restriction des modifications de la taille de la frame affecte certains cas d'utilisation. | Nous aimerions en savoir plus sur les types de cas d'utilisation concernés par la restriction et nous serions ravis de recevoir d'autres commentaires. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Worklets tiers | Les tiers peuvent-ils écrire dans Shared Storage, partitionné par origine ? Ou appeler d'autres worklets pour la mesure tierce ? | L'origine du contexte de navigation où le code est exécuté détermine le stockage partagé dans lequel les données sont écrites. Lorsqu'un code tiers est ajouté à une page, il peut être intégré en tant qu'iFrame avec son propre contexte de navigation, ce qui lui permet d'écrire dans sa propre origine. Le code tiers peut également être intégré en tant que script au lieu d'un iFrame, ce qui ne change pas le contexte de navigation. Le tiers peut alors écrire dans l'espace de stockage partagé de l'intégrateur. Notez que seul le propriétaire de ce stockage partagé peut le lire. |
| Déduplication | La déduplication ne serait pas possible pour les interactions en dehors de l'écosystème Chrome. | Le stockage partagé est destiné à fournir des résultats de couverture uniques basés sur le navigateur Chrome dans Chrome. Nous souhaitons collaborer avec les technologies publicitaires pour comprendre comment ces résultats peuvent être utilisés dans leurs modèles de couverture plus larges. Nous comprenons que les sorties elles-mêmes ne représentent peut-être qu'une partie des interactions. Nous souhaitons collaborer avec les technologies publicitaires pour explorer d'autres méthodologies de modélisation qui pourraient être superposées. |
| Période de suivi des conversions | Demander une période d'analyse du taux de conversion afin de voir les variations de conversion au fil du temps | Pour ce faire, vous pouvez traiter les différents chemins de conversion côté client à l'aide de Shared Storage, ce qui offre une flexibilité supplémentaire pour les analyses avancées par rapport au stockage sécurisé non partitionné du navigateur. |
| Période d'expiration de l'article | Demander à prolonger la période d'expiration à 90 jours | Le règlement sur la conservation des données a été mis à jour en novembre 2022. Il indique que chaque clé est effacée 30 jours après la dernière écriture. Nous attendons vos commentaires supplémentaires pour comprendre si la nouvelle règle fonctionnera pour l'écosystème. |
| Rotation des créations | Les cas d'utilisation de la rotation des créations ne reflètent pas les actions réelles après l'enchère. | Nous aimerions connaître l'avis d'autres entreprises ad tech côté achat sur l'exactitude de la documentation sur la rotation des créations. |
CHIPs
Aucun commentaire reçu ce trimestre.
FedCM
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Point de terminaison d'assertion d'identité | Autorisez explicitement les requêtes arbitraires au point de terminaison d'assertion d'identité. | Nous avons collaboré avec Mozilla sur cette pull request afin de limiter la capacité des sites Web à effectuer des requêtes authentifiées inter-origines de manière silencieuse sans gêner les utilisateurs. Nous continuerons d'examiner et de traiter d'autres commentaires. |
| Préremplir l'identité | FedCM peut-il être utilisé pour préremplir des formulaires de connexion avec un fournisseur d'identité de la liste FedCM ? | Le problème de ce cas d'utilisation est qu'il peut entraîner une fuite d'informations lorsqu'un site qui n'a pas interagi avec l'utilisateur peut interroger le dernier IDP utilisé par l'utilisateur. Nous examinons ce problème et nous serons ravis de recevoir d'autres commentaires. |
| Sélection de compte contextuelle | Proposition d'ajout de signaux contextuels dans l'UI de sélection de compte | Nous examinons cette proposition et sommes à l'écoute de vos commentaires supplémentaires. |
Lutter contre le spam et la fraude
API Private State Tokens (et autres API)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Enquête de collecte des fonctionnalités | Au début du premier trimestre, nous avons terminé de collecter les résultats de notre enquête sur les fonctionnalités requises pour différents cas d'utilisation de la lutte contre la fraude et les avons partagés publiquement (minutes, résultats). | Nous prévoyons d'intégrer ces commentaires lorsque nous développerons de nouvelles propositions et prototypes d'API dédiées et protégeant la confidentialité pour les fonctionnalités de lutte contre la fraude. Nous prévoyons de donner la priorité au développement lorsque le besoin est suffisamment important et qu'il existe une technologie existante sur laquelle nous pouvons nous appuyer pour proposer cette fonctionnalité sur le Web, tout en préservant la confidentialité des utilisateurs. Par exemple, l'intégrité de l'appareil et du démarrage a été très bien classée. De nombreuses plates-formes disposent d'API existantes qui partagent de manière sécurisée une évaluation de l'intégrité de l'appareil. Il s'agit donc d'un bon candidat pour poursuivre l'exploration au sein des groupes de la communauté. |
| Commentaires sur l'intent de livraison PST | Dans le cadre de l'intent d'expédition, nous avons reçu une inquiétude concernant la poursuite de la procédure, car nous utilisons une ancienne version de la carte de confidentialité. Nous avons également reçu des commentaires indiquant que la spécification n'était pas claire dans certaines sections et qu'elle devait être améliorée pour faciliter la compatibilité avec les navigateurs. | Nous prévoyons d'implémenter de nombreuses modifications de spécifications suggérées avant de passer en version GA, ainsi que quelques modifications d'API. Les commentaires nous sont parvenus juste à la fin du premier trimestre. Nous faisons donc un suivi des problèmes GitHub avec des détails spécifiques et une mise à jour de notre plan de lancement (en cours, à la date de publication de ce rapport sur les commentaires). Nous sommes prêts à examiner les modifications plus importantes apportées à l'API, mais nous pensons que la meilleure solution consiste à lancer la disponibilité générale et à recueillir les commentaires pratiques de plus de développeurs. Nous espérons poursuivre cette discussion et poursuivre la standardisation des navigateurs. Si et quand une nouvelle norme apparaîtra, nous envisagerons de l'adopter et de développer un plan de transition minutieux. |