Cette page a été traduite par l'API Cloud Translation.

Rapport de commentaires - T3 2023
bookmark_border Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Rapport trimestriel du troisième trimestre 2023 résumant les commentaires de l'écosystème reçus sur les propositions de la Privacy Sandbox et la réponse de Chrome.

Conformément à ses engagements envers la CMA, Google a accepté de publier des rapports trimestriels sur le processus d'engagement des partenaires pour ses propositions de Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des engagements). Ces rapports récapitulatifs sur les commentaires de la Privacy Sandbox sont générés en agrégeant les commentaires reçus par Chrome auprès des différentes sources listées dans la présentation des commentaires, y compris, mais sans s'y limiter: les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les personnes concernées du secteur et les forums sur les normes Web. Chrome accueille les commentaires reçus de l'écosystème et explore activement des moyens d'intégrer les enseignements dans les décisions de conception.

Les thèmes des commentaires sont classés en fonction de leur prévalence par API. Pour ce faire, nous prenons la quantité de commentaires que l'équipe Chrome a reçus sur un thème donné et l'organisons par ordre décroissant. Les thèmes courants des commentaires ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquentes soulevées par les équipes internes de Google et les formulaires publics.

Plus précisément, les comptes rendus des réunions des organismes de normalisation du Web ont été examinés. Pour les commentaires directs, les enregistrements de Google des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires publics ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation pour déterminer la prévalence relative des thèmes émergents en lien avec chaque API.

Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifique aux fins de cet exercice de rapport public. En raison de l'objectif actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API Topics, Protected Audience et Attribution Reporting.

Les commentaires reçus après la fin de la période de création de rapports en cours n'ont peut-être pas encore fait l'objet d'une réponse de Chrome.

Glossaire des acronymes

CHIPS: Cookies ayant un état partitionné indépendant
DSP: Plate-forme côté demande
FedCM: Gestion des identifiants fédérés
Lecteur d'empreinte digitale: Ensembles propriétaires
IAB: Interactive Advertising Bureau
IDP: Fournisseur d'identité
IETF: Internet Engineering Task Force
IP: Adresse IP
openRTB: Enchères en temps réel
Prolongation: Essai Origin
PatCG: Groupe de la communauté sur les technologies publicitaires privées
RP: Partie de confiance
SSP: Plate-forme côté offre
TEE: Environnement d'exécution sécurisé
UA: Chaîne user-agent
UA-CH: Hints client User-Agent
W3C: World Wide Web Consortium
WIPB: Blanchement volontaire des adresses IP

Commentaires généraux, aucune API ni technologie spécifique

Thème des commentaires	Résumé	Réponse de Chrome
Préparation de l'écosystème	Les SSP ont souligné que les éditeurs n'étaient pas prêts et ne réalisaient pas le travail de déploiement requis.	La Privacy Sandbox s'adresse spécifiquement aux éditeurs, avec des webinaires et des réunions dédiés, qui réunissent à la fois des éditeurs et des SSP pour accélérer le déploiement.
Abandon des cookies tiers	Les inquiétudes concernant l'abandon des cookies tiers (3PCD) s'intensifient au quatrième trimestre 2023 en raison d'un black-out technologique dans le secteur.	Le calendrier de la Privacy Sandbox a été discuté avec la CMA, et le séquencement devrait permettre de la rendre disponible au deuxième semestre 2024. La Privacy Sandbox publiera des informations plus détaillées sur le calendrier de déploiement de la 3PCD. Conformément aux engagements, la 3PCD est soumise à la résolution des préoccupations de la CMA en matière de concurrence.
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, les plans d'intégration de l'API Protected Audience de Google Ad Manager n'incluent pas la prise en charge du serveur d'annonces pour les éditeurs de Google sans contrôle des enchères de premier niveau.
Google Ad Manager	Google Ad Manager dispose d'un prix plancher secret qui n'est exposé qu'aux SSP Ad Exchange ou Open Bidding.	La documentation publique de Google Ad Manager indique que le gagnant de l'enchère contextuelle est transmis à la logique de notation de niveau supérieur et non à une enchère de composant, y compris AdX ou les enchères ouvertes. En outre, cette documentation indique la logique de calcul des scores de niveau supérieur : "Ad Manager compare l'enchère gagnante de chaque mise aux enchères de composant, y compris la mise aux enchères de composant d'Ad Manager pour les enchères de groupe d'intérêts de ses acheteurs, ainsi que la meilleure annonce contextuelle (qui est sélectionnée via l'allocation dynamique), et diffuse l'annonce avec 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 tiers.
Tests facilités par Chrome	Ajoutez des libellés pour les navigateurs qui ne figurent pas dans 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 non expérimentaux pouvait compliquer les problèmes de confidentialité liés au trafic en mode navigation privée.
Une agence publicitaire	Les agences ou les entreprises qui n'utilisent pas JavaScript sur leurs sites Web peuvent-elles utiliser les API de la Privacy Sandbox ?	N'importe qui peut appeler les API Privacy Sandbox. Si une agence ou toute autre personne souhaite créer des technologies directement sur les API, elle peut le faire. Les API côté client doivent être intégrées au client, tout comme les cookies. De nombreuses API, comme les cookies, disposent également d'une interface d'en-tête HTTP. Un framework du secteur de la publicité, Prebid, a déjà créé 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é des inquiétudes concernant la scalabilité de ces solutions en 2012 ?	En tant que champ d'étude, la technologie d'amélioration de la confidentialité (PET) a considérablement évolué depuis 2012, et avec elle les applications commercialement viables. La Privacy Sandbox repose sur des combinaisons de technologies de protection de la confidentialité qui n'auraient pas été possibles il y a une dizaine d'années. De plus, la puissance de calcul personnelle a augmenté, tout comme les attentes des consommateurs concernant les navigateurs et les attentes réglementaires en matière de confidentialité.
Machine learning	À quoi Google prévoit-il d'utiliser la Privacy Sandbox à des fins d'apprentissage automatique ?	Une grande partie de l'écosystème de technologie publicitaire utilise aujourd'hui le machine learning, et nous ne nous attendons pas à ce que cela change. La Privacy Sandbox n'empêche pas les entreprises d'ad tech 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 de créer des produits et des services qui répondent aux besoins de leurs clients, que cela inclue ou non le machine learning. Tout apprentissage automatique que les intégrateurs de la Privacy Sandbox créent sera évidemment connu d'eux et ne sera donc pas masqué.
Vérification des données	Comment les entreprises peuvent-elles vérifier que les données qu'elles reçoivent en utilisant la Privacy Sandbox sont exactes et que Google est prêt à être examiné par une entité telle que le Media Ratings Council (MRC) ?	Les API Privacy Sandbox sont intégrées à la plate-forme Open Source qui alimente Chrome. Les parties des API destinées à s'exécuter dans des environnements d'exécution sécurisés sont également Open Source et auditables. Tout le monde peut inspecter le code, y compris la MRC.
(Signalé également au cours des trimestres précédents) Assistance de production	Quel est le processus mis en place pour que Chrome prenne en charge les problèmes techniques et les escalades de la Privacy Sandbox affectant l'écosystème ?	Google propose différents canaux pour permettre aux technologies publicitaires de signaler les problèmes techniques et d'effectuer les escalades nécessaires pour les résoudre. De plus, Chrome prévoit de développer et d'étendre un processus pour résoudre les problèmes techniques et les escalades qui affectent la santé de l'écosystème. Chrome s'engage à fournir les ressources nécessaires à cette initiative. Veuillez consulter nos forums publics et privés pour envoyer des commentaires et escalader votre demande.
Modes de test facilités par Chrome	En savoir plus sur les délais et les implémentations exactes des modes de test facilités par Chrome	Nous avons publié un article de blog sur les modes de test et nous nous efforçons de vous communiquer plus d'informations prochainement. Nous acceptons les 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.* ou au mode Consentement ?	Nous ne prévoyons pas d'intégrer directement les API Privacy Sandbox au TCF v2 ni au mode Consentement. Toutefois, les entreprises et les groupes professionnels du secteur sont invités à adapter leurs produits et frameworks pour qu'ils fonctionnent avec les API de la Privacy Sandbox. Par exemple, avec des frameworks comme 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 nos composants de la Privacy Sandbox.

Inscription et attestation

Thème des commentaires	Résumé	Réponse de Chrome
Restriction	Le processus d'inscription permet à Google de décider quelle entreprise de l'écosystème est autorisée à utiliser les API de la 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 DUNS, peut fournir un lien vers un règlement sur la confidentialité, etc.) et rend l'attestation publique obligatoire pour appeler les API. Les entités qui peuvent remplir les conditions d'inscription seront validées. Pour les entreprises qui ne disposent pas de numéro DUNS, nous proposons un processus accéléré et sans frais avec Dun & Bradstreet pour en obtenir un. L'objectif est d'améliorer la protection de la confidentialité des API (par les mesures mentionnées ci-dessus) et d'ajouter une couche de transparence aux API de la Privacy Sandbox afin que les personnes concernées puissent mieux comprendre qui utilise quelle API et quelles attestations elles fournissent. Nous sommes ouverts à d'autres commentaires du secteur sur ce problème, qui ont déjà été utilisés pour façonner le processus.
Coûts liés à la réinscription	Le fichier d'attestation expire tous les 12 mois et nécessite une nouvelle inscription 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 au bout de 12 mois ou de toute autre période définie. Nous mettons à jour notre guide du développeur pour l'inscription avec des informations supplémentaires.
Fichier d'attestation	Comment le fichier d'attestation est-il utilisé ?	D'ici 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 rendre public tant qu'elles prévoient 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, et d'autres entités potentielles peuvent également effectuer des requêtes. Cette opération sera effectuée via le mécanisme propre au système d'enregistrement pour interroger les serveurs des entités enregistrées et s'assurer que le fichier d'attestation est valide. Les attestations seront incluses dans les rapports sur la transparence et visibles par le grand public. Nous attendons des entreprises qu'elles agissent conformément à leurs attestations, tout comme le reste de l'écosystème et les autorités réglementaires compétentes.
Inscription	L'inscription est-elle effectuée par site ou par origine ?	L'enregistrement se fait au niveau du site.

Afficher des publicités et des contenus pertinents

Thèmes

Thème des commentaires	Résumé	Réponse de Chrome
Performances	Problèmes de performances liés à l'impact du taux d'acceptation de Topics dans l'Espace économique européen.	Nous suggérons aux personnes concernées de contacter l'autorité compétente chargée de la protection des données à ce sujet. Ils sont les mieux placés pour répondre à ces préoccupations et déterminer si les applications des technologies de protection de la confidentialité sont encouragées par la loi ou traitées comme du suivi, nécessitant les mêmes approches en matière de consentement. Cela peut entraîner une disponibilité moins fréquente des API telles que celles de la Privacy Sandbox.
Inscription	Les enchérisseurs en aval doivent-ils s'inscrire à l'API Topics pour utiliser les signaux Topics des SSP en amont ?	Les récepteurs en aval des sujets au-delà de l'appelant initial de l'API Topics n'ont pas besoin d'être inscrits, bien que beaucoup soient susceptibles d'être inscrits pour d'autres utilisations de l'API. Une liste des participants à la Privacy Sandbox sera fournie de manière programmatique dans le cadre des efforts de transparence du programme, ce qui permettra à un appelant intéressé par l'API Topics de vérifier si le destinataire auquel il envoie un thème est inscrit, si l'appelant le souhaite.
Filtrage des sujets	Demande d'application du filtrage d'un autre appelant aux thèmes qu'il récupère sur la page, afin de ne partager que ce que les acheteurs peuvent récupérer.	Nous examinons cette demande et nous accueillons les commentaires supplémentaires de l'écosystème.
Exclusion de sites	Empêcher les sites Web d'alimenter les thèmes d'un utilisateur	Les sujets ne sont pas appelés par défaut. Il est important de noter qu'aucun contenu de page n'est pris en compte lors de la sélection des sujets, et que tous les sujets sont sélectionnés pour s'assurer qu'ils ne sont pas sensibles. Un site Web peut également empêcher son inclusion dans le calcul des thèmes à l'aide de l'en-tête de règles d'autorisation suivant: `Permissions-Policy: browsing-topics=()`.
Observation des thèmes	Autorisez les éditeurs à autoriser Chrome à classer les sujets en fonction du contenu de la page (par exemple, en-tête ou corps).	Nous avons précédemment envisagé de proposer une fonctionnalité permettant de classer les sites en fonction de thèmes en fonction du contenu des pages. Nous avons décidé de ne pas aller de l'avant pour des raisons de confidentialité et de sécurité. Cette proposition peut atténuer certaines de ces préoccupations, mais dans quelle mesure ? En raison de la période d'expérimentation de la CMA à venir, nous ne prévoyons pas que ce changement intervienne avant le 3PCD. N'hésitez pas à nous envoyer d'autres commentaires ici.
Observation des thèmes	Fournir des règles d'autorisation plus précises aux éditeurs	Fournir des règles d'autorisation plus précises aux éditeurs permettrait aux sites d'éditeurs d'avoir un impact négatif sur l'utilité de l'API Topics pour l'écosystème dans son ensemble, sans que cela n'ait d'impact négatif sur l'utilité de l'API Topics pour le site lui-même. Pour en savoir plus sur ce sujet, consultez le problème GitHub Modifier le règlement sur les autorisations pour prendre en charge des autorisations distinctes pour la récupération et l'observation.
Sujets médicaux et de santé	Pourquoi la taxonomie des thèmes ne couvre-t-elle pas les thèmes des catégories "Médical" ou "Santé" ?	Les catégories "Médecine" et "Santé" sont considérées comme des sujets sensibles et sont donc exclues de la taxonomie des sujets.
Récupération de thèmes	Méthode plus rapide pour les DSP d'obtenir des sujets sans les extraire à l'aide d'en-têtes.	Les méthodes d'en-tête sont plus performantes et moins coûteuses que de créer un iframe inter-origine et d'effectuer un appel `document.browsingTopics()` à partir de celui-ci. (Un iframe inter-origine doit être utilisé pour l'appel, car le contexte de niveau supérieur pour observer un sujet doit correspondre au contexte à partir duquel les sujets sont accessibles.) Cliquez ici pour en savoir plus.
Récupération de thèmes	Demandes de prise en charge de la transmission de sujets via des en-têtes sur les requêtes de balise de script multi-origines.	D'un point de vue de sécurité, ce n'est pas possible. Chaque document et son environnement d'exécution sont associés à une seule origine, celle du document. Les sous-ressources tierces chargées et exécutées dans ce même environnement sont considérées comme appartenant à l'origine du document. Cela permet d'éviter les fuites de données non consenties d'une origine à une autre. Vous pouvez également fournir un attribut `browsingTopics` sur les balises `<script>`. Cela doit être propre d'un point de vue de sécurité et ne pas ajouter de latence supplémentaire. Nous sommes à l'écoute des commentaires des personnes intéressées.
Notoriété	Améliorer la notoriété de l'API Topics et de son utilisation	Nous avons contacté la personne concernée qui a fourni ces commentaires, et ce problème a été résolu sur GitHub. À l'avenir, nous continuerons de faciliter la compréhension de l'API par l'écosystème et nous avons hâte d'entendre les avis des personnes concernées. En attendant, nous suggérons aux personnes intéressées par l'API Topics de se familiariser avec la documentation du guide du développeur Chrome.
Notification	Notification pour avertir l'utilisateur lorsque ses thèmes sont observés par un site Web.	Nous avons traité ces commentaires sur GitHub. Pour en savoir plus sur les commandes de Topics, consultez le Centre d'aide Chrome.
Machine learning	Comment le ML peut-il être utilisé pour déduire les sujets des utilisateurs ?	Nous examinons ce problème et nous serions ravis de recevoir vos commentaires supplémentaires.
Utilité pour différents types d'acteurs	Les petites entreprises de technologie publicitaire ne pourront peut-être pas observer les thèmes en raison de la façon dont les navigateurs les calculent.	Seules les technologies publicitaires ayant observé l'utilisateur consulter 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 dernières semaines pour cet utilisateur sur un site concernant ce thème, la valeur renvoyée sera vide. Cette fonctionnalité signifie que 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 de 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 peuvent déjà 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é par Chrome en août 2023, Chrome a commencé à abandonner la prise en charge de XHR lors de la transition de la version Preview d'Origin à la disponibilité générale. Au fur et à mesure de l'avancement de la mise en place de Topics, la prise en charge de XHR n'était incluse que pour les utilisateurs pour lesquels les fonctionnalités OT étaient activées et a été complètement abandonnée lorsque les groupes de test OT individuels ont été fusionnés. Si vous utilisiez Topics avec XHR, vos sites ne seront pas endommagés. Les thèmes ne seront pas ajoutés aux 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 des sujets. Fetch est compatible avec tous les navigateurs modernes, mais pas avec Internet Explorer ni Opera Mini.
Processus de mise à jour de la taxonomie et du classificateur	En savoir plus sur la taxonomie Topics et la fréquence de publication des classificateurs, ainsi que sur la façon dont les entreprises peuvent se préparer à ces mises à jour.	Notre réponse reste inchangée par rapport à la question 2: Comme indiqué dans notre article de blog récent, nous nous attendons à ce que la taxonomie évolue au fil du temps et que la gouvernance de la taxonomie soit finalement transférée à un tiers externe représentant les personnes concernées de l'ensemble du secteur. Nous avons également partagé le plan d'augmentation dans le groupe topics-announce.
Utilisation abusive	Attaque potentielle via une chaîne de redirection.	Nous examinons ce problème et nous sommes à l'écoute de vos commentaires supplémentaires.
Types d'inventaire des éditeurs	Quels types d'inventaire d'éditeurs seront compatibles avec les tests de Protected Audience et de Topics ?	Ni Protected Audience ni Topics ne sont intrinsèquement restrictifs en termes de types d'inventaires sur lesquels ils peuvent être utilisés.
Temps d'activation progressive	Nous vous recommandons de ne pas attendre que les nouvelles taxonomies atteignent 100%.	Suite à cette demande de commentaires de l'écosystème et aux discussions lors des réunions du PATCG, nous avons annoncé notre plan de déploiement de la nouvelle taxonomie.

API Protected Audience (anciennement FLEDGE)

Thème des commentaires	Résumé	Réponse de Chrome
Enchères de premier niveau	Possibilité d'utiliser le serveur d'annonces de l'éditeur Google sans accorder à Google Ad Manager le contrôle de l'enchère de l'API Protected Audience de niveau supérieur.	Réponse fournie par Google Ad Manager: Les plans de Google Ad Manager pour l'API Protected Audience n'incluent pas la prise en charge de l'ad server de l'éditeur Google sans le contrôle de l'enchère Protected Audience de niveau supérieur, pour les raisons suivantes. Pour diffuser correctement les annonces de nos clients sur le marché de la diffusion d'annonces par les éditeurs, le serveur d'annonces de l'éditeur Google doit conserver le contrôle de l'enchère Protected Audience de premier niveau. En tant qu'ad server pour les éditeurs, notre rôle est de fournir des prévisions aux éditeurs afin qu'ils puissent négocier des campagnes vendues directement sans surréservation, et de rythmer et diffuser leurs réservations directes de manière optimale. Pour ce faire, vous devez exécuter l'enchère finale afin de comparer toute la demande directe et indirecte éligible. La prévision et le pacing sont des fonctionnalités de base que les éditeurs attendent d'un ad server. Sans prévisions précises, les éditeurs peuvent finir par survendre leur inventaire, ce qui met en péril leur réputation commerciale. La régulation est également essentielle, car l'impossibilité de respecter les contrats de réservation avec les annonceurs risque également d'endommager la relation directe entre les éditeurs et les annonceurs, ce qui pourrait avoir un impact significatif sur l'activité des éditeurs. En résumé, nous ne considérons pas l'activité d'exécution de l'enchère Protected Audience de premier niveau par un ad server d'éditeur comme distincte des autres activités de l'ad server.
`directFrom SellerSignals`	`directFrom SellerSignals` permet à Google Ad Manager d'empêcher l'éditeur de voir le prix de son enchère contextuelle.	Réponse de Chrome: Les informations transmises à `runAdAuction()` ne proviennent pas nécessairement du vendeur, sauf si le vendeur appelle `runAdAuction()` à partir de son propre iframe. Dans une mise aux enchères multivendeur, il devient impossible de demander à tous les vendeurs de créer le frame appelant `runAdAuction()`. `directFromSellerSignals` a résolu ce problème en chargeant du contenu à partir d'un bundle de sous-ressources chargé à partir de l'origine d'un vendeur. Cela garantit que l'authenticité et l'intégrité des informations transmises à 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 de technologie transmettent aux enchères Protected Audience, ils peuvent demander cette fonctionnalité à ces fournisseurs. Réponse fournie par Google Ad Manager: Nous accordons depuis des années une attention toute particulière à l'équité des enchères, y compris en nous assurant qu'aucun prix d'une source publicitaire non garantie d'un éditeur, y compris les prix des éléments de campagne non garantis, n'est partagé avec un autre acheteur avant qu'il ne définisse son enchère. Nous avons ensuite réaffirmé cette promesse dans nos engagements envers l'Autorité française de la concurrence. Pour les enchères Protected Audience, nous avons l'intention de tenir notre promesse en utilisant `directFromSellerSignals` et de ne pas partager l'enchère de l'un des participants aux enchères avec un autre participant aux enchères avant la fin des enchères dans les enchères multi-vendeurs. Pour être clair, nous ne partagerons pas non plus le prix de l'enchère contextuelle avec notre propre enchère de composants, comme expliqué dans la mise à jour Clarifier davantage les dynamiques des enchères de premier niveau.
Exposition des informations	La logique métier sensible et les détails contractuels peuvent être exposés par le navigateur.	La personne qui utilise un navigateur Web peut voir tout ce qui se passe dans le navigateur. Lorsqu'une mise aux enchères d'annonces se produit dans le navigateur, il est vrai que la personne dont le navigateur est utilisé peut regarder cette mise aux enchères, y compris voir combien les différentes parties choisissent d'enchérir. Étant donné qu'un navigateur est l'agent de l'utilisateur, nous ne pensons pas qu'il soit possible ni souhaitable d'essayer de modifier cela. Toutefois, seule la personne qui utilise le navigateur peut voir ces opérations. Une mise aux enchères sur l'appareil exécutée à l'aide de l'API Protected Audience n'est pas visible par les serveurs, y compris ceux de Google.
`PerBuyerExperiment GroupId`	La plage de valeurs actuelle de `PerBuyerExperiment GroupId` pourrait permettre aux acheteurs de mettre en corrélation les données contextuelles avec la requête du serveur de confiance.	L'utilisation de l'API Protected Audience de cette manière est incompatible avec l'attestation obligatoire de la Privacy Sandbox selon laquelle les utilisateurs de l'API ne tenteront pas de contourner les protections de la Privacy Sandbox. À l'avenir, l'obligation d'exécuter les serveurs de clés-valeurs dans des environnements d'exécution sécurisés (TEE) fournira une protection technique contre cette attaque.
Règle de même origine	Assouplissez la règle d'origine commune pour autoriser les sous-domaines.	Nous examinons cette demande et nous sommes à l'écoute de autres commentaires de l'écosystème.
Gestion des versions de l'API	Demande de gestion des versions et de notes de version pour les modifications apportées à l'API Protected Audience.	Nous examinons cette demande et nous sommes à l'écoute de autres commentaires de l'écosystème.
Enchères multi-SSP	Autorisez les signaux d'enchères de niveau supérieur à effectuer des fusions JSON avec le signal de composant `auctionSignals`.	Nous examinons cette demande et nous sommes à l'écoute de autres commentaires de l'écosystème.
Limite d'enchère	Augmentez la limite du nombre de composants d'annonces entrant dans l'enchère de 20 à 40.	Nous examinons cette demande et nous invitons l'écosystème à nous faire part de commentaires supplémentaires sur l'utilité de cette fonctionnalité.
(également indiqué dans les trimestres précédents) Performances des enchères Protected Audience	Les testeurs signalent que les enchères Protected Audience ont une latence élevée.	En ce qui concerne les questions de latence, l'API Protected Audience a généralement suivi le paradigme standard existant consistant à créer des commandes permettant aux vendeurs de décider du temps et des ressources que les enchérisseurs peuvent consommer, et à créer des outils permettant aux acheteurs de décider de la meilleure façon d'utiliser les ressources à leur disposition. Ces commandes et outils sont généralement disponibles aujourd'hui, mais leurs avantages ne seront pleinement exploités qu'après leur adoption par les acheteurs et les vendeurs. De plus, Chrome continue de travailler sur diverses améliorations de l'infrastructure pour accélérer les 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 aspects de cet effort de réduction de la latence: les nouveaux outils que les acheteurs et les vendeurs trouveraient utiles, et les rapports sur les goulots d'étranglement observés que les ingénieurs Chrome devraient examiner.
Filtrage côté achat	Prise en charge du filtrage côté acheteur basé sur des groupes de centres d'intérêt.	Nous avons suggéré plusieurs façons dont les SSP et les DSP pourraient modifier leurs conceptions pour y parvenir: Déplacement de certaines tâches vers le serveur de clés/valeurs du DSP. Les SSP créent des signaux contextuels et les transmettent aux DSP. Les SSP qui mettent en cache des signaux contextuels pour les DSP
Contrôle des groupes de centres d'intérêt des éditeurs	Assistance pour les éditeurs qui souhaitent déléguer l'utilisation des groupes de centres d'intérêt créés par eux-mêmes.	Nous avons discuté de cette demande avec de nombreuses parties. Nous pensons que tous les cas d'utilisation impliquant la "délégation" des groupes de centres d'intérêt créés par les éditeurs peuvent être pris en charge dès maintenant. De plus, nous devrions développer une assistance supplémentaire pour fluidifier certains cas d'utilisation à l'avenir.
(également signalé au deuxième trimestre) Environnements d'exécution sécurisés	Prise en charge des environnements d'exécution sécurisés (TEE) dans les environnements cloud non publics.	Notre réponse est semblable à celle des trimestres précédents: Bien que nous continuions à explorer des options au-delà des solutions cloud publiques, nous ne prévoyons pas actuellement 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 présentent les déploiements sur site, nous pensons que continuer à développer et à améliorer les déploiements cloud (par exemple, en prenant en charge Google Cloud en plus d'AWS) est la solution la plus bénéfique pour l'écosystème. Toutefois, nous sommes à l'écoute de vos commentaires supplémentaires sur la nécessité et la faisabilité d'une telle exigence compte tenu des contraintes de confidentialité et de sécurité.
un environnement d'exécution fiable	Les composants du chemin de service du TEE, tels que l'équilibreur de charge, peuvent observer tout le trafic et disposer d'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é, que ce soit pour les enchères et la mise aux enchères, ou 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 proxyfier la technologie publicitaire et le trafic des outils de suivi via un proxy IP, ce qui empêchera les composants d'observer tout le trafic sur le chemin d'affichage.
Valeur TTL (Time To Live)	Le délai avant que les services ne doivent demander de nouvelles clés sera-t-il défini ou est-il censé ê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 récupérées toutes les N heures dans le chemin sans requête et mises en cache en mémoire, de sorte qu'il n'y ait pas plus d'un délai de N heures entre la rotation des clés et la récupération de ces clés par les serveurs. Le tampon d'une journée entre la rotation des clés et l'expiration permet de s'assurer que, même en cas d'échec de la génération de clés, les services peuvent continuer à fonctionner. Nous envisageons d'étendre la valeur TTL pour améliorer la résilience en cas d'indisponibilité. En cas de fuite de clé, nous prévoyons de forcer manuellement la génération de clés et d'invalider les clés plus tôt. Notez que les clés publiques sont mises en cache sur les clients, actuellement pendant 24 heures, afin de s'assurer qu'en cas d'indisponibilité du coordinateur, les services peuvent toujours fonctionner.
Lissage du trafic	Compatibilité avec le trafic shaping pour les services d'enchères et de mise aux enchères.	Les acheteurs peuvent indiquer, en fonction des données first party de l'éditeur ou des données contextuelles, la demande d'enchères Protected Audience. Les vendeurs peuvent également effectuer des déterminations similaires dans leur serveur publicitaire ou leur serveur Ad Exchange. Les modèles peuvent être entraînés sur des données propriétaires et sur tous les rapports agrégés 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 sur les composants	Quels sont les auctionSignals de premier niveau partagés avec les vendeurs de composants ?	Les acheteurs d'une enchère de composants ne reçoivent que des signaux du vendeur de composants. Nous prévoyons de partager prochainement des documents sur la séquence globale d'enchères combinées avec les enchères d'en-tête et les enchères Protected Audience.
Rendu vidéo	Prise en charge du rendu vidéo à l'aide de Protected Audience et de Fenced Frames.	L'API Protected Audience est compatible avec le rendu vidéo à l'aide d'un mécanisme qui repose sur des iFrames. Toutefois, nous n'avons pas encore conçu de solution compatible avec les cadres délimités. C'est l'une des raisons pour lesquelles nous avons décidé de repousser l'application des cadres délimités à 2026. Cela signifie que si un partenaire décide d'appliquer les cadres délimités dès maintenant, la compatibilité avec les vidéos ne sera pas assurée.
Limitation de la fréquence d'exposition	(également indiqué dans les trimestres précédents) Contrôles de la fréquence par utilisateur dans une campagne et un groupe d'annonces.	Notre réponse n'a pas changé depuis les rapports précédents: Protected Audience sera 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 plafonds spécifiques au site 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	Protected Audience permet-il de désactiver ou de bloquer par site d'annonceur, ou de quitter 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 de même origine pour l'URL source des scripts d'enchères	Assouplissement de l'exigence selon laquelle tous les champs spécifiant des URL pour le chargement de scripts ou de fichiers JSON doivent être de même origine que le propriétaire.	Nous examinons actuellement cette demande et nous accueillons les commentaires supplémentaires de l'écosystème.
`forDebuggingOnly`	Possibilité d'utilisation abusive de `forDebuggingOnly .reportAdAuctionWin` s'il reste après l'abandon des cookies tiers.	Au cours des dernières années, nous avons reçu des commentaires de l'écosystème concernant les lacunes fonctionnelles de l'API Protected Audience une fois que les cookies tiers seront obsolètes. Nous travaillons actuellement à la formulation d'un plan pour les prendre en charge après l'abandon des cookies tiers, sans compromettre les objectifs de la Privacy Sandbox. Nous sommes à l'écoute de vos suggestions et commentaires supplémentaires sur les fonctionnalités manquantes que l'écosystème souhaiterait voir.
Plusieurs groupes de centres d'intérêt	Utilisez plusieurs groupes de centres d'intérêt dans la même enchère.	Cette fonctionnalité n'est pas disponible dans l'API Protected Audience pour le moment, car elle entraînerait une modification du modèle de confidentialité sous-jacent. N'hésitez pas à nous contacter pour en discuter.
Enchères sur l'appareil	Chrome sur Android sera-t-il compatible avec les enchères Protected Audience sur l'appareil ?	Oui, les enchères sur l'appareil seront prises en charge dans Chrome sur Android.
(Rapporté au T2 2023) Données liées aux clics	Ajoutez des données liées aux clics à browserSignals.	Nous continuons d'évaluer cette demande de fonctionnalité et nous serions ravis de recevoir d'autres commentaires sur les raisons pour lesquelles elle devrait être prioritaire.
Fournisseurs d'environnements d'exécution sécurisés	Les offres d'environnement d'exécution sécurisé des différents fournisseurs de services cloud présentent-elles des différences importantes ?	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 la plus adaptée à ses besoins. Google Cloud. AWS
(Rapporté dans les trimestres précédents) Ciblage par exclusion des groupes d'intérêt	API permettant de cibler des 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é d'implémenter cette fonctionnalité et discutons de la demande.
Non-respect du règlement relatif au contenu	Prise en charge des fonctionnalités permettant aux utilisateurs de signaler les mauvaises annonces diffusées par l'API Protected Audience dans les cadres clôturés.	Nous pensons que le mécanisme de création de rapports sur les annonces dans des cadres délimités existant offre de bonnes options pour les technologies publicitaires qui souhaitent un flux de création de rapports "Mauvaises annonces" généré par l'utilisateur. Cela permettrait de signaler les annonces inappropriées d'une manière essentiellement inchangée par rapport à la norme du secteur actuelle. Nous sommes à l'écoute de toute demande de fonctionnalité supplémentaire si des lacunes subsistent, y compris après la suppression des cookies tiers, mais avant que le rendu de la balise de frame cloisonné ne devienne courant.
Rapports de l'API Private Aggregation	Comment calculer le temps passé par l'utilisateur dans ce groupe de centres d'intérêt ?	Dans Chrome M116 ou version ultérieure, vous devriez pouvoir utiliser la récence telle que définie dans pull/639.
Serveur k-anonymat	En savoir plus sur le serveur de k-anonymat	Pour en savoir plus sur les serveurs de k-anonymat, consultez cette page. Nous serons ravis de recevoir vos commentaires supplémentaires.
URL de création dynamique	Prise en charge des URL de création sans prédéclaration, tout en respectant l'anonymat k.	Nous examinons cette demande de fonctionnalité et nous serions ravis de recevoir d'autres commentaires sur les raisons pour lesquelles elle devrait être prioritaire.
Exigence de k-anonymat	L'exigence de k-anonymat pour les mises à jour des groupes de centres d'intérêt sera-t-elle réintroduite ?	Nous ne prévoyons pas de modifier la position exprimée dans ce post GitHub. Comme annoncé dans ce post, nous avons décidé de supprimer l'exigence d'anonymat k sur les mises à jour des groupes d'intérêts Protected Audience, ce qui n'a pas d'impact significatif sur les protections globales de la confidentialité de l'API. Nous prévoyons d'examiner d'autres protections plus directes potentielles (telles que la confidentialité des adresses IP ou un serveur de mise à jour de confiance) à une date ultérieure, lorsque les technologies associées seront plus développées, déployées et adoptées.
Tests bêta des services d'enchères et de mise aux enchères	Quand les tests bêta des services d'enchères et de mise aux enchères commenceront-ils ?	Comme indiqué dans la section Calendrier et feuille de route, la première phase de test des services d'enchères et de mise aux enchères commence en novembre 2023.
Roadblocking	Demande de prise en charge de la coordination des créations pour les réseaux publicitaires (SSP et DSP se trouvent dans la même entreprise ou les mêmes propriétés).	Nous vous remercions de nous avoir fait part de vos commentaires sur ce cas d'utilisation. Nous souhaitons savoir si d'autres technologies publicitaires sont intéressées par cette fonctionnalité. N'hésitez pas à nous faire part de vos commentaires supplémentaires.
Publicité native	Prise en charge des cadres délimités pour la publicité native.	Nous envisageons de prendre en charge ce cas d'utilisation et discutons des solutions et des solutions de contournement possibles.
K-anonymat	Comment maximiser les annonces des groupes de centres d'intérêt qui répondent aux seuils k-anon ?	Nous avons publié des conseils pratiques à ce sujet.
Prise en charge des requêtes 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 invitons les utilisateurs à envoyer d'autres problèmes sur GitHub pour expliquer pourquoi cette fonctionnalité doit être prioritaire.
Précision des rapports	Quelle est la granularité des rapports sur les annonces avec cadre délimité 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 pourrait compromettre la confidentialité des utilisateurs. Seul le `reserved.top_navigation` peut être appelé, qui sera envoyé en cas d'activation par l'utilisateur (par exemple, un clic) sur le cadre clôturé du composant de l'annonce, ce qui entraîne une navigation de niveau supérieur.
Mise en concurrence des annonces	Un SSP participant à une mise aux enchères de composants peut-il déclencher lui-même une autre mise aux enchères de composants ?	Un élément `componentSeller` ne peut pas inclure `componentAuctions`. Les enchères multivendeurs ne comportent que deux niveaux: 1. Enchères des composants en parallèle. 2. Mise aux enchères 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 seront-elles disponibles pendant la phase de test avec Chrome ?	Le serveur d'enchères et de mise aux enchères ne sera pas disponible pendant la phase de test facilitée par Chrome.
Signaux d'enchères	Autorisez les navigateurs à demander et à supprimer des signaux d'enchères.	Nous examinons cette demande et nous serions ravis de recevoir d'autres commentaires sur les raisons pour lesquelles elle devrait être traitée en priorité.
`generateBid()`	Possibilité de mettre à jour le `userBiddingSignals` de l'intérêtGroup via `updateURL`.	Nous examinons cette proposition et nous serions ravis de recevoir d'autres commentaires et de discuter de ce sujet.
Types d'inventaire des éditeurs	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 le SSP et la DSP est-elle requise pour l'API Protected Audience ?	L'intégration directe entre le SSP et le DSP n'est pas requise si le DSP n'a pas besoin de traiter les signaux contextuels sur son propre serveur afin de transmettre ces informations traitées à sa fonction d'enchères sur l'appareil.
Champ `bid_currency` dans une mise aux enchères et une mise aux enchères	Prise en charge du champ `bid_currency` dans le service d'enchères et de mise aux enchères.	B&A ne prend pas encore en charge `bid_currency`, mais nous prévoyons de le faire d'ici la fin de 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 de trop de données peut avoir des effets néfastes sur les performances du navigateur.
Cas d'utilisation intersites	Pouvons-nous utiliser les groupes de centres d'intérêt de l'API Protected Audience sur plusieurs sites Web ?	Protected Audience n'est pas conçu pour de tels cas d'utilisation, comme expliqué dans turtledove/issues/282.
Requêtes HTTP de l'API Interest Group	Incluez le blob de groupe d'intérêts dans les en-têtes HTTP.	Nous examinons cette demande et nous serions ravis de recevoir d'autres commentaires à ce sujet.
Contrôle de la qualité des annonces	Perte de contrôle de la qualité des annonces liée aux informations intersites	Nous prenons en compte ces commentaires et nous serons ravis de recevoir d'autres commentaires.
Outils pour les développeurs Chrome	Les requêtes réseau sortantes de l'API Protected Audience devraient être visibles dans l'onglet "Réseau" des outils pour les développeurs Chrome.	Nous travaillons à l'activation de cette fonctionnalité dans l'onglet "Réseau" et nous serions ravis de recevoir d'autres commentaires sur les raisons pour lesquelles elle devrait être prioritaire.
un environnement d'exécution fiable	Quand les informations sur les métriques ayant un impact sur la confidentialité (et leur degré) seront-elles ajoutées à la vidéo explicative sur la surveillance de l'environnement d'exécution sécurisé ?	Nous mettons à jour la vidéo explicative avec ces informations. La vidéo explicative mise à jour sera disponible d'ici novembre 2023.
`directFrom SellerSignals`	Pourquoi `directFrom SellerSignals` n'est-il pas empaqueté en tant que bundle Web ?	Vous pouvez consulter les raisons de cette décision ici.
Délégation d'impressions	Existe-t-il un moyen viable de déléguer des impressions lorsque le résultat de la sélection d'un groupe d'intérêts est une autre action de ciblage ?	Les enchères multiples 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 s'affiche dans un cadre clôturé, nos objectifs de confidentialité pour Protected Audience incluent le rendu de la création qui en résulte sans connaissance du contexte: l'URL de la page environnante ou le cookie propriétaire constituent une atteinte à la confidentialité. Dans cet environnement, une mise aux enchères imbriquée n'est pas viable. Deuxièmement, le modèle Protected Audience indique que le gagnant de chaque mise aux enchères doit être basé sur les données d'un seul site supplémentaire. Les enchères imbriquées pourraient aggraver ce problème, ce qui permettrait de choisir des annonces en fonction d'un profil multisite.
Critère de données au repos	Expliquez plus en détail le critère "Données au repos" dans le modèle de confiance du service clé-valeur.	Les données du service de clés-valeurs sont chargées en mémoire et diffusées à partir de là, plutôt que de mettre en cache la lecture.
Signal de données sur l'acheteur	La taille des signaux `buyer_data` reçus des DSP est-elle limitée ?	Aucune limite n'est actuellement imposée par le navigateur pour les signaux `buyer_data` reçus des DSP.

Mesurer les annonces numériques

Attribution Reporting (et d'autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Multi-appareil	Prévoyez la prise en charge multi-appareils de l'API Attribution Reporting.	La multi-plateforme présente de nouveaux défis en matière de confidentialité en plus des cookies tiers, et ajoute également des défis de distribution de la technologie en raison de la variété 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 les rapports sur l'attribution. Nous ne prévoyons pas de proposer la compatibilité multiappareil avant la suppression des cookies tiers.
(également indiqué dans les trimestres précédents) Taille des données de déclencheur	Pourquoi la taille des données de déclencheur est-elle limitée à trois bits ?	La taille est limitée à trois bits et huit valeurs distinctes pour s'assurer que la quantité d'informations intersites et intercontextes sur un utilisateur est limitée. Nous invitons les acteurs de l'écosystème à nous faire part de leurs commentaires pour nous indiquer si la paramétrisation actuelle pour les rapports au niveau des événements est suffisante.
Entonnoir de conversion	Enregistrez plusieurs domaines utilisés dans la conversion.	Ce cas d'utilisation est possible depuis l'ajout de plusieurs destinations. N'hésitez pas à nous faire part de vos commentaires supplémentaires.
Compatibilité avec le même domaine dans différents pays	Les rapports sur l'attribution fonctionnent-ils avec les sites Web qui ont le même domaine, mais plusieurs domaines de premier niveau de pays ?	Ce problème a été discuté et résolu avec la personne concernée qui a soulevé la question. Si une technologie publicitaire doit utiliser plusieurs domaines de premier niveau de pays, elle doit disposer de plusieurs enregistrements, un pour chaque domaine de premier niveau de pays.
Protected Audience et rapports sur l'attribution	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 les rapports sur l'attribution ?	Oui, la Privacy Sandbox devrait prendre en charge à la fois les VTC et les CTC dans Protected Audience.
Délais de génération des rapports agrégables	Réduire davantage les délais de génération des rapports agrégables.	Nous avons récemment reçu des commentaires à ce sujet et avons partagé des idées ici. Nous attendons avec impatience les commentaires supplémentaires de l'écosystème.
Délais de génération des rapports agrégables	Réduction des délais grâce à l'introduction de la médiation par serveur.	Nous examinons cette proposition et nous serions ravis de recevoir d'autres commentaires .
Délais de génération des rapports au niveau des événements	Réduire les délais de création des rapports au niveau des événements.	La proposition de configuration flexible complète au niveau des événements, décrite dans la section Configurations flexibles au niveau des événements, peut réduire les délais de création de rapports au niveau des événements à une heure, avec un compromis sur le bruit.
Origine de création de rapports par source	La limitation du nombre maximal d'origines de création de rapports source par site de création de rapports source 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.	Nous en avons discuté avec la personne concernée qui a soulevé le problème. Une solution potentielle consiste à utiliser une seule origine de création de rapports par site de création de rapports source. Nous la testons avant d'essayer d'autres solutions potentielles impliquant des redirections. Nous sommes également à l'écoute de tout commentaire supplémentaire de l'écosystème concernant cette limite.
Signaler un problème	Comment signaler des erreurs ou des problèmes liés à l'API Attribution Reporting à Chrome ?	Pour le moment, 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'il rencontre un problème lié à Chrome, nous lui recommandons de créer un bug Chromium. Pour savoir comment et où signaler un problème, consultez Interagir et partager des commentaires.
Déduplication	Comment pouvons-nous dédupliquer les conversions entre 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 cookies tiers. 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 à l'écoute de vos commentaires supplémentaires sur l'écosystème.
Déduplication et priorité	Demandez à avoir la priorité avant la déduplication.	Nous examinons cette demande et nous serons ravis de recevoir vos commentaires supplémentaires.
Lutte contre la fraude	Risque de falsification des données au niveau des événements par un utilisateur malveillant.	La validation des rapports ne fonctionne pas pour les rapports au niveau des événements pour les raisons décrites dans 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 les vues et la navigation dans les rapports sur l'attribution ?	L'option de filtrage intégrée suivante est disponible: `source_type`. Pour en savoir plus, cliquez ici.

Service d'agrégation

Thème des commentaires	Résumé	Réponse de Chrome
Récupération du budget	Certaines technologies publicitaires ont demandé la possibilité de retraiter les rapports en cas d'échec, d'erreur ou de suppression de leurs rapports.	L'équipe étudie des solutions pour y remédier tout en protégeant la confidentialité des utilisateurs.
Enregistrement du site	Plusieurs technologies publicitaires ont demandé de l'aide pour traiter plusieurs origines dans le même compte pour des cas d'utilisation tels que le fractionnement des données par zone géographique et annonceur. Ce comportement est également attendu par les technologies publicitaires, étant donné que l'enregistrement de l'API cliente est désormais basé sur le site (et non sur l'origine). La migration de l'enregistrement d'origine à l'enregistrement de site simplifie le processus d'intégration des technologies publicitaires grâce à la cohérence avec le processus d'enregistrement des clients.	Nous allons bientôt lancer la migration de l'enregistrement d'origine à l'enregistrement de site pour le service d'agrégation. Nous attendons les commentaires de l'écosystème.
Plan de publication et d'abandon	Calendrier de publication des fonctionnalités et correctifs du service d'agrégation, ainsi que de leur abandon. L'objectif de ce plan est de donner aux technologies publicitaires une visibilité sur nos règles de publication afin de leur permettre de se préparer aux prochaines versions et abandons, et de s'assurer qu'elles exécutent des versions de services stables et sécurisées.	Nous avons récemment publié une proposition de plan de publication et d'abandon pour le service d'agrégation. Nous attendons vos commentaires supplémentaires.
Coordinateurs	Que se passe-t-il si les coordinateurs du service d'agrégation sont hors service ?	Les deux coordinateurs doivent être entièrement disponibles pour que le système fonctionne correctement. Une courte indisponibilité est gérée par des nouvelles tentatives dans nos bibliothèques clientes. Une indisponibilité plus longue de l'un des deux coordinateurs entraîne l'échec des tâches d'agrégation. Les jobs peuvent être réexécutés si le budget de confidentialité n'est pas encore utilisé. En cas de défaillance de service ayant entraîné une consommation de budget sans rapport récapitulatif écrit dans l'espace de stockage de la 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 local. Nous travaillons également sur des fonctionnalités permettant de récupérer le budget en cas d'échec afin que les technologies publicitaires puissent réexécuter leurs tâches.

API Private Aggregation

Thème des commentaires	Résumé	Réponse de Chrome
URL du blob	Demande d'acceptation de l'URL de blob dans le stockage partagé.	La prise en charge de l'URL de blob a été ajoutée dans Chrome M116.

Limiter le suivi dissimulé

Réduction de l'User-Agent et User-Agent Client Hints

Thème des commentaires	Résumé	Réponse de Chrome
API JavaScript	Disponibilité de l'API JavaScript User-Agent Client Hints.	Nous n'avons pas l'intention de supprimer cette fonctionnalité, car elle est notre solution de base pour les partenaires qui souhaitent accéder activement aux données à haute entropie au-delà de ce qui est disponible par défaut dans l'UA congelée et réduite.
Informations sur l'appareil et le facteur de forme	Capacité des sites Web à comprendre les entrées, les sorties et d'autres informations que l'appareil qui accède au site Web peut prendre en charge.	Nous avons accepté cette demande suite aux commentaires de l'écosystème.

Protection IP (anciennement Gnatcatcher)

Thème des commentaires	Résumé	Réponse de Chrome
Trafic tiers éligible	À quoi fait référence le terme "trafic tiers éligible" dans la vidéo explicative ?	Nous sommes conscients de l'importance de cette question et nous travaillons activement à identifier le trafic tiers éligible et non éligible. N'hésitez pas à nous faire part de vos commentaires sur ce sujet.
Audits du trafic réseau	Possibilité pour les entreprises d'effectuer des audits du trafic réseau pour leurs réseaux.	Seul le trafic tiers intégré aux sites propriétaires sera affecté, ce qui devrait limiter la quantité de trafic nécessitant un filtrage. De plus, nous prévoyons de donner aux utilisateurs la possibilité d'utiliser ou non la protection IP. Pour Chrome géré par une entreprise, des règles d'entreprise permettront de désactiver la protection IP. Enfin, nous étudions les commandes (le cas échéant) qui seront fournies aux opérateurs de réseau pour désactiver la protection IP. N'hésitez pas à nous faire part de vos commentaires sur ce sujet.
Contrôle des accès	La protection IP peut avoir un impact sur les services Web qui utilisent des adresses IP pour le contrôle des accès.	Nous comprenons l'importance des cas d'utilisation de la lutte contre la fraude et l'impact potentiel de ces cas d'utilisation. Nous sollicitons les commentaires de l'écosystème pour nous aider à mieux prendre en charge les cas d'utilisation de la lutte contre la fraude qui reposent généralement sur les adresses IP.
Communication entre les proxys à deux sauts	Comment s'assurer qu'aucune information n'est transmise entre les proxys ?	Nous sommes en train de concevoir les interactions de proxy. Notre objectif est de minimiser les risques de partage de ces informations via des moyens commerciaux, procéduraux et techniques.
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, mais nous avons déjà partagé quelques considérations initiales.
Classification des bracelets d'activité	Comment la protection IP déterminera-t-elle ce qui constitue un traceur et ses variantes ?	Nous sommes conscients de l'importance de cette question et nous travaillons activement à identifier le trafic tiers éligible et non éligible. N'hésitez pas à nous faire part de vos commentaires sur ce sujet.
Analytics	La protection des adresses IP peut affecter la justesse des services d'analyse.	Nous souhaitons mieux comprendre l'impact de la protection des droits d'auteur et nous accueillons les commentaires et exemples supplémentaires de l'écosystème.
Proxy	Si un utilisateur utilise un proxy ou en a défini un manuellement, comment le masque d'adresse IP fonctionne-t-il dans ce cas ?	Nous cherchons à comprendre l'impact que la protection IP peut avoir sur d'autres proxys. Nous n'avons pas d'informations à vous communiquer à ce sujet pour le moment. N'hésitez pas à nous faire part de vos commentaires sur ce sujet.
Offre premium	La fonctionnalité IP Protection sera-t-elle payante ?	La protection de l'adresse IP sera disponible pour les utilisateurs de Chrome dans l'expérience de base du navigateur. Il ne s'agira pas d'une fonctionnalité payante.
Serveur proxy	Les mêmes serveurs proxy seront-ils utilisés pendant les sessions utilisateur ?	Une connexion HTTP/S utilise une seule paire de proxys et présente une seule adresse IP masquée à l'origine. En outre, il n'existe aucune contrainte stricte concernant les différentes connexions HTTP/S qui doivent utiliser les mêmes serveurs.
Plates-formes compatibles	Sur quelle plate-forme la protection IP sera-t-elle disponible ?	La protection des adresses IP sera initialement disponible sur Chrome pour Android et ordinateur. Nous continuons d'évaluer comment étendre cette protection à d'autres plates-formes.
Désactiver	Les utilisateurs pourront-ils désactiver IP Protection ?	Nous prévoyons de laisser aux utilisateurs le choix d'utiliser ou non la protection IP.
Anonymisation	Quels types de requêtes seront anonymisés avec la protection IP ?	Les requêtes HTTP/S et DNS vers les domaines tiers éligibles sont anonymisées via les proxys de confidentialité. Nous vous fournirons des informations supplémentaires dans une vidéo explicative à venir sur la façon dont nous déterminerons les domaines à inclure. Le reste du trafic (par exemple, le reste des requêtes DNS ou d'autres trafics HTTP/S) n'est pas affecté.
Visibilité des données	Les adresses réseau peuvent être accessibles lors du premier saut de la protection IP.	Dans le modèle de proxy à deux sauts, le premier saut (contrôle 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ôle par un CDN externe) ne voit qu'une tuple sur le premier saut (adresse IP du proxy + port) et l'adresse IP de destination. Pour la réponse renvoyée par l'origine, le deuxième saut peut transférer la réponse au proxy et au port du premier saut associés à la requête, et n'a pas besoin d'apprendre quoi que ce soit 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 deuxième saut n'apprend que l'adresse IP de destination.
WebView	La protection IP sera-t-elle disponible pour Android WebView à l'avenir ?	Nous n'avons pas de plans à ce sujet pour le moment, mais notre objectif est de fournir cette protection aussi largement que possible.

Atténuation du suivi des rebonds

Thème des commentaires	Résumé	Réponse de Chrome
Suivi des interactions	Comment les interactions des utilisateurs sont-elles suivies ?	Les mesures d'atténuation du suivi des rebonds suivent deux types d'interactions utilisateur: Activations utilisateur telles que définies par la spécification HTML. Il s'agit essentiellement de clics, de pressions sur les touches, d'appuis sur un écran tactile, etc. Affirmations webauth réussies. Il s'agit des cas où un utilisateur appuie sur une clé de sécurité ou utilise une clé d'accès comme forme d'authentification. 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 l'etld+1 sans schéma et l'heure de l'interaction. Les interactions protègent le domaine associé de 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 examinons cette demande et nous attendons les commentaires supplémentaires de l'écosystème.

Privacy Budget

Aucun commentaire reçu ce trimestre.

Prévention du suivi intersites pour améliorer la confidentialité

Ensembles de sites Web associés (anciennement "Ensembles propriétaires")

Thème des commentaires	Résumé	Réponse de Chrome
Approche centralisée	Inquiétude concernant l'approche de dépôt centralisé pour la gestion des ensembles de sites Web associés.	Un dépôt public et facilement accessible est essentiel à la conception d'un système de révision par les pairs, car il permet de rendre les envois responsables. La fonctionnalité des cookies tiers est finalement fournie par l'utilisation de l'API Storage Access ou de l'API rSAFor, l'adhésion à RWS fournissant un accès accordé automatiquement (par opposition aux invites avec l'API Storage Access). Nous pensons qu'une approche telle que le processus d'envoi de la notification RWS est une exigence appropriée pour l'accès aux cookies tiers accordé automatiquement.
Renommager le fichier JSON	Le nom du fichier JSON hébergé doit-il être modifié en raison du changement de nom de l'API ?	Oui, les consignes d'envoi ont été modifiées, et le domaine principal doit diffuser un fichier JSON à l'emplacement `/.well-known/related-website-set.json`. Les ensembles existants de la liste RWS ne doivent pas être modifiés, mais si des modifications sont apportées aux ensembles existants, le fichier JSON doit être modifié.
(également indiqué dans les trimestres précédents) Limite de domaines	Demande d'augmentation du nombre de domaines associés	Comme annoncé dans un article de blog le 31 août, nous avons augmenté la limite de domaines associés à cinq domaines suite aux commentaires de l'écosystème. Nous avons décidé d'augmenter la limite de 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	Les ensembles de sites Web associés ne fonctionneront-ils qu'avec les cookies tiers désactivés ?	Les ensembles de sites Web associés fonctionnent même si un utilisateur n'a pas bloqué les cookies tiers. Toutefois, aucun effet observable ne sera visible, car les cookies pertinents sont disponibles sans avoir besoin des ensembles de sites Web associés et de l'API Storage Access.
Modifications légitimes	Comment le dépôt des ensembles de sites Web associés empêche-t-il les non-propriétaires de modifier les ensembles ?	Conformément aux guides de soumission, n'importe qui peut envoyer une demande d'extraction sur GitHub pour modifier le fichier `first_party_sets.JSON`. Toutefois, si la demande de publication est approuvée (elle passe les validations techniques, etc.), elle sera fusionnée manuellement par lots dans la liste canonique des FPS une fois par semaine (les mardis à midi, heure de l'Est) par Google. Si un pirate informatique tente de modifier un ensemble qui ne lui appartient pas, cela ne devrait pas poser de problème, car il ne pourra pas modifier les fichiers `.well-known` et les validations échoueront.
Hijacking de domaine	Le piratage de domaine peut exposer les données de domaine associées à des tiers non autorisés.	Cela n'est pas possible, comme indiqué dans ce problème GitHub sur Protected Audience.

API Fenced Frames

Thème des commentaires	Résumé	Réponse de Chrome
Non-respect du règlement relatif au contenu	Autorisez les utilisateurs à signaler les annonces suspectes.	Les cadres délimités n'empêchent pas le signalement d'annonces suspectes. Les utilisateurs peuvent toujours interagir avec l'annonce et signaler les annonces suspectes à la technologie publicitaire de la manière habituelle.
Interaction avec les sites environnants	Autorisez les interactions avec le site Web de premier niveau ou environnant.	Nous souhaitons comprendre pourquoi cette demande est nécessaire et nous accueillons les commentaires supplémentaires de l'écosystème.
Publicité native	Prise en charge des cadres délimités pour la publicité native.	Nous envisageons de prendre en charge ce cas d'utilisation et discutons des solutions et des solutions de contournement possibles.

API Shared Storage

Thème des commentaires	Résumé	Réponse de Chrome
Multi-domaine	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 sommes à la recherche de contexte supplémentaire pour faire évoluer les propositions de stockage non partitionné.
URL du blob	Demande d'acceptation de l'URL de blob dans le stockage partagé.	La prise en charge de l'URL de blob a été ajoutée dans Chrome M116.

CHIPs