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

Rapport sur les commentaires – T4 2024

Rapport trimestriel du 4e trimestre 2024 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 personnes concernées 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 regroupant 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 agrégeons le nombre de commentaires que l'équipe Chrome a reçus sur un thème donné, puis nous les organisons par ordre décroissant. Les thèmes communs 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 qui ont été 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 publication de rapports publics. En raison de l'objectif actuel du développement et des tests, nous avons reçu des questions et des commentaires concernant en particulier les API et technologies Topics, PA et Attribution Reporting.

Il est possible que Chrome n'ait pas encore répondu aux commentaires reçus récemment.

Glossaire des acronymes

ARA: API Attribution Reporting
CHIPS: Cookies ayant un état partitionné indépendant
DSP: Plate-forme côté demande
FedCM: Gestion des identifiants fédérés
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
API PA: API Protected Audience (anciennement FLEDGE)
PatCG: Groupe de la communauté sur les technologies publicitaires privées
RP: Partie de confiance
RWS: Ensembles de sites Web associés (anciennement "Ensembles internes")
SSP: Plate-forme côté offre
UA: Chaîne user-agent
UA-CH: Hints client User-Agent
W3C: World Wide Web Consortium
WIPB: Blanchement d'adresse IP intentionnel

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

Thème des commentaires	Résumé	Réponse de Chrome
Engagements	La section G des engagements est essentielle à la viabilité de la Privacy Sandbox. Sans garantie que l'activité publicitaire de Google fonctionnera exclusivement sur les technologies de bac à sable, le risque d'une utilité de plus en plus faible est accru, tout comme la possibilité que Google abandonne cette technologie. Une telle cession ou une telle réduction de l'utilité constituerait une menace existentielle pour l'adressabilité axée sur la confidentialité sur le Web ouvert.	Les engagements ne garantissent pas que l'activité publicitaire de Google fonctionnera exclusivement sur les technologies de la Privacy Sandbox. Google prévoit d'utiliser une approche de portefeuille pour l'adressabilité, qui inclura les technologies de la Privacy Sandbox, comme le font les tiers. Nous savons que l'approche par portefeuille est courante dans l'écosystème publicitaire. Nous pensons qu'il est important que les développeurs disposent d'outils et de technologies protégeant la confidentialité. Nous continuerons de rendre les API Privacy Sandbox disponibles et d'investir dans celles-ci pour améliorer encore davantage la confidentialité et l'utilité.
Gouvernance	Le modèle de gouvernance proposé n'inclut pas de mécanismes spécifiques de responsabilisation dans les processus de consultation formelle ou d'appel.	Mauvaise réponse. (i) Le système de prise de décision et les publications associées, et (ii) la procédure d'appel fournissent des mécanismes spécifiques de responsabilisation. De plus, le fiduciaire de surveillance supervisera leur fonctionnement en détail.
Gouvernance	Commentaires indiquant que le modèle ne contient pas de dispositions pour la création et la maintenance d'une norme multiplate-forme.	Aucun modèle de gouvernance ne peut contraindre d'autres acteurs, dans ce cas les navigateurs, à adopter une norme. Nous n'avons donc pas proposé de modèle nécessitant l'adoption de normes multiplates-formes. Google continuera de participer aux forums de normalisation, où il est courant de proposer des normes et de partager son expérience de leur implémentation.
Gouvernance	Nous vous recommandons de prolonger la période de consultation d'au moins deux mois. Le modèle de gouvernance proposé ne laisse pas suffisamment de temps à l'écosystème pour analyser les impacts des modifications proposées.	La période de trois semaines ne correspond pas à la période complète de collecte des commentaires pour un changement donné, car les cycles de commentaires existants (qui sont beaucoup plus longs) se poursuivront. Le processus de consultation offre plutôt une nouvelle période de commentaires formels dans le processus existant pour les décisions stratégiques. Par conséquent, les tiers pourront continuer à nous faire part de leurs commentaires via différents forums (y compris GitHub, le W3C et des organismes de normalisation des annonces comme l'IAB Tech Lab) tout au long du développement de la fonctionnalité. En structurant les cycles de commentaires de cette manière, l'écosystème peut analyser et partager son point de vue sur un changement proposé sans retarder de manière significative le processus de développement.
Gouvernance	Demande d'informations sur les futurs plans de gouvernance.	Un résumé du modèle de gouvernance proposé est présenté dans le rapport du CMA du 2e/3e trimestre 2024 (pages 3 à 5 ici).
Demande d'exception	Demander une exception pour accéder aux cookies tiers (3PC) pour les utilisateurs ayant donné leur consentement.	Le consentement à l'accès et au stockage des données sur l'appareil à des fins de traitement de données spécifiques n'indique pas nécessairement qu'un utilisateur souhaite remplacer son paramètre 3PC dans Chrome. Autoriser le forçage des paramètres des cookies tiers d'un utilisateur au niveau du site créerait un potentiel de mauvaise utilisation considérable. De plus, il serait impossible pour Chrome d'auditer le comportement de tous les sites susceptibles de générer une demande d'exception.
Privacy Sandbox	Demande de taux d'acceptation des API Privacy Sandbox.	Nous ne prévoyons pas de partager ces informations avec l'écosystème. Les développeurs sont invités à appeler les API où ils ont déployé du code aujourd'hui pour estimer la disponibilité des API Privacy Sandbox.
Évaluation Origin	Prévoyez-vous de prolonger la phase d'évaluation de la fonctionnalité ?	La phase d'évaluation pour les origines a été prolongée jusqu'au 14 avril 2025.
Privacy Sandbox	Demandez une explication concise et non technique de la Privacy Sandbox qui met en avant sa valeur commerciale et obtient l'adhésion des dirigeants.	Nous avons récemment ajouté une section "Ressources pour les entreprises" sur privacysandbox.com (cliquez ici). Vous y trouverez ces informations.
Mode B	Lorsqu'un navigateur est en mode B, le fichier de cookies actuel (1PC, 3PC, stockage local) reste-t-il ou est-il effacé ?	Le fichier de cookies actuel ne sera pas effacé. Les cookies tiers resteront accessibles dans leur contexte propriétaire.
Nouvelle approche des cookies tiers sur Chrome	Les cookies tiers seront-ils complètement supprimés de Chrome à l'avenir ?	Nous proposons une approche actualisée qui donne plus d'importance au choix des utilisateurs. Comme indiqué ici, au lieu d'abandonner les cookies tiers, nous souhaitons proposer une nouvelle expérience dans Chrome qui permettra aux utilisateurs de faire un choix éclairé qui s'appliquera à toute leur navigation sur le Web. Ils pourront modifier ce choix à tout moment. Nous discutons de cette nouvelle approche avec les autorités de régulation et nous nous adresserons à l'ensemble du secteur avant de la déployer.
Tests Chrome	Demande de maintien de la disponibilité des libellés de test facilités par Chrome.	L'équipe Privacy Sandbox comprend que les entreprises souhaitent continuer à utiliser les libellés d'abandon des cookies. La procédure pour prolonger la disponibilité des libellés est semblable à celle pour prolonger un essai d'origine. Dans le cadre de ce processus, le test ne peut être étendu que pour trois jalons Chrome à la fois. Par exemple, le dernier test d'intention d'extension (I2EE) de Chrome pour les libellés d'abandon des cookies a été étendu pour les versions Chrome M130 à M132, inclusivement. Cela permet de prendre en charge les libellés jusqu'à la version stable M133 début février. Les extensions supplémentaires suivront le même processus. Nous vous recommandons donc de suivre les actualités dans le groupe de discussion par e-mail blink-dev.

Inscription et attestation

Aucun commentaire reçu ce trimestre.

Afficher des publicités et des contenus pertinents

Thèmes

Thème des commentaires	Résumé	Réponse de Chrome
Caractéristiques techniques	Le modèle de classification est-il partagé entre Android (par nom d'application) et Chrome (par nom d'hôte) ?	Non, ce sont des modèles distincts, car ils ont des taxonomies différentes.
Granularité de la taxonomie des sujets	Les thèmes sont trop génériques pour être utiles lorsqu'ils sont exploités avec des informations first party.	La taxonomie Topics vise à trouver l'équilibre entre utilité et confidentialité. Nous avons évalué les mécanismes possibles pour rendre les thèmes plus spécifiques, mais nous avons finalement décidé de ne pas le faire pour des raisons de sécurité et de confidentialité, entre autres. Les technologies publicitaires peuvent obtenir les meilleurs résultats en combinant tous les outils disponibles, tels que le machine learning et les signaux respectueux de la confidentialité des API respectueuses de la confidentialité, ainsi que des données contextuelles, des données de création et des données first party. Pour en savoir plus, consultez cette page.
Utilisation de l'API	La couverture de l'API Topics est faible.	Voici quelques raisons courantes d'une faible couverture: - Commandes utilisateur/Désactivation - Commandes de l'éditeur/Désactivation - Éligibilité des sites (les sites suivants ne sont pas approuvés pour être mis en correspondance avec Topics: sites non sécurisés, WebView, Chrome sur iOS et mode navigation privée) - Limites concernant les utilisateurs (les utilisateurs Chrome de moins de 18 ans ou qui utilisent le mode navigation privée ne peuvent pas être observés et ne peuvent pas être associés à des thèmes) - Exigence d'observation du vendeur (l'appelant doit avoir déjà vu l'utilisateur sur le site associé à un thème éligible) - Récence de l'implémentation (environ quatre semaines sont nécessaires pour que l'observation de l'appelant puisse être mise à l'échelle)
Utilisation de l'API	Demande d'informations sur l'utilisation de l'API Topics, car l'onglet "Networking" semble indiquer qu'un appel a été envoyé et intercepté, mais chrome://topics-internals/ n'indique pas que l'observateur a été enregistré.	Lorsque vous utilisez le mécanisme d'en-tête HTTP pour interagir avec l'API Topics, les thèmes sont envoyés dans l'en-tête de requête Sec-Browsing-Topics, mais ils ne sont observés que si le serveur répond avec l'en-tête de réponse Observe-Browsing-Topics: ?1. Pour en savoir plus, cliquez ici.
Participation à Chromium	Pour les ordinateurs, Chrome partagera-t-il avec les autres navigateurs basés sur Chromium le même contexte d'observation et de classement ? Pour les mobiles, Android Chrome partagera-t-il avec les autres navigateurs Android basés sur Chromium / Chromium intégré le même contexte d'observation et de classement ?	Chrome ne partage pas les données Topics avec les autres navigateurs de l'appareil.
Caractéristiques techniques	Comment l'API Topics détermine-t-elle si une page vue par un utilisateur est considérée comme une "entrée d'historique de sujets" ?	Pour être éligible au calcul hebdomadaire des thèmes, une visite de page doit comporter un appel "observe" (qui peut provenir de n'importe quel appelant). Sans appel "observe", la visite ne sera pas prise en compte dans l'historique des thèmes.
Sécurité	Comment l'API Topics empêche-t-elle un appelant d'obtenir les thèmes observés par d'autres appelants ?	Pour en savoir plus, consultez cette page.
Taxonomie	Comment la taxonomie de la structure arborescente de l'API Topics est-elle utilisée dans l'observation à chaque époque ?	Pour calculer les cinq premiers thèmes, seuls les thèmes d'origine fournis par le classificateur sont pris en compte. Le classement est déterminé par (i) la fréquence des visites de la page et (ii) un score de priorisation (voir les spécifications). Lorsque vous calculez le nombre d'appelants qui ont observé chacun des cinq premiers thèmes, il s'agit des appelants qui ont observé le thème principal ou l'un de ses thèmes descendants.
Caractéristiques techniques	Demande d'informations supplémentaires sur le bruit aléatoire de 5% dans la réponse.	Il y a toujours cinq thèmes principaux pour chaque époque. Si l'historique de navigation ne fournit pas cinq thèmes, des thèmes sont choisis au hasard jusqu'à ce qu'il y en ait cinq. Nous appelons ces sujets des "thèmes rembourrés". Les appelants ne recevront pas l'un de ces thèmes aléatoires ajoutés, sauf s'ils ont observé l'utilisateur sur un site contenant le thème au cours des dernières semaines (en appelant l'API). Lorsque l'API est appelée, un hachage par utilisateur, par site et par époque est calculé. Si ce hachage est inférieur à la probabilité de renvoyer un thème avec bruit, le thème aléatoire par utilisateur, par site et par époque est sélectionné. Toutefois, le sujet avec bruit n'est renvoyé (par exemple, il n'est pas filtré) que si l'appelant a observé le sujet sans bruit correspondant pour cet utilisateur/ce site/cette époque (voir explication). Ce filtrage garantit que les sujets avec bruit sont renvoyés 5% du temps pour l'appelant donné, quelle que soit sa capacité d'observation.
Caractéristiques techniques	Comment fonctionnent les sujets en double entre les semaines ? L'API sélectionne-t-elle indépendamment des semaines, puis les fusionne-t-elle ?	Les thèmes de chaque semaine (epoch) sont calculés indépendamment. Le thème particulier choisi pour être renvoyé à partir de chaque époque dépend du site sur lequel se trouve l'appelant. Nous ne tenons pas compte du fait que le thème peut être répété au fil des époques pour un appelant donné (et nous devrions donc envisager de sélectionner un autre thème). Toutefois, nous vous invitons à nous faire part de vos commentaires supplémentaires sur ce problème ici.

API Protected Audience

Thème des commentaires	Résumé	Réponse de Chrome
Tests A/B	La solution de stockage partagé décrite ici ajoute de la latence et présente un taux d'échec élevé (c'est-à-dire qu'une part importante du trafic se retrouve sans ID de population). Un ID à faible entropie (par exemple, 3 bits) peut suffire pour effectuer des tests A/B efficaces sans impact significatif sur la confidentialité.	Nous pensons que la solution de stockage partagé reste une approche viable, mais nous examinons cette demande et nous accueillons les commentaires supplémentaires de l'écosystème si cette fonctionnalité est une priorité.
Rapports	Demande de bits supplémentaires dans `reportWin()`, en particulier étant donné que les nouveaux rapports sur les clics et les impressions dans l'API PA utiliseront 6 à 8 bits, ce qui réduit de manière efficace les bits restants disponibles pour les autres rapports de l'API PA.	Pour des raisons de confidentialité, nous n'envisageons plus d'augmenter le nombre de bits de modelingSignals au-delà des 12 bits actuels. Nous invitons l'écosystème à nous faire part de ses commentaires sur notre proposition d'entraînement de modèles privés, qui vise à répondre aux besoins d'entraînement de ML dans un environnement sécurisé sans limite imposée par la Privacy Sandbox sur le nombre de bits.
Groupes de centres d'intérêt	Demander des cycles de vie de 90 jours pour les groupes de centres d'intérêt, car 30 jours n'est pas suffisant.	Comme indiqué dans notre article de blog, nous prévoyons de prolonger la durée de vie des stories Instagram à 90 jours. Pour en savoir plus, cliquez ici. Nous travaillons actuellement à l'implémentation et vous communiquerons le calendrier de lancement dès qu'il sera disponible.
Groupes de centres d'intérêt	Demande de mises à jour dynamiques pour la délégation IG.	Nous sommes au courant de cette demande de la part de plusieurs personnes concernées et nous recherchons une solution. Nous vous tiendrons informés sur GitHub au fur et à mesure de l'avancement de ce projet et nous serons ravis de recevoir d'autres commentaires de la part de l'écosystème.
Sur l'appareil	Montrer plus de valeur pour l'écosystème afin de continuer à investir dans des solutions d'API de PA sur l'appareil.	L'équipe Privacy Sandbox poursuit le développement d'API basées sur des technologies protégeant la confidentialité (PET, Privacy-Enhancing Technology), y compris l'API PA, afin d'offrir aux développeurs davantage d'options protégeant la confidentialité dans le navigateur. Ces technologies sont désormais disponibles à grande échelle dans les navigateurs Chrome (et pas seulement 1 %, comme certains développeurs l'ont mal compris). Que les utilisateurs activent ou non les cookies tiers, les développeurs peuvent choisir d'intégrer des solutions basées sur les PET à leurs produits, tout comme de nombreuses entreprises choisissent d'adopter d'autres solutions basées sur les PET en dehors du navigateur. De nombreux développeurs bénéficient déjà de l'investissement dans des solutions d'API PA sur l'appareil en étendant leur signal d'audience propriétaire déterministe pour améliorer la couverture sur les sites. Nous comprenons que certains développeurs ne choisiront d'utiliser les API Privacy Sandbox ou d'autres solutions basées sur les PET que si davantage de cookies tiers sont désactivés. Ils attendent des informations leur permettant de déterminer combien de navigateurs conserveront des cookies tiers. Nous sommes conscients que ces développeurs attendront de trouver les informations qu'ils recherchent pour prendre des décisions concernant leurs produits.
Groupes de centres d'intérêt	Autorisez les SSP à participer à la création d'IG et aux rôles qui leur sont associés. Les SSP considèrent cela comme une partie importante de leur valeur ajoutée et souhaitent pouvoir aider les éditeurs à vendre des IG via leurs SSP.	Plusieurs personnes nous ont demandé de prendre en charge des délégations IG plus avancées. Nous voyons la valeur ajoutée des SSP dans ce processus. Nous recherchons la meilleure solution permettant à différentes parties de participer au processus d'extension d'audience. Nous vous tiendrons informés sur GitHub au fur et à mesure de l'avancement de ce projet et nous serons ravis de recevoir d'autres commentaires de la part de l'écosystème.
Rapports	Différences entre le nombre de rapports sur les enchères non nulles entre l'API forDebuggingOnly et l'API Private Aggregation.	Nous nous attendons à ce qu'il existe une divergence pour deux raisons: Tout d'abord, le mode débogage de l'API Private Aggregation n'est disponible que lorsqu'il existe des 3PC autorisés sur l'appareil, tandis que l'API forDebuggingOnly est toujours disponible sans échantillonnage (ce dernier comportement finira par changer, comme indiqué ici). Deuxièmement, l'API Private Aggregation est soumise à des limites de contribution, contrairement à forDebuggingOnly. Toutefois, ces commentaires indiquent qu'un autre élément peut être à l'origine d'un écart inattendu. Nous collaborons avec un tiers pour résoudre ce problème.
Cliquabilité	Comme indiqué dans la proposition mise à jour du signal de popularité, les vues et les clics seraient enregistrés en renvoyant un nouvel en-tête de réponse HTTP aux requêtes initiées par l'attribut "attributionsrc" qui sont éligibles. Cet en-tête de réponse inclurait une liste d'origines pouvant être utilisée pour indiquer quelles autres parties peuvent inclure ces vues et clics dans leurs totaux cumulés. Cela signifie-t-il que la technologie publicitaire peut définir les origines de manière arbitraire ?	Dans la présentation de la mesure de la popularité, il est indiqué qu'une technologie publicitaire qui contribue à un événement de vue ou de clic pour le nombre de vues et de clics agrégés (une "origine de fournisseur") peut inclure un paramètre facultatif dans l'en-tête de réponse qui lui permet de spécifier "une ou plusieurs origines de propriétaires d'IG pour lesquelles cet événement peut être inclus dans le nombre de vues et de clics calculés qui sera fourni à leurs invocations `generateBid()` dans les enchères Protected Audience" ("origines éligibles"). Toutefois, ces vues et clics ne sont pas automatiquement inclus dans le nombre de vues et de clics. Au lieu de cela, chaque technologie publicitaire doit spécifier, dans ses IG, l'ensemble des"origines de diffusion" à partir desquelles les événements de vue et de clic doivent être inclus. Seules les données de ces origines de diffusion contribuent au nombre de vues et de clics présenté aux appels `generateBid()` de cette technologie publicitaire. Ce mécanisme nécessite un accord des deux côtés et empêche les acteurs malveillants d'influencer le nombre de vues et de clics pour d'autres technologies publicitaires. Cela signifie également qu'une technologie publicitaire"fournissant " qui définit des"origines éligibles" arbitrairement n'aura aucun impact sur le nombre de vues et de clics de ces origines éligibles, sauf si ces origines éligibles incluent explicitement et intentionnellement cette origine fournissant dans leur IG.
Entraînement de modèle privé	Dans certains cas, la descente de gradient stochastique à confidentialité différentielle (DP-SGD) ralentit considérablement le processus d'entraînement, car elle détruit la sparsité des gradients calculés lors de la rétropropagation. Quelles techniques sont envisagées pour y remédier ou quelles réflexions vous viennent à l'esprit à ce sujet ?	Nous connaissons certaines techniques permettant de préserver la sparsité dans DP-SGD (par exemple, celle-ci), et nous étudions la possibilité de prendre en charge ces types de techniques dans l'infrastructure d'entraînement de modèles privée. Nous vous tiendrons informé de l'évolution de la situation. N'hésitez pas à nous faire part de vos commentaires sur cette page.
Ciblage par exclusion	Demande d'informations sur le déploiement de la fonctionnalité de filtrage négatif d'Instagram décrite ici.	Comme indiqué dans notre réponse ici, nous prévoyons de prendre en charge les IG négatifs dans les enchères via l'API PA. Nous vous communiquerons un calendrier de lancement dès qu'il sera disponible. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur cette page.
Enchères	Est-il possible de combiner plusieurs IG lors des enchères ?	Cela n'est pas possible pour l'instant avec l'API PA. L'API PA repose sur la conception selon laquelle l'IDG concerne les informations qu'un seul site connaît sur l'utilisateur, ce qui a été au cœur des discussions avec l'écosystème dans son ensemble. Cette approche permet aux technologies publicitaires de créer diverses solutions qui aident les annonceurs à élargir leurs audiences propriétaires sur le Web. Nous sommes conscients que la proposition d'API Ads Selection de Microsoft propose une conception différente, dans laquelle les audiences sont basées sur des informations provenant de plusieurs sites. Nous continuerons de surveiller leur approche, mais nous aimerions que l'écosystème, y compris la communauté de la confidentialité, discute davantage de ces changements avant que nous n'envisagions d'apporter des modifications similaires à Chrome.
Annonces natives	Inquiétudes concernant la capacité de l'API PA à prendre en charge de manière adéquate les différents formats et exigences de rendu des annonces natives, et si l'API PA permet la flexibilité et l'optimisation des créations nécessaires à une publicité native efficace.	Nous travaillons activement à améliorer la prise en charge des annonces natives, et nous sommes à l'écoute des commentaires de l'écosystème.
Rapports	Demande d'amélioration de la robustesse des scripts de création de rapports qui se disputent les ressources avec les scripts d'enchères et qui peuvent être perdus lorsque l'utilisateur quitte le frame d'enchères en cours.	Nous espérons publier une réponse sur GitHub prochainement, mais nous ne pensons pas que ces problèmes affecteront de manière significative les signalements valides dans la pratique.
Remplacement de macro	Les remplacements de macro transmis par la configuration des enchères ne fonctionnent pas avec certaines configurations tierces.	La cause du problème était que cette fonctionnalité n'était pas activée pour tout le trafic libellé en mode A/B. Nous avons récemment décidé d'activer cette fonctionnalité (et d'autres dans la même situation) pour tout le trafic associé au mode A/B. Nous prévoyons d'effectuer ce changement au cours du premier trimestre 2025. N'hésitez pas à nous faire part de vos autres commentaires sur cette page.
Documentation	Je demande des précisions, car il semble y avoir une incohérence dans la documentation concernant l'unité de mesure de la valeur de récence dans l'objet browserSignals de `generateBid()`.	Pour en savoir plus, cliquez ici et consultez notre documentation. La bonne réponse est que l'unité de mesure est les millisecondes.
Rapports	Demande de rapports tiers : alors que les DSP et les SSP reçoivent des notifications d'impression de la part de Chrome, les fournisseurs techniques de couche intermédiaire ne le font pas par défaut.	Nous discutons actuellement de cette demande de fonctionnalité sur cette page et nous sommes à l'écoute de vos commentaires supplémentaires.
Groupes de centres d'intérêt	Demande d'aide pour exclure dynamiquement les acheteurs de groupes d'intérêts lorsque vous utilisez des workflows d'enchères parallèles pour les groupes d'intérêts.	Pour en savoir plus, consultez cette page.
Annonces natives	Les enchères indépendantes de l'API PA pour un chargement de page donné empêchent le filtrage des annonces sur la même page.	Nous étudions actuellement la possibilité d'intégrer davantage d'annonces natives, y compris des widgets de recommandation appelés "natifs" et qui comportent plusieurs annonces dans une même unité. Nous sommes conscients que la conception actuelle n'est peut-être pas compatible avec le filtrage des annonces sur la même page, et que d'autres protections telles que les frames cloisonnés peuvent également l'empêcher.
Annonces natives	Les fonctionnalités existantes de l'API PA, telles que l'analyse des créations, la création de rapports, etc., qui reposent sur des signaux basés sur des URL, devront peut-être être adaptées pour gérer les objets JSON utilisés dans les créations publicitaires natives.	Nous étudions activement la possibilité d'étendre la compatibilité avec les annonces natives. Nous évaluons également la faisabilité d'adapter l'API PA pour faciliter l'affichage des annonces natives.
Validation des annonces	La brand safety tierce dans l'API PA est affectée en raison des limites de latence et de mise en cache de perBuyerSignals, ce qui pose problème pour le contenu dynamique.	Nous sommes conscients que les SSP et les DSP doivent déterminer un TTL optimal pour la mise en cache, qui équilibre les objectifs de modelage du trafic et les TTL maximaux de brand safety afin de s'assurer que les données mises en cache restent pertinentes pour la brand safety. Nous étudions ce problème et vous tiendrons informé de son évolution.
Validation des annonces	Le remplacement de la macro FullpageURL par les SSP est nécessaire pour effectuer une mesure de la brand safety post-enchères.	La suggestion actuelle pour les SSP est de fournir ce signal avec deprecatedReplaceInURN.
Validation des annonces	L'absence de standardisation des formats de macro utilisés par les SSP pour la validation post-enchères peut entraîner des incohérences et des erreurs dans le traitement et l'analyse des données.	Les SSP et les outils de validation des annonces doivent collaborer directement pour définir des consignes et des spécifications claires sur l'utilisation des macros afin de standardiser les formats de macro entre les SSP, de garantir la cohérence et d'éviter les erreurs lors du traitement et de l'analyse des données. C'est une activité pour laquelle les organisations de normes publicitaires comme l'IAB Tech Lab sont particulièrement adaptées.
Validation des annonces	Les annonceurs et les vérificateurs d'annonces ont besoin d'un mécanisme permettant d'associer les vérifications avant et après enchères pour le même contexte d'éditeur afin de déboguer et de résoudre les problèmes.	Une option de vérification post-enchère consiste à utiliser des signaux basés sur les enchères et les campagnes intégrés aux rapports au niveau des événements. Cela peut permettre des jointures avec les journaux de décisions avant enchères. Nous étudions les modèles possibles pour y parvenir et vous tiendrons informé au fur et à mesure de leur développement.
Validation des annonces	Demande d'exploration de solutions de serveurs de clé-valeurs approuvées (TKV, Trusted Key-Value) (propriété de la DSP et de l'outil de validation des annonces) pour les enchères préalables et pour résoudre les limites des cadres clôturés pour les enchères postérieures.	Nous évaluons cette demande et nous invitons les membres de l'écosystème à nous envoyer leurs commentaires ici afin de trouver une solution qui pourrait prendre en charge la brand safety avant enchères et faciliter les exigences de coordination entre les parties.
Annonces natives	Demande d'audit du rendu post-enchères côté vente pour les annonces natives.	Nous étudions activement d'autres fonctionnalités d'annonces natives et envisageons d'adapter des fonctionnalités existantes comme celle-ci pour faciliter le rendu des annonces natives.

Enchères protégées (services de mise aux enchères et d'enchères)

Thème des commentaires	Résumé	Réponse de Chrome
Latence	Les mesures d'atténuation de la latence n'ont pas été suffisantes. Bien que les services de mise aux enchères et d'enchères puissent atténuer ce problème à long terme, Google ne s'est pas engagé à les rendre largement disponibles avant de modifier les PGC tiers dans Chrome.	Nous avons apporté plusieurs améliorations à la latence sur l'appareil au cours des derniers trimestres. Nous développons et évaluons également les services d'enchères et de mise aux enchères si nécessaire. Nous avons récemment mis à jour notre guide des bonnes pratiques concernant la latence, qui contient plus d'informations sur la façon de profiter de ces fonctionnalités. Nous continuons également à améliorer la latence, comme vous pouvez le voir sur cette page.
(également indiqué dans les trimestres précédents) Sécurité des enchères	Demande de clarifications sur les approches permettant d'empêcher ou d'atténuer les tentatives de falsification des enchères sur l'appareil (par exemple, y compris si Google considère cela comme un risque important).	Notre réponse n'a pas changé depuis les trimestres précédents: "Les mécanismes de création de rapports des annonces de l'API PA conservent les informations utilisées pour distinguer le trafic humain du trafic généré par des bots. De plus, les techniques actuelles d'inclusion ou d'exclusion de domaines basées sur les domaines peuvent être utilisées dans l'API PA. Cela est décrit plus en détail dans notre réponse au rapport de l'IAB Tech Lab sur la Privacy Sandbox."
Solutions sur site	Inquiétudes concernant le fait que les plus grands fournisseurs pourraient ne pas adopter la Privacy Sandbox ni les enchères et mises aux enchères en raison de l'absence de prise en charge du cloud privé, ainsi que de la feuille de route longue et opaque pour la prendre en charge.	Nous nous engageons à étendre les infrastructures sur lesquelles les services Privacy Sandbox s'exécutent. Nous avons récemment annoncé la prise en charge du cloud Azure et continuons d'étudier les solutions possibles pour fournir des mesures de confidentialité et de sécurité similaires pour les clouds privés. Depuis notre communication d'octobre, nous avons progressé dans nos recherches sur les approches potentielles pour protéger la confidentialité des utilisateurs de Chrome dans un environnement d'exécution sécurisé (TEE) sur site. Nous en sommes maintenant à un stade de nos recherches où nous souhaitons valider différentes approches auprès des personnes concernées par l'écosystème. Nous prévoyons de commencer à recueillir des commentaires au cours du premier trimestre. Les commentaires et la collaboration au sein de l'écosystème vous aideront à affiner les solutions possibles.
Tests	Est-il possible de créer des TEE pour tester les solutions de reporting de l'API PA (Real Time Reporting et Private Aggregation) ?	Pour les tests du service d'agrégation, les technologies publicitaires peuvent utiliser des données de test et des outils de test local pour générer des rapports récapitulatifs à des fins de test fonctionnel. Pour en savoir plus, consultez l'atelier de programmation sur les tests locaux ici. Pour tester l'agrégation dans le TEE, les technologies publicitaires doivent suivre la procédure d'inscription indiquée dans les conditions préalables de l'atelier de programmation ci-dessus. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur cette demande en cliquant ici.
Intégration des clés-valeurs de l'accord	Demander la possibilité d'extraire des informations basées sur les accords de KV pour les cas d'utilisation professionnels.	Nous évaluons cette demande de fonctionnalité et vous tiendrons informé sur GitHub.
Mesure des accords sans gagnant	Demander un signal ou la possibilité de comprendre quand un SSP n'a pas remporté l'enchère et pourquoi	Nous évaluons cette demande et vous tiendrons au courant sur GitHub.
Demande de fonctionnalité	Demande à la Privacy Sandbox de fournir une structure de dictionnaire pour aider à faire correspondre un groupe d'annonces à l'ensemble d'ID d'accords correspondant.	Nous évaluons cette demande, ainsi que d'autres moyens de réduire la taille de l'inventaire Google en ce qui concerne le stockage des ID de contrat. Nous vous tiendrons au courant sur GitHub.
Performances	Solutions permettant de mesurer les opportunités d'enchères d'annonces manquées, éventuellement en raison de la taille du script d'enchères.	Nous examinons cette demande et nous serons ravis de recevoir vos commentaires supplémentaires sur cette page.
Caractéristiques techniques	Actuellement, B&A ne lit que le champ prevWins au lieu du dernier champ prevWinMs qui a remplacé prevWins dans la spécification.	Il est exact que B&A ne transmet pas la durée en millisecondes dans prevWins à `generatebid()`. Chrome envoie la durée en secondes pour réduire la surcharge sur la charge utile. La solution consiste à demander à B&A de convertir les secondes en millisecondes. Les enchères et mises aux enchères fourniraient à la fois prevWins et prevWinsMs dans browserSignals pour les rendre compatibles avec les enchères sur l'appareil. Remarque : Même pour les enchères sur l'appareil pour le Web, prevWins et prevWinsMs correspondent à la même valeur, et prevWinsMs = prevWins * 1 000. Nous allons corriger ce problème en priorité.
Documentation	La documentation n'indique pas clairement comment tester l'interface utilisateur du vendeur. Il serait utile d'obtenir des conseils supplémentaires sur les tests juste après le déploiement, ainsi que sur l'utilisation de Bazel pour les compilations.	Cet atelier de programmation a été publié en tant que guide pour faciliter le test des SFEs par l'ensemble de l'écosystème.
Déploiement	Prévoyez-vous de fournir des binaires prédéfinis pour les enchères et les mises aux enchères ?	Nous envisageons de fournir des binaires prédéfinis pour les tests et les analyses, mais nous n'avons pas de calendrier précis à ce sujet. En attendant, les technologies publicitaires peuvent créer les binaires elles-mêmes et les valider à l'aide des hachages fournis.
Déploiement	Tous les types d'orchestration (serveur, client, mixte) doivent-ils être pris en charge, ou l'un d'entre eux doit-il être prioritaire sur les autres ?	Nous n'avons aucune recommandation spécifique concernant les modes implémentés par la technologie publicitaire. Le choix dépend de plusieurs facteurs, mais, en fin de compte, il dépend de ce qui est le plus adapté aux intérêts de vos clients.
Tests	Je souhaite obtenir des précisions sur les tests ayant échoué lors de la compilation de l'application de test A/B.	Cela peut être dû à un test instable. Nous avons conseillé à la technologie publicitaire d'utiliser l'option `--no-tests` pour toutes les commandes de compilation `build_and_test_all_in_docker` afin d'ignorer l'exécution des tests.
Journaux	Je souhaite savoir pourquoi les journaux de l'explorateur de journaux sur GCP sont tagués avec l'instance de VM exécutant le SFE en mode test, mais pas en mode production.	Il est difficile de généraliser, car cela dépend de ce qui a été vu exactement, mais en général: - Les journaux de non_prod sont probablement les journaux stderr redirigés par le fournisseur de services cloud (dans ce cas, GCP) et GCP a ajouté la balise. - Les journaux générés par la VM sont généralement tagués avec l'instance de VM, tandis que les journaux générés par le binaire ne sont pas tagués par GCP. - Les journaux de production sont exportés par Open Telemetry dans le TEE, qui comportent des balises différentes. Voici quelques informations sur ce qui est disponible dans non_prod et prod.
B&A	Erreur 403 en cas de secrets manquants lorsque la journalisation OTEL est désactivée.	Ce problème a été résolu dans la mise à jour 4.1, et la documentation a été modifiée en conséquence.
B&A	L'absence de fichier outputs.tf pour la configuration Terraform GCP entraîne une erreur.	Ce problème est désormais résolu.
Tests	Erreur lors de la récupération de la clé privée en mode test.	Dans ce cas, assurez-vous que les serveurs s'exécutent avec TEST_MODE=true. Pour en savoir plus, consultez cette vidéo.
Feuille de route	Est-il prévu que getInterestGroupAdAuctionData accepte plusieurs origines de vendeur et renvoie une mise en correspondance de l'origine du vendeur avec le texte chiffré de la charge utile d'enchères et de mise aux enchères ?	Oui, nous prévoyons d'ajouter la possibilité pour navigator.getInterestGroupAdAuctionData() d'accepter plusieurs vendeurs.
Caractéristiques du KV	L'URL KV (trustedScoringSignalsURL) peut-elle être transmise sous forme de promesse ?	Pour en savoir plus, consultez cette page.
B&A	Demande de création d'un nouvel en-tête de plate-forme pour indiquer au côté vendeur de la place de marché les fonctionnalités requises par le client (navigateur) pour qu'une mise aux enchères privée puisse avoir lieu.	Nous discutons actuellement de cette demande de fonctionnalité sur cette page et nous sommes à l'écoute de vos commentaires supplémentaires.
Lissage du trafic	Proposition visant à réduire les coûts incrémentaux liés à l'hébergement de serveurs d'enchères et de mise aux enchères, en particulier pour les DSP.	Nous discutons actuellement de cette proposition sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.
Bring-Your- Own-Binary	Envisagez de mettre à jour la vidéo explicative pour indiquer explicitement que tous les binaires sont compatibles.	Cette information a été mise à jour. Pour en savoir plus, cliquez ici.
Appels KV	`generateBid()` attend-il la fin de tous les appels de magasin de clés-valeurs (KV) ou s'exécute-t-il indépendamment ? En quoi le traitement par lot KV affecte-t-il la chronologie ?	Pour en savoir plus, consultez cette page.
Performances	Demande de documentation supplémentaire sur la réutilisation des scripts d'enchères et recommandation de définir des en-têtes de contrôle du cache sur les scripts.	La documentation a été ajoutée ici.
Performances	Demande d'envisager et d'explorer la possibilité de charger des ressources (par exemple, des scripts d'enchères) de manière asynchrone afin de réduire la latence des enchères sur l'appareil.	Nous discutons actuellement de cette demande de fonctionnalité sur cette page et nous sommes à l'écoute de vos commentaires supplémentaires.
Journalisation du consentement	Clarification nécessaire concernant l'erreur qui s'affiche lorsque vous essayez d'utiliser la journalisation du consentement en définissant le paramètre CONSENTED_DEBUG_TOKEN.	Dans ces cas, vérifiez que CONSENTED_DEBUG_TOKEN est présent dans le Gestionnaire de secrets, que ENABLE_OTEL_BASED_LOGGING est défini sur true et que TELEMETRY_CONFIG est défini sur mode: PROD. Consultez cette page pour en savoir plus, qui renvoie à la source ici.
Journaux	Les événements forDebuggingOnly sont-ils disponibles via les enchères et les mises aux enchères ?	forDebuggingOnly pour les enchères et les mises aux enchères est disponible pour les enchères d'un seul vendeur depuis avril 2024. Nous prévoyons de l'activer très prochainement pour les enchères multivendeurs.
Journaux des worklets	Demande de rendre la journalisation des worklets compatible avec ChromeDriver.	Nous examinons cette demande et nous serons ravis de recevoir vos commentaires supplémentaires sur cette page.

Mesurer les annonces numériques

Attribution Reporting (et autres API)

Thème des commentaires	Résumé	Réponse de Chrome
Rapports de débogage	Comment les rapports de débogage ARA seront-ils disponibles pour les technologies publicitaires suite à la nouvelle approche des cookies tiers sur Chrome ? Les technologies publicitaires doivent-elles toujours avoir accès aux rapports de débogage ARA pour les utilisateurs qui conservent des cookies tiers et dont les API Privacy Sandbox sont activées ?	Les technologies publicitaires auront accès à des solutions de débogage basées sur les cookies et sans cookies pour les utilisateurs pour lesquels les 3PC et l'ARA sont activés. Lorsque les cookies sont désactivés, ils n'ont accès qu'à la solution de débogage globale. Pour en savoir plus sur les solutions de débogage, cliquez ici et ici.
Détection de caractéristiques	Demande d'aide pour effectuer la détection de fonctionnalités pour ARA côté serveur.	Actuellement, la compatibilité avec la fonctionnalité ARA peut être identifiée en fonction de la version de Chrome indiquée dans la chaîne user-agent. Nous serons ravis de recevoir d'autres commentaires de la part de l'écosystème à ce sujet.
Demande de fonctionnalité	Demande que la valeur source_registration_time utilisée dans les informations partagées agrégées ARA soit plus précise (par exemple, arrondie à une heure ou une minute au lieu d'un jour) et configurable pour tenir compte du fuseau horaire (actuellement, uniquement UTC).	Arrondir le champ "source_registration_time" au jour le plus proche est un mécanisme de confidentialité qui limite la capacité d'une technologie publicitaire à associer un utilisateur spécifique à un enregistrement de source spécifique. Actuellement, la valeur source_registration_time est basée sur l'heure UTC. Une technologie publicitaire peut ajuster ses rapports sur les annonces pour tenir compte de ce paramètre. Vous pouvez nous faire part de vos commentaires sur l'écosystème concernant cette demande en cliquant ici.
Caractéristiques techniques	Demande de clarification de la spécification de "trigger_data" et de "priority", en particulier lorsqu'ils sont utilisés avec une valeur de tableau.	Ces champs n'acceptent pas de valeurs de tableau. Les crochets dans l'explication ne représentent pas un tableau, mais indiquent que le texte n'est pas un exemple de valeur, mais un espace réservé avec une description. Comme le suggère le texte entre crochets: - trigger_data est un int-64 - priority est un int-64 signé Aucun des champs n'accepte de valeurs de tableau. Nous vous recommandons également d'utiliser l'outil de validation des en-têtes pour ARA afin de tester différentes valeurs et de détecter les erreurs si la documentation est confuse.
Compatibilité avec les annonces AMP (Accelerated Mobile Pages)	ARA est-il compatible avec les annonces AMP ?	Vous pouvez consulter notre proposition sur la façon dont nous pourrions prendre en charge AMP sur cette page. N'hésitez pas à nous faire part de vos commentaires supplémentaires.
Caractéristiques techniques	Quelle URL sera considérée comme "site source" pour les annonces intégrées multicouches pour l'ARA ?	URL du site racine.
(Signalé également au cours des trimestres précédents) Demande de fonctionnalité	Demande de réduction de la valeur minimale de event_report_window de 3 600 secondes (1 heure) à 1 800 secondes (30 minutes).	Pour déterminer la période minimale de création de rapports, vous devez trouver un équilibre entre l'utilité et la confidentialité. La période de référence minimale d'une heure pour les rapports au niveau des événements est essentielle pour préserver la confidentialité et atténuer certains types d'attaques de reconstruction de l'historique. Pour nous faire part de vos commentaires supplémentaires concernant cette demande, cliquez ici.
Bruit	Comprendre plus en détail comment le bruit est implémenté dans les rapports ARA au niveau des événements afin de garantir une interprétation et une utilisation précises des données.	Pour en savoir plus, cliquez ici et sur ce lien.
Rapports	Les informations partagées des rapports agrégables ne contiennent plus source_registration_time par défaut.	Cela est dû à des modifications apportées à l'API. Pour en savoir plus, cliquez ici.
Rapports	`filtering_id` est absent de l'onglet "Rapports agrégables" de l'interface utilisateur chrome://attribution-internals/.	Le `filtering_id` est actuellement visible dans les détails de l'onglet "Enregistrements de déclencheurs" lorsque vous cliquez sur une ligne, ce qui vous permet de confirmer sa validité. Nous reconnaissons l'utilité de l'afficher dans l'onglet "Rapports agrégables". C'est pourquoi nous avons pris les mesures nécessaires.
Source d'attribution	Demande de clarification sur le fonctionnement de la source d'attribution.	Pour en savoir plus, consultez cette page.
Attribution de l'application au Web	Demande d'aide pour les implémentations où l'OS ou le Web est utilisé pour les sources.	Pour obtenir des conseils, consultez cette page.

Service d'agrégation

Thème des commentaires	Résumé	Réponse de Chrome
Demande de fonctionnalité	Demande d'un délai configurable pour AgS et/ou d'une meilleure visibilité sur l'état des tâches pour les exécutions à long terme.	Nous envisageons de proposer des fonctionnalités permettant de surveiller les tâches de longue durée. Nous serons ravis de recevoir d'autres commentaires de la part de l'écosystème à ce sujet.
Terraform	Terraform tente de modifier la stratégie IAM du compte, même si la liste service_account_token_creator_list n'est pas définie.	Les développeurs peuvent ajouter les autorisations qu'ils ont ajoutées dans leur fichier modules/adtech_setup/main.tf local.
Demande de documentation	Demander de la documentation ou un atelier de programmation expliquant comment surveiller l'état du service d'agrégation	Vous trouverez une description des alarmes existantes pouvant être utilisées pour surveiller l'état du service et de la tâche dans les fichiers Terraform de l'opérateur concernés (alarms.tf et monitoring.tf) du dépôt coordinator-services-and-shared-libraries. Nous publierons des documents et des conseils supplémentaires sur la surveillance des tâches de service d'agrégation.
Scaling	Comment surveiller les problèmes de scaling ?	Nous avons publié une version mise à jour de ces consignes, qui documentent l'échelle supérieure du service d'agrégation. Aucun signal direct n'indique actuellement qu'une erreur s'est produite, car la machine ne peut pas gérer l'ampleur de la tâche. Les signaux indirects incluent une consommation de mémoire de 90% avant un échec ou une tâche qui échoue de manière récurrente. Nous sommes à l'écoute de vos commentaires supplémentaires sur la nécessité d'un tel signal.
Caractéristiques techniques	Quelle est la durée d'exécution typique des lots de rapports AgS ?	Pour en savoir plus, cliquez ici.

API Private Aggregation

Thème des commentaires	Résumé	Réponse de Chrome
Demande de fonctionnalité	Demande d'autorisation des contributions de valeurs flottantes (y compris négatives) à contributeToHistogramOnEvent avec une sensibilité de 2^16	Nous discutons actuellement de cette proposition sur cette page et nous serons ravis de recevoir vos commentaires supplémentaires.

Limiter le suivi dissimulé

Réduction de l'User-Agent/Hints client User-Agent

Aucun commentaire reçu ce trimestre.

Protection IP (anciennement Gnatcatcher)

Thème des commentaires	Résumé	Réponse de Chrome
Géolocalisation	Demande de fichier de géolocalisation pour la protection des adresses IP	Le fichier mappant les adresses IP aux emplacements approximatifs pour la protection des adresses IP est disponible sur cette page. Veuillez noter que ce fichier est mis à jour régulièrement.

Atténuation du suivi des rebonds

Thème des commentaires	Résumé	Réponse de Chrome
Liste d'autorisation	La nouvelle position ne concerne plus la liste d'autorisation ni les mécanismes similaires qui seraient indépendants du processus de prise de décision de Google.	Google ne prévoit pas d'utiliser de listes d'autorisation associées aux mesures d'atténuation du suivi des rebonds. Les protections sont appliquées de manière uniforme à tous les domaines.
Conformité	L'ICO doit être compétente en matière de conformité en matière de confidentialité.	L'état de conformité n'a aucun lien avec l'application de la BTM, et Google ne prend aucune décision concernant la conformité lors de l'implémentation de la BTM.
Concurrence	Il semble que Google soit autorisé à exclure les concurrents de PET à l'aide de pratiques commerciales déloyales (ou d'autres mesures), puis à décider s'il les autorise à revenir sur le marché. La procédure d'appel actuelle peut empêcher temporairement les concurrents de PET d'utiliser des mesures de blocage des publicités ou des mesures similaires.	La proposition actuelle de BTM vise à utiliser le suivi des rebonds comme technique. Bien que Google vise à éviter de perturber certains cas d'utilisation pouvant impliquer des techniques similaires, il n'est pas prévu de fournir des exceptions individuelles à la BTM. Par conséquent, la question de l'exercice par Google d'un pouvoir discrétionnaire sur la présence de concurrents ne se pose pas.

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
(également indiqué dans les trimestres précédents) Limite de domaines pour les ensembles de sites Web associés	La limite actuelle de cinq domaines associés n'est pas suffisante pour les cas d'utilisation des mesures multisites.	Notre réponse est similaire à celle des trimestres précédents: Pour le moment, nous ne prévoyons pas d'augmenter la limite numérique. Cette limite a été établie en tenant compte de la confidentialité des utilisateurs, des commentaires des personnes concernées par l'écosystème du W3C et des implémentations comparables dans d'autres navigateurs. Pour en savoir plus, consultez nos articles de blog (1, 2). Nous vous recommandons d'examiner les cas d'utilisation qui nécessitent un accès aux cookies intersites au-delà de la limite numérique et d'utiliser nos conseils pour les cas d'utilisation de l'identité, les intégrations authentifiées et les cas d'utilisation publicitaires. Si vous avez d'autres commentaires à nous faire part concernant ce problème, cliquez ici.

API Fenced Frames

Thème des commentaires	Résumé	Réponse de Chrome
Annonces natives	L'affichage d'annonces natives dans les Fenced Frames pose des défis, car l'héritage du style de l'éditeur est limité en raison des limites de communication entre l'iFrame et la page de l'éditeur.	Nous étudions actuellement de nouvelles fonctionnalités pour les annonces natives, y compris après l'application des règles sur les cadres délimités. Si vous avez d'autres commentaires à nous faire part concernant ce problème, cliquez ici.

API Shared Storage

Thème des commentaires	Résumé	Réponse de Chrome
Utilisation de l'API	L'API Shared Storage n'est pas disponible sur certains appareils lorsque d'autres API Privacy Sandbox sont fonctionnelles.	Ce comportement est attendu pour un petit sous-ensemble d'utilisateurs (environ 1%) qui participent au test de la retenue du stockage partagé. Cette configuration expérimentale permet d'évaluer les performances et l'adoption des API dans différents scénarios.
Utilisation de l'API	Les écritures dans Shared Storage se produisent-elles sous l'origine de l'éditeur ou de l'origine du script d'enchères ? Les tests initiaux n'ont révélé aucune écriture lorsque l'origine de l'éditeur différait de l'origine du script.	Ce problème a été résolu et n'est toujours ouvert que dans le cas d'un bug possible dans les outils de développement. Pour en savoir plus, cliquez ici. Shared Storage écrit à l'origine de l'acheteur dans le contexte d'enchères de l'appel `generateBid`. L'écriture n'est pas liée à l'origine de l'éditeur, même si la page de l'éditeur se trouve sur un autre domaine.
Utilisation de l'API	Quelles sont les mesures de protection mises en place pour empêcher un utilisateur malveillant de lire les rapports sur le stockage partagé ?	Le stockage partagé est partitionné en appelant origin afin qu'un acteur malveillant ou une technologie publicitaire ne puisse pas lire les données de stockage partagé d'une autre technologie publicitaire. Les rapports d'agrégation privée sont envoyés directement à la même origine via TLS afin qu'ils ne puissent pas être interceptés.

CHIPS

Thème des commentaires	Résumé	Réponse de Chrome
Cookies partitionnés	La gestion des cookies n'est pas cohérente entre les différents ports localhost dans Chrome et Firefox, en particulier lorsque l'attribut "partitionné" est utilisé.	Firefox traite localhost avec des ports différents comme des clés de partition distinctes. Bien que ce comportement soit conforme aux principes de sécurité, il s'écarte de la spécification et de l'approche de Chrome. Nous prévoyons d'en discuter avec d'autres navigateurs lors d'une discussion sur les spécifications HTML et nous informerons l'écosystème si cela entraîne une modification de la clé de partition CHIPS. N'hésitez pas à nous faire part de vos commentaires supplémentaires sur ce problème en suivant ce lien.
Cookies partitionnés	Le brouillon de Clear-Site-Data autorise à tort l'effacement au-delà de la partition du site émetteur, ce qui contredit les discussions précédentes référencées ici.	Il s'agit d'un bug dans le document de spécification des normes que nous allons bientôt corriger. Le comportement correct est spécifié dans cette section de la vidéo explicative et correspond à celui des autres navigateurs dans le dépôt de vidéos explicatives sur le partitionnement de l'espace de stockage. L'implémentation de Chrome fonctionne déjà correctement.