Rapport trimestriel pour le 2e trimestre 2023 résumant les commentaires de l'écosystème concernant les propositions de 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 partenaires pour la Privacy Sandbox. (voir les paragraphes 12 et 17(c)(ii) du Engagements). Ces rapports récapitulatifs sur la Privacy Sandbox sont générés par agrégation commentaires reçus par Chrome de la part des différentes sources listées dans la section Commentaires présentation, y compris, mais sans s'y limiter: GitHub, les problèmes, le formulaire de commentaires mis à disposition privacysandbox.com, des réunions avec les acteurs du secteur les parties prenantes et les forums de normes Web. Chrome se félicite que les commentaires reçus de l'écosystème et étudie activement les moyens d'intégrer les enseignements tirés à décisions de conception.
Les thèmes de commentaires sont classés par prévalence par API. Pour ce faire, prenez une la quantité de commentaires reçus par l'équipe Chrome un thème donné et en organisant par ordre décroissant de quantité. Les commentaires courants thèmes ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), commentaires directs, GitHub et questions fréquentes via les équipes internes de Google et les formulaires publics.
Plus précisément, les comptes rendus des réunions d'organismes standards sur le Web étaient examiné et, pour un feedback direct, les enregistrements de Google concernant les réunions individuelles avec les partenaires, les e-mails reçus par les ingénieurs, la liste de diffusion de l'API et le public formulaire de commentaires 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 des thèmes émergents pour chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées les questions fréquentes, les réponses réelles apportées aux questions soulevées par les partenaires et la détermination d’une spécifiquement pour les besoins de cet exercice de création de rapports publics. refléter l'orientation actuelle du développement et des tests, les questions et les commentaires ; concernant Topics, Protected Audience et Attribution, en particulier de création de rapports.
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 une réponse Chrome prise en compte.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Gestion fédérée des identifiants
- Lecteur d'empreinte digitale
- Ensembles internes
- IAB
- l'Interactive Advertising Bureau
- IDP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- IP
- Adresse IP
- openRTB
- Enchères en temps réel
- Prolongation
- Phase d'évaluation
- PatCG
- Groupe de la communauté des technologies de publicité privée
- tiers assujetti à des restrictions
- 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
- Aveugle vis-à-vis des adresses IP
Commentaires d'ordre général, aucune API/technologie spécifique
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Gouvernance des données et Conformité réglementaire | Conseils sur l'utilisation de la Privacy Sandbox sur l'écosystème conformément aux exigences réglementaires. | Comme pour toute nouvelle technologie, chaque entreprise est tenue de s'assurer que son utilisation de la Privacy Sandbox est conforme à la loi. Google n'est pas en mesure de fournir des conseils juridiques. Nous sommes toutefois conscients que c'est un domaine d'intérêt majeur pour l'écosystème. Pour chaque API, nous avons publié une documentation technique détaillée qui devrait servir de base pour effectuer les évaluations juridiques nécessaires. Nous travaillons également à la mise à disposition de documents supplémentaires afin de soutenir les entreprises pour se conformer aux exigences réglementaires. |
| Proposition concernant les tests quantitatifs de la CMA | En savoir plus sur la proposition de tests quantitatifs de la CMA | Nous collaborons avec la CMA pour concevoir des expériences qui donneront une idée de l'impact de l'abandon des cookies tiers et de l'introduction des propositions de la Privacy Sandbox sur l'écosystème. En avril, la CMA a publié des conseils généraux sur le déroulement de la période de tests et d'essai, puis des conseils détaillés en juin. Nous vous invitons à partager directement vos questions et commentaires sur la proposition de tests quantitatifs de l'autorité britannique de la concurrence et des marchés. |
| Modes de test gérés par Chrome | Plus d'informations et de clarifications sur les calendriers des tests | Le 18 mai, nous avons publié un article de blog pour vous donner plus d'informations sur les deux modes de tests gérés par Chrome. Ces détails ne sont pas définitifs, et nous publierons d'autres instructions d'implémentation à mesure que nous progresserons au cours du troisième trimestre 2023. |
| Stockage partitionné | Le stockage partitionné sera-t-il utilisé lors des tests gérés par Chrome ? | Le partitionnement du stockage sera fourni à tous les utilisateurs avant le test d'abandon des cookies tiers. Elle sera donc activée pour toutes les sections du test. Les sites auront la possibilité d'activer un essai avant arrêt pour récupérer le stockage non partitionné pendant cette période. |
| Assistance pour la production | Quel processus Chrome a-t-il mis en place pour répondre aux problèmes techniques de la Privacy Sandbox et aux escalades qui affectent l'écosystème ? | Google propose plusieurs canaux pour permettre aux technologies publicitaires de signaler les problèmes et de faire remonter les problèmes, le cas échéant. Veuillez consulter notre post destiné aux développeurs pour en savoir plus sur les forums publics et privés afin de recueillir vos commentaires et faire remonter les problèmes. |
| Calendrier d'inscription | Le délai d'inscription actuel est trop court | Nous évaluons encore la date limite d'application du règlement, et nous aimerions connaître le délai le plus adapté pour l'écosystème. |
| Numéro D-U-N-S | En savoir plus sur les exigences concernant le numéro DUNS pour l'inscription et l'attestation | Les participants peuvent consulter les conditions requises pour obtenir un numéro DUNS sur le site Web de Dun & Bradstreet. Les exigences varient en fonction du marché, les participants doivent donc vérifier le site Web du marché spécifique qui les intéresse. Toutefois, les participants doivent généralement fournir des informations de base sur leur entreprise, telles que son nom, son adresse et les coordonnées du propriétaire ou du responsable de l'entreprise. Les participants peuvent également être invités à fournir des informations financières, telles que les revenus annuels de l'entreprise. Une fois la demande traitée, D&B l'examinera et émettra un numéro DUNS si elle est approuvée. |
| Passer de la phase d'évaluation à la disponibilité générale | La transition de la phase d'évaluation à la disponibilité générale affectera-t-elle les testeurs actuels de la phase d'évaluation ? | À partir du mois de juillet, les testeurs pourront accéder aux API de pertinence et de mesure en disponibilité générale. Cela permettra d'établir un chevauchement entre la disponibilité de la phase d'évaluation et la disponibilité générale. |
| Étude AdExchanger | En savoir plus sur la méthodologie de l'enquête | Les personnes interrogées ont demandé aux personnes interrogées d'estimer les taux de synchronisation et le chiffre d'affaires de leurs entreprises. Personnes interrogées pour répondre à leurs questions individuelles. |
| Valeurs de paramètres | Comment les valeurs des paramètres, telles que le niveau de bruit, les seuils d'anonymat et le budget de confidentialité, sont-elles déterminées ? | Cette explication sur GitHub présente les principes les plus généraux des API Privacy Sandbox. De nombreuses valeurs sont toujours en cours de finalisation, et vos commentaires à ce sujet sont les bienvenus. |
Afficher les contenus pertinents et Annonces
Thèmes
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Préservation de la confidentialité | Recherche évaluant l'API Topics sur la protection de la confidentialité | Nous participons activement à la communauté des chercheurs en présentant nos recherches sur les propriétés de confidentialité de l'API Topics dans des articles, des rapports et des présentations d'ateliers. Nous sommes heureux de voir que davantage de membres externes de la communauté de recherche interviennent dans ce domaine. L'API Topics protège les utilisateurs contre le suivi général sur le Web en rendant trop difficile le suivi des utilisateurs à grande échelle. Ces articles montrent que nous parvenons à tout faire grâce à l'API Topics. Elles sont plus privées que les cookies tiers et protègent les utilisateurs tout en soutenant les sites qu'ils aiment consulter. |
| La classification des thèmes n'est pas assez précise | La taxonomie des thèmes généraux n'inclut pas de thèmes plus précis, y compris spécifiques à une région. | En réponse aux commentaires précédents de l'écosystème, nous avons publié un article de blog le 15 juin décrivant une nouvelle taxonomie qui intègre de nombreuses améliorations suite aux commentaires de l'écosystème. Dans le cadre de notre travail sur la nouvelle taxonomie, nous avons collaboré avec plusieurs entreprises de l'écosystème, comme Raptive (anciennement CafeMedia) et Criteo. La classification mise à jour supprime les catégories qui semblent moins utiles, au profit de celles qui correspondent mieux aux centres d'intérêt des annonceurs, tout en maintenant notre engagement à exclure les thèmes potentiellement sensibles. Nous encourageons l'écosystème à examiner la classification la plus récente et à nous faire part de ses commentaires sur les modifications apportées. |
| Processus de mise à jour de la taxonomie et du classificateur | Vous trouverez plus d'informations sur la classification Topics et la fréquence de publication des classificateurs, ainsi que sur la manière dont les entreprises peuvent se préparer à ces mises à jour. | Comme indiqué dans notre récent article de blog, la taxonomie devrait évoluer au fil du temps et la gouvernance de la taxonomie devrait à terme être remplacée par une partie externe représentant les personnes concernées de l'ensemble du secteur. Nous avons également partagé le plan de montée en puissance dans le groupe topics-announce. |
| Impact sur les signaux propriétaires | L'augmentation du nombre de thèmes dans la récente mise à jour de la taxonomie peut s'avérer très intéressante et, par conséquent, dévaloriser d'autres signaux propriétaires basés sur les centres d'intérêt. | Dans le rapport du 1er trimestre 2023, la CMA a déclaré : "Nous comprenons que Google a discuté de sa nouvelle taxonomie avec plusieurs acteurs du marché sur l'ensemble de la chaîne d'approvisionnement ad tech. Même si quelques grands éditeurs ont déclaré qu'une plus grande utilité des thèmes augmenterait la pression de la concurrence sur leurs solutions basées sur les données first party, notre première idée est qu'une plus grande utilité est plus bénéfique pour la concurrence globale, en particulier pour la capacité des petits éditeurs à continuer à monétiser leur inventaire après l'abandon des cookies tiers." Notre point de vue est aligné sur ce commentaire de la CMA. |
| Utilité pour différents types de partenaires | Les technologies publicitaires qui agissent en tant que SSP et DSP peuvent présenter des avantages considérables par rapport aux autres acteurs de l'écosystème. | Notre réponse n'a pas changé par rapport aux trimestres précédents: "Google s'est engagé auprès de l'autorité britannique de la concurrence et des marchés à concevoir et à mettre en œuvre les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se faisant passer pour l'activité de Google, et à tenir compte de l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, quelle que soit leur taille. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que nos travaux respectent ces engagements. À mesure que les tests de la Privacy Sandbox progresseront, nous évaluerons les performances des nouvelles technologies pour différents types de personnes concernées. Les commentaires sont essentiels à cet égard, en particulier les commentaires spécifiques et exploitables qui peuvent nous aider à améliorer davantage les conceptions techniques. Nous avons collaboré avec l'autorité britannique de la concurrence et des marchés pour développer notre approche des tests quantitatifs. Nous soutenons également la publication d'une note sur la conception des tests afin de fournir plus d'informations aux acteurs du marché et de donner l'occasion de commenter les approches proposées." |
| Sujets descendants | Les critères de sélection des thèmes étant la fréquence des visites sur le navigateur, la fragmentation des segments va-t-elle empêcher les thèmes descendants d'arriver en tête ? | Chrome examine actuellement d'autres méthodologies de classement et examine d'autres signaux pour améliorer ce classement. Nous communiquerons nos plans révisés à l'écosystème en temps voulu. |
| Confidentialité | L'objectif de l'API Topics doit être de s'assurer que les informations sur les utilisateurs obtenues ou dérivées de cette API doivent être moins sensibles que celles obtenues avec les méthodes de suivi actuelles. | Nous pensons que l'API Topics est beaucoup plus privée que les technologies actuelles, limite considérablement la réidentification des utilisateurs et est conçue pour exclure les sujets sensibles. Nous reconnaissons que les thèmes peuvent être corrélés ou combinés avec des données first party pour créer des catégories sensibles. Cependant, nous pensons que l'API Topics est un pas en avant dans le respect de la confidentialité des utilisateurs et nous nous engageons à continuer à l'améliorer. |
| Structure de la taxonomie | Ajouter une structure d'ID, de gestion des versions et d'autres métadonnées à la taxonomie de thèmes | Actuellement, l'identifiant de la taxonomie est inclus dans la réponse de l'API. Alors que nous nous dirigeons vers une gouvernance à long terme, il est judicieux d'examiner l'objet Topics et d'inclure des métadonnées supplémentaires sur la gestion des versions si nécessaire. |
| Contrôle de l'éditeur | Les éditeurs doivent avoir leur mot à dire sur les thèmes selon lesquels leurs sites doivent être classés. | Une classification erronée des sites peut rendre le signal Topics un peu moins utile en tant que signal dans l'ensemble. Toutefois, les sites spécifiques qui sont mal classés ne sont pas plus, ni moins affectés par ce signal que les autres sites. En effet, les informations contextuelles d'un site seront toujours disponibles pour les enchères sur son site, ce qui fournirait des informations comparables au thème approprié, même en cas d'erreur de classification. N'hésitez pas à nous faire part de vos commentaires à ce sujet ici. Permettre aux éditeurs de contrôler leur classification présente des risques. Certains sites risquent de mal classer leurs sites de façon intentionnelle, réduisant ainsi l'utilité pour tous, ou d'encoder des significations sensibles pour des sujets moins courants, ce qui porte atteinte à la confidentialité des utilisateurs. |
| Extensions Chrome | Autoriser les extensions Chrome à gérer et à filtrer Topics, de la même manière que les extensions de gestion des cookies actuelles | Cela devrait déjà être possible, comme indiqué sur GitHub, mais n'hésitez pas à nous faire part de vos commentaires supplémentaires de la part de l'écosystème. |
| Transition vers la disponibilité générale | La transition de la phase d'évaluation à la disponibilité générale aura-t-elle un impact sur l'API Topics ? | Aucune donnée ne sera perdue pour les utilisateurs passant de la phase d'évaluation à la disponibilité générale. |
| Confidentialité | Les noms d'hôte peuvent contenir des informations privées susceptibles d'être divulguées par l'API Topics. | Nous avons mis en place un certain nombre de mesures d'atténuation pour garantir la confidentialité, comme décrit sur cette page. |
| Fraude et utilisation abusive | Empêcher la manipulation des Topics par des visites frauduleuses | Pour en savoir plus sur les mesures d'atténuation, cliquez ici. |
| Classificateur de thèmes | Les sites Web peuvent-ils demander à modifier leur classification par thèmes ? | Nous aimerions connaître l'avis de l'écosystème à ce sujet, et vos commentaires ici sont les bienvenus. |
| Sites de fournisseurs de thèmes | Désigner certains sites Web qui hébergent du contenu pour de nombreux thèmes en tant que "sites de fournisseurs de thèmes spéciaux" et entraîner des classificateurs selon les balises présentes sur les pages Web. | Nous discutons de cette proposition ici. N'hésitez pas à nous faire part de vos commentaires. |
API Protected Audience (anciennement FLEDGE)
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Lissage du trafic | Impact sur les performances du filtrage basé sur SSP pour optimiser la charge des requêtes par seconde (RPS) | Nous avons consacré beaucoup de temps à réfléchir à la forme de trafic, et nous recommandons aux SSP de tirer parti de la mise en cache. |
| Tester le volume | Il est difficile de tester l'API Protected Audience, car les SSP et les DSP ont des difficultés à générer des volumes de trafic importants. | Nous collaborons en permanence avec des partenaires SSP et DSP pour adopter et tester Protected Audiences. La disponibilité générale a commencé, et nous sommes convaincus que le pourcentage de trafic pour lequel les annonces personnalisées sont activées rendra le test plus intéressant pour les partenaires. |
| Complexité | L'implémentation des solutions Protected Audience nécessite des efforts et des coûts importants. | Nous sommes conscients que les nouvelles technologies, y compris la Privacy Sandbox, sont difficiles à adopter. L'équipe Privacy Sandbox travaille en étroite collaboration avec un large éventail de personnes concernées pour éduquer et soutenir leurs efforts. Elle évalue en permanence d'autres accélérateurs pour soutenir l'adoption de l'écosystème. |
| Environnements d'exécution sécurisés | Compatibilité avec les environnements d'exécution sécurisés (TEE) dans les environnements cloud non publics | Nous étudions des options qui pourraient s'étendre à d'autres solutions cloud, mais il n'est actuellement pas possible de prendre en charge les TEE sur site en raison des limitations de sécurité sur site qui nécessiteraient une évaluation chronophage de la Privacy Sandbox. Compte tenu des exigences de sécurité de la Privacy Sandbox et des défis majeurs que posent les déploiements sur site, nous pensons que continuer d'étendre et d'améliorer les déploiements dans le cloud (par exemple, en prenant en charge GCP en plus d'AWS) est le plus bénéfique pour l'écosystème. Cependant, nous aimerions recevoir vos commentaires supplémentaires sur les raisons pour lesquelles une telle exigence est nécessaire. |
| Type de facturation | Enchères et L'offre de services d'enchères augmentera le coût et la complexité des technologies publicitaires par rapport aux modèles côté client. | Nous développons actuellement un guide pour estimer les coûts liés à la gestion des processus d'enchères et de mise aux enchères dans la section "Enchères et Serveur d'enchères, qui sera corrélé à l'utilisation de technologies publicitaires, afin d'atteindre l'un des objectifs de nos conceptions. |
| Chronologies de K-Anon | Quand les contraintes de k-anonymat prévues seront-elles appliquées à "renderUrl" ? | Nous vous expliquerons bientôt le calendrier d'application des règles. |
| Restrictions runAdAuction | Chrome peut-il limiter l'appel de runAdAuction uniquement à partir de la page supérieure ? |
Bien que notre conception soit entièrement compatible avec l'appel de runAdAuction depuis la première page, nous pensons qu'il serait plus nuisible pour les éditeurs de limiter cet appel uniquement à partir du domaine de premier niveau.L'écosystème nous a spécifiquement indiqué que la Privacy Sandbox devrait réduire la charge qui pèse sur les éditeurs et les annonceurs. Ces commentaires s'alignent sur le principe général du développement Web selon lequel les propriétaires de sites peuvent utiliser des outils tiers pour gérer leurs sites. L'objectif de la Privacy Sandbox est d'encourager un écosystème sain, sans avoir à définir le fonctionnement des éditeurs et des technologies publicitaires. En permettant à l'éditeur de choisir qui et comment appeler runAdAuction sur son site, nous sommes convaincus que nous offrons aux éditeurs la flexibilité nécessaire pour trouver la meilleure façon de répondre à leurs besoins. |
| Aide à l'implémentation | Chrome peut-il créer une mise aux enchères multivendeur ou contribuer à sa mise en œuvre Open Source ? | La Privacy Sandbox vise à développer des technologies protégeant la confidentialité qui ne s'appuient pas sur des cookies tiers ni d'autres identifiants intersites. Nous voulons encourager un écosystème sain, sans avoir à exiger de règles sur le fonctionnement des technologies publicitaires. Nous avons publié des conseils sur le fonctionnement des API dans notre dépôt GitHub et sommes prêts à explorer des solutions avec le secteur. Nous ne prévoyons pas de développer une implémentation spécifique, car notre mission principale est de concevoir des technologies de plate-forme, et non de dicter des stratégies d'utilisation de ces technologies. Nos technologies aideront les entreprises d'ad tech à mieux servir leurs clients avec les bons garde-fous de confidentialité pour les consommateurs. |
| Enchères multivendeurs | Chrome forcera-t-il le partage d'une requête avec les enchères de composants ? | L'API Protected Audience est conçue pour permettre aux parties qui lancent le système d'enchères multivendeurs de transmettre des informations à l'enchère du composant (remarque: uniquement avant le lancement de l'enchère). Cela dit, nous ne voyons aucun moyen pour le navigateur de déterminer si une information constitue une information gagnante contextuelle ou non. Nous n'avons donc pas pu appliquer le blocage ni exiger certaines informations. |
| Préférence des utilisateurs pour le suivi du consentement | Une technologie publicitaire demandant à l'AP comment implémenter correctement le suivi du consentement des utilisateurs | Notre réponse inclut ce que nous avons dit au premier trimestre: "Pour des annonces spécifiques, la technologie publicitaire pertinente est la partie la mieux placée pour contrôler les créations diffusées et la façon dont elles sont sélectionnées." Nous avons abordé un certain nombre de scénarios liés à ce problème lors de la réunion de mai sur l'audience protégée de WICG, et n'hésitez pas à nous faire part de vos commentaires et discussions supplémentaires sur ce sujet. |
| Audiences personnalisées | Les cas d'utilisation des SSP liés à la création d'audiences personnalisées seront-ils compatibles avec l'API Protected Audience ? | L'API Protected Audience permet aux SSP et à d'autres fournisseurs de technologie publicitaire de posséder et de gérer des audiences personnalisées. D'autres instructions sur l'intégration d'une SSP à l'API PA sont en cours de développement. Elles seront mises à la disposition des SSP et d'autres fournisseurs de technologie publicitaire pour les aider dans leurs efforts d'intégration. |
| Formats | Les vidéos sont-elles compatibles avec l'API Protected Audience ? | Les annonces vidéo sont diffusées de deux façons: au format XML VAST ou HTML (annonce OutStream pouvant charger le code XML VAST dans un lecteur vidéo). Les acheteurs peuvent renvoyer l'un ou l'autre de ces formats via une URL de rendu. La spécification VAST a été récemment mise à jour pour être compatible avec l'API Attribution Reporting. Les sites qui diffusent des annonces vidéo doivent se préparer à la diffusion d'annonces via l'API Protected Audience. Cela signifie que les tags d'emplacement peuvent transmettre l'URL d'un iFrame Protected Audience à un lecteur vidéo. Pour les frames cloisonnés, nous nous efforcerons de répondre aux besoins en vidéo avant l'obligation d'utiliser les images cloisonnées, qui ne doit pas avoir lieu avant 2026. |
| Rythme | Comment le cas d'utilisation de Pacing fonctionne-t-il avec l'API Protected Audience ? | Nous vous remercions de vos commentaires. Nous aimerions voir plus d'instances de cette demande, avec davantage de détails provenant d'un plus grand nombre de SSP partenaires, car il s'agissait principalement d'une préoccupation pour les DSP à ce jour. |
| Fréquence de mise à jour | La fréquence des appels provenant de dailyUpdate (jusqu'à un par groupe de centres d'intérêt et par jour) peut ne pas être suffisante pour certains cas d'utilisation (par exemple, pour mettre à jour des informations sur les produits). |
Nous vous remercions de vos commentaires. D'autres solutions permettent aux technologies publicitaires d'utiliser des signaux actualisés à différentes cadences, comme les recherches de valeurs-clés. |
| Contrôle de la qualité des annonces | Comment les éditeurs mettent-ils en œuvre le contrôle de la qualité des annonces ? | Aujourd'hui, l'API Protected Audience permet aux éditeurs d'informer leurs SSP sur certains contrôles qu'ils peuvent établir dans le cadre de la configuration des enchères avant enchère (c'est-à-dire les listes de blocage basées sur les libellés associés aux annonces). N'hésitez pas à nous faire part de vos commentaires sur les fonctionnalités supplémentaires éventuellement requises par l'écosystème. |
| Débogage | Quand la fonctionnalité forDebuggingOnly sera-t-elle supprimée ? |
Nous prévoyons de supprimer forDebuggingOnly pour les événements de perte en raison de l'abandon des cookies tiers. Nous prévoyons de supprimer au plus tôt forDebuggingOnly pour les victoires en 2026. |
| Groupes de centres d'intérêt multi-appareils | Proposition d'activation des groupes de centres d'intérêt multi-appareils pour les user-agents authentifiés | Nous évaluons cette proposition, mais la spécificité élevée du ciblage multi-appareil pose d'importants problèmes de confidentialité, comme indiqué dans ce problème GitHub. |
| Remarketing dynamique (également disponible au premier trimestre) | Le remarketing dynamique sera-t-il toujours possible avec l'API Protected Audience après l'abandon des cookies tiers ? | Nous pensons que ce cas d'utilisation est possible avec Protected Audience, comme expliqué ici. |
| Données sur les clics | Ajouter les données liées aux clics dans browserSignals. |
Nous vous demandons actuellement de plus d'informations sur la date à laquelle le clic s'est produit afin d'obtenir une position préliminaire. |
| (Également indiqué au 4e trimestre 2022) Fonctions définies par l'utilisateur dans Protected Audience | Comment les fonctions définies par l'utilisateur (UDF) seront-elles prises en charge dans l'API Protected Audience ? Ces fonctions peuvent être programmées par les utilisateurs finaux afin d'étendre les fonctionnalités de l'API. | La technologie publicitaire qui a soulevé ce problème a également indiqué qu'elle est encore en train d'évaluer ce qu'elle pourrait faire avec l'UDF. Il n'y a donc pas encore de commentaires exploitables concernant cette action, pas avant au moins avant qu'elle ne soit disponible pour tous les utilisateurs. |
| Devise | Les montants en devise ne doivent pas être représentés par des virgules flottantes. | Nous avons abordé ce problème sur cette page en détail. |
| Fonctionnalités de sélection d'annonces non DSP | Quel rôle jouent les ad servers dans les enchères de l'API Protect Audience ? | Nous sommes au courant de la demande des ad servers pour continuer à proposer des services de sélection d'annonces post-enchères et d'optimisation des créations dynamiques. Nous évaluons actuellement l'analyse détaillée des écarts entre l'API Protected Audience actuelle et ces demandes. |
| GenerateBid | Compatibilité avec Google Ads d'afficher plus d'une annonce candidate par groupe de centres d'intérêt à partir de generateBid et d'obtenir une note de ces candidats dans "scoreAd". |
Ceci est en cours d'évaluation. N'hésitez pas à nous envoyer vos commentaires supplémentaires. |
| Ordre d'enchères | Les enchères de l'API Protected Audience doivent-elles être les dernières à être exécutées pour pouvoir bénéficier du résultat de toutes les autres enchères ? | Il n'existe aucune exigence technique pour que l'API Protected Audience s'exécute en dernier. |
| Navigation non déclenchée par l'utilisateur | Exposer la navigation non lancée par l'utilisateur | Nous examinons actuellement cette demande et en discutons ici . N'hésitez pas à nous faire part de vos commentaires. |
| Mise en cache | La SSP ne doit pas créer l'élément perBuyerSignals d'une DSP donnée à partir d'un cache si l'état de l'utilisateur change. | Nous sommes conscients que la mise en cache ne fonctionne pas pour tous les cas d'utilisation des signaux par acheteur et nous étudions d'autres options. N'hésitez pas à nous faire part de tout commentaire supplémentaire de la part de l'écosystème pour savoir si la mise en cache est adaptée à leurs cas d'utilisation. |
| Attribution Reporting et Protected Audience | Comment les API Attribution Reporting et Protected Audience peuvent-elles fonctionner ensemble ? | Des intégrations sont actuellement disponibles pour l'API Protected Audience pour les deux modes de l'API Attribution Reporting (rapports au niveau des événements et récapitulatifs). Le 1er juin, nous avons partagé plus d'informations sur l'intégration améliorée de l'API Protected Audience et d'Attribution Reporting. Pour en savoir plus, cliquez ici. |
| Point de terminaison du serveur | Le point de terminaison du serveur sera-t-il le serveur d'agrégation de confiance dans la conception finale ? | Le point de terminaison du serveur est un point de terminaison géré par une technologie publicitaire et indépendant des serveurs d'agrégation de confiance utilisés pour traiter les rapports collectés et transformés. Aucune modification n'est prévue pour le point de terminaison des rapports pour le moment. La conception actuelle vise à garantir que les rapports agrégables eux-mêmes (avec charges utiles chiffrées) ne divulguent pas de données intersites. Un point de terminaison de confiance ne devrait donc pas être nécessaire. Autre complication : les différentes technologies publicitaires auront probablement des stratégies de traitement par lot souhaitées différentes. N'hésitez pas à nous envoyer vos commentaires supplémentaires. |
| WebIDL | La spécification actuelle de l'API Protected Audience n'est pas compatible avec la spécification WebIDL. | Nous évaluons ces commentaires et discutons du problème ici. |
| Gestion du consentement | Comment le signal de consentement sera-t-il géré dans l'API Protected Audience ? | Les informations contextuelles n'entrent pas dans le champ d'application de l'API Protected Audience. Nous discutons de ce problème. N'hésitez pas à nous faire part de vos commentaires. |
| Marketing basé sur le compte | Des cas d'utilisation marketing basés sur les comptes seraient-ils possibles ? | L'API Protected Audience prend en charge divers cas d'utilisation marketing basés sur l'audience. Nous continuons de comprendre comment l'API Protected Audience peut répondre au mieux à ce cas d'utilisation spécifique, et nous apprécions les commentaires supplémentaires de l'écosystème sur ce problème. |
| Enchères des composants | Quels sont les scores des participants aux enchères ? | Les enchères des composants ne évaluent pas directement les groupes de centres d'intérêt, mais plutôt les annonces et les enchères envoyées par une DSP à partir de la fonction generateBid. La fonction generateBid() est exécutée par groupe d'intérêt, et la DSP renvoie le code suivant lors de l'exécution de generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contributions externes | Demande d'assistance pour les contributions externes sur la base de code GitHub du serveur de clés-valeurs. | Nous cherchons à mettre à jour nos processus pertinents pour permettre les contributions externes au code GitHub. |
| Taille du groupe de centres d'intérêt | Quel est le nombre maximal de clés que l'IG peut accepter ? | La taille d'un IG est actuellement limitée à 50 Ko, et les clés sont prises en compte dans ce calcul. N'hésitez pas à examiner la limite de taille pour en savoir plus. |
| Traitement par lot | Comment peut-on réduire le nombre d'appels de serveurs de K/V ? | Vous pouvez utiliser des en-têtes HTTP Cache-Control pour réduire le nombre d'appels K/V. Par exemple, il peut être mis en cache lors des enchères de composants, ainsi que dans les espaces publicitaires d'une même page. |
| Contrôle des versions | Compatibilité avec plusieurs versions du code de technologie publicitaire | Les services d'enchères et de mise aux enchères seront compatibles avec plusieurs versions du code de technologie publicitaire. Dans l'API Bidding and Auction, la demande SelectAd peut spécifier la version du code utilisée pour la demande d'enchère (pour les enchères, les mises aux enchères et la création de rapports). |
| Stockage partagé | Prise en charge de l'écriture sur le stockage partagé dans le service d'enchères et de mise aux enchères. | À l'heure actuelle, les services d'enchères et de mise aux enchères ne sont pas compatibles avec le stockage partagé, mais nous aimerions recevoir des commentaires supplémentaires expliquant l'importance de ces cas d'utilisation pour l'écosystème. |
| Web-to-app | Permettre le partage Web-to-app des groupes de centres d'intérêt. | Le web-to-app n'est actuellement pas limité au déploiement de l'API Protected Audience sur Chrome et Android, mais nous souhaitons connaître l'importance de ce cas d'utilisation dans l'écosystème. |
| K-anonymat | Gérer les remplacements liés à K-Anonymat | Nous discutons de ce problème. N'hésitez pas à nous faire part de vos commentaires. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Configurations alternatives des rapports sur les conversions après affichage au niveau des événements | Commentaires sur les configurations alternatives des rapports sur les conversions après affichage au niveau des événements | Certains utilisateurs nous ont fait part du fait que les configurations actuelles au niveau des événements ne sont pas optimales et nous demandons leur avis sur les configurations globales optimales. N'hésitez pas à nous faire part de vos commentaires à ce sujet. Nous pensons que notre explication flexible au niveau des événements permet également de résoudre ce problème. |
| Configurations flexibles au niveau des événements | Quel est l'état de la fonctionnalité de configuration flexible au niveau de l'événement ? | Nous avons partagé une documentation sur la configuration flexible au niveau des événements. Cette fonctionnalité est encore au stade de proposition, et nous souhaitons recueillir des commentaires sur son intérêt pour l'écosystème. |
| Configurations flexibles au niveau des événements | Comment peut-on rapprocher les rapports en conflit provenant de différentes parties ? | La plupart des scénarios de création de rapports sont traités à l'aide de rapports globaux, tandis que la proposition de configuration flexible au niveau des événements offre une flexibilité supplémentaire pour les rapports au niveau des événements, qui sont le plus souvent utilisés pour les cas d'utilisation d'optimisation. N'hésitez pas à nous faire part de tout autre commentaire sur l'écosystème concernant ce scénario. |
| Enregistrement de la source | Que se passe-t-il si l'enregistrement de la source a lieu après celui du déclencheur ? | Actuellement, si l'enregistrement de la source a lieu après l'enregistrement du déclencheur, la source et le déclencheur ne peuvent pas être attribués l'un à l'autre. Il semble s'agir d'un scénario limite. N'hésitez pas à nous faire part de vos commentaires concernant ce problème. Nous nous efforcerons de le résoudre s'il s'agit d'un scénario que de nombreuses technologies publicitaires semblent être confrontées. |
| Collaboration avec plusieurs agences publicitaires | Comment les DSP peuvent-elles utiliser l'API Attribution Reporting lorsqu'un annonceur travaille avec plusieurs agences publicitaires ? | L'API prend en charge les redirections et peut donc être utilisée même lorsqu'un annonceur travaille avec plusieurs agences de publicité. De plus, il existe des limites concernant les redirections afin de s'assurer que l'API améliore la confidentialité. Nous avons également identifié une solution de contournement potentielle utilisant l'API Shared Storage pour le scénario spécifique proposé par la technologie publicitaire. N'hésitez pas à nous faire part de vos commentaires sur ce scénario et nous continuerons à le perfectionner. |
| Limites de destination | L'application de limites à la destination peut avoir un impact sur le cas d'utilisation des annonces à actualisation automatique. | Nous avons abordé ce problème lors de la réunion WICG du 1er mai et attendons de recevoir des commentaires sur ce que serait une limite raisonnable. Nous avons ajouté une explication sur l'attribution Reporting avec les rapports au niveau des événements, en indiquant que le navigateur peut limiter le nombre d'eTLD+1 "destination" représentés par les sites sources. (voir Demande d'extraction). |
| Attribution Reporting et Protected Audience | Comment les API Attribution Reporting et Protected Audience peuvent-elles fonctionner ensemble ? | Des intégrations sont actuellement disponibles pour l'API Protected Audience pour les deux modes de l'API Attribution Reporting (rapports au niveau des événements et récapitulatifs). Le 1er juin, nous avons partagé plus d'informations sur l'intégration améliorée de l'API Protected Audience et d'Attribution Reporting. Pour en savoir plus, cliquez ici. |
| Configurations flexibles au niveau des événements | Partagez les bonnes pratiques de simulation du bruit maintenant que les paramètres sont configurables. | Nous proposons du code partagé sur GitHub que n'importe qui peut utiliser pour évaluer le gain d'informations et l'impact du bruit pour les configurations flexibles au niveau des événements qu'il souhaite tester. Nous aimerions connaître l'avis de toutes les personnes qui choisissent de tester avec le code et qui souhaitent nous faire part de leurs commentaires. |
| Mesure de l'attribution multi-applications et Web | Quand la mesure de l'attribution multi-applications et Web sera-t-elle disponible ? | Le 9 mai, nous avons annoncé un test pour la mesure de l'attribution multi-applications et Web via l'API Attribution Reporting. Bien que la disponibilité générale des API de pertinence et de mesure soit prévue dans Chrome 115, la mesure de l'attribution multi-applications et Web ne devrait pas entrer en disponibilité générale avec Chrome 115 pour le moment. |
| Dédupliquer les conversions | Comment comparer les solutions de mesure indépendantes avec l'ARA ? | Comme pour la pratique standard actuelle, les annonceurs doivent faire appel à un fournisseur de mesure tiers indépendant pour supprimer les rapports sur les conversions en double. Nous avons mis en place des ressources expliquant comment dédupliquer les conversions afin de créer des rapports au niveau des événements. |
| Perte de données lors de la mise à jour de la base de données Attribution Reporting | Des données seront-elles perdues lorsque Chrome mettra à jour la base de données Attribution Reporting comme annoncé ? | À partir de la version 115 de Chrome, nous commencerons à activer par défaut les API de pertinence et de mesure pour une partie des utilisateurs de Chrome. Cette disponibilité générale augmentera à mesure que nous surveillerons d'éventuels problèmes. L'objectif est d'atteindre une disponibilité de 100% sur une période de plusieurs semaines d'ici le troisième trimestre 2023. Cela coïncide avec la fin de la phase d'évaluation de la pertinence et des mesures. À partir de juillet, les testeurs pourront s'inscrire pour accéder à ces API en disponibilité générale. Ainsi, la disponibilité de la phase d'évaluation initiale et de la disponibilité générale par le biais de l'inscription ne sera pas la même. Votre jeton d'évaluation de l'origine est valide jusqu'au 19 septembre. Toutefois, nous vous recommandons de vous inscrire aux API avant l'expiration afin de pouvoir en sortir facilement de la phase d'évaluation sans interrompre les tests en cours. Comme indiqué dans cette annonce, les données enregistrées à partir d'anciennes versions (M113 et antérieures) ne seront pas migrées après la mise à jour. Vous risquez donc de perdre des données. Cette perte de données n'apparaîtra pas dans les rapports de débogage et nous essaierons d'éviter toute perte de données de 114 à 115. |
| Facturation | Utiliser Attribution Reporting pour la facturation au coût par conversion | Comme indiqué dans cet article, l'API Attribution Reporting n'est peut-être pas adaptée aux besoins de facturation au coût par conversion, en raison du bruit ajouté aux rapports récapitulatifs et au niveau des événements. Nous encourageons les acteurs de l'écosystème à nous faire part de leurs commentaires concernant l'impact de l'API Attribution Reporting sur GitHub sur les différents modèles de facturation. |
Service d'agrégation
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Modification du délai de création des rapports agrégables | Réactions positives à la proposition visant à faire passer le délai du rapport agrégable de [10 à 60 minutes] à [0 à 10 minutes] suite aux commentaires de l'écosystème | Nous sommes ravis de la réaction positive au changement proposé, et nous encourageons l'écosystème à continuer à nous faire part de ses commentaires sur nos propositions. |
| Solution sur site | Le service d'agrégation peut-il être déployé dans des centres de données sur site ? | Nous étudions des options qui pourraient s'étendre à d'autres solutions cloud, mais il n'est actuellement pas possible de prendre en charge les TEE sur site en raison des limitations de sécurité sur site qui nécessiteraient une évaluation chronophage de la Privacy Sandbox. Compte tenu des exigences de sécurité de la Privacy Sandbox et des défis majeurs que posent les déploiements sur site, nous pensons que continuer d'étendre et d'améliorer les déploiements dans le cloud (par exemple, en prenant en charge GCP en plus d'AWS) est le plus bénéfique pour l'écosystème. Cependant, nous aimerions recevoir vos commentaires supplémentaires sur les raisons pour lesquelles une telle exigence est nécessaire. |
| Traiter à nouveau les rapports pour différentes périodes | Possibilité de traiter à nouveau les rapports pour différentes périodes | Nous avons reçu des demandes similaires concernant la possibilité de diviser des lots pour différentes plages de dates. Une proposition consiste à permettre d'étendre l'ID partagé avec un libellé défini par la technologie publicitaire afin que les rapports puissent être divisés en différents lots. Nous en sommes au tout début d'évaluation de ce processus et nous mettrons l'écosystème à jour au fur et à mesure de l'évolution de cette proposition. |
| Implications d'un environnement d'exécution sécurisé sur la confidentialité | Opinion positive sur les implications des environnements d'exécution sécurisés sur la confidentialité | Nous sommes heureux des réactions positives de l'écosystème concernant nos propositions, et n'hésitez pas à nous en faire part à mesure que nous continuons à les améliorer et à les développer. |
| Conditions d'utilisation | Quelle est la date limite pour accepter les conditions d'utilisation du service d'agrégation ? | Bien que nous n'ayons pas encore spécifié de date limite pour accepter les conditions d'utilisation, nous encourageons les entreprises de l'écosystème à accepter les conditions d'utilisation dès que possible afin d'éviter tout retard dans le processus d'inscription. Nous encourageons les entreprises à nous contacter en cas de questions. |
| Découverte de clés | La fonctionnalité de découverte de clés permettra aux testeurs d'interroger des rapports globaux sans avoir besoin de la liste explicite des combinaisons de clés possibles afin de traiter les rapports récapitulatifs pour l'attribution multiréseau, et d'améliorer les performances et la précision. | Nous étudions actuellement des solutions et des solutions de contournement, et nous aimerions recevoir d'autres commentaires de la part de l'écosystème. |
API Private Aggregation
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Origine du rapport | Comment l'origine des rapports est-elle définie ? | L'origine des rapports est toujours l'origine du script de l'appelant Private Aggregation. |
| Espace clé de 128 bits | Clarté sur la limitation de l’espace clé de 128 bits | Nous allons clarifier cette limitation de l'espace de clés et résoudre les incohérences entre les pages. Nous vous recommandons d'utiliser des stratégies de hachage pour rester dans cet espace de clés. |
| Contribution maximale par rapport | La limite actuelle de 20 contributions par rapport est trop faible. | Plutôt que d'augmenter le nombre maximal de contributions, nous sommes prêts à envisager de scinder les rapports au lieu de les tronquer. Nous interagirons avec l'écosystème à mesure que cette proposition évoluera. |
| Rapports sur la couverture | Demande de création de rapports sur la couverture multiplate-forme/multi-appareil. La couverture est une métrique essentielle dans la publicité axée sur la marque. Les annonceurs s'appuient sur des approximations multi-plateformes/multi-appareils pour les rapports sur la couverture et la fréquence afin d'analyser leurs campagnes et de répartir les dépenses. Les modèles de couverture utilisent les cookies tiers comme signal pour mesurer les annonces diffusées dans des environnements tiers. Les technologies publicitaires ont donc demandé une autre solution une fois les cookies tiers abandonnés. |
L'équipe de la Privacy Sandbox développe des fonctionnalités permettant d'intégrer des méthodologies de couverture multidomaine après l'abandon des cookies tiers. N'hésitez pas à nous faire part de vos commentaires. |
Limiter le suivi dissimulé
User-Agent Reduction/User-agent Client Hints
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également disponible au 1er trimestre 2023) Conseils concernant d'autres facteurs de forme | Requête de User-Agent Client Hints (UA-CH) pour fournir des facteurs de forme supplémentaires tels que TV ou VR | Nous travaillons encore sur certaines décisions de conception clés (comme proposer une valeur unique comme "TV" ou une liste de fonctionnalités de facteur de forme), mais restez intéressé par le prototypage de cette idée. |
| Privacy Budget | Les restrictions Privacy Budget peuvent rendre les requêtes UA-CH non déterministes lorsque trop de requêtes sont envoyées. | Nous n'avons pas de nouvelles informations sur la proposition Privacy Budget pour le moment, mais nous nous sommes engagés à ne pas limiter les demandes de conseils pour les clients UA avant l'abandon des cookies tiers. |
| Compatibilité du site | Certains sites Web utilisent la marque UA-CH pour empêcher certains navigateurs d'y accéder. | Il existe des cas d'utilisation valables pour disposer d'une liste de marques, dont la compatibilité. Un UA est sans frais pour avoir plusieurs marques pour contourner ces problèmes. |
Protection de la propriété intellectuelle (anciennement Gnatcatcher)
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Fraude et Utilisation abusive | Comment les entreprises peuvent-elles mettre en place des mesures de lutte contre la fraude avec la protection de la propriété intellectuelle ? | Nous sommes conscients de l'importance des cas d'utilisation de lutte contre la fraude et de leur impact potentiel sur ces cas d'utilisation. Nous prévoyons de publier davantage d'informations sur la lutte contre la fraude dans le courant de l'été. Nous souhaitons recueillir des commentaires sur l'écosystème afin de mieux gérer les cas d'utilisation de lutte contre la fraude. |
| GeoIP | En savoir plus sur le calendrier des tests et du déploiement de GeoIP | Chrome a récemment publié de nouvelles informations détaillant nos plans GeoIP. Nous prévoyons de publier davantage d'informations sur le calendrier de déploiement au troisième trimestre. Dans un premier temps, nous prévoyons de lancer IP Protection sous la forme d'une fonctionnalité activable par l'utilisateur sur un petit pourcentage du trafic. Nous sommes conscients que cette proposition peut entraîner des changements importants pour les entreprises. Nous souhaitons donc laisser à l'écosystème le temps de s'adapter et de nous faire part de ses commentaires avant de déployer cette fonctionnalité à plus grande échelle. |
| Authentification du compte | Comment l'authentification des comptes avec le serveur proxy fonctionnera-t-elle exactement ? | Nous prévoyons de publier davantage d'informations sur l'authentification des comptes dans le courant de l'été, même si nous vous avons déjà communiqué quelques considérations initiales. |
Atténuation du suivi des rebonds
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Conseils pour les tests | Informations sur la façon de tester l'atténuation du suivi des rebonds | En mai, nous avons publié un article de blog contenant des informations supplémentaires sur la façon de tester l'atténuation du suivi des rebonds. |
| Documentation | Clarté dans la proposition de suivi des rebonds | La proposition actuelle est en cours de développement, et Chrome continue de la mettre à jour afin de clarifier et de fournir des informations à l'écosystème. Nous nous efforçons de vous fournir plus d'informations. N'hésitez pas à nous faire part de vos commentaires. |
| Suppression des cookies | La fonctionnalité d'atténuation du suivi des rebonds supprime-t-elle tous les cookies d'un domaine ? | L'atténuation du suivi des rebonds vide l'intégralité de l'espace de stockage et du cache, comme expliqué ici. |
| Contourner l'atténuation du suivi des rebonds | Vous pouvez contourner la classification de l'outil de suivi des rebonds en effectuant des redirections avec des pop-ups ou de nouveaux onglets. | La spécification de l'atténuation du suivi des rebonds est toujours en cours de développement. Jusqu'à présent, nous nous sommes principalement concentrés sur les redirections du même onglet, mais nous prévoyons de travailler sur les flux de pop-up à l'avenir. N'hésitez pas à nous envoyer vos commentaires supplémentaires. |
Privacy Budget
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Ciblage de proximité | Privacy Budget peut avoir un impact sur les cas d'utilisation du ciblage de proximité. | Nous avons reçu des commentaires à ce sujet, et nous aimerions en savoir plus sur les conséquences potentielles de ce problème sur l'écosystème. |
Renforcer les limites de confidentialité intersites
Ensembles internes
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également indiqué au cours des trimestres précédents) Limite de domaines | Demande d'extension du nombre de domaines associés | Chrome évalue la limite numérique appropriée pour le sous-ensemble associé afin de trouver un juste équilibre entre confidentialité et utilité pour les cas d'utilisation identifiés. Dès le départ, Chrome a fait savoir que le nombre exact du sous-ensemble associé n'était pas encore finalisé. |
| Cas d'utilisation intégré | Compatibilité avec les cas d'utilisation intégrés nécessitant des ensembles internes, des CHIPs et un espace de stockage partagé | Les commentaires sur ce cas d'utilisation ont été transmis à Chrome. L'équipe est en train d'examiner le problème, et les commentaires supplémentaires sont les bienvenus. |
| Gestion des dépôts | Informations sur les règles de suppression des ensembles internes du dépôt GitHub en cas d'incohérence ou de négligence | Chrome a reçu des commentaires sur ce cas d'utilisation. Notre équipe étudie ce problème et souhaiterait d'autres commentaires. |
| Formation des utilisateurs | Chrome devrait permettre aux utilisateurs de mieux connaître et comprendre les ensembles internes pour favoriser l'adoption. | L'équipe Chrome s'est engagée à informer les utilisateurs sur les ensembles internes. C'est pourquoi nous avons publié un article du Centre d'aide (accessible depuis l'interface utilisateur Chrome) à cet effet. Chrome s'efforce également de continuer à apprendre à mieux informer les utilisateurs dans les contextes appropriés. |
| Après 3PCD | Les cookies tiers continueront d'exister dans un ensemble interne après l'abandon des cookies tiers. | Bien que requestStorageAccess et requestStorageAccessFor proposent à nouveau les cookies tiers pour des cas d'utilisation spécifiques et clairement définis, ils nécessitent désormais un appel actif par le site au lieu d'être disponibles par défaut, comme c'est le cas actuellement pour les cookies tiers (dans Chrome).Bien que cette invocation dans un ensemble unique ne nécessite pas l'approbation de l'utilisateur, les utilisateurs peuvent empêcher cela en désactivant ce comportement dans les paramètres. Des informations supplémentaires sont disponibles pour les utilisateurs dans l'article du centre d'aide (accessible depuis l'interface utilisateur de Chrome). Nous prévoyons de développer le guide du développeur existant à mesure que le FPS augmente jusqu'à 100%. |
| Envoi d'ensembles internes | Renommez l'élément .well-known/first-party-set requis pour inclure une extension .json. |
Nous avons effectué cette modification afin de nous assurer que certains forfaits d'hébergement Web sont compatibles. |
| Enregistrement auprès de l'IANA | first_party_sets.JSON doit être enregistré auprès de l'IANA |
Nous étudions la proposition. Si vous avez d'autres commentaires, veuillez cliquer ici. |
API Fenced Frames
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Blocage des annonces | Les cadres cloisonnés permettent aux bloqueurs de publicité de bloquer plus facilement les annonces. | Les extensions peuvent interagir avec les cadres cloisonnés de la même manière qu'elles le feraient avec des cadres iFrame. L'URL réelle vers laquelle le cadre cloisonné va être redirigé sera également visible par les extensions. Elles peuvent donc appliquer n'importe quelle règle de correspondance d'URL pour le blocage, comme dans les cadres iFrame. Le simple fait de bloquer tous les cadres cloisonnés de manière inconditionnelle peut endommager les cas d'utilisation de cadres cloisonnés non publicitaires. |
API Shared Storage
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Adoption plus large | Le stockage partagé doit être une norme du secteur disponible pour tous les navigateurs. | Nous accordons une grande importance à vos commentaires. Chrome continue de participer activement aux forums du W3C pour défendre la proposition, recueillir des commentaires et favoriser son adoption. |
| Portes de sortie | Les portes de sortie du stockage partagé sont trop limitées. | Nous tenons compte de ces commentaires. Nous vous invitons à nous faire part de vos commentaires sur les raisons pour lesquelles les portes de sortie sont trop limitées. |
| Conformité vis-à-vis des réglementations | Comment Shared Storage gère-t-il la conformité réglementaire, comme les règles de conservation des données ? | Le stockage partagé offre la flexibilité nécessaire pour implémenter et personnaliser la logique afin de contrôler la durée de vie et l'expiration de toutes les données stockées. Les technologies publicitaires peuvent mettre à jour ou effacer les données de stockage partagé en fonction des horodatages d'écriture. |
| Tests A/B | Comment effectuer des tests A/B pour Shared Storage et l'API Protected Audience ? | Nous travaillons à la publication d'instructions supplémentaires à ce sujet et espérons vous donner plus d'informations à l'avenir. |
| Limite de stockage partagé | Que se passe-t-il une fois la limite de stockage partagé atteinte ? | Si la limite est atteinte, aucune autre entrée ne sera stockée. |
| Accès multiples sur le même chargement de page | Que se passe-t-il lorsque l'espace de stockage partagé fait l'objet de plusieurs accès lors du même chargement de page ? | La meilleure façon de gérer cela est d'utiliser la fonction window.sharedStorage.append(key, value). Plutôt que de mettre à jour la valeur de chaque annonce, ce qui pourrait entraîner des conflits en cas d'annonces multiples. La fonction "append" ajoute simplement la nouvelle valeur à la fin de la valeur préexistante. |
| Fonctionnalité iFrame | Le stockage partagé sera-t-il compatible avec certaines fonctionnalités iFrame lorsqu'elles ne fonctionneront plus après l'abandon des cookies tiers ? | Après l'abandon des cookies tiers, le stockage local dans les iFrames sera partitionné par le site de premier niveau, mais les iFrames eux-mêmes ne seront pas bloqués. Les données du stockage local d'un iFrame ne peuvent pas être répliquées sur plusieurs sites de premier niveau, mais le stockage local peut toujours être utilisé dans l'iFrame. |
Chips
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Limite de partition | 10 Kio par site partitionné reste conséquent et souhaiterait que ce quota soit réduit. | Firefox a déjà indiqué une position positive sur les CHIPS. Pour l'assistance avec Webkit, nous encourageons les développeurs à fournir directement à Apple leurs commentaires sur ce problème GitHub concernant leurs cas d'utilisation où les cookies partitionnés sont privilégiés par rapport au stockage partitionné. |
| Intégrations authentifiées | Les CHIPs peuvent affecter le flux de connexion SSO actuel en raison de l'impact des différents partitionnements sur les intégrations authentifiées. | Nous avons l'intention d'exploiter l'API Storage Access (avec des invites utilisateur) pour prendre en charge le cas d'utilisation des intégrations authentifiées, et nous avons récemment envoyé un intent-to-prototype. |
| Règles à vie | Des règles potentielles à vie s'appliqueront-elles aux cookies propriétaires ? | Pour le moment, nous ne prévoyons pas d'imposer de limites de durée de vie aux cookies propriétaires. |
FedCM
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Prise en charge des autorisations OAuth | S'aligner sur l'autorisation des champs d'application OAuth hors profil | Nous sollicitons activement les commentaires de la communauté des identités Web via le FedID CG du W3C pour déterminer les meilleures façons de prendre en charge l'autorisation au-delà de l'authentification de base après l'abandon des cookies tiers. |
| Compatibilité SAML | Se conformer aux exigences de compatibilité SAML | L'équipe recherche activement l'avis des communautés de recherche et d'enseignement sur les besoins d'assistance SAML (en plus de l'assistance OpenID-connect) après l'abandon des cookies tiers. |
Lutter contre le spam et la fraude
API Private State Token (et autres API)
| Thème Commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Explorer de nouveaux signaux | Plusieurs partenaires ont exprimé leur volonté d'explorer les signaux facilités par le navigateur pour évaluer l'intégrité des appareils ou la confiance des utilisateurs. De manière générale, ils sont également prudents, car les nouveaux signaux spécifiques sont suffisants pour conserver le niveau actuel de détection des fraudes. | Nous sommes impatients d'explorer de nouvelles propositions avec la communauté de la lutte contre la fraude et la sécurité sur le Web, et nous comprenons et partageons leurs préoccupations. C'est précisément la raison pour laquelle "lutter contre le spam et la fraude". est l'un des principaux axes de travail de la Privacy Sandbox. C'est pourquoi nous continuons à privilégier les investissements pour préserver la sécurité sur le Web à mesure que nous améliorons la confidentialité des utilisateurs. |
| Commentaires positifs sur PST | Plusieurs partenaires ont fait part de leur intérêt pour le test et l'utilisation des TVP pour différents cas d'utilisation de lutte contre la fraude et de sécurité sur le Web. | Nous sommes ravis de recevoir de l'aide et de l'intérêt pour l'exploration de nouvelles solutions utilisant les TVP. Des ressources et des exemples de code sont disponibles sur le site pour les développeurs Chrome. Si vous avez besoin d'autres commentaires, n'hésitez pas à les consulter. |
| Fraude et utilisation abusive | Conseils pour la détection et la prévention de la fraude publicitaire dans les mesures après l'abandon des cookies tiers lorsque les identifiants ne sont plus disponibles. | Nous avons lancé des outils tels que les jetons d'état privés, qui aident à récupérer une partie des signaux perdus par les cookies tiers à des fins de lutte contre la fraude, mais avec de nouveaux paramètres de confidentialité en place. Nous investissons activement dans de nouvelles propositions de lutte contre la fraude et les utilisations abusives pour préserver nos capacités avec les autres changements apportés à la Privacy Sandbox. |
| Taux d'informations de l'émetteur vers l'origine | Le taux d'informations entre l'émetteur et l'origine est suffisamment élevé pour identifier les utilisateurs uniques. | Nous avons mis à jour les spécifications pour clarifier les données utilisateur pouvant être transmises à l'aide de jetons d'état privés. Par nature, il est possible d’utiliser jusqu’à six clés publiques à la fois, ce qui peut représenter un « état » pour un utilisateur particulier. Ces ensembles de clés ne peuvent être mis à jour que tous les 60 jours (sauf dans de rares cas où une rotation des clés d'urgence est nécessaire), ce qui ralentit la possibilité de joindre des données utilisateur supplémentaires au fil du temps. Toute nouvelle API Web offre un juste équilibre entre l'utilité et les nouvelles informations sur les utilisateurs. Nous estimons que les PST offrent le juste milieu pour protéger la confidentialité des utilisateurs tout en permettant les principaux cas d'utilisation de lutte contre la fraude impactés par l'abandon des cookies tiers. |
| Extraire l'intégration | L'intégration de fetch est compliquée et inutile. |
L'utilisation de fetch présente des avantages et des inconvénients, et nous aimerions poursuivre la normalisation au sein de l'écosystème Web, mais nous pensons qu'il serait trop tôt pour effectuer ce changement tant que nous n'aurons pas une idée plus précise de ce à quoi ressemblera la norme. Si et quand une norme émergera, nous nous engageons également à faire en sorte que les développeurs Web s'engagent de manière responsable vers cette norme. |
| Emplacement de stockage | Les configurations de clés de jetons d'état privés doivent être stockées au même emplacement que le protocole PrivacyPass. | Lors des tests effectués lors de la phase d'évaluation, les développeurs ont indiqué qu'ils préféraient la flexibilité de stocker leurs clés sur des URL générales plutôt que dans un répertoire .well-known. Le format d'engagement de clé de PrivacyPass n'est pas particulièrement adapté à une version où les collections de clés sont destinées à permettre l'ajout de "métadonnées publiques" implicites. . Si un variant de PrivacyPass finit par être standardisé avec des métadonnées publiques (POPRF, aveuglement RSA partiel ou keysets), il est possible que nous passions à une future version de PST pour prendre en charge cette fonctionnalité. |
| Implémentation de l'en-tête de l'API | Questions concernant l'implémentation de l'en-tête de l'API | À mesure que l'API se standardise et que l'utilisation de cette API dans l'écosystème gagne en maturité, nous espérons être en mesure de prendre en charge à la fois la version standard sans en-tête de cette API et éventuellement de supprimer la version d'en-tête si l'utilisation est suffisamment faible, ou si les développeurs disposent d'outils et d'une assistance suffisants pour corréler les demandes d'émission/d'utilisation avec d'autres données. Nous discutons de ce problème ici. |
| Inscription | Est-il pratique de demander aux émetteurs de s'enregistrer auprès des fournisseurs de navigateurs ? | Nous avons mis à jour les spécifications pour décrire le processus d'enregistrement des émetteurs pour les jetons d'état privés. Bien qu'il utilise son propre processus, il est semblable aux plans d'enregistrement pour le reste du travail de la Privacy Sandbox, où nous demandons aux émetteurs de déclarer publiquement comment ils ont l'intention d'utiliser les fichiers PST et d'accepter les restrictions techniques qui protègent la confidentialité des utilisateurs. |