Rapport trimestriel du 1er trimestre 2023 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'objectif de développement et de test actuel, des questions et des commentaires ont été reçus en particulier concernant les API Topics, FLEDGE et Attribution Reporting.
Il est possible que les commentaires reçus après la fin de la période de référence en cours ne soient pas encore pris en compte dans la réponse Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Federated Credential Management
- Lecteur d'empreinte digitale
- Ensembles internes
- IAB
- l'Interactive Advertising Bureau
- IdP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- ML
- Adresse IP (Internet Protocol)
- openRTB
- Enchères en temps réel
- Prolongation
- Phase d'évaluation
- PatCG
- Groupe de la communauté des technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client user-agent
- W3C
- Consortium World Wide Web
- En cours
- Aveugle délibéré des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Tests et essais | Pertinence des tests pour éclairer l'évaluation de la CMA si les API Privacy Sandbox ne sont pas terminées au début du test | Le développement des API Privacy Sandbox progresse rapidement.
Elles sont déjà disponibles en phase d'évaluation et seront accessibles à tous pour 100% du trafic cet été. Nous avons également clarifié le calendrier pour certaines fonctionnalités (telles que les rapports au niveau des événements FLEDGE et l'affichage FLEDGE avec des iFrames) qui ne seront pas affectées avant 2026. Nous encourageons l'écosystème à tester les API et à envoyer des commentaires à la CMA en fonction des attentes des testeurs une fois les cookies tiers obsolètes. Cela peut contribuer à leur évaluation de l'impact probable de l'abandon des cookies tiers. |
| Contrôle utilisateur | Conseils clairs pour l'écosystème sur les implications des contrôles utilisateur des API Privacy Sandbox | Nous ne sommes pas en mesure de fournir des conseils juridiques sur les éléments que l'utilisateur contrôle l'écosystème peut utiliser. Parallèlement, Chrome teste la mise à jour des commandes utilisateur de la Privacy Sandbox ("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 Privacy Sandbox. Les mises à jour incluent une langue et des mises en page plus claires et plus utiles. Une fois que Chrome aura évalué ces améliorations et décidé de les étendre à une population plus large, il peut partager davantage d'informations avec l'écosystème. |
| Fuite de données | Risque de fuite de données first party vers Google et d'autres tiers en cas de piratage du navigateur | Notre explication FLEDGE indique clairement que les données d'une technologie publicitaire ne sont partagées qu'avec la même technologie publicitaire (soit avec ses worklets, soit avec ses serveurs de confiance), soit lorsqu'elles sont explicitement partagées par cette technologie publicitaire (par exemple, lorsqu'un acheteur indique au vendeur l'URL de l'annonce qu'il souhaite afficher). La seule exception est que la vérification du k-anonymat doit être effectuée par un serveur centralisé mondial, un domaine auquel nous continuons à consacrer d'importantes ressources. Consultez l'explication sur le k-anonymat pour obtenir une vue détaillée de notre vision de la confidentialité. En outre, nous sommes disposés à fournir plus de détails sur le fonctionnement des protections des technologies publicitaires utilisées dans la conception du serveur de k-anonymat. |
| Autre forum de discussion | Demande de création d'un forum supplémentaire du W3C pour que les joueurs de l'écosystème non technique puissent donner leur avis | Le formulaire de commentaires de la Privacy Sandbox convient aux commentaires généraux et spécifiques, techniques ou non. Le groupe Améliorer la publicité sur le Web est un forum de discussion qui se déroule par appel hebdomadaire et par dépôt GitHub. La page Commentaires de la Privacy Sandbox sur developer.chrome.com présente d'autres mécanismes permettant d'envoyer des commentaires et d'engager la discussion. Chrome continue également d'organiser des événements tels que des permanences publiques pour faciliter les questions et le partage de contenu. En outre, Chrome a organisé ou participé à plus d'une douzaine d'événements du secteur au cours du dernier trimestre. |
| Clarification du calendrier | Précisions sur la date exacte de disponibilité générale au 3e trimestre 2023 | Selon le calendrier publié sur PrivacySandbox.com, le déploiement en disponibilité générale prévoit le lancement de la version 115 de Chrome. |
| reCAPTCHA | Impact des API Sandbox pour 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é sur le Web ni sur la fraude. Il élabore son propre plan pour préparer et ajuster l'abandon des cookies tiers. Il est donc mieux placé pour répondre à cette question. |
| Extensions Google Chrome | Les technologies de la Privacy Sandbox telles que les mesures anti-coupures de suivi (ACT) s'appliqueront-elles aux extensions Chrome ? | Nous n'avons pas encore annoncé de décision concernant les extensions Chrome concernées. Toutefois, si une technologie collecte dissimuler des informations sur un utilisateur, cela ne respecte pas nos principes de confidentialité. |
Diffusez des annonces et des contenus pertinents
Sujets
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Revue de la conception du TAG | Le TAG a publié la version "Early Design Review of Topics". | Nous restons mobilisés pour Topics, et avons annoncé des informations sur notre engagement à l'égard de Topics sur la page des dernières mises à jour et sur ce numéro. Nous avons répondé point par point à l'examen du TAG et partagé notre vision globale. L'API Topics restera une partie de l'ensemble d'API que l'écosystème publicitaire devrait tester en 2023. Nous espérons que les commentaires que nous recevrons en lien avec les tests et l'expérience des responsables de la mise en œuvre contribueront à l'élaboration de nouvelles normes internavigateurs dans ce domaine. Nous sommes impatients de continuer à collaborer avec l'écosystème pour faciliter la transition, lorsque l'API Topics pourrait être une norme convenue avec une compatibilité entre les navigateurs. |
| Approche des sujets | Compatibilité avec l'approche ouverte de Chrome pour le développement de l'API Topics | Nous apprécions ce sentiment et avons hâte de continuer à travailler avec ce groupe de l'industrie pour développer une API Topics qui apportera de la valeur à l'écosystème dans son ensemble. |
| (également indiqué au troisième trimestre 2022) Classification des thèmes pas assez précise |
La classification des thèmes généraux n'inclut pas des thèmes plus précis, y compris des thèmes spécifiques à une région. | Mise à jour Q1: L'amélioration de la taxonomie est un effort continu. Au deuxième trimestre, nous annoncerons une nouvelle taxonomie pour l'API Topics. Pour élaborer cette nouvelle classification, nous avons travaillé en étroite collaboration avec des entreprises de tout l'écosystème. Nous sollicitons activement vos commentaires sur la taxonomie 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 tenir compte de certains points, dont 1) les implications potentielles en termes de confidentialité (un plus grand nombre de sujets peuvent introduire 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 détecté le thème choisi par le passé). |
| (également enregistré au quatrième trimestre 2022) Impact sur les signaux propriétaires |
Le signal Topics peut être très utile et, par conséquent, dévalue 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. Nous comprenons que certains grands éditeurs craignent que Topics ait un impact négatif sur leurs stratégies de données first party. Nous sommes impatients de procéder à des tests dans l'écosystème, qui vous permettront de mieux comprendre l'impact de Topics sur les éditeurs. |
| Cas d'utilisation de Topics non liés aux annonces | Utilisation de Topics à des fins autres que la diffusion de publicité ciblée par centres d'intérêt | L'API Topics est conçue pour répondre au cas d'utilisation de la publicité ciblée par centres d'intérêt, qui, selon nous, constitue un cas d'utilisation critique pour le Web libre et ouvert. Nous cherchons actuellement à obtenir des commentaires sur d'autres cas d'utilisation et nous en évaluons actuellement les données. |
| État d'activation par défaut | Impact de la législation régionale sur le consentement par défaut pour Topics | Nous ne faisons pas de commentaires sur les opinions juridiques. |
| (également indiqué au 3e trimestre 2022) Sites mal classés |
Annonces utilisant le ciblage lorsque les thèmes d'un site donné sont mal catégorisés. | Mise à jour du 1er trimestre: Au deuxième trimestre, nous annoncerons le lancement d'un classificateur mis à jour pour l'API Topics, et nous avons hâte d'interagir avec l'écosystème sur ce sujet. En réponse aux commentaires actuels, les sites sont classés à l'aide d'une liste de remplacements soigneusement sélectionnée, qui contient 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: les sites qui utilisent l'auto-étiquetage pour encoder des significations différentes (et potentiellement sensibles) en sujets ; les sites qui présentent leurs sujets de façon trompeuse en vue d'en tirer un profit financier ; les sites qui attaquent des sujets afin de les rendre moins utiles à d'autres personnes (par exemple, spammer les sujets des internautes avec du bruit dénué de sens). 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. |
| Classificateur de thèmes | Requête pour renvoyer des informations supplémentaires indiquant les motifs pour lesquels le message "Aucun sujet" est renvoyé à l'appelant à des fins de débogage. | Nous comprenons et apprécions que les outils de débogage sont utiles pour les développeurs, car ils travaillent à l'intégration de l'API Topics dans leurs systèmes. Toutefois, en exposant des informations supplémentaires (telles que la raison pour laquelle aucun sujet n'a été renvoyé), nous pouvons partager par inadvertance des informations permettant aux parties de découvrir des détails supplémentaires (par exemple, si un utilisateur est en mode navigation privée, a désactivé l'API, etc.) au-delà de ce qui était prévu, ce qui nuit à la confidentialité des utilisateurs. Bien que nous ne prévoyions pas de fournir d'autres outils de débogage pour le moment, nous vous invitons à nous faire part de vos commentaires sur les outils qui vous seraient utiles. |
| Récupération d'informations privées (PIR) | Demande d'adoption de la récupération d'informations privées par l'API Topics | Nous avons déjà enquêté sur l'utilisation de PIR et nous avons partagé les compromis possibles ici. |
| Flux d'enchères | Les thèmes seront-ils représentés différemment 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 se distingue de la proposition d'audiences définies par le vendeur de l'IAB Tech Lab. Ces deux éléments devraient être représentés clairement dans le flux d'enchères. Découvrez comment les thèmes Topics seront représentés dans les demandes d'enchères OpenRTB. |
API Protected Audience (anciennement FLEDGE)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Disponibilité de la fonctionnalité FLEDGE | Clarification sur les calendriers de test et d'implémentation des fonctionnalités FLEDGE telles que l'application de Fenced Frame, K-Anonymity, etc. | Nous avons partagé un article de blog sur diverses fonctionnalités FLEDGE limitées et sur leur disponibilité. N'hésitez pas à nous faire part de vos commentaires à ce sujet à mesure que nous continuons à développer FLEDGE. |
| Restrictions d'affichage des produits | Demande d'assouplissement des annonces composées de plusieurs restrictions pour les cadres Fenced FLEDGE | Comme nous l'avons annoncé en février, l'utilisation de Fenced Frames restera facultative jusqu'en 2026 au moins, et le comportement des iFrames sera compatible avec les urn-iframes. Nous vous invitons à poursuivre la discussion à ce sujet. |
| Problèmes d'évolutivité | Performances de FLEDGE à mesure que l'utilisation évolue | Nous tenons compte de vos commentaires et sommes attentifs aux éléments de contexte afin de pouvoir proposer des solutions concrètes. La première étape a consisté à séparer les commentaires en deux catégories, ce que nous avons fait:
|
| (également disponible au troisième trimestre 2022) Visibilité de la logique d'enchères |
Inquiétudes concernant le fait que la logique d'enchères des DSP ne soit pas exposée dans JavaScript | Mise à jour Q1: Nous avons partagé une proposition qui limiterait la capacité des pirates informatiques à demander des données au serveur par exploration (navigation forcée). Nous invitons les joueurs de l'écosystème à nous faire part de leurs commentaires ou de leur soutien à cette proposition. |
| Difficultés du test | Possibilité pour les DSP plus petites de tester correctement FLEDGE et de réduire le risque que les annonceurs ne souhaitent effectuer des tests qu'avec des DSP plus volumineuses | Nous nous engageons à travailler avec des DSP plus petites et encourageons fortement l'élargissement des tests auprès des DSP et des annonceurs de toutes tailles à mesure que FLEDGE passe en disponibilité générale. Nous aimerions savoir comment nous pourrions les aider au mieux à tester FLEDGE avec d'autres membres de l'écosystème. Nous serions ravis de savoir comment nous pourrions inciter les annonceurs à effectuer des tests avec des DSP plus petites. |
| Remarketing dynamique | Le remarketing dynamique sera-t-il toujours possible avec l'abandon des cookies tiers par FLEDGE ? | Nous envisageons de répondre à cette question et souhaitons la bienvenue aux acteurs de l'écosystème pour vous expliquer comment ils envisagent d'utiliser le remarketing dynamique. |
| Fraude/Utilisation abusive | Comment l'écosystème peut-il réduire les risques et empêcher les acteurs ou les acheteurs mal intentionnés de se positionner en tant qu'audience souhaitable ? | Nous sommes impatients de poursuivre notre collaboration avec les acteurs de l'écosystème concernant la fraude et les abus, et nous aimerions recevoir d'autres commentaires à ce sujet. |
| Préférences utilisateur | Processus d'enregistrement des préférences utilisateur et de leur utilisation dans la sélection des annonces | Pour des annonces spécifiques, la technologie publicitaire pertinente est la mieux placée pour contrôler quelles créations sont diffusées ou comment elles sont sélectionnées. |
| Proposition concernant les tests quantitatifs | Pour que les tests quantitatifs soient justes, doit-il être effectué sur le trafic sans cookies tiers ou avec des SSP qui n'utilisent que FLEDGE ? Comment peut-on éviter le mélange de signaux provenant de cookies tiers ? | Nous apprécions vos commentaires et travaillons avec la CMA pour concevoir des expériences 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 invitons à transmettre vos commentaires supplémentaires sur la proposition de tests quantitatifs de la CMA directement à la CMA. |
| Documentation plus claire | Demande de documentation plus claire sur la configuration des enchères | Nous espérons partager un article de blog avec des informations supplémentaires sur les rapports sur les enchères FLEDGE au cours des prochaines semaines. |
| Parallélisation | Le service d'enchères et de mise aux enchères (B&A) sera-t-il compatible avec la mise en parallèle ? | Une technologie publicitaire qui utilise des serveurs d'enchères / de mise aux enchères peut démarrer plusieurs serveurs capables de diffuser des résultats en parallèle. |
| Atténuation des abus | Le serveur de k-anonymat FLEDGE utilisant des jetons d'état privés sera-t-il suffisant pour garantir la confidentialité des utilisateurs ? | L'intérêt de la propriété k-anonymat est moins axé sur le microciblage que sur la mise en place d'un arrêt d'urgence pendant la phase provisoire, pendant laquelle FLEDGE permet la création de rapports au niveau des événements. Nous avons déjà partagé d'autres réflexions et nous vous invitons à nous faire part de vos commentaires. |
| Conflit de module ES | Requête de suppression de generateBid en tant que fonction globale, car elle est en conflit avec le module ES |
Nous discutons de cette demande et nous aimerions recevoir des commentaires supplémentaires. |
| Mise aux enchères des composants | Demander aux éditeurs de mieux contrôler la conception des enchères | Plan d'enchères et de mise aux enchères pour la mise aux enchères des composants, comme c'est le cas pour Chrome sur l'appareil. |
| Calendrier des enchères et mises aux enchères | Clarté du calendrier pour les technologies publicitaires intéressées par les tests des serveurs d'enchères et de mise aux enchères | Nous venons de mettre à jour le document explicatif pour les enchères et les mises aux enchères, et nous avons mis à jour la section "Calendrier" afin d'inclure des définitions claires des délais pour les différentes phases des tests d'enchères et de mise aux enchères sur Chrome, après s'être alignés sur la CMA. |
| Schéma de contrôle du délai d'inactivité | 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 créerons des rapports sur nos développements. |
| Flux d'enchères des créations | 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 créerons des rapports sur nos développements. |
reportWin |
Proposition visant à fournir des informations supplémentaires sur l'enchère la mieux notée, provenant d'un propriétaire de groupe de centres d'intérêt différent du gagnant dans la fonction reportWin |
C'est une proposition intéressante. Nous envisagerons d'ajouter d'autres signaux dans les rapports globaux et vous invitons à nous faire part de vos commentaires supplémentaires ici. |
| Types d'événement | Normalisation des types d'événements pour les API de mesure lorsqu'elles sont intégrées à FLEDGE | C'est une proposition intéressante. Nous l'ajouterons à la file d'attente des propositions à étudier et créerons des rapports sur nos développements. Cela nécessitera une coordination avec nos efforts plus larges dans ce domaine, car cela affecterait d'autres API de la Privacy Sandbox au-delà de FLEDGE. N'hésitez pas à nous envoyer vos commentaires supplémentaires. |
| Solutions à long terme pour la création de rapports au niveau des événements | Volonté de conserver certaines données comme highestScoringOtherBid même après l'abandon des cookies tiers |
Comme nous l'avons annoncé dans l'article de blog de février, les rapports sur l'attribution des enchères au niveau des événements seront disponibles jusqu'à "au moins 2026". Nous n'avons pas d'autres informations à vous communiquer pour le moment, mais nous aimerions recevoir des commentaires supplémentaires expliquant pourquoi il est important de maintenir certaines données disponibles après l'abandon des cookies tiers. |
| Limite du nombre de 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 groupes de centres d'intérêt par propriétaire et jusqu'à 1 000 propriétaires de groupes de centres d'intérêt. Il s'agit d'un garde-fous, et non d'un renfort lors d'un fonctionnement normal. |
| Signaux au niveau des événements | Prise en charge d'une proposition comportant des signaux au niveau de l'événement pour generateBid et reportWin, qui pourraient être utilisés pour l'entraînement du machine learning. |
Nous vous avons fait part de notre décision concernant les signaux conçus par le navigateur et les signaux définis par la technologie publicitaire ici. Nous sommes ravis de recevoir des 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 impose une condition supplémentaire selon laquelle le tuple du propriétaire du groupe de centres d'intérêt, de l'URL du script d'enchères et de la création affichée doit être k-anonyme pour qu'une annonce soit diffusée. |
| Application de K-anon | Le k-anonymat est-il appliqué à la paire (componentAd, size) ? | Oui. Consultez turtledove/issues/312. |
| Exigences relatives aux services d'enchères et de mise aux enchères | Comment les services d'enchères et de mise aux enchères aident-ils les participants à intégrer FLEDGE sur l'appareil et d'autres à des services d'enchères et de mise aux enchères ? | La conception est encore en cours de finalisation. Si vous voulez nous faire part de vos commentaires, cliquez ici. |
| Attribution après affichage | L'attribution après affichage sera-t-elle disponible ? | Actuellement, nous n'avons pas défini de définition standard de la visibilité, et nous nous basons sur la création elle-même pour marquer un événement de vue. Pour en savoir plus, consultez turtledove/issues/452. |
| Le ciblage par similarités | La Privacy Sandbox peut-elle être compatible avec le "ciblage similaire" ? | Nous abordons ici le cas d'utilisation et souhaitons que des entrées supplémentaires soient ajoutées. |
| API de surveillance en temps réel | Proposition d'approche de surveillance FLEDGE en temps réel | Nous sommes en train de discuter de la proposition et les informations supplémentaires sont les bienvenues ici. |
| Rapports FLEDGE | Les champs reportWin et reportResult doivent être définis de manière aléatoire pour éviter toute sous-évaluation ou sous-évaluation des performances. |
reportResult() doit d'abord être exécuté par le vendeur avant reportWin() par l'acheteur pour que les signaux du vendeur de reportResult() puissent être inclus dans reportWin(). Pour en savoir plus, consultez l'explication. |
| Serveurs de valeurs-clés personnalisées (K/V) | Les serveurs K/V personnalisés seront-ils acceptés à l'avenir ? | Nous discutons de cette question ici et nous sommes ravis de recueillir tout commentaire supplémentaire. |
| Enchères de premier niveau | Doit-il s'agir de l'ad server pour exécuter un mécanisme d'enchères de premier niveau ? | L'API FLEDGE ne spécifie pas quelle partie doit l'appeler. Il n'y a aucune exigence à ce sens dans la conception de FLEDGE. Tout le monde peut lancer la mise aux 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 de l'enchère, y compris le choix des vendeurs de premier niveau et de composants. |
| Champ d'application de l'API | FLEDGE a-t-il l'intention de travailler avec des données first party ? | Nous publierons des contenus au deuxième trimestre 2023 pour préciser que les données first party sont effectivement utilisables avec FLEDGE à la fois pour 1) les utiliser en tant que logique pour déterminer l'appartenance à un groupe de centres d'intérêt et 2) pour alimenter les signaux d'enchères utilisateur en tant que signaux d'enchères utilisateur pour la génération ultérieure de logique d'enchères. |
| Groupes de centres d'intérêt multidomaines | Possibilité de créer des groupes de centres d'intérêt sur plusieurs domaines | Toute information disponible au moment de l'ajout d'un navigateur à un groupe de centres d'intérêt peut servir à informer cette audience. Lorsque les cookies tiers seront supprimés, la disponibilité des données intersites pour éclairer la création de groupes de centres d'intérêt sera limitée. |
| Logique d'enchères côté client | Transférer la logique d'enchères côté serveur existante vers le client | Nous souhaitons en savoir plus sur les domaines difficiles ou manquants dans le processus de portage. N'hésitez pas à nous faire part de vos commentaires ou idées 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 ils peuvent stocker des objets au format JSON ou Protocol Buffer et les sérialiser en chaîne. |
| Liste de blocage des annonceurs | Quels signaux seraient appropriés pour fournir à un acheteur 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 (CPI et CPM, par exemple) | Nous aimerions en savoir plus sur les raisons pour lesquelles cette fonctionnalité est nécessaire compte tenu de la conception actuelle, et nous aimerions recevoir des commentaires supplémentaires. |
| Logique de mise aux enchères | Le navigateur ou l'ad server décide-t-il du gagnant d'une enchère ? | La sélection des gagnants est exécutée dans le bac à sable, et toutes les décisions sont prises par le code du vendeur. Le navigateur fournit simplement un environnement scellé et privé dans lequel s'exécute le code de l'acheteur et du vendeur. |
| Autorisations – Règles | La règle Permissions-Policy FLEDGE actuelle continuera-t-elle d'être appliquée une fois la phase d'évaluation terminée ? | Pour la phase d'évaluation, les listes d'autorisation par défaut actuelles des deux fonctionnalités sont temporaires et seront modifiées. Nous souhaitons savoir combien de temps les technologies publicitaires devront se préparer au changement avant de commencer à l'appliquer. |
| Contrainte de taille de signal | Les demandes de signaux d'enchères de confiance sont regroupées entre plusieurs groupes de centres d'intérêt ayant 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 sur l'appareil. Les appelants d'un serveur d'enchères et de mise aux enchères auront une contrainte plus souple. |
| Signaux de rapport | Ajoutez un signal supplémentaire, script-errors, pour permettre la récupération du nombre d'erreurs côté client par propriétaire de groupe de centres d'intérêt et par computeBid ou reportWin / reportResult. |
Nous envisageons les problèmes de confidentialité potentiels liés à cette proposition et nous invitons les acteurs de l'écosystème à partager des informations supplémentaires sur les raisons pour lesquelles cette approche est nécessaire. |
| Taille de la fenêtre K-Anon | Augmentez la taille de la fenêtre K-Anon par rapport à la limite actuelle de sept jours. | Cette décision est à l'étude et nous attendons actuellement une autre intervention de la part 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 d'expiration, de hiérarchisation et de limite sur les SSP et les DSP. Elles offrent aux technologies publicitaires un contrôle précis dans les cas où les performances de l'appareil peuvent être l'une des raisons de limiter la participation aux enchères lorsque l'appareil appartient à un grand nombre de groupes de centres d'intérêt. |
| Test des services d'enchères et de mise aux enchères | Demander aux joueurs de l'écosystème d'utiliser leur propre serveur pendant la phase de test afin d'avoir plus de journaux disponibles pour le débogage | Les enchères et la mise aux enchères permettent aux utilisateurs de lancer les serveurs de fournisseurs cloud approuvés et d'effectuer leur scaling. Pour préserver la confidentialité des utilisateurs, nous exigeons que l'exécution s'effectue dans un environnement d'exécution sécurisé (TEE). Nous allons bientôt publier une présentation sur le débogage des TEE d'enchères et de mise aux enchères, et nous développons des fonctionnalités pour y parvenir. Nous souhaitons demander des commentaires supplémentaires à ce sujet. |
| Exigences réglementaires | FLEDGE collaborera-t-il avec des fournisseurs cloud de différents pays pour assurer la conformité avec les exigences réglementaires locales ? | Nous sommes toujours prêts à recevoir des suggestions d'autres fournisseurs cloud, mais nous prévoyons actuellement de prendre en charge GCP et AWS lorsque l'abandon des cookies tiers sera appliqué. Pour en savoir plus, consultez cette explication. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Analyse de données sur l'impact du bruit | Conseils sur la façon d'effectuer une analyse de données sur l'impact du bruit | Nous avons partagé des documents supplémentaires sur le bruit et les décisions de conception qui peuvent être utilisés pour modifier l'impact du bruit sur les données de technologie publicitaire. Un guide plus détaillé est également disponible. |
| Rapports nuls | Clarté sur l'implémentation des rapports nuls | Nous travaillons actuellement sur une proposition visant à implémenter des rapports nuls. Nous vous communiquerons bientôt plus d'informations à ce sujet. 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 | Ajuster le niveau de bruit en fonction de la durée de la période d'attribution | Nous sommes ravis de cette proposition et nous travaillons à l'ajouter à la spécification. N'hésitez pas à nous envoyer d'autres commentaires. |
| Taille des données du déclencheur | Pourquoi la taille des données du déclencheur est-elle limitée à 3 bits ? | La taille est limitée à 3 bits et à 8 valeurs distinctes pour garantir que la quantité d'informations intersites/contextuelles concernant un utilisateur est limitée. Nous invitons les joueurs de l'écosystème à envoyer leurs commentaires pour déterminer si le paramétrage actuel de la création de rapports au niveau des événements est pertinent. |
| Déclencheurs de création de rapports au niveau des événements | Autoriser la hiérarchisation dans une clé de déduplication | Nous explorons les solutions à ce problème et nous vous invitons à nous faire part d'autres commentaires. |
| Compatibilité avec le débogage | Clarté du débogage après l'abandon des cookies tiers | Nous souhaitons prendre en charge le débogage après l'abandon des cookies tiers et nous réfléchissons actuellement aux options qui s'offrent à nous. Nous souhaiterions recueillir des commentaires et des idées supplémentaires. |
| Autres options de conversion après clic | Demande d'informations supplémentaires sur les alternatives pour les conversions après clic | Nous encourageons l'écosystème à utiliser l'API Attribution Reporting en tant que système de mesure privé durable pour les cas d'utilisation applicables de mesure des conversions. Il existe d'autres alternatives, et les fournisseurs de technologie publicitaire devront décider de la solution appropriée en fonction de leurs besoins en termes de confidentialité et d'utilité. |
| Cas d'utilisation pour la facturation | Clarté de la compatibilité d'Attribution Reporting avec les cas d'utilisation de la facturation basée sur les conversions | Nous nous efforçons de publier des contenus publics afin de clarifier le champ d'application de l'API Attribution Reporting pour la facturation. À l'origine, la portée de l'API Attribution Reporting n'était pas compatible avec la facturation au CPA. Elle est compatible avec la facturation au CPC et au CPM, qui constituent la structure de facturation utilisée par la majorité des technologies publicitaires. Nous pourrons être amenés à utiliser cette fonctionnalité à l'avenir si d'autres commentaires sont envoyés au sujet de l'écosystème. |
| Cas d'utilisation compatibles | Documentation de cas d'utilisation pour l'API de mesure | Nous travaillons à 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 des clics sur une annonce | Nous discutons actuellement de votre demande et nous aimerions que vous nous fassiez part de vos commentaires. |
| Solution de mesure | Compatibilité avec les solutions de mesure sur plusieurs DSP | Les fournisseurs de solutions de mesure peuvent utiliser l'API Attribution Reporting pour répartir les données entre plusieurs DSP. De plus, nous proposons la prise en charge d'une liste d'URL dans attributionsrc, ce qui permettra aux DSP d'accepter plus facilement les requêtes de l'API Attribution Reporting des fournisseurs de solutions de mesure. N'hésitez pas à nous faire part de vos commentaires sur la proposition ci-dessus. |
| Création de rapports au niveau des événements | Demandez à ce que le nombre de jours avant l'envoi direct du rapport soit disponible directement. | Cette demande peut déjà être calculée par les technologies publicitaires à l'aide des informations actuellement disponibles. Nous n'avons pas reçu d'autres commentaires de l'écosystème concernant cette demande, mais nous sommes prêts à en faire part. |
source_registration_time |
Ajoutez source_registration_time dans Attribution Reporting au niveau de l'événement. |
Nous envisageons d'examiner cette demande et nous aimerions savoir si les acteurs de l'écosystème considèrent cette fonctionnalité utile. |
| Mode navigation privée | Des solutions de mesure sont-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. En mode navigation privée, les cookies tiers sont désactivés par défaut. |
| Data clean rooms | Les API de mesure seront-elles compatibles avec les salles blanches ? | Une salle blanche de données type est un environnement dans lequel des données d'identification individuelles provenant de différentes sources sont importées dans une base de données afin d'effectuer des analyses basées sur la fusion de ces données sous-jacentes. Les deux frameworks de mesure pour les 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. Toutefois, les informations côté conversion associées seront limitées et bruyantes. Les rapports agrégables 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 servir d'entrée pour les analyses que vous effectuez ou d'informations supplémentaires. |
Service d'agrégation
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (également indiqué au 4e trimestre 2022) Retards dans la création de rapports |
Quel est le délai attendu pour la création des rapports ? | Mise à jour du 1er trimestre 2023: Suite aux commentaires de nos partenaires, nous avons partagé des propositions pour réduire le délai et atténuer l'impact de ce retard. Les deux propositions ont été soutenues par des technologies publicitaires lors des appels WICG. |
| Aucune règle en double | 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 visant à ajouter un délai supplémentaire aux informations partagées des rapports agrégables, ainsi qu'une définition de l'ID partagé pour le service d'agrégation afin de répondre partiellement à l'impact de la perte de retard sur l'API agrégée. N'hésitez pas à nous faire part de vos commentaires sur cette proposition. |
| Traitement des données | Demande d'activation de la prise en charge de plusieurs cartes de données tout en respectant la confidentialité différentielle, à l'aide de Privacy Budget | Nous envisageons d'utiliser une façon plus flexible d'utiliser Privacy Budget pour ce cas d'utilisation. Vos commentaires supplémentaires sont donc les bienvenus. |
| (également indiqué au deuxième trimestre 2022) Ergonomie des requêtes | Activer l'interrogation de l'agrégation de clés. | Mise à jour du 1er trimestre 2023: La demande de fonctionnalité est toujours en cours d'examen, mais nous n'avons aucune proposition à faire pour le moment. |
| Limites de la phase d'évaluation | Clarifiez le champ d'application du service d'agrégation, par exemple sur la règle "pas de doublons", qui n'est pas actuellement appliquée dans la phase d'évaluation. | Nous prévoyons de mettre à jour notre documentation afin de clarifier ce qui sera disponible dans la phase d'évaluation et dans la DG. |
API Private Agrégation
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Budget de contribution à l'agrégation privée | Le budget de contribution de niveau 1 est trop restrictif. | Chaque appel de l'API Private Aggregation est appelé une 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 de toutes les clés d'agrégation, la somme doit être inférieure au budget de contribution. Dans la conception actuelle, nous limitons les contributions pour une origine de reporting particulière au cours des dernières 24 heures environ (sous la forme d'une fenêtre glissante). Il s'agit du budget de contribution L1 mentionné dans le commentaire. Nous recommandons aux développeurs d'adapter les valeurs qu'ils contribuent en fonction du volume attendu (c'est-à-dire, pas seulement en utilisant la valeur 1). Il peut donc être judicieux d'utiliser une valeur plus faible pour les événements les plus courants afin d'éviter l'épuisement du budget. Nous souhaitons actuellement obtenir des commentaires sur le budget de contribution de l'API Private Aggregation concernant la limite numérique et le champ d'application. Nous envisageons de déplacer le champ d'application d'une origine à un site par site, et de déplacer la limite existante vers une fenêtre de dix minutes avec une limite quotidienne plus grande. |
Limiter le suivi dissimulé
Réduction user-agent/Indicateurs client User-Agent
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Adoption UA-R | Sur les 10 000 premiers sites du Royaume-Uni, seul 1% des sites utilisant la publicité programmatique envoient des indications aux clients HTTP. Les DSP qui n'ont pas migré peuvent avoir un impact sur les capacité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 via la balise HTML <meta> et les API JavaScript, le nombre de sites utilisant UA-CH est nettement supérieur au chiffre de 1% indiqué dans les commentaires. Compte tenu de cela et d'autres faits, y compris les commentaires de l'écosystème, nous sommes convaincus que nous lancerons progressivement la phase 6 de la réduction UA, conformément au calendrier publié, tout en tenant la CMA informée. Nous constatons que les sites disposent de près de deux ans de délai pour se préparer à la transition et qu'un essai d'abandon est toujours disponible pour les sites qui pensent ne pas être prêts. |
| Conseils pour d'autres formats | Demande de facteurs de forme supplémentaires par UA-CH, tels que TV, VR | Nous sommes ravis de cette proposition et nous travaillons à l'intégrer à la conception. N'hésitez pas à nous envoyer tout commentaire supplémentaire. |
| Tests automatiques | Demande de résolution du bug UA-CH dans Chrome sans interface graphique avant l'expédition de la phase 6 de l'UAR | Le bug en question a été corrigé. |
| Compatibilité 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 sous iOS), le projet WebKit devra prendre en charge UA-CH avant de pouvoir être activé (car ils contrôlent la pile réseau). |
Protection de l'adresse IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (également mentionnés au 4e trimestre) Cas d'utilisation de la géolocalisation | La protection de l'adresse IP peut empêcher les cas d'utilisation légitimes de la géolocalisation de fonctionner à l'avenir, tels que la personnalisation du contenu basée sur la géolocalisation. | Notre réponse n'a pas changé depuis le 4e trimestre 2022: "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. Nous souhaitons obtenir des commentaires de l'écosystème sur la précision de la géolocalisation par IP. |
| Conformité réglementaire | Si une région compte moins d'un million d'habitants, le seuil actuel de protection IP d'un million empêche les sites Web d'utiliser des adresses IP à des fins de conformité réglementaire. | 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 souhaitons recueillir les 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 des adresses 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 puisse pas empêcher techniquement les parties de partager des adresses IP non masquées avec d'autres. Nous travaillons sur des mesures d'atténuation qui éviteront ce risque d'abus. À mesure que nous itérerons la proposition, nous encourageons les échanges et la discussion. Plus précisément, nous souhaitons connaître tous les cas d'utilisation pour lesquels les parties pensent 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 IP. | L'entité effectuant le blocage doit désactiver la protection de l'adresse IP pour ce scénario. Nous avons répondu à ce problème et nous aimerions vous faire part de vos commentaires. |
| Listes de blocage d'adresses IP concernées par la proposition de protection de l'adresse IP | De nombreuses entreprises de technologie publicitaire utilisent une liste de blocage de base d'adresses IP, telle que la liste d'adresses IP du centre de données du TAG, pour éviter d'enchérir sur un inventaire publicitaire très susceptible d'être frauduleux (ou du moins non monétisable). Dans le cas où une technologie publicitaire serait également un outil de suivi et pourrait être soumise à la proposition de protection de la propriété intellectuelle, cette entreprise pourrait perdre la possibilité d'effectuer une vérification de base des annonces avant d'acheter un inventaire publicitaire. | Nous encourageons davantage de commentaires et de discussions sur la proposition de protection de la propriété intellectuelle concernant les problèmes potentiels et les solutions. Une option consiste à appliquer ces listes similaires à la protection des adresses IP, afin de ne pas envoyer par proxy les clients provenant d'adresses IP précédemment signalées. |
Renforcez les limites de confidentialité intersites
Ensembles internes
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également indiqué au 4e trimestre) Limite par domaine | Demande d'augmentation du nombre de domaines associés | Notre réponse n'a pas changé depuis le 4e trimestre 2022: "Nous avons clarifié dans les appels des WICG que Chrome s'est engagé à fournir une solution utilisable qui tient également compte de la confidentialité des utilisateurs. À cet égard, nous apprécierions les commentaires de la communauté sur les cas d'utilisation spécifiques qui peuvent être affectés par la limite du domaine, afin que l'équipe puisse envisager les moyens de traiter ces cas d'utilisation tout en continuant à protéger la confidentialité des utilisateurs." |
| Envoi d'un autre FPS | Proposition d'un autre moyen d'envoyer des listes mondiales pour le lecteur d'empreinte digitale | Pour le moment, nous nous apprêtons à proposer des ensembles internes (FPS) dans Chrome et nous avons configuré un dépôt GitHub centralisé permettant d'accepter les envois d'ensembles. Comme nous espérons que le FPS saura combler le vide avec les solutions de plate-forme Web existantes en vue de l'abandon des cookies tiers, nous nous attendons à apprendre d'eux comment les auteurs de sites exploitent le FPS. À mesure que la liste des ensembles s'allonge et que l'écosystème s'adapte à l'univers des cookies tiers, nous pouvons également mûrir le processus au point d'envisager d'autres schémas décentralisés, comme celui proposé. Avec le processus actuel, nous prévoyons de mettre en place des durées de vie définies, ce qui nous permettra de faire évoluer le processus d'admission au fil du temps. Nous reviendrons sur cette idée une fois que le processus d'envoi sera terminé. |
| Modération du dépôt | Modération de la communauté du dépôt de soumissions du FPS pour éviter les abus. Les acteurs malintentionnés peuvent facilement submerger le processus en s'appuyant sur des origines de brûlures d'écran pour proposer des ensembles. De plus, un très grand nombre de demandes peut affecter les opérations liées à des propositions concrètes définies. | Nous essayons de rendre les vérifications aussi objectives que possible en nous appuyant sur des contrôles de validation technique. Nous pensons que c'est l'approche la plus évolutive. Dans le respect de cet objectif, nous nous efforcerons également de rendre le processus résilient aux envois de spam / brûleurs. |
| Sous-ensembles associés | Le FPS pourra-t-il prendre en charge les cas d'utilisation de flux de fournisseurs tiers/SaaS via des sous-ensembles associés ? | Le cas d'utilisation des flux fournisseurs tiers / SaaS n'est actuellement pas pris en compte pour les ensembles propriétaires. N'hésitez pas à nous faire part de commentaires supplémentaires sur la façon dont les cookies intersites sont utilisés pour ces cas d'utilisation. |
| Intégration du lecteur d'empreinte digitale et CHIPS | Demande d'intégration 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 d'en discuter plus en détail lors d'un appel WICG. Nous vous invitons à fournir des informations supplémentaires. |
| 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 à d'autres commentaires reçus ainsi qu'à nos objectifs de confidentialité. Nous avons fourni une réponse expliquant pourquoi nous n'allons pas implémenter cette proposition pour le moment. |
| Mémoire | Changement attendu de la taille de la mémoire du navigateur lorsque la liste de FPS est intégrée. | Il existe des précédents dans les navigateurs qui stockent ce type de listes avec un impact minimal sur la mémoire, comme la liste de protection contre le suivi de déconnexion. Bien que la liste des ensembles internes soit copiée localement sur chaque client Chrome, nous continuons à surveiller la taille du fichier et nous avons la certitude que nous pouvons optimiser l'espace mémoire utilisé. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Limites de Fenced Frames | Clarté des limites imposées par Fenced Frames | En mars, nous avons mis à jour notre explication sur Fenced Frames afin de fournir des informations sur ses fonctionnalités. N'hésitez pas à nous faire part de vos commentaires supplémentaires. |
| Développer les informations d'accès | Requête d'élargissement de l'accès aux informations autour des cadres voisins | Nous cherchons à mieux comprendre pourquoi l'écosystème l'impose, et n'hésitez pas à nous faire part de vos commentaires. |
| Cadres cloisonnés et cadres iFrame | Questions concernant la parité des fonctionnalités entre les cadres cloisonnés et les cadres iFrame | L'ensemble des API et rapports Privacy Sandbox disponibles seront disponibles de la même manière pour les iFrames et les FencedFrames. |
| Redimensionnement de Fenced Frames | Limiter les changements de taille des frames affecte certains cas d'utilisation. | Nous souhaitons en savoir plus sur les types de cas d'utilisation concernés par cette restriction et nous aimerions nous faire part de vos commentaires. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Worklets tiers | Les tiers peuvent-ils écrire dans du stockage partagé, partitionné par origine ? Ou appeler d'autres Worklets pour des mesures tierces ? | L'origine du contexte de navigation où le code est exécuté détermine le stockage partagé dans lequel les données sont écrites. Lorsque du code tiers est ajouté à une page, il peut être intégré en tant qu'iFrame avec son propre contexte de navigation, ce qui permet au code tiers 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, et le tiers peut écrire dans l'espace de stockage partagé de l'outil d'intégration. Notez que seul le propriétaire de ce stockage partagé peut lire à partir de ce stockage partagé. |
| 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 sorties de couverture unique basées sur le navigateur Chrome dans Chrome. Nous souhaitons collaborer avec les technologies publicitaires pour comprendre comment ces résultats peuvent être utilisés dans le cadre de leurs modèles de couverture plus larges. Nous sommes conscients que les résultats eux-mêmes ne représentent peut-être qu'une partie des interactions, et nous souhaitons collaborer avec des technologies publicitaires pour explorer d'autres méthodologies de modélisation qui pourraient être superposées. |
| Période d'analyse des conversions | Demander une période d'analyse du taux de conversion pour voir l'évolution des conversions au fil du temps | Pour ce faire, il suffit de 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 à un stockage sécurisé dans un navigateur non partitionné. |
| Période d'expiration de l'article | Demander à prolonger la période d'expiration à 90 jours | Les règles de conservation des données ont été mises à jour en novembre 2022 et indiquent que chaque clé est effacée après 30 jours après la dernière écriture. N'hésitez pas à nous faire part de vos commentaires pour savoir si le nouveau règlement sera adapté à 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 post-enchères. | Nous souhaitons recueillir l'avis d'un plus grand nombre d'entreprises de technologie publicitaire côté achat pour savoir si la documentation sur la rotation des créations est exacte ou non. |
CHIPs
Nous n'avons reçu aucun commentaire ce trimestre.
FedCM
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Point de terminaison d'assertion d'identité | Autorisez explicitement les requêtes arbitraires envoyées au point de terminaison d'assertion d'identité. | Nous avons collaboré avec Mozilla sur cette demande d'extraction pour limiter la capacité des sites Web à envoyer des requêtes avec identifiants multi-origines en mode silencieux, sans gêner les utilisateurs. Nous continuerons également à examiner et à traiter les autres commentaires. |
| Préremplir l'identité | FedCM peut-il être utilisé pour préremplir les formulaires de connexion avec un fournisseur d'identité figurant sur la liste FedCM ? | Le problème avec ce cas d'utilisation est qu'il peut entraîner la fuite d'informations lorsqu'un site qui n'a pas interagi avec l'utilisateur est en mesure d'interroger le dernier IdP utilisé. Nous discutons de ce problème plus en détail et nous aimerions recevoir des commentaires supplémentaires. |
| Sélection de compte contextuelle | Proposition d'ajout de signaux de contexte dans l'interface utilisateur de sélection de compte | Nous examinons actuellement cette proposition et sommes toujours ouverts à des discussions supplémentaires. |
Lutter contre le spam et la fraude
API Private State Token (et autres API)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Enquête sur les fonctionnalités de collecte des données | Au début du 1er trimestre, nous avons fini de collecter les résultats de nos enquêtes pour lesquels des fonctionnalités sont nécessaires pour divers cas d'utilisation de lutte contre la fraude, et nous les avons partagés publiquement (minutes, résultats). | Nous prévoyons de prendre en compte ces commentaires lors du développement de nouvelles propositions et de nouveaux prototypes d'API conçues sur mesure et protégeant la confidentialité pour les fonctionnalités de lutte contre la fraude. Nous nous attendons à prioriser le développement lorsque les besoins sont suffisants et qu'il existe des technologies existantes sur lesquelles nous pouvons nous appuyer pour introduire 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é classée parmi les premiers et de nombreuses plates-formes disposent d'API 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'intention d'expédition PST | Dans le cadre de l'intention de procéder à l'expédition, nous avons reçu une préoccupation quant au fait que nous utilisons une ancienne version du Privacy Pass. 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'appliquer un grand nombre des modifications de spécifications suggérées avant l'expédition en DG, ainsi que quelques modifications d'API. Nous avons reçu des commentaires à la fin du premier trimestre. Nous effectuons donc un suivi des problèmes liés à GitHub avec des détails spécifiques et une mise à jour de notre plan de lancement (en cours, à compter de la publication de ce rapport de commentaires). Nous sommes prêts à envisager les modifications plus importantes de l'API, mais nous pensons que la meilleure solution consiste à passer en disponibilité générale et à obtenir les commentaires pratiques d'un plus grand nombre de développeurs. Nous espérons poursuivre cette discussion et poursuivre la normalisation des navigateurs. Si une nouvelle norme devrait émerger, nous envisagerons d'adopter et d'élaborer un plan pour effectuer la transition vers celle-ci. |