Rapport trimestriel du deuxième trimestre 2023 résumant les commentaires de l'écosystème reçus sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.
Les thèmes des commentaires sont classés en fonction de leur prévalence par API. Pour ce faire, nous prenons la quantité de commentaires que l'équipe Chrome a reçus sur un thème donné et l'organisons par ordre décroissant. Les thèmes courants des commentaires ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquentes soulevées par les équipes internes de Google et les formulaires publics.
Plus précisément, les comptes rendus des réunions des organismes de normalisation du Web ont été examinés. Pour les commentaires directs, les enregistrements de Google des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires publics ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation pour déterminer la prévalence relative des thèmes émergents en lien avec chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifique aux fins de cet exercice de rapport public. En raison de l'objectif actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Protected Audience et Attribution Reporting.
Les commentaires reçus après la fin de la période de création de rapports en cours n'ont peut-être pas encore fait l'objet d'une réponse de Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Gestion des identifiants fédérés
- Lecteur d'empreinte digitale
- Ensembles propriétaires
- IAB
- Interactive Advertising Bureau
- IDP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- IP
- Adresse IP
- openRTB
- Enchères en temps réel
- Prolongation
- Essai Origin
- PatCG
- Groupe de la communauté sur les technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client User-Agent
- W3C
- World Wide Web Consortium
- WIPB
- Blanchement volontaire des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Gouvernance des données et conformité aux réglementations | Conseils sur l'utilisation de Privacy Sandbox dans le respect des 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 ne peut pas fournir de conseils juridiques. Nous sommes toutefois conscients que ce domaine est un axe d'intérêt clé 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 mettons également tout en œuvre pour mettre à disposition des documents supplémentaires afin d'aider les entreprises à se conformer aux exigences réglementaires. |
| Proposition de test quantitatif de la CMA | En savoir plus sur la proposition de tests quantitatifs de la CMA | Nous collaborons avec la CMA pour concevoir des tests qui donneront un aperçu 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 ce à quoi vous attendre pendant la période de test et d'essai, suivis de conseils détaillés en juin. Nous vous encourageons à nous faire part directement de vos questions ou commentaires sur la proposition de tests quantitatifs de la CMA. |
| Modes de test facilités par Chrome | Informations supplémentaires et précisions sur les calendriers de test | Le 18 mai, nous avons publié un article de blog qui fournit plus d'informations sur les deux modes de test gérés par Chrome. Ces informations ne sont pas définitives. Nous publierons d'autres conseils d'implémentation au cours du troisième trimestre 2023. |
| Stockage partitionné | Le stockage partitionné sera-t-il utilisé lors des tests facilités par Chrome ? | Le partitionnement de l'espace de stockage sera déployé auprès de tous les utilisateurs avant le test de l'abandon des cookies tiers. Il sera donc activé pour tous les groupes de test. Pendant cette période, les sites pourront activer une phase d'évaluation d'abandon pour récupérer l'espace de stockage non partitionné. |
| Assistance de production | Quel est le processus en place pour que Chrome puisse gérer les problèmes techniques et les escalades de la Privacy Sandbox affectant l'écosystème ? | Google propose différents canaux pour permettre aux technologies publicitaires de signaler les problèmes et d'effectuer les escalades nécessaires. Pour en savoir plus sur les forums publics et privés destinés à envoyer des commentaires et à escalader des problèmes, consultez notre présentation des commentaires. |
| Calendrier d'inscription | Le délai actuel d'inscription est trop court | Nous évaluons toujours la date limite d'application et nous aimerions connaître l'avis de l'écosystème sur le calendrier le plus approprié. |
| Numéro DUNS | En savoir plus sur l'obligation de fournir un 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 selon le marché. Les participants doivent donc s'assurer de consulter le site Web du marché qui les intéresse. En général, cependant, les participants doivent fournir des informations de base sur leur entreprise, telles que son nom, son adresse et les coordonnées de son propriétaire ou de son responsable. Les participants peuvent également être invités à fournir des informations financières, telles que les revenus annuels de l'entreprise. Une fois la demande terminée, D&B l'examinera et vous enverra un numéro D-U-N-S si elle est approuvée. |
| Passer de la phase d'évaluation de l'origine à la disponibilité générale | La transition de la phase d'évaluation Origin vers la disponibilité générale aura-t-elle une incidence sur les testeurs actuels de la phase d'évaluation Origin ? | À partir de juillet, les testeurs pourront accéder aux API de pertinence et de mesure en disponibilité générale. Il y aura donc un chevauchement entre la disponibilité de la version d'essai de l'origine et la disponibilité générale. |
| Étude AdExchanger | En savoir plus sur la méthodologie d'enquête | Les personnes interrogées ont été invitées à estimer les taux de synchronisation et les revenus de leur entreprise. La méthodologie utilisée par les personnes interrogées pour répondre à leurs questions individuelles était à leur charge. |
| Valeurs de paramètres | Comment les valeurs de paramètres telles que le niveau de bruit, les seuils d'anonymat et le budget de confidentialité sont-elles déterminées ? | Cet article explicatif GitHub présente les principes plus généraux qui sous-tendent les API Privacy Sandbox. De nombreuses valeurs sont encore en cours de finalisation. N'hésitez pas à nous faire part de vos commentaires à ce sujet. |
Afficher des publicités et des contenus pertinents
Thèmes
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Protection de la confidentialité | Études évaluant l'API Topics en termes de protection de la confidentialité | Nous sommes activement impliqués dans la communauté de recherche et présentons 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 ravis de voir davantage de membres externes de la communauté de recherche s'intéresser à ce domaine. L'API Topics protège les utilisateurs contre le suivi général sur le Web en rendant le suivi des utilisateurs à grande échelle trop difficile. Ces articles montrent que nous y parvenons avec l'API Topics. Ils sont plus respectueux de la confidentialité que les cookies tiers, protègent les utilisateurs tout en soutenant les sites qu'ils aiment consulter. |
| Taxonomie des sujets pas assez détaillée | La taxonomie des thèmes généraux n'inclut pas les thèmes plus précis, y compris ceux spécifiques à une région. | En réponse aux commentaires précédents de l'écosystème, nous avons publié un article de blog le 15 juin détaillant une nouvelle taxonomie mise à jour qui intègre de nombreuses améliorations suite aux commentaires de l'écosystème. Dans le cadre de notre travail sur la taxonomie révisée, nous avons collaboré avec plusieurs entreprises de l'écosystème, telles que Raptive (anciennement CafeMedia) et Criteo. La nouvelle taxonomie supprime les catégories qui, selon nos informations, sont moins utiles, et les remplace par des catégories qui correspondent mieux aux centres d'intérêt des annonceurs, tout en respectant notre engagement d'exclure les sujets potentiellement sensibles. Nous encourageons l'écosystème à examiner la dernière taxonomie et à nous faire part de ses commentaires sur les modifications. |
| Processus de mise à jour de la taxonomie et du classificateur | En savoir plus sur la taxonomie Topics et la fréquence de publication des classificateurs, ainsi que sur la façon dont les entreprises peuvent se préparer à ces mises à jour | Comme indiqué dans notre récent article de blog, nous nous attendons à ce que la taxonomie évolue au fil du temps et que sa gouvernance soit finalement confiée à un tiers externe représentant les personnes concernées de l'ensemble du secteur. Nous avons également partagé le plan de déploiement dans le groupe topics-announce. |
| Impact sur les signaux first party | L'augmentation du nombre de thèmes dans la mise à jour récente de la taxonomie peut être très utile et, par conséquent, dévaloriser d'autres signaux propriétaires basés sur les centres d'intérêt. | Dans son rapport du premier trimestre 2023, la CMA a indiqué que "Google a discuté de sa nouvelle taxonomie proposée avec plusieurs acteurs du marché dans la chaîne d'approvisionnement de la technologie publicitaire. Bien que certains grands éditeurs aient indiqué qu'une plus grande utilité des thèmes augmenterait la pression concurrentielle sur leurs solutions basées sur les données first party, notre avis préliminaire est que plus l'utilité est grande, mieux c'est pour la concurrence dans son ensemble, 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 conforme à ce commentaire de la CMA. |
| Utilité pour différents types d'acteurs | Les technologies publicitaires qui jouent le rôle de SSP et de DSP peuvent présenter des avantages significatifs par rapport aux autres acteurs de l'écosystème. | Notre réponse n'a pas changé depuis les trimestres précédents: "Google s'est engagé auprès de la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en favorisant son propre activité, et à prendre en compte l'impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, quelle que soit leur taille. Nous continuons à travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. À mesure que les tests de la Privacy Sandbox avancent, l'une des questions clés que nous allons évaluer est la performance des nouvelles technologies pour différents types d'acteurs. Les commentaires sont essentiels à cet égard, en particulier ceux qui sont spécifiques et exploitables, qui peuvent nous aider à améliorer davantage les conceptions techniques. Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous encourageons la CMA à publier une note sur la conception des tests afin de fournir plus d'informations aux participants au marché et de leur 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 dans le navigateur, la fragmentation des segments entraînera-t-elle une absence de thèmes descendants dans les premiers résultats ? | Chrome évalue actuellement d'autres méthodologies de classement et explore d'autres signaux susceptibles d'améliorer le classement. Nous communiquerons nos nouveaux plans à l'écosystème en temps voulu. |
| Confidentialité | L'objectif de l'API Topics doit être de s'assurer que les informations utilisateur obtenues ou dérivées de l'API Topics sont moins sensibles sur le plan personnel que ce qui pourrait être dérivé à l'aide des méthodes de suivi actuelles. | Nous pensons que l'API Topics est beaucoup plus respectueuse de la confidentialité que les technologies actuelles, qu'elle limite considérablement la réidentification des utilisateurs et qu'elle est conçue pour exclure les sujets sensibles. Nous sommes conscients que les thèmes peuvent être corrélés ou combinés à des données first party pour créer des catégories sensibles. Toutefois, nous pensons que l'API Topics constitue un progrès en termes de confidentialité des utilisateurs, et nous nous engageons à continuer à l'améliorer. |
| Structure de la taxonomie | Ajouter un ID, une gestion des versions et d'autres structures de métadonnées à la taxonomie des sujets | Actuellement, nous incluons l'ID de taxonomie dans la réponse de l'API. À mesure que nous passons à une gouvernance à long terme, il est logique 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 de leurs sites. | Une mauvaise classification des sites peut rendre le signal Topics légèrement moins utile dans l'ensemble, mais les sites spécifiques mal classés ne sont pas plus ou moins affectés que les autres. En effet, les informations contextuelles d'un site sont toujours disponibles pour les enchères sur son site, ce qui fournit des informations comparables à celles du bon thème, même en cas de mauvaise classification. N'hésitez pas à nous faire part de vos commentaires à ce sujet ici. Autoriser les éditeurs à contrôler leur classification présente des risques. Les sites peuvent classer leurs sites de manière incorrecte de manière intentionnelle, ce qui réduit leur utilité pour tous, ou encoder des significations sensibles dans des sujets moins courants, ce qui nuit à la confidentialité des utilisateurs. |
| Extensions Chrome | Autoriser les extensions Chrome à gérer et filtrer les sujets, comme les extensions de gestion des cookies actuelles | Cela devrait déjà être possible, comme indiqué sur GitHub, mais nous sommes à l'écoute des commentaires supplémentaires de l'écosystème. |
| Passer à la disponibilité générale | L'API Topics sera-t-elle affectée lors de la transition de la phase d'évaluation à la disponibilité générale ? | Aucune donnée ne sera perdue pour les utilisateurs qui passent de la version bêta d'Origin à la version générale. |
| Confidentialité | Les noms d'hôte peuvent contenir des informations privées qui peuvent être révélées par l'API Topics | Nous avons mis en place un certain nombre de mesures d'atténuation pour protéger la confidentialité, comme indiqué ici. |
| Fraude et abus | Empêcher la manipulation des sujets par des visites frauduleuses | Cliquez ici pour en savoir plus sur les mesures d'atténuation. |
| Classificateur de thèmes | Les sites Web peuvent-ils demander à modifier leur classification par thèmes ? | Nous souhaitons recueillir l'avis de l'écosystème sur ce sujet et nous invitons à nous faire part de vos commentaires ici. |
| Sites des fournisseurs de thèmes | Désignez certains sites Web qui hébergent du contenu pour de nombreux thèmes comme "Sites de fournisseurs de thèmes spéciaux" et entraînez des classificateurs en fonction des balises fournies sur les pages Web. | Nous discutons de la proposition ici et nous attendons vos commentaires supplémentaires. |
API Protected Audience (anciennement FLEDGE)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Lissage du trafic | Impact des performances du filtrage basé sur l'SSP pour optimiser la charge en requêtes par seconde (RPS) | Nous avons beaucoup réfléchi à la gestion du trafic. Nous recommandons aux SSP de profiter du cache. |
| Volume de test | Il est difficile de tester Protected Audience, car les SSP et les DSP ont du mal à générer de grands volumes de trafic. | Nous collaborons en permanence avec nos partenaires SSP et DSP pour qu'ils adoptent et testent les audiences protégées. La disponibilité générale a commencé, et nous sommes convaincus que le pourcentage de trafic avec PA activé permettra aux partenaires de tester plus facilement cette fonctionnalité. |
| Complexité | L'implémentation de 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 collabore étroitement avec un large éventail d'acteurs pour les informer et les aider dans leurs efforts. Elle évalue en permanence d'autres accélérateurs pour favoriser 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 actuellement des options de compatibilité au-delà des solutions cloud, mais il n'est pas possible pour le moment de prendre en charge les TEE sur site, en raison des limites de sécurité sur site qui nécessiteraient une évaluation longue pour la Privacy Sandbox. Compte tenu des exigences de sécurité de la Privacy Sandbox et des défis importants que présentent les déploiements sur site, nous pensons que le développement et l'amélioration des déploiements cloud (par exemple, la prise en charge de GCP en plus d'AWS) sont les plus bénéfiques pour l'écosystème. Toutefois, nous acceptons d'autres commentaires sur les raisons pour lesquelles cette exigence est nécessaire. |
| Type de facturation | La proposition de services d'enchères et de mise aux enchères augmentera les coûts et la complexité pour les technologies publicitaires par rapport aux modèles côté client. | Nous développons actuellement un guide permettant d'estimer les coûts de prise en charge des workflows d'enchères et de mise aux enchères dans le serveur d'enchères et de mise aux enchères. Il sera corrélé à l'utilisation de la technologie publicitaire, ce qui répondra à l'un des objectifs de nos conceptions. |
| Chronologies K-Anon | Quand les contraintes de k-anonymat prévues seront-elles appliquées à "renderUrl" ? | Nous préparons une vidéo expliquant le calendrier d'application de cette mesure, que nous publierons prochainement. |
| Restrictions runAdAuction | Chrome peut-il limiter runAdAuction à être appelé uniquement depuis la page de premier niveau ? |
Bien que notre conception permette de faire appel à runAdAuction depuis la page principale, nous pensons qu'il serait plus dommageable pour les éditeurs de le limiter à un appel depuis le domaine principal.L'écosystème nous a indiqué spécifiquement que la Privacy Sandbox doit réduire au maximum la charge pour 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 à prescrire le fonctionnement des éditeurs et des technologies publicitaires. En permettant à l'éditeur de choisir comment et qui appelle runAdAuction sur son site, nous pensons lui offrir la flexibilité nécessaire pour trouver le meilleur chemin d'accès à ses exigences. |
| Assistance à l'implémentation | Chrome peut-il créer ou contribuer à une implémentation Open Source d'enchères multi-vendeurs ? | La Privacy Sandbox vise à développer des technologies protégeant la confidentialité qui ne dépendent pas des cookies tiers ni d'autres identifiants intersites. Nous souhaitons promouvoir un écosystème sain sans avoir à prescrire 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 créer d'implémentation spécifique, car notre mission principale est de créer des technologies de plate-forme, et non de dicter des stratégies d'utilisation de ces technologies. Nos technologies permettront aux entreprises de technologie publicitaire de mieux servir leurs clients en leur offrant les protections de confidentialité appropriées. |
| Enchères multivendeurs | Chrome force-t-il le partage d'un gagnant "contextuel" avec les enchères de composants ? | L'API Protected Audience est conçue pour permettre aux parties qui lancent l'enchère multivendeur de transmettre des informations à l'enchère des composants (remarque: uniquement avant de lancer l'enchère). Cela dit, nous ne voyons aucun moyen pour le navigateur de déterminer si une information est un gagnant contextuel ou non. Nous ne pouvons donc pas imposer le blocage ou l'obligation de fournir certaines informations. |
| Préférence de l'utilisateur pour le suivi du consentement | Adtech demande à l'autorité de protection des données comment implémenter correctement le suivi du consentement des utilisateurs | Notre réponse inclut ce que nous avons indiqué dans la question 1: "Pour les annonces spécifiques, la technologie publicitaire concernée est la partie la mieux placée pour contrôler les créations diffusées ou la manière dont elles sont sélectionnées." Nous avons discuté de plusieurs scénarios liés à ce problème lors de la réunion du groupe de travail WICG sur l'audience protégée de mai. Nous sommes à l'écoute de vos commentaires et de vos discussions sur ce problème. |
| 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 autres fournisseurs de technologie publicitaire de posséder et de gérer des audiences personnalisées. Des conseils supplémentaires sur la façon dont un SSP peut intégrer l'API PA sont en cours de développement et seront mis à la disposition des SSP et des autres fournisseurs de technologies publicitaires pour les aider dans leurs efforts d'intégration. |
| Formats | La vidéo est-elle compatible avec l'API Protected Audience ? | Les annonces vidéo sont diffusées de deux manières: au format XML VAST ou HTML (une annonce OutStream qui peut également charger du code XML VAST dans un lecteur vidéo). Les acheteurs peuvent renvoyer l'un ou l'autre format via une URL de rendu. La spécification VAST a été récemment mise à jour pour prendre en charge l'API Attribution Reporting. Les sites diffusant des annonces vidéo devront se préparer à la façon dont les annonces seront diffusées via l'API Protected Audience. Cela signifie que vous devez vous assurer que les tags d'emplacement peuvent transmettre l'URL d'un iframe Protected Audience à un lecteur vidéo. Pour les écrans délimités, nous nous efforcerons de répondre aux besoins des vidéos avant l'obligation d'utiliser ces écrans, qui n'interviendra pas avant 2026. |
| Rythme | Comment fonctionne le cas d'utilisation de la régulation de la diffusion avec l'API Protected Audience ? | Nous vous remercions de vos commentaires. Nous aimerions recevoir davantage de demandes de ce type avec plus de détails de la part de davantage de partenaires SSP, car jusqu'à présent, ce problème concernait principalement les DSP. |
| Fréquence de mise à jour | La fréquence des appels de dailyUpdate (un appel par groupe de centres d'intérêt et par jour maximum) peut ne pas être suffisante pour certains cas d'utilisation, comme la mise à jour des informations sur les produits. |
Nous vous remercions de vos commentaires. D'autres solutions sont disponibles pour permettre aux technologies publicitaires d'utiliser des signaux actualisés à différentes fréquences, comme les recherches de clés-valeurs. |
| Contrôle de la qualité des annonces | Comment les éditeurs mettent-ils en place un contrôle de la qualité des annonces ? | Aujourd'hui, l'API Protected Audience permet aux éditeurs d'informer leurs SSP sur certaines commandes qu'ils peuvent définir dans la configuration des enchères, les enchères préalables (par exemple, 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 dont l'écosystème pourrait avoir besoin. |
| 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 forDebuggingOnly pour les événements de victoire au plus tôt en 2026. |
| Groupes de centres d'intérêt inter-appareils | Proposition d'activation des groupes de centres d'intérêt inter-appareils pour les agents utilisateur authentifiés | Nous évaluons cette proposition, mais la forte spécificité du ciblage inter-appareils pose des problèmes de confidentialité importants, comme indiqué dans ce problème GitHub. |
| (également indiqué au T1) Remarketing dynamique | 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. |
| Cliquez sur "Données associées". | Ajouter des données liées aux clics à browserSignals. |
Nous demandons actuellement des précisions sur le moment où le clic s'est produit afin de vous donner une position préliminaire. |
| (Signalé également 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 ? Il s'agit de fonctions pouvant être programmées par les utilisateurs finaux pour étendre les fonctionnalités de l'API. | La technologie publicitaire à l'origine de ce problème a également indiqué qu'elle évaluait toujours ce qu'elle pouvait faire avec les fonctions définies par l'utilisateur. Il n'y a donc pas encore de commentaires pratiques à prendre en compte, pas avant la disponibilité générale. |
| Devise | Les montants en devise ne doivent pas être représentés à l'aide de virgules flottantes. | Nous avons abordé ce problème en détail ici. |
| Fonctionnalités de sélection des annonces autres que les DSP | Quel est le rôle des ad servers dans les enchères de l'API Protected Audience ? | Nous sommes conscients des demandes des ad servers de continuer à proposer des services de sélection d'annonces post-enchères et d'optimisation de créations dynamiques. Nous évaluons actuellement l'analyse détaillée des écarts entre l'API Protected Audience actuelle et ces demandes. |
| GenerateBid | Prise en charge de la proposition de Google Ads consistant à renvoyer plusieurs annonces candidates par groupe d'intérêts publicitaires à partir de generateBid et à évaluer ces annonces candidates dans "scoreAd". |
Nous évaluons actuellement cette possibilité. N'hésitez pas à nous envoyer d'autres commentaires ici. |
| Ordre d'enchères | Les enchères de l'API Protected Audience doivent-elles être les dernières à s'exécuter afin qu'elles puissent prendre en compte le résultat de toutes les autres enchères ? | Il n'est pas nécessaire que l'API Protected Audience s'exécute en dernier. |
| Navigation non déclenchée par l'utilisateur | Exposer la navigation non déclenchée par l'utilisateur | Nous examinons cette demande et en discutons ici . N'hésitez pas à nous faire part de vos commentaires supplémentaires. |
| Mise en cache | Le SSP ne doit pas créer les perBuyerSignals d'un DSP donné à 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 évaluons d'autres options. Nous sommes à l'écoute de tout commentaire supplémentaire de l'écosystème sur la question de savoir si le cache fonctionnerait pour leurs cas d'utilisation. |
| Attribution Reporting et Protected Audience | Comment l'API Attribution Reporting et l'API Protected Audience peuvent-elles fonctionner ensemble ? | Les 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). Nous avons fourni plus d'informations sur l'amélioration de l'intégration de l'API Protected Audience et d'Attribution Reporting le 1er juin. Cliquez ici pour en savoir plus. |
| Point de terminaison du serveur | Le point de terminaison du serveur sera-t-il le serveur d'agrégation approuvé dans la conception finale ? | Le point de terminaison du serveur est un point de terminaison géré par la technologie publicitaire, indépendant des serveurs d'agrégation approuvés 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 à s'assurer que les rapports agrégables eux-mêmes (avec des charges utiles chiffrées) ne fuient pas de données intersites. Un point de terminaison fiable ne devrait donc pas être nécessaire. Autre complication : les différentes technologies publicitaires ont probablement des stratégies de traitement par lot différentes. N'hésitez pas à nous envoyer d'autres commentaires ici. |
| 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 transfert du signal de consentement sera-t-il géré dans l'API Protected Audience ? | Les informations contextuelles ne relèvent pas du champ d'application de l'API Protected Audience. Nous examinons ce problème et nous serons ravis de recevoir d'autres commentaires. |
| Marketing basé sur les comptes | Les cas d'utilisation du marketing par compte seraient-ils possibles ? | L'API Protected Audience est compatible avec différents cas d'utilisation du marketing basé sur l'audience. Nous continuons à comprendre comment l'API Protected Audience peut le mieux prendre en charge ce cas d'utilisation particulier. Nous sommes à l'écoute de vos commentaires supplémentaires sur ce problème. |
| Enchères de composants | Quel est le score des participants aux enchères de composants ? | Les enchères des composants n'évaluent pas directement les groupes de centres d'intérêt, mais plutôt les annonces et les enchères qu'une DSP envoie à partir de la fonction generateBid. La fonction generateBid() s'exécute par groupe de centres d'intérêt, et la DSP renvoie ce qui suit 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'acceptation des contributions externes au code source GitHub du serveur de clés-valeurs. | Nous souhaitons 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 prendre en charge ? | La limite actuelle est de 50 ko pour la taille d'un IG, et les clés sont incluses dans cette limite. Nous sommes à votre disposition pour discuter de la limite de taille. |
| Traitement par lot | Comment réduire le nombre d'appels au serveur K/V ? | Vous pouvez utiliser les en-têtes HTTP Cache-Control pour réduire le nombre d'appels K/V. Par exemple, il peut être mis en cache pour les enchères de composants, ainsi que pour 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 seront compatibles avec plusieurs versions du code de technologie publicitaire. Dans l'API d'enchères et de mise aux enchères, la requête SelectAd peut spécifier la version du code utilisée pour la requête d'enchères (c'est-à-dire pour les enchères et les rapports). |
| Stockage partagé | Prise en charge de l'écriture dans le stockage partagé dans le service d'enchères et de mise aux enchères. | Pour le moment, les services d'enchères ne sont pas compatibles avec le stockage partagé, mais nous vous invitons à nous faire part de commentaires supplémentaires sur l'importance de ces cas d'utilisation pour l'écosystème. |
| Web-to-app | Prise en charge du partage de groupes d'intérêt entre le Web et l'application. | Le transfert Web vers une application n'est actuellement pas inclus dans le déploiement de l'API Protected Audience dans Chrome et Android, mais nous aimerions connaître l'avis de l'écosystème sur l'importance de ce cas d'utilisation. |
| K-anonymat | Gérer les chemins à afficher de remplacement pour le k-anonymat | Nous examinons le problème et nous serons ravis de recevoir d'autres commentaires. |
Mesurer les annonces numériques
Attribution Reporting (et d'autres API)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Autres configurations de rapports au niveau des événements de la vidéoconférence | Commentaires sur les configurations de rapports au niveau des événements pour les VTC alternatives | Nous avons reçu des commentaires selon lesquels les configurations actuelles au niveau des événements ne sont pas optimales. Nous vous demandons donc de nous faire part de vos commentaires sur les configurations globales optimales. Nous sommes à l'écoute de vos commentaires supplémentaires à ce sujet et pensons que notre explication flexible au niveau des événements vous aidera également à y répondre. |
| Configurations flexibles au niveau des événements | Quel est l'état de la fonctionnalité de configuration flexible au niveau des événements ? | Nous avons partagé des documents sur la configuration flexible au niveau des événements. Cette fonctionnalité est encore au stade de proposition. Nous souhaitons connaître votre avis sur son utilité pour l'écosystème. |
| Configurations flexibles au niveau des événements | Comment concilier les rapports contradictoires de différentes parties ? | La plupart des scénarios de création de rapports sont gérés à l'aide de rapports agrégables, tandis que la proposition de configuration flexible au niveau des événements est spécifiquement destinée à offrir 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 vos commentaires concernant ce scénario. |
| Enregistrement de la source | Que se passe-t-il si l'enregistrement de la source se produit après l'enregistrement du déclencheur ? | Actuellement, si un enregistrement de 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 cas particulier. N'hésitez pas à nous faire part de vos commentaires supplémentaires concernant ce problème. Nous nous efforcerons de le résoudre si de nombreuses technologies publicitaires semblent y être confrontées. |
| Travailler avec plusieurs agences publicitaires | Comment les DSP peuvent-elles utiliser l'API Attribution Reporting lorsqu'un annonceur travaille avec plusieurs agences publicitaires ? | L'API est compatible avec les redirections et peut donc être utilisée même si un annonceur travaille avec plusieurs agences publicitaires. De plus, certaines restrictions s'appliquent aux redirections afin de s'assurer que l'API améliore la confidentialité. Nous avons également identifié une solution de contournement potentielle à l'aide de l'API Shared Storage pour le scénario spécifique soulevé par la technologie publicitaire. N'hésitez pas à nous faire part de vos commentaires supplémentaires concernant ce scénario. Nous continuerons d'apporter des améliorations en fonction de ces commentaires. |
| Limites de destination | Les limites de destination peuvent avoir un impact sur le cas d'utilisation des annonces à actualisation automatique. | Nous avons discuté de ce problème lors de la réunion du groupe de travail WICG du 1er mai et nous recherchons des commentaires sur une limite raisonnable. Nous avons ajouté à la présentation d'Attribution Reporting avec les rapports au niveau des événements que le navigateur peut limiter le nombre d'eTLD+1 de destination représentés par les sites sources. (voir demande de fusion). |
| Attribution Reporting et Protected Audience | Comment l'API Attribution Reporting et l'API Protected Audience peuvent-elles fonctionner ensemble ? | Les 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). Nous avons fourni plus d'informations sur l'amélioration de l'intégration de l'API Protected Audience et d'Attribution Reporting le 1er juin. Cliquez ici pour en savoir plus. |
| Configurations flexibles au niveau des événements | Partagez les bonnes pratiques de simulation du bruit maintenant que les paramètres sont configurables. | Nous avons partagé du code sur GitHub que tout le monde peut utiliser pour évaluer le gain d'informations et l'impact du bruit pour toutes les configurations flexibles au niveau des événements qu'il souhaite tester. Nous serions ravis de connaître l'avis de toute personne qui choisira de tester le code. |
| Mesure de l'attribution entre applications et Web | Quand la mesure de l'attribution entre applications et Web sera-t-elle disponible ? | Le 9 mai, nous avons annoncé un test de mesure de l'attribution entre les applications et le Web via l'API Attribution Reporting. La disponibilité générale est prévue pour les API de pertinence et de mesure dans Chrome 115, mais la mesure de l'attribution entre les applications et le Web ne sera pas disponible pour tous les utilisateurs avec Chrome 115. |
| Dédupliquer les conversions | Comment les solutions de mesure indépendantes peuvent-elles être conciliées avec l'ARA ? | Comme c'est actuellement la pratique standard, les annonceurs doivent faire appel à un fournisseur de solutions de mesure tiers indépendant pour dédupliquer les rapports sur les conversions. Nous avons fourni des ressources pour dédupliquer les conversions afin de créer des rapports au niveau des événements. |
| Perte de données lors des mises à jour de la base de données des rapports sur l'attribution | Des données seront-elles perdues lorsque Chrome mettra à jour la base de données de rapports sur l'attribution, comme annoncé ? | À partir de Chrome 115 stable, nous commencerons à activer les API de pertinence et de mesure par défaut pour une partie des utilisateurs de Chrome. Cette disponibilité générale sera étendue à mesure que nous surveillerons les problèmes potentiels. L'objectif est d'atteindre une disponibilité de 100% sur une période de plusieurs semaines, d'ici le troisième trimestre 2023. Cette date coïncide avec la fin de l'essai sur l'origine de la pertinence et des mesures. À partir de juillet, les testeurs pourront s'inscrire pour accéder à ces API en disponibilité générale. Cela permettra de chevaucher la période de disponibilité de l'essai d'origine et la disponibilité générale via l'inscription. Votre jeton d'essai d'origine sera valide jusqu'au 19 septembre, mais nous vous recommandons de vous inscrire aux API avant cette date afin de quitter facilement l'essai d'origine sans interrompre les tests en cours. Comme indiqué dans cette annonce, les données enregistrées à partir d'anciennes versions (M113 et versions antérieures) ne seront pas migrées après la mise à jour. Il est donc possible que des données soient perdues. Cette perte de données ne s'affichera pas dans les rapports de débogage. Nous allons essayer d'éviter la perte de données entre 114 et 115. |
| Facturation | Utiliser les rapports sur l'attribution 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 au niveau des événements et aux rapports récapitulatifs. Nous encourageons les acteurs de l'écosystème à partager leurs commentaires sur l'impact de l'API Attribution Reporting sur différents modèles de facturation sur GitHub. |
Service d'agrégation
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Modification du délai des rapports agrégables | Réactions positives à la proposition de modifier le délai de génération des rapports agrégables de [10-60 min] à [0-10 min] suite aux commentaires de l'écosystème | Nous sommes ravis de constater que la proposition de modification a été bien accueillie et nous encourageons l'écosystème à continuer à nous faire part de ses commentaires. |
| Solution sur site | Le service d'agrégation peut-il être déployé dans des centres de données sur site ? | Nous étudions actuellement des options de compatibilité au-delà des solutions cloud, mais il n'est pas possible pour le moment de prendre en charge les TEE sur site, en raison des limites de sécurité sur site qui nécessiteraient une évaluation longue pour la Privacy Sandbox. Compte tenu des exigences de sécurité de la Privacy Sandbox et des défis importants que présentent les déploiements sur site, nous pensons que le développement et l'amélioration des déploiements cloud (par exemple, la prise en charge de GCP en plus d'AWS) sont les plus bénéfiques pour l'écosystème. Toutefois, nous acceptons d'autres commentaires sur les raisons pour lesquelles cette exigence est nécessaire. |
| Retraitrer des rapports pour différentes périodes | Possibilité de retraiter des rapports pour différentes périodes | Nous avons reçu des demandes similaires pour pouvoir diviser les lots en fonction de différentes périodes. 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 sommes encore en train d'évaluer ce processus et nous tiendrons l'écosystème informé au fur et à mesure de l'évolution de cette proposition. |
| Implications de l'environnement d'exécution sécurisé en termes de confidentialité | Opinion positive sur les implications de la confidentialité des environnements d'exécution sécurisés | Nous sommes ravis de constater que l'écosystème a réagi positivement à nos propositions. Nous attendons avec impatience vos commentaires supplémentaires pour continuer à itérer et à développer nos idées. |
| Conditions d'utilisation | À quelle date devez-vous accepter les conditions d'utilisation du service d'agrégation ? | Nous n'avons pas encore spécifié de date limite pour accepter les conditions d'utilisation, mais nous encourageons les entreprises de l'écosystème à les accepter dès que possible afin d'éviter tout retard d'inscription. Nous encourageons les entreprises à nous contacter si elles ont des questions. |
| Découverte de clés | La fonctionnalité de découverte de clés permettra aux testeurs d'interroger des rapports agrégés sans avoir besoin de la liste explicite des combinaisons de touches possibles afin de traiter les rapports récapitulatifs pour l'attribution multiréseau afin d'améliorer les performances et la précision. | Nous étudions actuellement les solutions et les solutions de contournement possibles, et nous accueillons les commentaires supplémentaires de l'écosystème. |
API Private Aggregation
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Origine du signalement | Comment l'origine des rapports est-elle définie ? | L'origine des rapports est toujours l'origine du script de l'appelant de l'agrégation privée. |
| Espace de clés 128 bits | Clarification concernant la limite de l'espace de clés 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 diviser les rapports plutôt que de les couper à la limite. Nous solliciterons l'écosystème au fur et à mesure que cette proposition évoluera. |
| Rapports sur la couverture | Demande de rapports sur la couverture multiplate-forme/multi-appareil. La couverture est une métrique fondamentale de la publicité axée sur la marque. Les annonceurs s'appuient sur des approximations multiplates-formes/multiappareils pour les rapports sur la couverture et la fréquence afin d'analyser leurs campagnes et d'allouer leurs 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 solution de remplacement une fois que les cookies tiers seront abandonnés. |
L'équipe Privacy Sandbox étudie des fonctionnalités permettant de prendre en charge les méthodologies de couverture multidomaine après l'abandon des cookies tiers. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème. |
Limiter le suivi dissimulé
Réduction de l'User-Agent/Hints client User-Agent
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également indiqué au 1er trimestre 2023) Conseils pour d'autres facteurs de forme | Demande d'User-Agent Client Hints (UA-CH) pour fournir des facteurs de forme supplémentaires tels que la télévision et la réalité virtuelle | Nous travaillons toujours sur certaines décisions de conception clés (fournir une valeur unique telle que "TV" ou une liste de fonctionnalités de facteur de forme), mais nous restons intéressés par le prototypage de cette idée. |
| Privacy Budget | Les restrictions liées au budget de confidentialité peuvent entraîner une non-déterminisme des requêtes UA-CH lorsqu'un nombre trop important de requêtes est envoyé. | Nous n'avons pas de nouvelles concernant la proposition de budget de confidentialité pour le moment, mais nous nous sommes engagés à ne pas limiter les demandes d'indices client UA avant l'abandon des cookies tiers. |
| Compatibilité du site | Les sites Web utilisent la marque UA-CH pour empêcher certains navigateurs d'accéder à leurs sites. | Il existe des cas d'utilisation valides pour une liste de marques, dont la compatibilité. Une UA peut avoir plusieurs marques pour contourner ces problèmes. |
Protection IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Fraude et utilisation abusive | Comment les entreprises peuvent-elles mettre en place des mesures antifraude avec la protection de l'adresse IP ? | Nous sommes conscients de l'importance des cas d'utilisation de la lutte contre la fraude et de l'impact potentiel de ces cas d'utilisation. Nous prévoyons de publier plus d'informations sur la lutte contre la fraude dans le courant de l'été. Nous souhaitons recueillir les commentaires de l'écosystème pour mieux répondre aux cas d'utilisation de la lutte contre la fraude. |
| GeoIP | En savoir plus sur le calendrier de test et de déploiement de GeoIP | Chrome a récemment publié de nouvelles informations sur nos plans concernant les adresses IP géographiques. Nous prévoyons de publier d'autres informations sur les délais de déploiement au troisième trimestre. Nous prévoyons de lancer la protection des adresses IP en tant que fonctionnalité nécessitant l'activation par l'utilisateur pour un petit pourcentage du trafic dans un premier temps. En effet, nous sommes conscients que cette proposition peut impliquer 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 la fonctionnalité plus largement. |
| Authentification du compte | Comment se passe exactement l'authentification du compte avec le serveur proxy ? | Nous prévoyons de publier plus d'informations sur l'authentification des comptes dans le courant de l'été, mais nous avons déjà partagé quelques considérations initiales. |
Atténuation du suivi des rebonds
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Conseils de test | Informations sur le test de la mesure d'atténuation du suivi des rebonds | En mai, nous avons publié un article de blog qui vous explique comment tester la mesure d'atténuation du suivi des rebonds. |
| Documentation | Clarification de la proposition de suivi des rebonds | La proposition actuelle est en cours de développement, et Chrome continue de la mettre à jour pour clarifier et informer l'écosystème. Nous mettons tout en œuvre pour vous fournir plus d'informations et nous serons ravis de recevoir vos commentaires supplémentaires. |
| Suppression des cookies | La fonctionnalité de mitigation du suivi des rebonds supprime-t-elle tous les cookies d'un domaine ? | La mitigation du suivi des rebonds (BTM) efface tout l'espace de stockage et tout le cache, comme expliqué ici. |
| Contourner la mesure d'atténuation du suivi des rebonds | La classification du traceur de rebond peut être contournée en effectuant des redirections avec des pop-ups ou de nouveaux onglets. | La spécification sur l'atténuation du suivi des rebonds est toujours en cours de développement. Nous nous sommes principalement concentrés sur les redirections dans le même onglet jusqu'à présent, mais nous prévoyons de travailler sur les flux de pop-ups à l'avenir. N'hésitez pas à nous envoyer d'autres commentaires ici. |
Privacy Budget
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Ciblage de proximité | Le budget de confidentialité peut avoir un impact sur les cas d'utilisation du ciblage par proximité. | Nous avons reçu des commentaires sur ce problème et aimerions en savoir plus sur les impacts potentiels sur l'écosystème. |
Prévention du suivi intersites pour améliorer la confidentialité
Ensembles propriétaires
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| (également indiqué dans les trimestres précédents) Limite de domaines | Demande d'augmentation du nombre de domaines associés | Chrome évalue la limite numérique appropriée pour le sous-ensemble associé, qui équilibre la confidentialité et l'utilité pour les cas d'utilisation identifiés. Dès le début, Chrome a indiqué 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 qui nécessitent des ensembles propriétaires, des CHIP et un espace de stockage partagé | Chrome a bien reçu les commentaires sur ce cas d'utilisation. L'équipe étudie la question et est à l'écoute de autres commentaires. |
| Gestion des dépôts | Informations sur les règles de suppression des ensembles propriétaires du dépôt GitHub en cas de divergences ou de négligence | Chrome a bien reçu les commentaires sur ce cas d'utilisation. L'équipe étudie le problème et apprécie les commentaires supplémentaires. |
| Formation des utilisateurs | Chrome doit sensibiliser les utilisateurs et leur expliquer les ensembles propriétaires pour favoriser leur adoption. | Chrome s'engage à informer les utilisateurs sur les ensembles propriétaires. À cet effet, il a publié un article du centre d'aide (accessible depuis l'interface utilisateur de Chrome). Chrome s'efforce également de continuer à apprendre comment mieux informer les utilisateurs dans les contextes appropriés. |
| Post 3PCD | Les cookies tiers continueront d'exister dans un ensemble propriétaire après l'abandon des cookies tiers. | Bien que requestStorageAccess et requestStorageAccessFor rendent effectivement les cookies tiers disponibles à nouveau pour des cas d'utilisation spécifiques et clairement définis, ils nécessitent désormais une invocation active par le site, au lieu d'être disponibles par défaut, comme c'est actuellement le cas pour les cookies tiers (dans Chrome).Bien que cette invocation dans un seul ensemble ne nécessite pas l'approbation de l'utilisateur, les utilisateurs peuvent l'empêcher en désactivant ce comportement dans les paramètres. Pour en savoir plus, consultez l'article du centre d'aide (accessible depuis l'interface utilisateur de Chrome). Nous prévoyons d'étendre le guide du développeur existant à mesure que les FPS augmenteront jusqu'à 100%. |
| Envoi des ensembles propriétaires | Renommez le .well-known/first-party-set requis pour qu'il inclue une extension .json. |
Nous avons apporté ce changement pour nous assurer que certains forfaits d'hébergement Web sont compatibles. |
| Enregistrement IANA | first_party_sets.JSON doit être enregistré auprès de l'IANA. |
Nous examinons cette proposition et nous vous invitons à nous faire part de vos commentaires supplémentaires ici. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Blocage des annonces | Les cadres délimités peuvent faciliter le blocage des annonces par les bloqueurs de publicité. | Les extensions peuvent interagir avec les Fenced Frames de la même manière qu'elles le feraient avec les iFrames. L'URL réelle vers laquelle le frame clôturé est sur le point d'être redirigé sera également visible par les extensions. Elles peuvent donc appliquer des règles de correspondance d'URL pour le blocage, comme elles le feraient dans les iFrames. Bloquer simplement tous les cadres délimités sans condition peut entraîner des problèmes dans les cas d'utilisation autres que les annonces des cadres délimités. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Adoption plus large | Le stockage partagé doit être une norme du secteur, disponible dans tous les navigateurs. | Nous vous remercions de nous avoir fait part de vos commentaires. Chrome continue de participer activement aux forums du W3C pour promouvoir la proposition, recueillir des commentaires et favoriser son adoption. |
| Portes de sortie | Les sorties de stockage partagé sont trop limitées. | Nous prenons en compte ces commentaires et nous serons ravis de recevoir d'autres commentaires de l'écosystème sur les raisons pour lesquelles les portes de sortie sont trop limitées. |
| Conformité vis-à-vis des réglementations | Comment Shared Storage gérera-t-il la conformité aux réglementations, telles que les règles de conservation des données ? | Shared Storage offre la flexibilité nécessaire pour implémenter et personnaliser une logique permettant 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 codes temporels d'écriture. |
| Tests A/B | Comment effectuer des tests A/B pour l'API Shared Storage et Protected Audience ? | Nous travaillons actuellement à la publication d'informations supplémentaires à ce sujet et nous espérons vous en dire plus à l'avenir. |
| Limite de stockage partagé | Que se passe-t-il lorsque la limite de stockage partagé est atteinte ? | Si la limite est atteinte, aucune autre entrée n'est stockée. |
| Plusieurs accès au même chargement de page | Que se passe-t-il lorsque le stockage partagé est consulté plusieurs fois lors d'un même chargement de page ? | Le meilleur moyen de gérer cela est d'utiliser la fonction window.sharedStorage.append(key, value). au lieu de mettre à jour la valeur pour chaque annonce, ce qui pourrait entraîner des conflits en cas de présence de plusieurs annonces. La fonction d'ajout ajoute simplement la nouvelle valeur à la fin de l'ancienne. |
| Fonctionnalités des iFrames | Shared Storage sera-t-il compatible avec certaines fonctionnalités d'iFrame une fois qu'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 elles-mêmes ne seront pas bloquées. Les données du stockage local d'un iframe ne peuvent pas être répliquées sur plusieurs sites de niveau supérieur, mais le stockage local peut toujours être utilisé dans l'iframe. |
CHIPs
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Limite de partition | 10 ko par site partitionné est encore important. Nous aimerions que ce nombre soit réduit. | Firefox a déjà indiqué une position positive sur CHIPS. Pour obtenir de l'aide concernant Webkit, nous encourageons les développeurs à envoyer directement leurs commentaires à Apple concernant ce problème GitHub concernant leurs cas d'utilisation où les cookies partitionnés sont préférés au stockage partitionné. |
| Intégrations authentifiées | Les chips peuvent avoir un impact sur le flux de connexion SSO actuel en raison d'une partitionnement différente qui affecte les éléments intégrés authentifiés. | Nous prévoyons d'utiliser l'API Storage Access (avec des invites utilisateur) pour prendre en charge le cas d'utilisation des éléments intégrés authentifiés. Nous avons récemment envoyé un intent-to-prototype. |
| Règles de durée de vie | Les règles de durée de vie potentielles s'appliqueront-elles aux cookies propriétaires ? | Pour le moment, nous n'avons pas l'intention d'imposer de limite de durée de vie aux cookies propriétaires. |
FedCM
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Compatibilité avec l'autorisation OAuth | Adéquation avec l'autorisation des champs d'application OAuth autres que les profils | Nous sollicitons activement les commentaires de la communauté Web Identity via le groupe de travail FedID du W3C sur les meilleurs moyens d'accepter l'autorisation au-delà de l'authentification de base après l'abandon des cookies tiers. |
| Compatibilité avec SAML | Respecter les exigences de compatibilité avec SAML | L'équipe recherche activement des commentaires de la part des communautés de recherche et d'enseignement sur les besoins de compatibilité avec SAML (en plus de la compatibilité avec OpenID Connect) après l'abandon des cookies tiers. |
Lutter contre le spam et la fraude
API Private State Tokens (et autres API)
| Thème des commentaires | Résumé | Réponse de Chrome |
|---|---|---|
| Explorer de nouveaux signaux | Plusieurs partenaires ont exprimé leur intérêt pour l'exploration des signaux d'intégrité de l'appareil ou de confiance des utilisateurs, facilités par le navigateur. De manière générale, ils sont également sceptiques quant à la capacité des nouveaux signaux dédiés à maintenir les niveaux actuels de détection des fraudes. | Nous sommes ravis d'explorer de nouvelles propositions avec la communauté de lutte contre la fraude et la sécurité du Web, et de prendre en compte et de partager ses préoccupations. C'est précisément pour cette raison que la lutte contre le spam et la fraude a été un axe de travail essentiel de la Privacy Sandbox, et que nous continuons de donner la priorité aux investissements visant à préserver la sécurité du Web tout en améliorant la confidentialité des utilisateurs. |
| Commentaires positifs sur PST | Plusieurs partenaires ont exprimé leur intérêt à tester ou à utiliser des PST pour différents cas d'utilisation de lutte contre la fraude ou de sécurité Web. | Nous sommes ravis de constater que vous êtes intéressés par l'exploration de nouvelles solutions utilisant des PST. Des ressources et des exemples de code sont disponibles sur le site pour les développeurs Chrome. N'hésitez pas à nous faire part de vos commentaires. |
| Fraude et abus | Conseils pour la prévention / la détection 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é, qui permettent de récupérer une partie du signal perdu 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 afin de préserver les fonctionnalités avec d'autres modifications de la Privacy Sandbox. |
| Taux d'informations de l'émetteur sur l'origine | Le taux d'informations de l'émetteur à l'origine est suffisamment élevé pour identifier les utilisateurs uniques. | Nous avons mis à jour la spécification pour indiquer plus clairement quelles données utilisateur peuvent être transmises à l'aide de jetons d'état privés. Par conception, jusqu'à six clés publiques peuvent être utilisées à 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 de clé d'urgence est nécessaire), ce qui ralentit la possibilité de joindre des données utilisateur supplémentaires au fil du temps. Avec toute nouvelle API Web, il existe un équilibre entre l'utilité fournie et les nouvelles informations utilisateur nettes qu'elle fournit. Nous estimons que les PST permettent de trouver le juste équilibre entre la protection de la confidentialité des utilisateurs et l'activation des principaux cas d'utilisation de la lutte contre la fraude affectés par l'abandon des cookies tiers. |
| Intégration de Fetch | L'intégration de fetch est complexe et inutile. |
L'utilisation de fetch présente des avantages et des inconvénients. Nous aimerions poursuivre la standardisation dans l'écosystème Web, mais nous pensons qu'il serait trop tôt pour effectuer ce changement tant que nous n'avons pas une idée plus claire de la norme. Si et quand une norme apparaîtra, nous nous engageons également à la faire adopter de manière responsable par les développeurs Web. |
| Emplacement de stockage | Les configurations de clé des jetons d'état privé doivent être stockées au même emplacement que le protocole PrivacyPass. | Lors des tests effectués pendant le test Origin, 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é dans PrivacyPass n'est pas particulièrement adapté à une version où les ensembles de clés sont destinés à permettre une valeur "métadonnées publiques" implicite. Si une variante de PrivacyPass finit par être normalisée avec des métadonnées publiques (en tant que POPRF, aveuglage RSA partiel ou ensembles de clés), nous pourrions passer à une future version de PST pour la prendre en charge. |
| Implémentation de l'API dans l'en-tête | Questions concernant l'implémentation de l'en-tête de l'API | À mesure que l'API sera standardisée et que l'utilisation de l'écosystème de cette API évoluera, nous espérons pouvoir prendre en charge à la fois la version standard sans en-tête de cette API et éventuellement abandonner la version avec en-tête si l'utilisation est suffisamment faible ou si les outils/l'assistance pour les développeurs sont suffisants pour les méthodes standards de mise en corrélation des demandes d'émission/d'utilisation avec d'autres données. Nous en discutons ici. |
| Inscription | Est-il pratique d'obliger les émetteurs à s'inscrire auprès des fournisseurs de navigateurs ? | Nous avons mis à jour la spécification pour décrire le processus d'enregistrement de l'émetteur pour les jetons d'état privés. Bien qu'il utilise son propre processus, il est semblable aux plans d'inscription pour le reste du travail de la Privacy Sandbox, où nous demandons aux émetteurs de faire une déclaration publique sur la façon dont ils prévoient d'utiliser les PST et de reconnaître les restrictions techniques qui protègent la confidentialité des utilisateurs. |