Rapport trimestriel pour le 2e trimestre 2023 résumant les commentaires reçus par l'écosystème sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Dans le cadre de ses engagements envers la CMA, Google a accepté de fournir publiquement des rapports trimestriels sur le processus d'engagement des parties prenantes pour ses propositions de la Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des Engagements). Ces rapports récapitulatifs des commentaires de la Privacy Sandbox sont générés en regroupant les commentaires reçus par Chrome à partir des différentes sources, comme indiqué dans la présentation des commentaires, y compris, mais sans s'y limiter, les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les acteurs du secteur et les forums sur les normes Web. Chrome se félicite des commentaires reçus de l'écosystème et recherche activement des moyens d'intégrer les enseignements tirés dans les décisions de conception.
Les thèmes de commentaires sont classés par prévalence par API. Pour ce faire, nous regroupons les commentaires reçus par l'équipe Chrome sur un thème donné et les classons par ordre décroissant de quantité. Les thèmes de commentaires courants ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquemment posées par les équipes internes de Google et dans des formulaires publics.
Plus précisément, les comptes-rendus des réunions des organes standards Web ont été examinés et, en vue de recueillir des commentaires directs, les enregistrements des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires public ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation afin de déterminer la prévalence relative des thèmes émergents pour chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles apportées aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifiquement pour cet exercice de reporting public. Compte tenu de l'intérêt actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Protected Audience et Attribution Reporting.
Il est possible que les commentaires reçus après la fin de la période de référence en cours ne soient pas encore pris en compte dans la réponse Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Federated Credential Management
- Lecteur d'empreinte digitale
- Ensembles internes
- IAB
- l'Interactive Advertising Bureau
- IdP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- ML
- Adresse IP (Internet Protocol)
- openRTB
- Enchères en temps réel
- Prolongation
- Phase d'évaluation
- PatCG
- Groupe de la communauté des technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client user-agent
- W3C
- Consortium World Wide Web
- En cours
- Aveugle délibéré des adresses IP
Commentaires généraux, aucune API/technologie spécifique
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Gouvernance des données et conformité réglementaire | Conseils d'écosystème sur l'utilisation de la Privacy Sandbox 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 à d'autres personnes. Nous sommes toutefois conscients qu'il s'agit d'un domaine d'intérêt majeur pour l'écosystème. Pour chaque API, nous avons publié une documentation technique complète qui devrait servir de base pour les évaluations juridiques nécessaires. Nous mettons également à disposition des documents supplémentaires pour aider les entreprises à se conformer aux exigences réglementaires. |
| Proposition de test quantitatif 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 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 test et d'essai, suivis de conseils détaillés en juin. Nous vous encourageons à transmettre vos questions ou commentaires sur la proposition de tests quantitatifs de la CMA directement à la CMA. |
| Modes de test gérés par Chrome | Plus d'informations et de précisions sur les calendriers de tests | Le 18 mai, nous avons publié un article de blog détaillant les deux modes de tests facilités par Chrome. Ces informations ne sont pas définitives, et nous publierons d'autres conseils d'implémentation au cours du troisième trimestre 2023. |
| Stockage partitionné | Le stockage partitionné sera-t-il utilisé pendant les tests gérés par Chrome ? | Le partitionnement du stockage sera envoyé à tous les utilisateurs avant le test d'abandon des cookies tiers. Elles seront donc activées pour tous les groupes du test. Les sites pourront activer un essai d'abandon pour récupérer de l'espace de stockage non partitionné pendant cette période. |
| Assistance pour la production | Quel processus Chrome a-t-il mis en place pour résoudre les problèmes techniques liés à la Privacy Sandbox et les escalades qui affectent l'écosystème ? | Google propose différents canaux pour permettre aux technologies publicitaires de signaler les problèmes et de les escalader. Veuillez consulter notre post destiné aux développeurs pour en savoir plus sur les forums publics et privés afin d'envoyer des commentaires et d'escalader des problèmes. |
| Calendrier d'inscription | Le délai actuel pour l'inscription est trop court | Nous sommes encore en train d'évaluer la date limite d'application des règles, et nous aimerions avoir votre avis sur la date la plus appropriée. |
| Numéro DUNS | En savoir plus sur l'exigence de numéro DUNS pour l'inscription et l'attestation | Les participants trouveront sur le site Web de Dun & Bradstreet les conditions à remplir pour obtenir un numéro DUNS. Les exigences varient selon le marché, les participants doivent donc s'assurer de consulter le site web du marché spécifique qui les intéresse. En règle générale, les participants doivent fournir des informations de base sur leur établissement, telles que son nom, son adresse et les coordonnées du propriétaire ou du responsable. Les participants peuvent également être invités à fournir des informations financières, telles que le chiffre d'affaires annuel de l'entreprise. Une fois la demande complétée, D&B l'examinera et émet 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 vers la disponibilité générale affectera-t-elle les testeurs actuels de la phase d'évaluation ? | À partir de juillet, les testeurs pourront accéder aux API de pertinence et de mesure en disponibilité générale. Ainsi, la disponibilité de la phase d'évaluation sera différente de celle de la disponibilité générale. |
| Étude AdExchanger | En savoir plus sur la méthodologie des enquêtes | Les personnes interrogées devaient estimer les taux de synchronisation et les revenus de leurs entreprises. La méthode utilisée par les personnes interrogées pour répondre à leurs questions était de leur ressort. |
| Valeurs de paramètres | Comment les valeurs des paramètres tels que le niveau de bruit, les seuils d'anonymat et le budget Privacy Budget sont-ils déterminés ? | Ce document explicatif GitHub présente les principes plus généraux sur lesquels reposent les API Privacy Sandbox. De nombreuses valeurs sont encore en cours de finalisation, et vos commentaires sont les bienvenus. |
Diffusez des annonces et des contenus pertinents
Sujets
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Préservation de la confidentialité | Étude évaluant l'API Topics pour 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 en atelier. Nous sommes heureux de constater que davantage de membres externes de la communauté des chercheurs participent à 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 c'est ce que nous faisons avec l'API Topics. Ils sont plus privés que les cookies tiers et protègent les utilisateurs tout en soutenant les sites qu'ils aiment consulter. |
| Taxonomie des thèmes pas assez précise | La classification des thèmes généraux n'inclut pas des thèmes plus précis, y compris des thèmes spécifiques à une région. | En réponse aux commentaires précédemment envoyés par 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 classification, nous avons collaboré avec plusieurs entreprises de l'écosystème, telles que Raptive (anciennement CafeMedia) et Criteo. La nouvelle classification permet de supprimer les catégories qui, selon nous, étaient 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 taxonomie la plus récente et à donner son avis sur les modifications. |
| Processus de mise à jour des taxonomies et des classificateurs | Vous trouverez plus d'informations sur la classification et la cadence de publication de la classification Topics, ainsi que sur la façon dont les entreprises peuvent se préparer à ces mises à jour. | Comme indiqué dans un récent article de blog, nous nous attendons à ce que la classification évolue au fil du temps. À terme, la gouvernance de la classification devrait finalement être confiée à un tiers externe représentant les acteurs du secteur. Nous avons également partagé le plan d'activation progressive 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 utile et dévalorisera donc d'autres signaux first party 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 discute de sa nouvelle taxonomie avec plusieurs acteurs du marché sur l'ensemble de la chaîne d'approvisionnement ad tech. Alors que 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, nous avons constaté que, globalement, la concurrence serait plus efficace en termes d'utilité globale, en particulier en ce qui concerne la possibilité pour les petits éditeurs de continuer à monétiser leur inventaire après l'abandon des cookies tiers." Notre point de vue correspond au commentaire de la CMA. |
| Utilité pour les 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é envers la CMA à concevoir et à implémenter les propositions de la Privacy Sandbox de manière à ne pas fausser la concurrence en se faisant prévaloir de son propre activité, et à tenir compte de son impact sur la concurrence dans la publicité numérique, ainsi que sur les éditeurs et les annonceurs, quelle que soit leur taille. Nous continuons de travailler en étroite collaboration avec la CMA pour nous assurer que notre travail respecte ces engagements. À mesure que les tests de la Privacy Sandbox progressent, nous évaluerons l'une des principales questions que nous évaluerons concernant les performances des nouvelles technologies pour différents types de personnes concernées. Les commentaires sont essentiels à cet égard, en particulier les commentaires spécifiques et exploitables qui peuvent nous aider à améliorer davantage les conceptions techniques. Nous avons travaillé avec la CMA pour développer notre approche des tests quantitatifs. Nous soutenons également la publication par la CMA d'une note sur la conception des tests afin de fournir plus d'informations aux acteurs du marché et de donner des commentaires sur les approches proposées." |
| Sujets descendants | Le critère de sélection des sujets étant la fréquence des visites de navigateurs, la fragmentation des segments fera-t-elle que les thèmes descendants n'arriveront jamais en tête ? | Chrome évalue actuellement d'autres méthodes de classement et explore d'autres signaux susceptibles d'améliorer le 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 utilisateur obtenues ou dérivées à partir de cette API soient moins sensibles que celles pouvant être obtenues avec les 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 l'identification des utilisateurs et qu'elle est conçue pour exclure les sujets sensibles. Nous sommes conscients que les thèmes peuvent être mis en corrélation ou combinés avec des données first party pour créer des catégories sensibles. Cependant, nous pensons que l'API Topics constitue un pas en avant en termes de confidentialité des utilisateurs et que nous nous engageons à continuer d'améliorer cette API. |
| Structure de la taxonomie | Ajouter l'ID, la gestion des versions et d'autres structures de métadonnées à la taxonomie des thèmes | Actuellement, nous incluons l'ID de taxonomie 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 donner leur avis sur la classification de leurs sites dans Topics. | La classification erronée des sites peut rendre le signal Topics légèrement moins utile en tant que signal dans l'ensemble, mais les sites spécifiques mal classés ne sont pas plus ni moins affectés par ce problème que tous les autres sites. En effet, les informations contextuelles d'un site sont toujours disponibles pour les enchères sur ce site, ce qui fournit des informations comparables au sujet approprié, même en cas d'erreur de classification. N'hésitez pas à nous envoyer vos commentaires à ce sujet ici. Permettre aux éditeurs de contrôler leur classification comporte des risques. Les sites risquent de classer intentionnellement leurs sites de manière incorrecte, ce qui réduit leur utilité pour tous, ou d'encoder des sens sensibles dans des sujets moins courants, portant atteinte à la confidentialité des utilisateurs. |
| Extensions Chrome | Autoriser les extensions Chrome à gérer et filtrer les thèmes, comme les extensions actuelles de gestion des cookies | Cela devrait déjà être possible, comme nous l'avons évoqué sur GitHub, mais n'hésitez pas à nous faire part d'autres commentaires de la part de l'écosystème. |
| Transition vers la disponibilité générale | Le passage de la phase d'évaluation à la disponibilité générale aura-t-il un impact sur l'API Topics ? | Aucune donnée n'est perdue pour les utilisateurs qui passent 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 disposons de plusieurs mesures d'atténuation pour garantir la confidentialité, comme indiqué ici. |
| Fraude et abus | Comment prévenir la manipulation de Topics par des visites frauduleuses ? | Les mesures d'atténuation sont décrites ici. |
| Classificateur de thèmes | Les sites Web peuvent-ils demander à modifier leur classification Topics ? | Votre avis nous intéresse. Cliquez ici pour nous faire part de vos commentaires. |
| Sites des fournisseurs Topics | désigner certains sites Web hébergeant du contenu relatif à de nombreux thèmes en tant que "sites de fournisseurs de thèmes spécifiques" et entraîner des classificateurs en fonction des balises fournies sur les pages Web ; | Nous discutons de cette proposition ici, et tout commentaire supplémentaire nous intéresse. |
API Protected Audience (anciennement FLEDGE)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| lissage du trafic | Impact sur les performances du filtrage basé sur les SSP pour optimiser la charge des requêtes par seconde (RPS) | Nous avons passé un temps considérable à réfléchir au lissage du trafic et nous recommandons aux SSP de tirer parti de la mise en cache. |
| Test du volume... | Difficile de tester Protected Audience, car les SSP et les DSP ont du mal à obtenir des volumes de trafic importants. | Nous collaborons en permanence avec nos partenaires SSP et DSP pour adopter et tester les audiences protégées. Le lancement de la phase de disponibilité générale a commencé et nous sommes convaincus que le pourcentage de trafic pour lequel les enchères sont activées rendra le test des partenaires plus agréable. |
| de la complexité | La mise en œuvre de solutions Protected Audience nécessite des efforts et des coûts importants. | Nous sommes conscients que les nouvelles technologies sont difficiles à adopter, y compris la Privacy Sandbox. L'équipe de la Privacy Sandbox travaille en étroite collaboration avec un large éventail de personnes concernées pour former et soutenir 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 des options potentiellement compatibles au-delà des solutions cloud, mais il n'est actuellement pas possible d'accepter 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 importants que posent les déploiements sur site, nous pensons que continuer à développer et à 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 vous invitons à nous faire part de commentaires supplémentaires expliquant pourquoi une telle 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 élaborons actuellement un guide permettant d'estimer les coûts liés aux flux de travail d'enchères et de mise aux enchères sur le serveur d'enchères et de mise aux enchères. Ce guide sera mis en corrélation avec l'utilisation des technologies publicitaires, ce qui permettra d'atteindre l'un des objectifs de nos conceptions. |
| Chronologie de K-Anon | Quand les contraintes de k-anonymat planifiées seront-elles appliquées à "renderUrl" ? | Nous travaillons sur une explication concernant le calendrier d'application des règles que nous publierons prochainement. |
| Restrictions runAdAuction | Chrome peut-il limiter l'appel de runAdAuction à partir de la page supérieure ? |
Bien que notre conception soit entièrement compatible avec runAdAuction, qui peut être appelé à partir de la page supérieure, nous pensons qu'il serait plus préjudiciable pour les éditeurs d'autoriser cet appel uniquement à partir du domaine de premier niveau.L'écosystème de la Privacy Sandbox nous a expliqué que c'était pour réduire au maximum la charge que doivent peser 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 leur site. L'objectif de la Privacy Sandbox était d'encourager un écosystème sain sans avoir à définir le fonctionnement des éditeurs et des technologies publicitaires. En permettant aux éditeurs de choisir qui appelle runAdAuction sur leur site et de quelle manière, nous pensons leur offrir la flexibilité nécessaire pour trouver le meilleur chemin en fonction de leurs besoins. |
| Assistance à l'implémentation | Chrome peut-il créer ou contribuer à une implémentation Open Source d'une mise aux enchères multivendeur ? | 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 à définir le fonctionnement des technologies publicitaires. Nous avons publié des conseils sur le fonctionnement des API dans notre dépôt GitHub et nous sommes prêts à explorer des solutions avec le secteur. Nous ne prévoyons pas de créer d'implémentations spécifiques, 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 répondre aux besoins de leurs clients en mettant en place les garde-fous de confidentialité adaptés. |
| Enchères multivendeurs | Chrome forcera-t-il le partage d'un gagnant "contextuel" avec les mises aux enchères des composants ? | L'API Protected Audience est conçue pour permettre aux parties qui lancent l'enchère multivendeur de transmettre des informations à la mise aux enchères des composants (remarque: uniquement avant de lancer l'enchère). Cela dit, nous n'avons aucun moyen pour le navigateur de déterminer si une information est déterminante d'un point de vue contextuel ou non. Nous ne pouvions donc pas imposer de blocage ou d'exigence de certaines informations. |
| Préférence des utilisateurs pour le suivi du consentement | AdTech demandant aux API publicitaires comment implémenter correctement le suivi du consentement de l'utilisateur | Notre réponse inclut ce que nous avons dit au premier trimestre: "Pour des annonces spécifiques, la technologie publicitaire pertinente est la mieux placée pour contrôler quelles créations sont diffusées et comment elles sont sélectionnées." Nous avons abordé plusieurs scénarios liés à ce problème lors de la réunion protégée de l'audience protégée du WICG de mai. N'hésitez pas à nous faire part de commentaires et discussions supplémentaires 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 à d'autres fournisseurs de technologie publicitaire de posséder et de gérer des audiences personnalisées. D'autres conseils sur la façon dont une SSP peut s'intégrer à l'API PA sont en cours de développement. Ils seront mis à la disposition des SSP et d'autres fournisseurs de technologie publicitaire afin de soutenir 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 manières différentes: au format XML VAST ou HTML (annonce OutStream qui, à terme, peut également charger du 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 diffusant des annonces vidéo devront se préparer à la diffusion des annonces via l'API Protected Audience. Vous devez donc vous assurer que les tags d'emplacement peuvent transmettre l'URL d'un iFrame Protected Audience à un lecteur vidéo. Pour Fenced Frames, nous nous efforcerons de répondre aux besoins vidéo avant l'obligation d'utiliser Fenced Frames, qui n'aura pas lieu avant 2026. |
| Rythme | Comment le cas d'utilisation du rythme fonctionne-t-il avec l'API Protected Audience ? | Nous vous remercions de vos commentaires. Nous aimerions voir davantage d'exemples de cette demande, avec davantage d'informations provenant d'un plus grand nombre de SSP partenaires, car jusqu'à présent, ce problème est principalement lié aux DSP. |
| Fréquence de mise à jour | La fréquence des appels depuis dailyUpdate (jusqu'à 1 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 les informations produit. |
Nous vous remercions de vos commentaires. D'autres solutions permettent aux technologies publicitaires d'utiliser des signaux actualisés à différentes fréquences, comme les recherches K/V. |
| Contrôle de la qualité des annonces | Comment les éditeurs mettent-ils en œuvre le contrôle qualité des annonces ? | Aujourd'hui, l'API Protected Audience offre aux éditeurs des fonctionnalités permettant aux éditeurs d'informer leurs SSP sur certains contrôles qu'ils peuvent mettre en place dans la configuration des enchères, avant l'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 pouvant être 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 forDebuggingOnly au plus tôt pour les événements gagnants en 2026. |
| Groupes de centres d'intérêt multi-appareils | Proposition visant à activer des groupes de centres d'intérêt multi-appareils pour les user-agents authentifiés | Nous évaluons cette proposition, mais la grande spécificité du ciblage multi-appareil pose des problèmes de confidentialité importants, comme indiqué dans ce problème GitHub. |
| (également enregistré au 1er trimestre) 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 grâce à l'API Protected Audience, comme expliqué ici. |
| Données associées au clic | Ajouter les données sur les clics à browserSignals. |
Nous vous demandons actuellement des précisions sur le moment où le clic s'est produit afin de donner une position préliminaire. |
| (également disponible au 4e trimestre 2022) Fonctions définies par l'utilisateur dans Protected Audience | Comment les fonctions définies par l'utilisateur (UDF) seront-elles compatibles avec l'API Protected Audience ? Ces fonctions peuvent être programmées par les utilisateurs finaux pour étendre les fonctionnalités de l'API. | La technologie publicitaire qui a soulevé ce problème a également indiqué qu'elle était encore en train d'évaluer ce qu'elle pourrait faire avec l'UDF. Par conséquent, il n'y a pas encore de feedback exploitable à ce stade, pas encore avant la disponibilité générale. |
| Currency | Les montants en devise ne doivent pas être représentés par des valeurs à virgule flottante. | Nous avons traité ce problème en détail ici. |
| 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 conscients que les ad servers souhaitent 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 de l'écart existant entre l'API Protected Audience actuelle et ces demandes. |
| GenerateBid | Prise en charge de la proposition Google Ads consistant à renvoyer plusieurs annonces candidates par groupe de centres d'intérêt à partir de generateBid, et à attribuer à ces candidats des scores dans "scoreAd". |
Cet examen est en cours. N'hésitez pas à nous envoyer d'autres commentaires. |
| Ordre de mise aux enchères | Les enchères de l'API Protected Audience doivent-elles être les dernières à lancer pour pouvoir prendre en compte les résultats 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 déclenchée par l'utilisateur | Nous examinons actuellement cette demande et nous en discutons ici . Tout commentaire supplémentaire est important pour nous. |
| Mise en cache | Les SSP ne doivent pas créer les 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 envisageons d'autres options. N'hésitez pas à nous faire part de vos commentaires sur l'adéquation de la mise en cache avec les cas d'utilisation de l'écosystème. |
| 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 dans les deux modes de l'API Attribution Reporting (rapports récapitulatifs et au niveau des événements). Nous avons partagé davantage d'informations sur l'intégration améliorée de l'API Protected Audience et d'Attribution Reporting le 1er juin. En savoir plus |
| 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. Il est 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 moment pour le point de terminaison du rapport. La conception actuelle vise à s'assurer que les rapports agrégables eux-mêmes (avec des charges utiles chiffrées) ne divulguent pas de données intersites. Un point de terminaison approuvé ne devrait donc pas être nécessaire. Une complication supplémentaire est que 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. |
| WebIDL | La spécification actuelle de l'API Protected Audience n'est pas compatible avec la spécification WebIDL. | Nous sommes en train d'évaluer ces commentaires et de discuter du problème ici. |
| Gestion du consentement | Comment la transmission des signaux de consentement sera-t-elle gérée dans l'API Protected Audience ? | Les informations contextuelles n'entrent pas dans le champ d'application de l'API Protected Audience. Nous discutons actuellement de ce problème, et vos commentaires sont les bienvenus. |
| Marketing basé sur le compte | Les cas d'utilisation marketing basés sur les comptes seraient-ils possibles ? | L'API Protected Audience est compatible avec divers cas d'utilisation du marketing basé sur l'audience. Nous continuons à comprendre comment l'API Protected Audience peut répondre au mieux à ce cas d'utilisation particulier, et nous vous invitons à nous faire part de tout commentaire supplémentaire sur ce problème de la part de l'écosystème. |
| Mise aux enchères des composants | Quel est le score des différents participants aux enchères ? | Les enchères des composants ne attribuent pas directement un score aux groupes de centres d'intérêt, mais aux annonces et aux enchères qu'une DSP soumet à la fonction generateBid. La fonction generateBid() s'exécute par groupe de centres d'intérêt et le DSP renvoie les éléments suivants 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 le code base GitHub du serveur de clés-valeurs. | Nous cherchons à mettre à jour nos processus pertinents pour prendre en charge les contributions externes au code GitHub. |
| Taille du groupe d'intérêt | Quel est le nombre maximal de clés prises en charge par l'IG ? | La limite actuelle est de 50 Ko pour la taille d'un seul profil d'utilisateur, et les clés sont prises en compte dans ce nombre. N'hésitez pas à consulter d'autres discussions sur la taille limite. |
| 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, elles peuvent être mises en cache pour plusieurs mises aux enchères, ainsi que pour plusieurs 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 sont compatibles avec plusieurs versions du code de technologie publicitaire. Dans l'API Bidding and Bidding, la requête SelectAd peut spécifier la version du code utilisée pour la demande d'enchère (pour les enchères / la mise aux enchères et la création de rapports). |
| Stockage partagé | Prise en charge de l'écriture dans le stockage partagé via le service d'enchères et de mise aux enchères. | Actuellement, les services d'enchères et de mise aux enchères ne sont pas compatibles avec le stockage partagé. Toutefois, nous aimerions recueillir vos commentaires sur l'importance de ces cas d'utilisation pour l'écosystème. |
| Web-to-app | Permettre le partage web-to-app de groupes de centres d'intérêt. | Actuellement, le déploiement de l'API Protected Audience sur Chrome et Android ne concerne pas le Web-to-app, mais l'écosystème nous intéresse. Il nous explique l'importance de ce cas d'utilisation. |
| K-anonymat | Gérer les remplacements k-anonymat | Nous discutons actuellement de ce problème et nous aimerions recevoir des commentaires supplémentaires. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Autres configurations de rapports VTC au niveau des événements | Commentaires sur les configurations alternatives des rapports VTC au niveau des événements | D'après les commentaires d'utilisateurs, les configurations actuelles au niveau des événements n'étaient pas optimales, et nous aimerions connaître votre avis sur les configurations globales optimales. Nous sommes prêts à recevoir d'autres commentaires à ce sujet et pensons que notre explication flexible au niveau de l'événement contribuera également à résoudre ce problème. |
| 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é de la documentation sur la configuration flexible au niveau des événements. Cette fonctionnalité est encore à l'état de proposition et nous souhaiterions savoir si elle sera utile à l'écosystème. |
| Configurations flexibles au niveau des événements | Comment rapprocher les rapports contradictoires 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 davantage de flexibilité pour les rapports au niveau des événements, qui sont le plus souvent utilisés pour des cas d'utilisation d'optimisation. N'hésitez pas à nous faire part de vos commentaires ou réactions sur ce scénario. |
| Enregistrement de la source | Que se passe-t-il si l'enregistrement de la source a lieu après l'enregistrement du déclencheur ? | Actuellement, si un enregistrement de source a lieu après l'enregistrement du déclencheur, celui-ci ne peut pas être attribué l'un à l'autre. Il semble s'agir d'un cas limite. N'hésitez pas à nous faire part de vos commentaires concernant ce problème. Nous nous efforcerons de le traiter s'il s'agit d'un scénario que de nombreuses technologies publicitaires semblent être confrontées. |
| Collaborer avec plusieurs agences publicitaires | Comment les DSP peuvent-elles utiliser l'API Attribution Reporting lorsqu'un annonceur travaille avec plusieurs agences publicitaires ? | L'API accepte les redirections et peut donc être utilisée même lorsqu'un annonceur travaille avec plusieurs agences publicitaires. De plus, certaines limites s'appliquent aux redirections afin de garantir 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 mentionné par la technologie publicitaire. N'hésitez pas à nous faire part de vos commentaires concernant ce scénario. Nous continuerons à faire évoluer la situation en conséquence. |
| Limites de destination | Les limites du nombre de destinations peuvent avoir un impact sur le cas d'utilisation des annonces actualisées automatiquement. | Nous avons abordé ce problème lors de la réunion du 1er mai du WICG et nous souhaiterions recueillir des commentaires sur ce que serait une limite raisonnable. Nous avons ajouté le guide d'explication sur les rapports sur l'attribution avec les rapports au niveau des événements, indiquant que le navigateur peut limiter le nombre d'eTLD+1 de destination représentés par les sites sources. (Consultez la section Demande d'extraction.) |
| 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 dans les deux modes de l'API Attribution Reporting (rapports récapitulatifs et au niveau des événements). Nous avons partagé davantage d'informations sur l'intégration améliorée de l'API Protected Audience et d'Attribution Reporting le 1er juin. 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 tous les utilisateurs peuvent utiliser pour évaluer le gain d'informations et l'impact du bruit pour les configurations flexibles au niveau des événements qu'ils souhaitent tester. N'hésitez pas à nous faire part de vos commentaires si vous décidez de tester le code. |
| Mesure de l'attribution entre les applications et le Web | Quand la mesure de l'attribution entre les applications et le Web sera-t-elle disponible ? | Le 9 mai, nous avons annoncé le test de la mesure de l'attribution Web et multi-applications via l'API Attribution Reporting. Bien que la disponibilité générale prévue pour les API de pertinence et de mesure dans Chrome 115 soit prévue, ce n'est pas le cas actuellement de la mesure de l'attribution entre les applications et le Web dans Chrome 115. |
| Dédupliquer des conversions | Comment concilier des solutions de mesure indépendantes et ARA ? | Conformément à la pratique habituelle actuelle, les annonceurs font appel à un fournisseur de solutions de mesure indépendant et indépendant pour dédupliquer les rapports sur les conversions. Nous avons fourni des ressources expliquant comment dédupliquer des conversions pour les rapports au niveau des événements. |
| Perte de données lors des mises à jour de la base de données Attribution Reporting | Y aura-t-il une perte de données après la mise à jour de la base de données Attribution Reporting dans Chrome, comme annoncé ? | À partir de la version stable de Chrome 115, nous commencerons à activer les API de pertinence et de mesure pour une partie des utilisateurs de Chrome par défaut. Cette disponibilité générale s'étend à mesure que nous analysons d'éventuels problèmes. L'objectif est d'atteindre une disponibilité de 100% sur une période de quelques semaines d'ici le troisième trimestre 2023. Cela coïncidera avec la fin de la phase d'évaluation pour la pertinence et les mesures. À partir de juillet, les testeurs pourront s'inscrire pour accéder à ces API en disponibilité générale. Cela permettra un chevauchement entre la disponibilité de la phase d'évaluation et la disponibilité générale lors de l'inscription. Votre jeton pour la phase d'évaluation restera valide jusqu'au 19 septembre. Toutefois, nous vous recommandons de vous inscrire aux API avant la fin de la période d'évaluation afin de 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 versions 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ît pas dans les rapports de débogage. 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, il est possible que l'API Attribution Reporting ne soit 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 différents modèles de facturation. |
Service d'agrégation
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Modification du délai 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 voir les réactions positives à la modification proposée et nous encourageons l'écosystème à continuer de 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 potentiellement compatibles au-delà des solutions cloud, mais il n'est actuellement pas possible d'accepter 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 importants que posent les déploiements sur site, nous pensons que continuer à développer et à 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 vous invitons à nous faire part de commentaires supplémentaires expliquant pourquoi une telle exigence est nécessaire. |
| Traiter à nouveau les rapports pour différentes périodes | Possibilité de retraiter les rapports pour différentes périodes | Nous avons reçu des demandes similaires de 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 une technologie publicitaire afin que les rapports puissent être divisés en différents lots. Nous sommes en train d'évaluer ce processus et nous tiendrons l'écosystème à jour au fur et à mesure de l'évolution de cette proposition. |
| Conséquences sur la confidentialité de l'environnement d'exécution sécurisé | Sentiments positifs des environnements d'exécution sécurisés vis-à-vis de la confidentialité | Nous sommes ravis des réactions positives de la part de l'écosystème concernant nos propositions. N'hésitez pas à nous faire part d'autres commentaires à mesure que nous continuons à développer et à itérer. |
| 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 fixé 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 des clés | La fonctionnalité de découverte clé permettra aux testeurs d'interroger des rapports globaux sans avoir besoin de la liste explicite des combinaisons de clés possibles. L'objectif est de traiter les rapports récapitulatifs pour l'attribution multiréseau, et d'améliorer ainsi les performances et la précision. | Nous étudions actuellement des solutions et des solutions alternatives, et nous aimerions recevoir d'autres commentaires de la part de l'écosystème. |
API Private Agrégation
| Thème des 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 Agrégation. |
| Espace clé de 128 bits | Clarté de la limite d'espace clé de 128 bits | Nous allons clarifier cette limitation 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 tronquer le nombre maximal de contributions. Nous ferons participer l'écosystème à mesure que cette proposition évoluera. |
| Rapports sur la couverture | Demande de reporting multi-plateforme/multi-appareils sur la couverture. La couverture est une métrique fondamentale de la publicité axée sur la marque. Les annonceurs s'appuient sur les estimations multi-plateformes/multi-appareils pour créer des rapports sur la couverture et la fréquence de diffusion 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 Privacy Sandbox explore actuellement des fonctionnalités compatibles avec les méthodes 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 des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (également disponible au premier trimestre 2023) Conseils pour les facteurs de forme supplémentaires | Demande de User-Agent Client Hints (UA-CH) afin de fournir des facteurs de forme supplémentaires, tels qu'un téléviseur ou une réalité virtuelle. | Nous travaillons encore sur des décisions de conception clés (que ce soit pour fournir une valeur unique telle que "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 budgétaires liées à la confidentialité peuvent rendre les requêtes UA-CH non déterministes lorsqu'un trop grand nombre de requêtes sont envoyées. | Nous n'avons aucune nouvelle mise à jour concernant la proposition de budget pour la confidentialité pour le moment, mais nous nous sommes engagés à ne pas limiter les demandes d'indicateurs client UA avant l'abandon des cookies tiers. |
| Compatibilité des sites | Les sites Web utilisent la marque UA-CH pour empêcher certains navigateurs d’accéder aux sites. | Il existe des cas d'utilisation valables pour les listes de marques, dont la compatibilité. Dans UA, vous pouvez faire appel à plusieurs marques pour résoudre ces problèmes. |
Protection de l'adresse IP (anciennement Gnatcatcher)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Fraude et abus | Comment les entreprises peuvent-elles mettre en place des mesures de lutte contre la fraude avec la protection de l'adresse IP ? | Nous comprenons l'importance des cas d'utilisation de lutte contre la fraude et leur impact potentiel. Nous prévoyons de publier d'autres informations sur la lutte contre la fraude dans le courant de l'été. Nous souhaitons recueillir les commentaires de notre écosystème sur la façon dont nous pouvons mieux prendre en charge les cas d'utilisation de la lutte contre la fraude. |
| GeoIP | En savoir plus sur le calendrier de test et de déploiement pour GeoIP | Chrome a récemment publié de nouvelles informations détaillant nos projets GeoIP. Nous prévoyons de communiquer davantage d'informations sur les calendriers de déploiement au cours du troisième trimestre. Dans un premier temps, nous prévoyons de lancer la protection de l'adresse IP sous la forme d'une fonctionnalité qui peut être activée par les utilisateurs sur un petit pourcentage du trafic. En effet, nous sommes conscients que cette proposition peut impliquer des changements importants pour les entreprises. Nous voulons donc laisser à l'écosystème le temps de s'adapter et de fournir des commentaires avant que la fonctionnalité ne soit déployée à plus grande échelle. |
| Authentification du compte | Comment l'authentification de compte avec le serveur proxy fonctionnera-t-elle exactement ? | Nous prévoyons de publier plus d'informations sur l'authentification des comptes dans le courant de l'été, même si nous vous avons déjà fait part de quelques considérations initiales. |
Atténuation du suivi des rebonds
| Thème des 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 les méthodes permettant de tester l'atténuation du suivi des rebonds. |
| Documentation | Clarté de la proposition concernant le suivi des rebonds | La proposition actuelle étant en grande partie en cours de développement, Chrome continue de la mettre à jour afin de la clarifier et de fournir des informations à l'écosystème. Nous nous efforçons de fournir plus d'informations et nous aimerions connaître votre avis. |
| Suppression des cookies | La stratégie d'atténuation du suivi des rebonds supprimera-t-elle tous les cookies d'un domaine ? | L'atténuation du suivi des rebonds (BTM) entraîne la suppression de tout l'espace de stockage et de l'intégralité du cache, comme expliqué ici. |
| Contourner les mesures d'atténuation du suivi des rebonds | Il est possible de contourner cette classification en effectuant des redirections avec des pop-ups ou de nouveaux onglets. | La spécification d'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 sur le même onglet, mais nous prévoyons de travailler sur les flux pop-up à l'avenir. N'hésitez pas à nous envoyer d'autres commentaires. |
Privacy Budget
| Thème des 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 impacts potentiels de l'écosystème. |
Renforcez les limites de confidentialité intersites
Ensembles internes
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| (Également signalé au cours des trimestres précédents) Limite par domaine | Demande d'augmentation du nombre de domaines associés | Chrome évalue la limite numérique appropriée pour le sous-ensemble associé, qui permettra de trouver un juste équilibre entre confidentialité et utilité pour les cas d'utilisation identifiés. Dès le départ, Chrome a indiqué que le nombre exact pour le sous-ensemble "Associé" n'était pas encore finalisé. |
| Cas d'utilisation intégré | Prise en charge des cas d'utilisation intégrés nécessitant des ensembles internes, des CHIP et un espace de stockage partagé | Chrome a reçu des commentaires concernant ce cas d'utilisation. Notre équipe les examine et souhaite les commentaires supplémentaires. |
| Gestion des dépôts | Informations sur les règles permettant de supprimer des ensembles internes du dépôt GitHub en cas d'écarts ou de négligence | Chrome a reçu des commentaires concernant ce cas d'utilisation. Notre équipe examine actuellement ce problème et souhaiterait recevoir des commentaires supplémentaires. |
| Formation des utilisateurs | Chrome doit aider les utilisateurs à mieux comprendre les ensembles internes afin de favoriser leur adoption. | L'équipe Chrome s'est engagée à informer les utilisateurs sur les ensembles internes et a publié un article du Centre d'aide (lien depuis l'interface utilisateur de Chrome) à ce sujet. Chrome s'efforce également de continuer à apprendre à informer au mieux les utilisateurs dans les contextes appropriés. |
| Post 3PCD | Les cookies tiers continueront d'exister dans un ensemble interne après l'abandon des cookies tiers. | requestStorageAccess et requestStorageAccessFor rendent effectivement les cookies tiers disponibles à nouveau pour des cas d'utilisation spécifiques et clairement définis, mais ils nécessitent désormais un appel actif par le site, au lieu d'être disponibles par défaut, comme avec l'état actuel des cookies tiers (dans Chrome).Bien que cet appel ne nécessite pas l'approbation de l'utilisateur au sein d'un même ensemble, celui-ci peut l'empêcher en désactivant cette option dans les paramètres. Les utilisateurs peuvent consulter cet article du Centre d'aide (accessible depuis l'interface utilisateur de Chrome) pour en savoir plus. Nous prévoyons de compléter le guide du développeur existant à mesure que le FPS augmentera de 100%. |
| Envoi d'ensembles internes | Renommez le .well-known/first-party-set requis pour inclure une extension .json. |
Nous avons effectué ce changement afin de nous assurer que certains forfaits d'hébergement Web sont acceptés. |
| Enregistrement auprès de l'IANA | first_party_sets.JSON doit être enregistré auprès de l'IANA |
Nous examinons actuellement la proposition. Si vous souhaitez nous faire part de vos commentaires, cliquez ici. |
API Fenced Frames
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Blocage des annonces | Les cadres cloisonnés peuvent permettre 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'avec les iFrames. L'URL réelle vers laquelle le frame cloisonné est sur le point d'accéder est également visible par les extensions. Elles peuvent donc appliquer n'importe quelle règle de blocage d'URL, comme c'est le cas dans les iFrames. Le simple fait de bloquer tous les cadres cloisonnés sans condition peut briser les cas d'utilisation des cadres cloisonnés non publicitaires. |
API Shared Storage
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Adoption plus large | Le stockage partagé doit être un standard dans l'industrie et disponible pour tous les navigateurs. | Vos commentaires sont les bienvenus. Chrome continue de participer activement aux forums W3C pour défendre la proposition, obtenir des commentaires et favoriser l'adoption. |
| Portes de sortie | Les portes de sortie du stockage partagé sont trop limitées. | Nous prenons en compte ces commentaires et nous aimerions recevoir des commentaires supplémentaires sur l'écosystème pour expliquer pourquoi les portes de sortie sont trop limitées. |
| Conformité vis-à-vis des réglementations | Comment le stockage partagé gère-t-il la conformité réglementaire, telle que les règles de conservation des données ? | Le stockage partagé offre la flexibilité d'implémenter et de personnaliser une logique pour contrôler la durée de vie et l'expiration des 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 réaliser des tests A/B pour le stockage partagé et l'API Protected Audience ? | Nous nous efforçons de publier des conseils 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 n'est stockée. |
| Plusieurs accès sur le même chargement de page | Que se passe-t-il lorsque le stockage partagé est utilisé plusieurs fois au cours d'un même chargement de page ? | La meilleure façon de gérer cela consiste à 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. Elle 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 si celles-ci cesseront de fonctionner après l'abandon des cookies tiers ? | Après l'abandon des cookies tiers, le stockage local dans des iFrames sera partitionné par le site de premier niveau, mais les iFrames eux-mêmes ne seront pas bloqués. Les données stockées dans l'espace de 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 des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Limite de partition | 10 Kio par site partitionné reste substantiel et aimerait être réduit. | Firefox a déjà indiqué une position positive sur les CHIPS. Pour l'assistance Webkit, nous encourageons les développeurs à faire part de commentaires directement à Apple sur ce problème GitHub concernant leurs cas d'utilisation où les cookies partitionnés sont préférables au stockage partitionné. |
| Intégrations authentifiées | Les CHIP peuvent affecter le flux de connexion SSO actuel en raison d'un partitionnement différent affectant les intégrations authentifiées. | Nous prévoyons d'exploiter l'API Storage Access (avec des invites utilisateur) pour prendre en charge le cas d'utilisation des intégrations authentifiées. Nous avons récemment envoyé un intent-to-prototype. |
| Règles à vie | Les règles à vie potentielle s'appliqueront-elles aux cookies propriétaires ? | À l'heure actuelle, nous ne prévoyons pas d'imposer de limites à vie aux cookies propriétaires. |
FedCM
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Prise en charge de l'autorisation OAuth | Aligner sur l'autorisation des champs d'application OAuth sans profil | Nous sollicitons activement l'avis de la communauté Web Identity par l'intermédiaire du FedID CG du W3C sur 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 | Respecter les exigences de compatibilité SAML | L'équipe sollicite activement l'avis des communautés de chercheurs et d'enseignement sur les besoins en matière de compatibilité SAML (en plus de la prise en charge d'OpenID-connect) suite à l'abandon des cookies tiers. |
Lutter contre le spam et la fraude
API Private State Token (et autres API)
| Thème des commentaires | Résumé | Réponse Chrome |
|---|---|---|
| Explorer de nouveaux signaux | Plusieurs partenaires ont exprimé un sentiment positif à l'égard de l'exploration des signaux facilités par les navigateurs concernant l'intégrité de l'appareil ou la confiance des utilisateurs. De manière générale, ils s'inquiètent également de ce que les nouveaux signaux spécifiques suffisent à maintenir le niveau actuel de détection des fraudes. | Nous avons hâte de découvrir ensemble de nouvelles propositions au sein de la communauté de lutte contre la fraude et de la sécurité sur le Web, mais aussi de prendre en compte et de faire part de leurs préoccupations. C'est pour cette raison que la "lutte contre le spam et la fraude" est au cœur du projet Privacy Sandbox. C'est pourquoi nous continuons d'investir en priorité pour préserver la sécurité sur le Web tout en améliorant la confidentialité des utilisateurs. |
| Avis positifs sur PST | Plusieurs partenaires ont manifesté leur intérêt pour tester ou utiliser des fichiers PST pour divers cas d'utilisation liés à la lutte contre la fraude ou la sécurité sur le Web. | Nous sommes ravis de recevoir de l'aide et nous sommes disposés à explorer davantage de nouvelles solutions qui utilisent les fichiers 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 et la détection des fraudes publicitaires 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 du signal perdu par les cookies tiers à des fins de lutte contre la fraude, mais avec de nouveaux paramètres de confidentialité. Nous investissons activement dans de nouvelles propositions de lutte contre la fraude et les abus afin de préserver les fonctionnalités avec d'autres changements concernant la Privacy Sandbox. |
| Taux d'informations entre l'émetteur et 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 la nature des données utilisateur qui peuvent être transmises à l'aide de jetons d'état privés. De par leur 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 les rares cas où une rotation des clés d'urgence est nécessaire), ce qui ralentit le processus d'association de données utilisateur supplémentaires au fil du temps. Avec toute nouvelle API Web, elle fournit un juste milieu entre l'utilité et les nouvelles informations sur l'utilisateur. Nous estimons que les PST permettent de 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 tenter de standardiser davantage l'écosystème Web. Toutefois, nous pensons qu'il serait trop tôt pour effectuer cette modification avant d'avoir une idée plus précise de ce à quoi ressemblera la norme. Si une norme émerge, nous nous engageons également à faire en sorte que les développeurs Web adoptent cette norme de façon responsable. |
| 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 de la phase d'évaluation, les développeurs ont indiqué qu'ils préféraient pouvoir 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 dans laquelle les ensembles de clés sont destinés à autoriser une valeur implicite de "métadonnées publiques". Si une variante de PrivacyPass finit par être standardisée avec des métadonnées publiques (que ce soit en tant que POPRF, aveuglement partiel des RSA ou jeux de clés), nous pouvons passer à une prochaine version de PST pour prendre en charge cela. |
| Implémentation d'en-tête de l'API | Questions concernant l'implémentation de l'en-tête de l'API | Au fur et à mesure que l'API sera standardisée et que l'utilisation de cette API par l'écosystème se développera, nous espérons prendre en charge les deux versions standard sans en-tête de cette API et éventuellement abandonner la version d'en-tête si elle est suffisamment peu utilisée, ou si les outils et la prise en charge des développeurs sont suffisants pour établir une corrélation entre les demandes d'émission/d'utilisation avec d'autres données. Nous discutons de ce problème ici. |
| Inscription | Est-il pratique pour les émetteurs de s'enregistrer auprès des fournisseurs de navigateurs ? | Nous avons mis à jour la spécification afin de décrire le processus d'enregistrement des émetteurs pour les jetons d'état privés. Bien qu'elle utilise son propre processus, elle 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 leur intention d'utiliser les PST et d'accepter les restrictions techniques qui protègent la confidentialité des utilisateurs. |