Rapport trimestriel pour le 3e 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 ou technologie spécifique
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Préparation des écosystèmes | Les SSP ont souligné leur inquiétude : les éditeurs ne seraient pas prêts et n'effectuaient pas le travail de déploiement requis. | Privacy Sandbox vise spécifiquement à informer les éditeurs, via des webinaires dédiés et des réunions avec les éditeurs et les SSP pour faciliter le déploiement. |
| Abandon des cookies tiers | Les préoccupations concernant l'abandon des cookies tiers (3PCD) s'intensifient au 4e trimestre 2023 en raison de la panne technologique dans le secteur. | Le calendrier de la Privacy Sandbox a été discuté avec la CMA, et le séquencement a mené à un second semestre 2024 de préparation. Privacy Sandbox publiera des informations plus détaillées sur l'ordre d'activation des 3PCD. En vertu des Engagements, 3PCD est soumis aux problèmes de concurrence de la CMA qui sont résolus. |
| Google Ad Manager | Google Ad Manager refuse d'exposer la surface de l'API, ce qui rend les tests difficiles. | Réponse fournie par Google Ad Manager:pour les raisons expliquées dans cette réponse de Google Ad Manager, Google Ad Manager prévoit d'intégrer l'API Protected Audience sans prendre en charge l'ad server éditeur Google qui ne contrôle pas l'enchère de premier niveau. |
| Google Ad Manager | Google Ad Manager dispose d'un prix plancher secret qui n'est exposé qu'aux SSP AdX ou Open Bidding. | La documentation publique de Google Ad Manager indique que le gagnant de l'enchère contextuelle est transmis à la logique d'évaluation de niveau supérieur et non à une enchère associée à un composant, y compris AdX ou Open Bidding. En outre, cette documentation indique la logique d'attribution de scores de niveau supérieur : "Ad Manager comparera l'enchère gagnante de chaque enchère composante, y compris l'enchère individuelle d'Ad Manager pour les enchères de groupe de centres d'intérêt de ses acheteurs, ainsi que la meilleure annonce contextuelle (sélectionnée par l'allocation dynamique), et diffusera l'annonce associée à l'enchère la plus élevée." |
| Google Ad Manager | Les produits Google Ads doivent être soumis aux mêmes règles que les produits publicitaires tiers. | Les produits Google Ads sont déjà soumis aux mêmes règles que les produits tiers. |
| Tests facilités par Chrome | Ajoutez des libellés pour les navigateurs ne figurant pas dans la liste A ou B. | Nous n'envisageons pas de le faire pour le moment, car notre enquête a révélé que l'ajout de libellés qui ne sont pas de test peut compliquer les questions de confidentialité concernant le trafic en mode navigation privée. |
| Une agence publicitaire | Les agences ou les entreprises qui n'ont pas de code JavaScript sur leurs sites Web peuvent-elles utiliser les API Privacy Sandbox ? | Tout le monde peut appeler les API Privacy Sandbox. Si une agence ou toute autre personne veut créer des technologies directement à partir des API, Les API côté client nécessitent une intégration avec le client, tout comme les cookies. De nombreuses API, comme les cookies, disposent également d'une interface d'en-tête HTTP. Nous avons déjà vu un framework du secteur publicitaire, Prebid, qui crée des intégrations côté client avec les API. D'autres organisations pourraient faire de même. |
| Solutions côté client | Pourquoi Google adopte-t-il des solutions côté client pour la Privacy Sandbox alors qu'un ingénieur a déjà exprimé son inquiétude concernant l'évolutivité de ces solutions en 2012 ? | Le domaine d'étude des technologies axées sur l'amélioration de la confidentialité a considérablement évolué depuis 2012 et offre par la même occasion des applications commercialement viables. La Privacy Sandbox repose sur des combinaisons de PET qui n'auraient pas été réalisables il y a plus de 10 ans. En outre, la puissance de calcul personnelle a augmenté, tout comme les attentes des consommateurs vis-à-vis des navigateurs et les attentes réglementaires en matière de confidentialité. |
| Machine learning | Quelle utilisation prévue de la Privacy Sandbox par Google pour le machine learning est-elle prévue ? | Une grande partie de l'écosystème de technologie publicitaire utilise le machine learning aujourd'hui, et nous ne nous attendons pas à ce que cela change. La Privacy Sandbox n'empêche pas les entreprises de technologie publicitaire ni quiconque de continuer à utiliser le machine learning. La Privacy Sandbox n'exige pas non plus que les entreprises qui intègrent ses API utilisent le machine learning. Il est raisonnable de s'attendre à ce que les entreprises continuent à créer des produits et des services de manière à répondre aux besoins de leurs clients, que ce soit en utilisant le machine learning ou non. Tous les modèles de machine learning créés par les intégrateurs de la Privacy Sandbox seront bien entendu connus et ne seront donc pas dissimulés. |
| Validation des données | Comment les entreprises peuvent-elles vérifier que les données qu'elles reçoivent de l'utilisation de la Privacy Sandbox sont exactes et que Google accepte que Google soit examinée par une entité telle que le Media Ratings Council (MRC) ? | Les API Privacy Sandbox sont conçues sur la plate-forme Open Source de Chrome. Les parties des API destinées à s'exécuter dans des environnements d'exécution sécurisés sont également Open Source et vérifiables. Toute personne qui souhaite inspecter le code peut le faire, y compris le MRC. |
| (également indiqué aux trimestres précédents) Assistance production | Quel est le processus en place pour que Chrome traite les problèmes techniques de la Privacy Sandbox et les escalades qui affectent l'écosystème ? | Google fournit une gamme de canaux permettant aux technologies publicitaires de signaler les problèmes techniques et de faire remonter ces problèmes de manière appropriée. De plus, Chrome s'attend à développer et à faire évoluer un processus pour résoudre les problèmes techniques et les escalades affectant la santé de l'écosystème. Chrome s'engage à fournir les ressources nécessaires à cet effort. 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. |
| Modes de test gérés par Chrome | En savoir plus sur les délais et les implémentations exactes des modes de test gérés par Chrome | Nous avons publié un article de blog sur les modes de test. Nous nous efforçons de partager plus d'informations prochainement. Nous accueillons des suggestions concernant la taille des libellés du mode test. |
| Intégration avec d'autres normes du secteur | Les API Privacy Sandbox se connecteront-elles au TCF v2.* et au mode Consentement, ou aux deux ? | Nous ne prévoyons pas d'intégrer directement les API Privacy Sandbox dans la version 2 du TCF ou le mode Consentement. Toutefois, les entreprises et les groupes professionnelles du secteur sont invités à adapter leurs produits et leurs frameworks pour qu'ils fonctionnent conjointement avec les API Privacy Sandbox. Par exemple, avec des frameworks tels que le TCF, chaque participant doit déterminer sa propre approche de conformité en fonction du signal TCF qu'il reçoit et des règles TCF associées. Nous attendons des entreprises qu'elles déterminent quand et comment utiliser les différentes fonctionnalités proposées par les composants de la Privacy Sandbox. |
Inscription et attestation
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Restriction | Le processus d'inscription permet à Google de décider quelle entreprise de l'écosystème est autorisée à utiliser les API Privacy Sandbox. | Le processus d'inscription et d'attestation implique essentiellement la validation de l'entité (par exemple, l'entité dispose d'un numéro DUN, peut fournir un lien vers des règles de confidentialité, etc.) et fait de l'attestation publique une exigence pour l'appel des API. Les entités qui remplissent correctement les conditions d'inscription seront validées. Pour les entreprises qui n'ont pas de DUN, nous proposons à Dun & Bradstreet une procédure accélérée et sans frais pour en acquérir un. L'objectif est d'améliorer la protection de la confidentialité des API (selon les mesures que nous venons de citer) et d'ajouter une couche de transparence aux API Privacy Sandbox, afin que les parties intéressées puissent mieux comprendre qui utilise quelle API et quelles attestations sont émises. Nous sommes ouverts à davantage de commentaires du secteur sur ce problème, qui ont déjà été utilisés pour façonner le processus. |
| Frais de réenregistrement | Le fichier d'attestation expire tous les 12 mois et nécessite le réenregistrement des sites Web. | Nous avons tenu compte des commentaires de l'écosystème et avons modifié notre approche en conséquence. Cela signifie que les fichiers n'expirent plus après 12 mois ou une période donnée. Nous mettons à jour notre guide du développeur sur l'inscription en y ajoutant des informations supplémentaires. |
| Fichier d'attestation | Comment le fichier d'attestation est-il utilisé ? | Avant la date limite d'application, toutes les entreprises qui appellent des API de pertinence et de mesure devront importer le fichier d'attestation sur leur site et le conserver pour le public tant que vous prévoyez de continuer à appeler les API. Les sites Web peuvent s'attendre à recevoir environ une requête par heure de la part de la Privacy Sandbox, mais aussi à d'autres entités potentielles. Pour ce faire, le mécanisme propre au système d'enregistrement permet d'interroger les serveurs des entités enregistrées et de s'assurer que le fichier d'attestation est valide. Les attestations seront incluses dans les rapports "Transparence des informations" et visibles par le grand public. Nous attendons des entreprises qu'elles agissent conformément à leurs attestations déclarées, de même que le reste de l'écosystème et les organismes de réglementation compétents. |
| Inscription | Les inscriptions sont-elles effectuées par site ou par origine ? | L'inscription est effectuée au niveau du site. |
Diffusez des annonces et des contenus pertinents
Sujets
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Performances | Préoccupations concernant l'impact du taux d'activation de Topics dans l'Espace économique européen | Nous suggérons aux personnes concernées concernées de contacter l'autorité chargée de la protection des données au sujet de ce problème. Ils sont mieux placés pour répondre à ces préoccupations et déterminer si l'application de technologies qui renforcent la confidentialité est incitée par la loi ou traitée comme un suivi, ce qui nécessite la même approche en termes de consentement. Sinon, des API comme celles de la Privacy Sandbox risquent de ne pas être disponibles aussi souvent. |
| Inscription | Les enchérisseurs en aval doivent-ils s'inscrire à l'API Topics pour utiliser les signaux Topics des SSP en amont ? | Il n'est pas nécessaire d'enregistrer les destinataires en aval des sujets au-delà de l'appelant initial de l'API Topics, mais beaucoup sont susceptibles de l'être pour d'autres utilisations de l'API. Une liste des inscrits à la Privacy Sandbox sera fournie par programmation dans le cadre des efforts de transparence du programme, ce qui permettra à un appelant intéressé de l'API Topics de vérifier si le destinataire auquel il envoie un sujet est inscrit, s'il le souhaite. |
| Filtrage des thèmes | Demandez à appliquer le filtrage d'un autre appelant aux thèmes qu'il récupère sur la page, afin de ne partager que les acheteurs susceptibles de récupérer. | Nous étudions cette demande et nous aimerions recevoir des commentaires supplémentaires de la part de l'écosystème. |
| Exclusion de sites | Excluez des sites Web de la contribution aux thèmes d'un utilisateur. | Les thèmes ne sont pas appelés par défaut. Il est important de noter qu'aucun contenu de la page n'est pris en compte lorsque des thèmes sont sélectionnés, et que tous les thèmes sont sélectionnés pour garantir qu'ils ne sont pas sensibles. Un site Web peut également l'empêcher d'être inclus dans le calcul des thèmes via l'en-tête de règle d'autorisation suivant: Permissions-Policy:
browsing-topics=() |
| Observation des thèmes | Autorisez les éditeurs à autoriser Chrome à classer les thèmes en fonction du contenu de la page (par exemple, la tête ou le corps). | Nous avions envisagé de proposer une fonctionnalité permettant de classer les sites par thèmes en fonction du contenu de la page. Nous avons pris la décision de ne pas continuer, compte tenu des préoccupations concernant la confidentialité et la sécurité. Cette proposition peut atténuer certaines de ces préoccupations, mais elle n'est pas claire dans quelle mesure. En raison de la période de test de la CMA à venir, ce changement ne devrait pas se produire avant la 3PCD. N'hésitez pas à nous faire part de vos commentaires. |
| Observation des thèmes | Fournir des règles d'autorisation plus précises pour les éditeurs. | Fournir des règles d'autorisation plus précises pour les éditeurs permettrait à leurs sites d'avoir un impact négatif sur l'utilité de l'API Topics dans son ensemble, sans que cela n'affecte l'utilité de l'API Topics pour le site lui-même. Pour obtenir des informations plus détaillées à ce sujet, consultez la section Mettre à jour la stratégie d'autorisations pour prendre en charge des autorisations distinctes pour la récupération et l'observation du problème GitHub. |
| Sujets médicaux et de santé | Pourquoi la classification des thèmes ne couvre-t-elle pas les thèmes des catégories "Médecine" ou "Santé" ? | Les catégories médicales et de santé sont considérées comme des sujets sensibles et sont donc exclues de la classification Topics. |
| Récupération de thèmes | Moyen plus rapide pour les DSP d'obtenir des thèmes sans les récupérer à l'aide d'en-têtes. | Les méthodes d'en-tête sont plus performantes et moins coûteuses que la création d'un iFrame multi-origine et un appel document.browsingTopics() à partir de celui-ci. Un iFrame multi-origine doit être utilisé pour l'appel, car le contexte de premier niveau permettant d'observer un sujet doit correspondre au contexte à partir duquel les sujets sont accessibles. Ce point a été expliqué en détail ici. |
| Récupération de thèmes | Requêtes permettant la transmission de thèmes via des en-têtes dans des requêtes de tags de script multi-origines | Du point de vue de la sécurité, cela n'est pas possible. Chaque document et son environnement d'exécution sont associés à une seule origine, à savoir celle du document. Les sous-ressources tierces chargées et exécutées dans cet environnement sont considérées comme appartenant à l'origine du document. Cela permet d'éviter les fuites de données non autorisées d'une origine à une autre. Vous pouvez également fournir un attribut browsingTopics sur les balises <script>. Elle doit être claire du point de vue de la sécurité et ne doit pas ajouter de latence supplémentaire. N'hésitez pas à nous faire part de vos
commentaires. |
| Notoriété | Améliorez la notoriété de l'API Topics et son utilisation auprès du public. | Nous avons échangé avec la personne qui nous a transmis ces commentaires, et le problème a été résolu sur GitHub.
À l'avenir, nous continuerons à aider l'écosystème à comprendre l'API et nous avons hâte de connaître le point de vue des personnes concernées. En attendant, nous recommandons aux personnes qui souhaitent en savoir plus sur l'API Topics de se familiariser avec la documentation du guide du développeur Chrome. |
| Notification | Notification visant à alerter l'utilisateur lorsque ses Topics sont observés par un site Web. | Nous avons traité ces commentaires sur GitHub. Pour en savoir plus sur les commandes Topics, les utilisateurs peuvent consulter le Centre d'aide Chrome. |
| Machine learning | Comment utiliser le ML pour déduire les Topics utilisateur ? | Nous sommes en train d'examiner ce problème et nous invitons à nous faire part de tout commentaire supplémentaire. |
| Utilité pour les différents types de partenaires | Les petites entreprises de technologie publicitaire peuvent ne pas être en mesure d'observer Topics en raison de la façon dont les navigateurs les calculent. | Seules les technologies publicitaires ayant observé l'utilisateur ayant consulté une page sur le thème en question au cours des trois dernières semaines recevront un thème. Si la technologie publicitaire n'a pas appelé l'API au cours des trois semaines précédentes pour cet utilisateur sur un site consacré à ce thème, la valeur renvoyée sera vide. Avec cette fonctionnalité, les technologies publicitaires dont les services sont utilisés par un plus grand nombre de propriétaires de sites, et qui ont donc plus d'occasions d'observer une visite du site par un utilisateur donné, peuvent recevoir plus de thèmes que d'autres technologies publicitaires. Cette fonctionnalité est essentielle pour la protection de la confidentialité de l'API, car elle limite la disponibilité des informations sur un utilisateur aux seules parties qui sont déjà en mesure d'observer les mêmes informations sous-jacentes (actuellement via des cookies tiers). |
| Requête XHR | Quand l'inclusion de Topics dans les requêtes XMLHttpRequest (XHR) sera-t-elle abandonnée ? |
Comme annoncé en août 2023, Chrome a commencé à abandonner la compatibilité avec XHR lors du passage de la phase d'évaluation à la disponibilité générale. Avec la montée en puissance de Topics, la compatibilité XHR n'a été incluse que pour les utilisateurs pour lesquels les fonctionnalités OT étaient activées. Elle a été complètement abandonnée lors de la fusion des groupes de test OT individuels. Si vous utilisiez Topics avec XHR, vos sites fonctionneront correctement. Les thèmes ne seront tout simplement pas ajoutés à vos en-têtes de requête XHR. Nous vous recommandons de passer à fetch pour votre requête, d'utiliser l'attribut iFrame ou d'utiliser l'API JavaScript pour récupérer les thèmes. La récupération est compatible avec tous les navigateurs récents, mais pas avec Internet Explorer ni Opera Mini. |
| Processus de mise à jour des taxonomies et des classificateurs | Vous trouverez plus d'informations sur la fréquence de publication de la classification et du classificateur Topics, ainsi que sur la manière dont les entreprises peuvent se préparer à ces mises à jour. | Notre réponse reste la même depuis le 2e trimestre: Comme indiqué dans notre article de blog récent, nous nous attendons à ce que la taxonomie évolue au fil du temps, et que sa gouvernance finisse par être transférée à une partie externe représentant les intervenants de l'ensemble du secteur. Nous avons également partagé le plan d'activation progressive dans le groupe Topics-announce. |
| Utilisation abusive | Attaque potentielle via une chaîne de redirection. | Nous envisageons de résoudre ce problème et nous vous invitons à nous faire part de vos commentaires. |
| Types d'inventaires de l'éditeur | Quels types d'inventaires de l'éditeur les tests Protected Audience et Topics prendront-ils en charge ? | Ni Protected Audience ni Topics ne sont intrinsèquement restrictifs en termes de types d'inventaires sur lesquels ils peuvent être utilisés. |
| Délai d'activation | Aucun délai d'activation n'est recommandé pour que les nouvelles taxonomies atteignent 100%. | Suite à cette demande de commentaires de l'écosystème et à la discussion lors des réunions du PATCG, nous avons annoncé notre plan de déploiement de la nouvelle taxonomie. |
API Protected Audience (anciennement FLEDGE)
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Enchères de premier niveau | Possibilité d'utiliser l'ad server éditeur de Google sans donner à Google Ad Manager le contrôle des enchères de premier niveau de l'API Protected Audience. | Réponse fournie par Google Ad Manager: Les plans de Google Ad Manager pour l'API Protected Audience n'incluent pas la compatibilité avec l'ad server des éditeurs Google sans le contrôle du système d'enchères de premier niveau Protected Audience, pour les raisons suivantes. Afin de bien servir nos clients sur le marché de la diffusion d'annonces pour les éditeurs, l'ad server éditeur de Google doit conserver le contrôle du système d'enchères Protected Audience de premier niveau. En tant qu'ad server éditeur, notre rôle consiste à fournir aux éditeurs des prévisions afin qu'ils puissent négocier des campagnes vendues directement sans surréservation, et réguler et diffuser leurs réservations directes de manière optimale. Pour ce faire, vous devez lancer la mise aux enchères finale afin de comparer toutes les demandes directes et indirectes éligibles. Les prévisions et le rythme sont des fonctionnalités essentielles que les éditeurs attendent d'un ad server. Sans prévisions précises, les éditeurs risquent de survendre leur inventaire, ce qui met en péril la réputation de leur entreprise. Le rythme est également essentiel, car si vous ne parvenez pas à remplir les contrats de réservation avec les annonceurs, la relation directe éditeur-annonceur risque d'être nuisible, ce qui pourrait avoir des répercussions importantes sur l'activité des éditeurs. En résumé, l'activité d'un ad server de l'éditeur, qui consiste à exécuter la mise aux enchères Protected Audience de premier niveau, ne se distingue pas des autres activités de l'ad server de l'éditeur. |
directFrom |
directFrompermet à Google Ad Manager d'empêcher l'éditeur de voir le prix de son enchère contextuelle. |
Réponse de Chrome: Les informations transmises dans runAdAuction() ne proviennent pas du vendeur, sauf si celui-ci appelle runAdAuction() à partir de son propre iFrame. Dans une mise aux enchères multivendeur, il devient impossible que tous les vendeurs créent le frame en appelant runAdAuction(). directFromSellerSignals a résolu ce problème en chargeant du contenu à partir d'un groupe de sous-ressources chargé depuis l'origine d'un vendeur. Cela garantit que l'authenticité et l'intégrité des informations transmises lors d'une mise aux enchères à partir des configurations des enchères du vendeur ne peuvent pas être manipulées. Si les éditeurs souhaitent utiliser l'API Protected Audience pour comprendre les informations que leurs fournisseurs technologiques transmettent aux enchères Protected Audience, ils peuvent demander cette fonctionnalité à ces fournisseurs.Réponse fournie par Google Ad Manager: Depuis des années, nous accordons une grande importance à l'équité des enchères. Par exemple, nous nous sommes engagés à ce qu'aucun prix issu des sources publicitaires non garanties d'un éditeur, y compris les prix des éléments de campagne non garantis, ne soit communiqué à un autre acheteur avant d'enchérir. Nous avons ensuite réaffirmé nos engagements envers l'Autorité française de la concurrence. Pour les enchères Protected Audience, nous souhaitons tenir nos promesses en exploitant directFromSellerSignals et en ne partageant l'enchère d'un participant à l'enchère avec aucun autre participant avant la fin de l'enchère dans les enchères multivendeurs. Précisons que nous ne partagerons pas non plus le prix de l'enchère contextuelle avec notre propre mise aux enchères, comme expliqué dans la mise à jour intitulée Précisions concernant la dynamique des enchères principales. |
| Exposition à l'information | Le navigateur peut exposer la logique métier et les détails contractuels sensibles. | L'utilisateur d'un navigateur Web peut voir tout ce qui se passe dans le navigateur. Lorsqu'une enchère publicitaire a lieu dans le navigateur, il est vrai que la personne qui l'a créée peut la regarder, y compris voir combien les différentes parties choisissent d'enchérir. Le navigateur étant l'agent de l'utilisateur, nous ne pensons pas qu'il soit possible ou souhaitable d'essayer de modifier cela. Toutefois, seule l'utilisateur du navigateur a une visibilité sur ces opérations. Une enchère sur l'appareil exécutée à l'aide de l'API Protected Audience n'est visible par aucun serveur, y compris celui de Google. |
PerBuyerExperiment |
La plage de valeurs actuelle de PerBuyerExperimentpourrait permettre aux acheteurs de corréler les données contextuelles avec la requête du serveur de confiance. |
L'utilisation de l'API Protected Audience de cette manière va à l'encontre de l'attestation obligatoire de la Privacy Sandbox indiquant que les utilisateurs de l'API n'essaieront pas de contourner les protections de la Privacy Sandbox. À l'avenir, l'exécution des serveurs de clés-valeurs dans des environnements d'exécution sécurisés (TEE) fournira une protection technique contre cette attaque. |
| Règles d'origine identique | Assouplissez la règle d'origine commune pour autoriser les sous-domaines. | Nous examinons cette demande et sommes ravis de recevoir d'autres commentaires de la part de l'écosystème. |
| Gestion des versions de l'API | Requête de gestion des versions et notes de version concernant les modifications apportées à l'API Protected Audience. | Nous examinons cette demande et sommes ravis de recevoir d'autres commentaires de la part de l'écosystème. |
| Enchères sur plusieurs SSP | Autorisez les signaux d'enchères de premier niveau à effectuer des fusions JSON avec le signal de composant auctionSignals. |
Nous examinons cette demande et sommes ravis de recevoir d'autres commentaires de la part de l'écosystème. |
| Limite d'enchère | Faites passer de 20 à 40 la limite du nombre de composants d'annonce entrant dans l'enchère. | Nous examinons cette demande et nous aimerions vous faire part de commentaires supplémentaires de l'écosystème sur l'utilité de cette fonctionnalité. |
| (également pris en compte lors des trimestres précédents) Performances des enchères Protected Audience |
indiquent aux testeurs que les enchères Protected Audience ont une latence élevée. | En ce qui concerne la latence, l'API Protected Audience a généralement suivi le paradigme standard existant : créer des contrôles permettant aux vendeurs de déterminer le temps et les ressources que les enchérisseurs peuvent utiliser, et créer des outils permettant aux acheteurs de décider de la meilleure façon d'utiliser les ressources qui leur sont mises à leur disposition. Ces contrôles et outils sont généralement disponibles aujourd'hui, mais leurs avantages ne se concrétiseront pleinement qu'après leur adoption par les acheteurs et les vendeurs. En outre, Chrome continue de travailler sur diverses améliorations de l'infrastructure visant à accélérer la vitesse des enchères (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Nous vous invitons à nous faire part de vos commentaires sur les deux parties de cet effort de latence: de nouveaux outils utiles aux acheteurs et aux vendeurs, et des rapports sur les goulots d'étranglement observés que les ingénieurs de Chrome doivent étudier. |
| Filtrage côté achat | Ajout de la prise en charge du filtrage côté achat en fonction des groupes de centres d'intérêt. | Nous avons suggéré plusieurs façons pour les SSP et les DSP de modifier leur conception pour gérer cela:
|
| Contrôle des groupes d'intérêt des éditeurs | Assistance pour les éditeurs qui souhaitent déléguer l'utilisation de groupes de centres d'intérêt créés par les éditeurs. | Nous avons engagé des discussions avec de nombreuses parties au sujet de cette demande. Nous pensons que tous les cas d'utilisation impliquant la "délégation" des groupes de centres d'intérêt créés par l'éditeur peuvent être pris en compte dès maintenant. De plus, nous devrions proposer une assistance supplémentaire afin de faciliter le déroulement de certains cas d'utilisation à l'avenir. |
| (également indiqué au 2e trimestre) Environnements d'exécution sécurisés | Compatibilité avec les environnements d'exécution sécurisés (TEE) dans les environnements cloud non publics. | Notre réponse est semblable aux trimestres précédents: Bien que nous continuions à étudier la possibilité d'autres options que les solutions basées sur le cloud public, nous ne prévoyons actuellement pas de prendre en charge les TEE sur site. À ce stade, compte tenu des exigences de sécurité de la Privacy Sandbox et des défis importants que posent les déploiements sur site, nous sommes convaincus que continuer à développer et à améliorer les déploiements dans le cloud (par exemple, en prenant en charge Google Cloud en plus d'AWS) est le plus bénéfique pour l'écosystème. Toutefois, nous aimerions recevoir des commentaires supplémentaires expliquant pourquoi une telle exigence est nécessaire et réalisable compte tenu des contraintes de confidentialité et de sécurité. |
| un environnement d'exécution fiable | Les composants du chemin de diffusion TEE, tels que l'équilibreur de charge, peuvent observer tout le trafic et obtenir des informations sur l'adresse IP de chaque requête. | Actuellement, l'adresse IP est transmise en tant que métadonnées dans les en-têtes de requête au service publicitaire du vendeur non approuvé, tant pour les enchères que pour les enchères Protected Audience sur l'appareil. Pour en savoir plus, consultez la section Transfert de métadonnées. À long terme, nous prévoyons de transmettre par proxy une technologie publicitaire et de suivre le trafic via un proxy IP, ce qui empêchera les composants d'observer l'ensemble du trafic sur le chemin de diffusion. |
| Valeur TTL (Time To Live) | La valeur TTL (Time To Live) avant que les services doivent demander de nouvelles clés sera-t-elle définie ou est-elle censée être flexible (ou dynamique) ? | La valeur TTL est généralement statique. Actuellement, la valeur TTL pour le public est de huit jours, et la rotation a lieu tous les sept jours. La valeur TTL est également la même pour les clés privées dans le cas du service d'agrégation. Dans le cas des services d'enchères et de mise aux enchères, les clés privées et publiques sont extraites toutes les N heures dans le chemin sans requête et mises en cache en mémoire. Il n'y a donc pas plus de N heures entre la rotation des clés et la récupération de ces clés par les serveurs. La marge d'un jour entre la rotation et l'expiration des clés permet de s'assurer que les services peuvent continuer à fonctionner même si la génération des clés échoue. Nous envisageons d'étendre la valeur TTL pour plus de résilience en cas de panne. En cas de fuite de clé, nous prévoyons de forcer manuellement la génération des clés et de les invalider plus rapidement. Notez que les clés publiques sont mises en cache sur les clients, actuellement pendant 24 heures, afin de garantir que les services continuent de fonctionner en cas de panne du coordinateur. |
| lissage du trafic | Compatibilité avec le lissage du trafic pour les services d'enchères et de mise aux enchères. | En fonction des données first party de l'éditeur ou des données contextuelles de l'éditeur, les acheteurs peuvent indiquer une demande d'enchères Protected Audience. Les vendeurs peuvent également prendre des décisions similaires sur l'ad server ou le serveur Ad Exchange du vendeur. Les modèles peuvent être entraînés sur des données propriétaires et n'importe quel rapport agrégé des enchères Protected Audience. Les vendeurs peuvent utiliser ces informations pour éviter d'envoyer des requêtes aux serveurs d'enchères et de mise aux enchères lorsqu'il n'y a pas de demande d'enchères Protected Audience. Nous pensons que cela peut être un moyen efficace de façonner le trafic. |
| Enchères d'éléments individuels | Quels signaux d'enchères de premier niveau sont partagés avec les vendeurs de composants ? | Les acheteurs participant à une mise aux enchères de composants ne reçoivent que des signaux du vendeur de composants. Nous souhaitons partager prochainement une documentation sur la séquence globale d'une mise aux enchères combinée avec des enchères d'en-tête et une mise aux enchères Protected Audience. |
| Rendu vidéo | Prise en charge du rendu vidéo à l'aide de Protected Audience et des Fenced Frames. | L'API Protected Audience prend en charge le rendu vidéo à l'aide d'un mécanisme basé sur des iFrames. Cependant, nous n'avons pas encore conçu de solution compatible avec Fenced Frames, et c'est l'une des raisons pour lesquelles nous avons décidé de repousser l'application de Fenced Frames à 2026. Cela signifie que si un partenaire décide d'appliquer Fenced Frames maintenant, il ne sera pas compatible avec la vidéo. |
| Limitation de la fréquence d'exposition | (également disponible lors des trimestres précédents) Contrôles de la fréquence par utilisateur dans une campagne et un groupe d'annonces. |
Notre réponse reste la même que dans les rapports précédents: Protected Audience est compatible avec la limitation de la fréquence d'exposition pour les enchères sur l'appareil, ainsi que pour les campagnes contextuelles et de branding. Le stockage partagé et les limites spécifiques aux sites peuvent également être utilisés pour des contrôles supplémentaires de la limitation de la fréquence d'exposition. |
| Préférences pour les annonces | L'API Protected Audience permet-elle de désactiver les cookies ou de les ajouter à la liste de blocage par site d'annonceurs, ou de laisser tous les groupes de centres d'intérêt du même propriétaire ? | Les utilisateurs peuvent bloquer l'accès à l'API Protected Audience et à d'autres fonctionnalités de la Privacy Sandbox de plusieurs façons. |
| Règle d'origine identique pour l'URL source des scripts d'enchères et d'enchères | Assouplissez l'exigence selon laquelle tous les champs spécifiant des URL pour le chargement de scripts ou de fichiers JSON doivent avoir la même origine que le propriétaire. | Nous examinons actuellement cette demande et nous souhaitons vous faire part d'autres commentaires de la part de l'écosystème. |
forDebuggingOnly |
Risque d'utilisation abusive de forDebuggingOnly s'il reste après le format 3PCD. |
Ces dernières années, nous avons reçu des commentaires de l'écosystème concernant les lacunes de fonctionnalité dans Protected Audience une fois les cookies tiers abandonnés. Nous travaillons à élaborer un plan pour les prendre en charge après la 3PCD sans compromettre les objectifs de la Privacy Sandbox. N'hésitez pas à nous faire part de vos suggestions et de vos commentaires sur les fonctionnalités manquantes que l'écosystème souhaiterait voir. |
| Plusieurs groupes de centres d'intérêt | Utiliser plusieurs groupes de centres d'intérêt dans la même enchère | Cette fonctionnalité n'est pas compatible avec l'API Protected Audience à l'heure actuelle, car cela entraînerait une modification du modèle de confidentialité sous-jacent. N'hésitez pas à consulter cette page pour en savoir plus. |
| Enchères sur l'appareil | Chrome sur Android acceptera-t-il les enchères Protected Audience sur l'appareil ? | Oui, les enchères sur les appareils seront proposées dans Chrome sur Android. |
| (selon le T2 2023) Données sur les clics | Ajout des données sur les clics dans browserSignals. | Nous continuons d'évaluer cette demande de fonctionnalité et nous invitons à nous faire part de commentaires supplémentaires sur les raisons pour lesquelles cette fonctionnalité doit être prioritaire. |
| Fournisseurs d'environnements d'exécution fiables | Existe-t-il des différences substantielles entre les offres d'environnement d'exécution sécurisé des différents fournisseurs cloud ? | Nous n'avons connaissance d'aucune différence majeure, mais nous recommandons à l'écosystème de consulter les guides de déploiement publics pour déterminer la solution qui répond le mieux à ses besoins. Google Cloud. AWS. |
| (Comparé les trimestres précédents) Compatibilité avec le ciblage par groupes de centres d'intérêt à exclure |
API compatible avec le ciblage par groupes de centres d'intérêt à exclure: diffusion d'annonces uniquement si un utilisateur n'appartient pas à un groupe de centres d'intérêt. | Nous étudions la possibilité de mettre en œuvre cette fonctionnalité et discutons de cette demande. |
| Non-respect du règlement relatif au contenu | Prise en charge des fonctionnalités qui permettent aux utilisateurs de signaler les annonces inappropriées diffusées par l'API Protected Audience dans Fenced Frames. | Nous pensons que le mécanisme existant de création de rapports sur les annonces Fenced Frame offre de bonnes options pour les technologies publicitaires qui souhaitent un flux de rapports "Annonces indésirables" généré par l'utilisateur. Cela permettrait de générer des rapports sur les annonces indésirables, d'une manière pratiquement inchangée par rapport à la norme du secteur actuelle. Nous acceptons les demandes de fonctionnalités supplémentaires si des lacunes subsistent, y compris pendant la période qui suit la suppression des cookies tiers, mais avant que le rendu Fenced Frame ne se généralise. |
| Rapports de l'API Private Agrégation | Comment pouvons-nous calculer le temps que l'utilisateur a passé dans ce groupe de centres d'intérêt ? | Dans Chrome M116 et versions ultérieures, vous devriez pouvoir utiliser la récence définie par pull/639. |
| Serveur K-Anonymity | En savoir plus sur le serveur K-Anonymity. | Nous avons partagé plus d'informations sur les serveurs K-Anonymity et nous aimerions connaître votre avis. |
| URL de créations dynamiques | Prise en charge des URL de création sans prédéclaration, tout en respectant le k-anonymat. | Nous discutons de cette demande de fonctionnalité et nous aimerions vous faire part de commentaires supplémentaires sur les raisons pour lesquelles cette fonctionnalité doit être prioritaire. |
| Exigence k-anonymat | L'exigence de k-anonymat sera-t-elle réintégrée dans les mises à jour apportées aux groupes d'intérêt ? | Nous ne prévoyons aucun changement de position dans cet article GitHub. Comme annoncé dans cet article, nous avons décidé de supprimer l'exigence de k-anonymat pour les mises à jour des groupes de centres d'intérêt de l'API Protected Audience, qui n'a pas d'impact significatif sur la protection globale de la confidentialité de l'API. Nous prévoyons d'envisager d'autres protections directes potentielles (comme la confidentialité des adresses IP ou un serveur de mise à jour fiable) à une date ultérieure, lorsque les technologies associées seront davantage développées, déployées et adoptées. |
| Test bêta des services d'enchères et de mise aux enchères | Quand débutera les tests bêta des services d'enchères et de mise aux enchères ? | Comme indiqué dans le calendrier et la feuille de route, la première phase des tests des services d'enchères et de mise aux enchères commencera en novembre 2023. |
| Créations synchronisées | Demande de coordination des créations pour les réseaux publicitaires (SSP et DSP appartiennent à la même entreprise ou aux mêmes propriétés). | Nous apprécions vos commentaires concernant ce cas d'utilisation, et nous souhaitons savoir si d'autres technologies publicitaires souhaitent que cette fonctionnalité soit compatible. N'hésitez pas à nous envoyer tout commentaire supplémentaire. |
| Publicité native | Prise en charge de Fenced Frame pour la publicité native. | Nous envisageons de prendre en charge ce cas d'utilisation et de envisager des solutions et solutions alternatives. |
| K-anonymat | Comment optimiser les annonces liées à des groupes de centres d'intérêt qui atteignent les seuils de k-anon ? | Nous avons partagé des conseils tactiques à ce sujet. |
| Compatibilité POST | Prise en charge de l'envoi de données d'enchères via des requêtes POST. | Nous évaluons cette demande de fonctionnalité et nous accueillons d'autres envois de problèmes GitHub pour expliquer pourquoi cette fonctionnalité doit être traitée en priorité. |
| Précision des rapports | Quelle est la précision des rapports sur les annonces Fenced Frame avec des annonces composées de plusieurs éléments ? | La conception actuelle ne permet pas de capturer l'ID ou la position du produit, car cela peut compromettre la confidentialité des utilisateurs. Seul reserved.top_navigation peut être appelé. Il est envoyé en cas d'activation de l'utilisateur (par exemple, un clic) sur le frame cloisonné du composant d'annonce, ce qui entraîne une navigation de premier niveau. |
| Mise en concurrence des annonces | Une SSP participant à une mise aux enchères de composants peut-elle déclencher elle-même une autre mise aux enchères de composants ? | Un élément componentSeller ne peut pas également inclure componentAuctions.Le système d'enchères multivendeurs ne comporte que deux niveaux: 1. Mise aux enchères des composants en parallèle 2. L'enchère de premier niveau (où l'annonce gagnante de chaque componentAuction est en concurrence). |
| Disponibilité des services d'enchères et de mise aux enchères | Les enchères et les enchères seront-elles disponibles pendant la phase de test facilitée par Chrome ? | Le serveur d'enchères et de mise aux enchères n'est pas disponible pendant la phase de tests facilités par Chrome. |
| Signaux d'enchères | Autorisez les navigateurs à demander et à supprimer des signaux d'enchères. | Nous discutons de cette demande et nous vous invitons à nous faire part de vos commentaires sur les raisons pour lesquelles cette demande doit être traitée en priorité. |
generateBid() |
Possibilité de mettre à jour la valeur userBiddingSignals de "interestGroup" via updateURL. |
Nous examinons cette proposition et nous invitons à nous faire part de tout autre commentaire ainsi qu'à toute autre discussion. |
| Types d'inventaires de l'éditeur | Quels types d'inventaires d'éditeurs seront compatibles avec les tests Protected Audience et TOPICS ? | Ni Protected Audience ni Topics ne sont intrinsèquement restrictifs en termes de types d'inventaires sur lesquels ils peuvent être utilisés. |
| Intégration de serveur à serveur | L'intégration directe entre la SSP et la DSP est-elle requise pour Protected Audience ? | L'intégration directe entre la SSP et la DSP n'est pas nécessaire si la DSP n'a pas besoin de traiter les signaux contextuels dans son propre serveur afin de transmettre les informations traitées à sa fonction d'enchères sur l'appareil. |
Un champ bid_currency dans les enchères et mises aux enchères |
Compatibilité du champ bid_currency dans le service d'enchères et de mise aux enchères. |
Les enchères et mises aux enchères ne sont pas encore compatibles avec les bid_currency, mais nous prévoyons de les accepter d'ici fin janvier 2024. Consultez le calendrier. |
perBuyerSignals |
La taille de perBuyerSignals est-elle limitée ? |
Le nombre de signaux par acheteur n'est pas limité, mais l'envoi d'une trop grande quantité de données peut nuire aux performances du navigateur. |
| Cas d'utilisation intersites | Est-il possible d'utiliser les groupes de centres d'intérêt de l'API Protected Audience sur plusieurs sites Web ? | L'API Protected Audience n'est pas conçue pour de tels cas d'utilisation, comme expliqué dans turtledove/issues/282. |
| Requêtes HTTP de groupes de centres d'intérêt | Inclure l'objet Blob du groupe d'intérêt dans les en-têtes HTTP. | Nous envisageons d'examiner cette demande et nous vous invitons à nous faire part de vos commentaires. |
| Contrôle de la qualité des annonces | Perte du contrôle qualité des annonces lié aux informations intersites. | Nous les prenons en compte et nous vous invitons à nous faire part de tout autre commentaire. |
| Outils pour les développeurs Chrome | Les requêtes réseau Protected Audience sortantes doivent être visibles dans l'onglet "Network" (Réseau) des outils pour les développeurs Chrome. | Nous travaillons à l'activation de cette fonctionnalité dans l'onglet "Network" (Réseau). Nous vous invitons à nous faire part de vos commentaires supplémentaires sur les raisons pour lesquelles cette fonctionnalité doit être prioritaire. |
| un environnement d'exécution fiable | Quand les détails sur les métriques qui ont une incidence sur la confidentialité (et leur degré) seront-ils ajoutés à l'explication sur la surveillance de l'environnement d'exécution sécurisé ? | Nous sommes en train de mettre à jour l'explication avec ces informations. La mise à jour explicative sera disponible en novembre 2023. |
directFrom |
Pourquoi directFrom n'est-il pas empaqueté en tant que bundle Web ? |
Nous avons indiqué la raison de cette décision sur cette page. |
| Délégation d'impression | Existe-t-il un moyen viable de déléguer les impressions lorsque le résultat de la sélection d'un groupe de centres d'intérêt est une autre action de ciblage ? | Plusieurs enchères imbriquées ne sont pas compatibles avec nos objectifs de confidentialité pour deux raisons. Tout d'abord, lorsque le gagnant d'une mise aux enchères apparaît dans un cadre Fenced Frame, nos objectifs en matière de confidentialité pour Protected Audience incluent le rendu de la création qui en résulte sans connaître le contexte: l'URL de la page environnante ou le cookie propriétaire constituent un cas de non-respect de la confidentialité. Dans cet environnement, les enchères imbriquées ne sont pas viables. Ensuite, le modèle Protected Audience indique que le gagnant de chaque mise aux enchères doit se baser sur les données d'un seul site supplémentaire. Les enchères imbriquées constitueraient un moyen d'aggraver ce phénomène, ce qui donnerait la possibilité de choisir des annonces en fonction d'un profil sur plusieurs sites. |
| Critère des données au repos | Expliquer plus en détail le critère des données au repos dans le modèle de confiance du service clé-valeur. | Les données du service Key Values sont chargées en mémoire et diffusées à partir de là, au lieu d'effectuer une mise en cache en lecture seule. |
| Signal de données de l'acheteur | Une limite de taille est-elle définie pour les signaux buyer_data reçus des DSP ? |
Actuellement, le navigateur n'impose aucune limite pour les signaux buyer_data reçus des DSP. |
Mesurer les annonces numériques
Attribution Reporting (et autres API)
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Multi-appareil | Préparez la compatibilité multi-appareil pour l'API Attribution Reporting. | Les tests inter-appareils présentent de nouveaux défis en matière de confidentialité, en plus des 3PC, et ajoutent également des défis liés à la distribution des technologies, étant donné la gamme d'appareils et de plates-formes qu'un utilisateur peut utiliser. Nous étudions des solutions potentielles, mais nous nous concentrons sur les cas d'utilisation critiques actuellement pris en charge par Attribution Reporting et nous n'avons pas l'intention d'introduire une compatibilité multi-appareil avant la suppression des cookies tiers. |
| (Également indiqué aux trimestres précédents) Taille des données du déclencheur |
Pourquoi la taille des données du déclencheur est-elle limitée à 3 bits ? | La taille est limitée à 3 bits et à 8 valeurs distinctes pour garantir que la quantité d'informations intersites et inter-contextes concernant un utilisateur est limitée. Nous encourageons les joueurs de l'écosystème à envoyer leurs commentaires pour savoir si le paramétrage actuel des rapports au niveau des événements est suffisant. |
| Entonnoir de conversion | Signalez plusieurs domaines qui ont été utilisés lors de la conversion. | Ce cas d'utilisation est possible depuis l'ajout de plusieurs destinations. N'hésitez pas à nous envoyer tout commentaire supplémentaire. |
| Compatibilité avec le même domaine dans des pays différents | Attribution Reporting fonctionne-t-il avec les sites Web qui ont le même domaine, mais des TLD qui se trouvent dans plusieurs pays ? | Ce problème a été discuté et résolu avec le partenaire qui a soulevé la question. Si une technologie publicitaire doit utiliser plusieurs TLD nationaux, elle doit disposer de plusieurs inscriptions, un pour chaque TLD national. |
| Protected Audience et Attribution Reporting | Les technologies publicitaires peuvent-elles accéder à la fois aux conversions après affichage pour les enchères Protected Audience et aux conversions après clic pour Attribution Reporting ? | Oui, la Privacy Sandbox doit prendre en charge à la fois les VTC et les CTC dans Protected Audience. |
| Retards dans les rapports agrégables | Réduisez encore davantage le délai des rapports agrégables. | Nous avons récemment reçu des commentaires à ce sujet et nous avons partagé des idées ici. N'hésitez pas à nous faire part d'autres commentaires de la part de l'écosystème. |
| Retards dans les rapports agrégables | Réduction des délais grâce à la médiation sur serveur | Nous examinons cette proposition et attendons-nous de tout commentaire supplémentaire . |
| Retards dans les rapports au niveau des événements | Réduisez le délai de création des rapports au niveau des événements. | La proposition flexible complète au niveau des événements, décrite dans la section Configurations flexibles au niveau des événements, peut réduire le délai de création des rapports au niveau des événements jusqu'à une heure, tout en réduisant le bruit. |
| Origine des rapports par source | La limitation du nombre maximal d'origines de création de rapports sur les sources par site de création de rapports empêche les technologies publicitaires d'enregistrer des sources provenant de différentes origines de création de rapports pour une seule origine d'éditeur. | Ce point a été discuté avec le partenaire qui a soulevé le problème. Une solution potentielle consistant à utiliser une seule origine de création de rapport par site de création de rapports sur la source est testée avant d'essayer d'autres solutions potentielles impliquant des redirections. Nous sommes ouverts à tout autre commentaire de notre écosystème concernant cette limite. |
| Signaler des problèmes | Comment signaler les erreurs ou les problèmes liés à l'API Attribution Reporting dans Chrome ? | Actuellement, nous recommandons aux technologies publicitaires de signaler toute erreur de l'API Attribution Reporting qu'elles peuvent rencontrer en tant que problème sur GitHub. S'ils rencontrent un problème lié à Chrome, nous leur recommandons de créer un bug Chromium. Pour savoir où et comment signaler des problèmes, consultez la section Interagir et envoyer des commentaires. |
| Déduplication | Comment dédupliquer les conversions sur différents pipelines et appareils ? | La déduplication entre les appareils et les pipelines de mesure est un défi connu et actuel auquel les technologies publicitaires sont également confrontées aujourd'hui avec les 3PC. Avec l'API Attribution Reporting, les technologies publicitaires peuvent décider quand enregistrer des conversions spécifiques et ajouter des métadonnées spécifiques pour indiquer les pipelines de mesure qu'elles ont utilisés pour suivre les conversions (en d'autres termes, une partie de la clé d'agrégation), qui peuvent être comparées à d'autres pipelines de mesure. Nous sommes prêts à nous faire part de tout autre commentaire à ce sujet. |
| Déduplication et priorité | Demandez à être prioritaire avant la déduplication. | Nous examinons cette demande et nous vous invitons à nous faire part de tout autre commentaire. |
| Lutte contre la fraude | Risque de falsification des données au niveau des événements par des utilisateurs malveillants. | La vérification des rapports ne fonctionne pas pour la création de rapports au niveau des événements pour les raisons décrites dans la section Pourquoi cette fonctionnalité n'est-elle pas compatible avec les rapports au niveau des événements ?. |
| Type de conversion | Comment faire la différence entre la conversion après affichage et la navigation dans Attribution Reporting ? | L'option de filtrage intégrée suivante est disponible: source_type.
En savoir plus |
Service d'agrégation
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Récupération du budget | Certaines technologies publicitaires ont demandé à pouvoir retraiter les rapports en cas d'échec, d'erreur ou de suppression de leurs rapports. | L'équipe examine des moyens de résoudre ce problème tout en protégeant la confidentialité. |
| Enregistrement du site | Plusieurs technologies publicitaires ont demandé une assistance pour traiter plusieurs origines dans le même compte pour des cas d'utilisation tels que la répartition des données par zone géographique et annonceur. Ce comportement est également attendu par les technologies publicitaires, étant donné que l'inscription de l'API cliente est désormais basée sur le site (et non sur l'origine). La migration de l'enregistrement de l'origine vers le site simplifie le processus d'intégration des technologies publicitaires grâce à la cohérence avec le processus d'inscription du client. | Nous allons bientôt lancer la migration de l'enregistrement de l'origine à l'inscription de sites pour le service d'agrégation. Les commentaires de l'écosystème sont les bienvenus. |
| Plan de lancement et d'abandon | Calendrier de publication et d'abandon des fonctionnalités du service d'agrégation et des correctifs publiés. L'objectif de ce plan est d'offrir aux technologies publicitaires une visibilité sur nos règles de publication afin de leur permettre de se préparer aux versions à venir et aux abandons, et de s'assurer qu'elles exécutent des versions stables et sécurisées des services. | Nous avons récemment publié une proposition pour le plan de lancement et d'abandon du service d'agrégation. Vos commentaires supplémentaires sont les bienvenus. |
| Coordinateurs | Que se passe-t-il si les coordinateurs descendent dans le service d'agrégation ? | Les deux coordinateurs doivent être entièrement disponibles pour que le système fonctionne correctement. Dans nos bibliothèques clientes, les nouvelles tentatives peuvent être prises en compte lors de l'indisponibilité de courte durée ; si l'un des deux coordinateurs est indisponible, les tâches d'agrégation échoueront. Les tâches peuvent être réexécutées si le budget dédié à la confidentialité n'est pas encore consommé. Dans le cas où une défaillance du service a entraîné une consommation du budget sans qu'un rapport récapitulatif soit écrit dans le stockage de technologie publicitaire, nous recommandons actuellement d'utiliser des rapports de débogage pour récupérer les résultats à l'aide de l'outil de test en local. Nous travaillons également sur des fonctionnalités qui permettront de récupérer le budget en cas d'échec afin que les technologies publicitaires puissent réexécuter leurs tâches. |
API Private Agrégation
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| URL du blob | Requête de prise en charge de l'URL Blob dans le stockage partagé. | La prise en charge de l'URL Blob a été ajoutée dans Chrome M116. |
Limiter le suivi dissimulé
User-Agent Reduction et Hints client user-agent
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| API JavaScript | Disponibilité de l'API JavaScript User-Agent Client Hints. | Nous ne prévoyons pas de supprimer cette fonctionnalité, car il s'agit de notre solution de base pour les partenaires qui souhaitent accéder activement aux données à entropie élevée au-delà de ce qui est disponible par défaut dans les services UA figés et réduits. |
| Informations sur l'appareil et le facteur de forme | Capacité des sites Web à comprendre les entrées, les sorties et d'autres informations prises en charge par l'appareil qui consulte le site Web. | Nous avons ajouté cette demande suite aux commentaires de l'écosystème. |
Protection de l'adresse IP (anciennement Gnatcatcher)
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Trafic tiers éligible | À quoi correspond le "trafic tiers éligible" dans l'explication ? | Nous comprenons l'importance de cette question et nous nous efforçons d'identifier le trafic tiers éligible ou non. N'hésitez pas à nous faire part de vos commentaires à ce sujet. |
| Audits du trafic réseau | Assistance permettant aux entreprises d'effectuer des audits du trafic réseau pour leurs réseaux | Seul le trafic tiers intégré à des sites propriétaires sera affecté, ce qui devrait limiter la quantité de trafic nécessitant un filtrage. En outre, nous prévoyons de donner aux utilisateurs la possibilité d'utiliser ou non la protection de l'adresse IP. Pour les navigateurs Chrome contrôlés par l'entreprise, des règles d'entreprise permettront de désactiver cette protection. Enfin, nous étudions les contrôles (le cas échéant) qui seront fournis aux opérateurs réseau pour désactiver la protection de l'adresse IP. N'hésitez pas à nous faire part de vos commentaires à ce sujet. |
| Contrôle des accès | La protection des adresses IP peut affecter les services Web qui utilisent des adresses IP pour le contrôle des accès. | Nous comprenons l'importance des cas d'utilisation de lutte contre la fraude et leur impact potentiel. 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 lutte contre la fraude qui s'appuient généralement sur les adresses IP. |
| Communication entre les proxys à deux sauts | Comment vérifier qu'il n'y a pas d'informations entre les proxys | Nous sommes en train de concevoir les interactions proxy. Notre objectif est de réduire les chances de ce type de partage d'informations par le biais de moyens commerciaux, techniques et de processus. |
| Authentifications autres que Google | Prise en charge des authentifications autres que Google. | Nous prévoyons de publier plus d'informations sur l'authentification des comptes à l'avenir, même si nous avons partagé quelques considérations initiales. |
| Classification du coach électronique | Comment la protection de l'adresse IP détermine-t-elle ce qui constitue un traceur et ses variantes ? | Nous comprenons l'importance de cette question et nous nous efforçons d'identifier le trafic tiers éligible ou non. N'hésitez pas à nous faire part de vos commentaires à ce sujet. |
| Analyse | La protection de l'adresse IP peut affecter la précision des services d'analyse. | Nous cherchons à mieux comprendre l'impact de la protection de la propriété intellectuelle, et nous aimerions recevoir d'autres commentaires et exemples de l'écosystème. |
| Proxy | Si un utilisateur utilise un proxy ou a défini manuellement un proxy, comment le masque d'adresse IP fonctionnera-t-il dans ce cas ? | Nous cherchons à comprendre l'impact que la protection de l'adresse IP peut avoir sur les autres proxys. Nous n'avons pas l'intention de vous communiquer d'autres informations pour le moment. N'hésitez pas à nous faire part de vos commentaires à ce sujet. |
| Offre Premium | La fonctionnalité de protection de l'adresse IP sera-t-elle payante ? | La protection de l'adresse IP sera disponible pour les utilisateurs de Chrome dans le cadre de l'expérience de navigation principale. Cette fonctionnalité ne sera pas payante. |
| Serveur proxy | Les mêmes serveurs proxy seront-ils utilisés lors des sessions utilisateur ? | Une connexion HTTP/S utilise une seule paire de proxys et présente une seule adresse IP masquée à l'origine. En dehors de cela, il n'existe aucune contrainte stricte sur différentes connexions HTTP/S devant utiliser les mêmes serveurs. |
| Plates-formes compatibles | Sur quelle plate-forme la protection de l'adresse IP sera-t-elle disponible ? | La protection de l'adresse IP sera d'abord disponible dans Chrome pour Android et pour ordinateur. Nous continuons à réfléchir à la façon d'étendre la protection à d'autres plates-formes. |
| Désactiver | Les utilisateurs pourront-ils désactiver la protection de l'adresse IP ? | Nous prévoyons de permettre aux utilisateurs de choisir s'ils souhaitent ou non utiliser la protection des adresses IP. |
| Anonymisation | Quels types de demandes sont anonymisées dans le cadre de la protection de la propriété intellectuelle ? | Les requêtes HTTP/S et DNS adressées à des domaines tiers éligibles sont anonymisées via les proxys de confidentialité. Nous vous donnerons plus de détails dans une prochaine vidéo qui explique comment nous déterminerons les domaines à inclure. Le reste du trafic (par exemple, le reste des requêtes DNS ou tout autre trafic HTTP/S) n'est pas affecté. |
| Visibilité des données | Les adresses réseau sont accessibles lors du premier saut dans la protection des adresses IP. | Dans le modèle de proxy à deux sauts, le premier saut (contrôlé par Google) ne voit que l'adresse IP du client source et une requête de connexion au deuxième saut, tandis que le deuxième saut (contrôlé par un CDN externe) ne voit qu'un tuple au premier saut (adresse IP proxy + port) et à l'adresse IP de destination. Pour la réponse renvoyée à partir de l'origine, le deuxième saut peut transmettre la réponse au premier saut proxy+port associé à la requête et n'a pas besoin d'en savoir plus sur l'adresse IP du client d'origine (et le premier saut renvoie simplement la réponse au client, sans rien apprendre sur l'adresse IP de destination). De cette manière, le premier saut n'apprend que l'adresse IP du client et le deuxième saut, tandis que le second n'apprend que l'adresse IP de destination. |
| WebView | La protection de l'adresse IP sera-t-elle disponible pour Android WebView à l'avenir ? | Nous n'avons pas l'intention de partager cette protection pour le moment, mais nous souhaitons proposer cette protection le plus largement possible. |
Atténuation du suivi des rebonds
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Suivi des interactions | Comment les interactions des utilisateurs sont-elles suivies ? | Les mesures d'atténuation du suivi des rebonds permettent de suivre deux types d'interactions utilisateur:
Ces interactions sont associées au site de premier niveau sur les pages où elles se produisent. Par exemple, si un utilisateur clique dans un iFrame intégré, l'interaction est associée au site de premier niveau et non au site intégré. Les interactions sont stockées dans une base de données contenant le etld+1 sans schéma et l'heure de l'interaction. Les interactions protègent le domaine associé contre la suppression de l'état d'atténuation du suivi des rebonds pendant 45 jours. |
| Exceptions ajoutées à la liste d'autorisation | Les domaines peuvent-ils être exemptés ? | Nous envisageons d'examiner cette demande, et nous aimerions recevoir d'autres commentaires de l'écosystème. |
Privacy Budget
Nous n'avons reçu aucun commentaire ce trimestre.
Renforcez les limites de confidentialité intersites
Ensembles de sites Web associés (anciennement ensembles internes)
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Approche centralisée | Inquiétudes concernant l'approche du référentiel centralisé pour la gestion des ensembles de sites Web associés | Un dépôt public et facilement accessible est essentiel à la conception de RWS, car il permet la responsabilité des envois. La fonctionnalité de cookie tiers est finalement fournie par l'utilisation de l'API Storage Access ou rSAFor, l'adhésion RWS fournissant un accès autorisé automatiquement (par opposition aux invites avec l'API Storage Access). Nous pensons qu'une approche comme le processus d'envoi RWS constitue une exigence appropriée pour l'autorisation automatique de l'accès aux cookies tiers. |
| Renommer le fichier JSON | Avec le changement de nom de l'API, doit-il être modifié le nom du fichier JSON hébergé ? | Oui, les consignes d'envoi ont été modifiées et le domaine principal doit diffuser un fichier JSON à l'adresse /.well-known/related-website-set.json. Les ensembles existants dans la liste RWS n'ont pas besoin d'être modifiés, mais si des modifications sont soumises à des ensembles existants, le fichier JSON doit être modifié. |
| (Également signalé au cours des trimestres précédents) Limite par domaine | Demande d'augmentation du nombre de domaines associés | Comme annoncé dans un article de blog du 31 août, nous avons augmenté la limite des domaines associés à cinq domaines suite aux commentaires envoyés par l'écosystème. Nous avons décidé d'augmenter la limite des domaines associés à cinq domaines (plus un domaine principal), ce qui correspond le mieux à l'implémentation la plus comparable proposée par un autre navigateur majeur. |
| Cookies tiers | La fonctionnalité d'ensembles de sites Web associés ne fonctionnera-t-elle que si les cookies tiers sont désactivés ? | Les Ensembles de sites Web associés fonctionneront même si un utilisateur n'a pas bloqué les cookies tiers. Toutefois, il n'y aura aucun effet observable, car les cookies pertinents sont disponibles sans qu'il soit nécessaire d'utiliser les Ensembles de sites Web associés et l'API Storage Access. |
| Modifications légitimes | Comment le dépôt d'ensembles de sites Web associés empêche-t-il les non-propriétaires de modifier les ensembles ? | Conformément aux guides d'envoi, tout le monde peut envoyer une demande d'extraction sur GitHub pour modifier le fichier first_party_sets.JSON. Toutefois, si la demande d'extraction est approuvée (réussite de validations techniques, etc.), elle sera manuellement fusionnée par lots avec la liste canonique des FPS par Google une fois par semaine (les mardis à 12h, heure de la côte Est).Si un acteur malintentionné tente de modifier un ensemble dont il n'est pas propriétaire, cela ne devrait pas être un problème, car il ne pourra pas modifier les fichiers .well-known, et les validations échoueront donc. |
| Piratage de domaine | Le piratage de domaine peut exposer les données du domaine à des tiers non autorisés. | Cela n'est pas possible, comme indiqué dans ce problème GitHub de l'API Protected Audience. |
API Fenced Frames
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Non-respect du règlement relatif au contenu | Autoriser les utilisateurs à signaler les annonces suspectes | Fenced Frames ne permet pas d'empêcher les rapports sur les annonces suspectes. Les utilisateurs peuvent toujours interagir avec l'annonce et signaler les annonces suspectes à la technologie publicitaire comme d'habitude. |
| Interaction avec les sites environnants | Permettent l’interaction avec le site web environnant ou de premier niveau. | Nous cherchons à comprendre pourquoi cette demande est nécessaire et nous aimerions recevoir des commentaires supplémentaires de la part de l'écosystème. |
| Publicité native | Prise en charge de Fenced Frame pour la publicité native. | Nous envisageons de prendre en charge le cas d'utilisation et étudions d'éventuelles solutions et solutions. |
API Shared Storage
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Plusieurs domaines | Autorisez la communication entre les domaines pour le stockage local. | Ce cas d'utilisation n'est actuellement pas conforme aux portes de sortie protégeant la confidentialité du stockage partagé, mais nous apprécions des contextes supplémentaires à mesure que nous faisons évoluer les propositions de stockage non partitionné. |
| URL du blob | Requête de prise en charge de l'URL Blob dans le stockage partagé. | La prise en charge de l'URL Blob a été ajoutée dans Chrome M116. |
CHIPs
Nous n'avons reçu aucun commentaire ce trimestre.
FedCM
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Cookies tiers | FedCM est-il actuellement désactivé si les utilisateurs activent l'option"Bloquer les cookies tiers" dans les paramètres Chrome ? | Oui, FedCM est actuellement désactivé. Pour les tests, nous vous recommandons d'activer également chrome://flags/#fedcm-.Nous prévoyons de prendre en charge FedCM sans cookies tiers à l'avenir. |
Lutter contre le spam et la fraude
API Private State Token (et autres API)
| Feedback Theme | Résumé | Réponse Chrome |
|---|---|---|
| Expiration des jetons | Une fois Google Chrome désinstallé, le jeton sera-t-il perdu ou mis en cache ? | Le jeton sera perdu si l'utilisateur désinstalle Google Chrome. |
| Informations sur le jeton | Comment les émetteurs peuvent-ils garder les informations émises dans le jeton d'état privé privées ? | Les informations restent toujours privées dans le jeton et ne peuvent pas être déchiffrées par des tiers externes qui ne possèdent pas les clés. |
| Erreur lors de la démo | Erreur lors de la tentative d'exécution de la démo de jeton d'état privé. | Nous avons mis à jour la version de démonstration, qui devrait maintenant fonctionner correctement. |