Rapport trimestriel du 1er trimestre 2022 résumant les commentaires reçus par l'écosystème sur les propositions de la Privacy Sandbox et la réponse de Chrome.
Dans le cadre de ses engagements envers l'autorité de la concurrence et des marchés, Google a accepté de fournir publiquement des rapports trimestriels sur le processus d'engagement des parties prenantes pour ses propositions de la Privacy Sandbox (voir les paragraphes 12 et 17(c)(ii) des Engagements). Ces rapports récapitulatifs des commentaires de la Privacy Sandbox sont générés en regroupant les commentaires reçus par Chrome à partir des différentes sources, comme indiqué dans la présentation des commentaires, y compris, mais sans s'y limiter, les problèmes GitHub, le formulaire de commentaires disponible sur privacysandbox.com, les réunions avec les acteurs du secteur et les forums sur les normes Web. Chrome se félicite des commentaires reçus de l'écosystème et recherche activement des moyens d'intégrer les enseignements tirés dans les décisions de conception.
Les thèmes de commentaires sont classés par prévalence par API. Pour ce faire, nous regroupons les commentaires reçus par l'équipe Chrome sur un thème donné et les classons par ordre décroissant de quantité. Les thèmes de commentaires courants ont été identifiés en examinant les sujets de discussion des réunions publiques (W3C, PatCG, IETF), les commentaires directs, GitHub et les questions fréquemment posées par les équipes internes de Google et dans des formulaires publics.
Plus précisément, les comptes-rendus des réunions des organes standards Web ont été examinés et, en vue de recueillir des commentaires directs, les enregistrements des réunions individuelles avec les personnes concernées, les e-mails reçus par les ingénieurs individuels, la liste de diffusion de l'API et le formulaire de commentaires public ont été pris en compte. Google a ensuite coordonné les équipes impliquées dans ces différentes activités de sensibilisation afin de déterminer la prévalence relative des thèmes émergents pour chaque API.
Les explications des réponses de Chrome aux commentaires ont été élaborées à partir de questions fréquentes publiées, de réponses réelles apportées aux problèmes soulevés par les personnes concernées et de la détermination d'une position spécifiquement pour cet exercice de reporting public. Compte tenu de l'intérêt actuel du développement et des tests, des questions et des commentaires ont été reçus en particulier concernant les API et technologies Topics, Fledge et Attribution Reporting.
Il est possible que les commentaires reçus récemment ne soient pas encore pris en compte dans la réponse Chrome.
Glossaire des acronymes
- CHIPS
- Cookies ayant un état partitionné indépendant
- DSP
- Plate-forme côté demande
- FedCM
- Federated Credential Management
- Lecteur d'empreinte digitale
- Ensembles internes
- IAB
- l'Interactive Advertising Bureau
- IdP
- Fournisseur d'identité
- IETF
- Internet Engineering Task Force
- ML
- Adresse IP (Internet Protocol)
- openRTB
- Enchères en temps réel
- Prolongation
- Phase d'évaluation
- PatCG
- Groupe de la communauté des technologies publicitaires privées
- RP
- Partie de confiance
- SSP
- Plate-forme côté offre
- TEE
- Environnement d'exécution sécurisé
- UA
- Chaîne user-agent
- UA-CH
- Hints client user-agent
- W3C
- Consortium World Wide Web
- En cours
- Aveugle délibéré des adresses IP
Thèmes communs de toutes les sources de commentaires
Dans nos discussions et nos canaux d'envoi de commentaires, nous abordons des questions portant sur le calendrier, les niveaux de trafic et la disponibilité des tests. En particulier, les testeurs ont toujours souhaité savoir quand les API seront disponibles pour les tests et si les tests seront disponibles dans le monde entier.
Pour répondre à ces commentaires, Chrome a communiqué des informations à grande échelle et publiera des questions fréquentes pour confirmer que les tests seront disponibles dans le monde entier. De plus, Chrome continuera de mettre à jour régulièrement le calendrier public avec l'aide de la CMA.
Diffusez des annonces et du contenu pertinents
| API / Technologie | Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Rubriques | Utilité des sujets sommaires | Certains utilisateurs craignent que la classification générale des thèmes ne soit pas suffisamment utile pour la publicité ciblée par centres d'intérêt. | Pour déterminer l'utilité de l'API, nous effectuerons des tests. Chrome s'attend à ce que la classification évolue en fonction des résultats des tests. |
| Rubriques | Taxonomie | Les partenaires du secteur souhaitent avoir leur mot à dire en influençant la taxonomie. | Chrome reste ouvert pour l'ajout de données à la taxonomie. Les commentaires concernant le modèle de gouvernance mis en place par l'équipe Chrome et la manière dont d'autres organismes du secteur peuvent jouer un rôle plus actif dans le développement et la maintenance de la classification à long terme sont les bienvenus. |
| Rubriques | Utilité pour différents types de sites | Des inquiétudes ont été soulevées concernant l'utilité des sites en fonction de leur niveau de trafic ou de la spécialisation de leur contenu. | Pour déterminer l'utilité de l'API, nous effectuerons des tests. Chrome s'attend à ce que la classification et d'autres paramètres évoluent en fonction des résultats des tests. L'évolution de la taxonomie ou des paramètres peut ne pas nécessiter de modifications incompatibles avec les versions antérieures. De plus, Chrome s'attend à ce que les commentaires influencent encore l'évolution de l'API Topics après l'abandon des cookies tiers. |
| Rubriques | Méthodologie de classification des sites | Demandez aux sites de décider ou d'influencer leur classification Topics. | L'équipe Chrome étudie actuellement cette demande, mais la communauté des navigateurs Web et les DSP s'inquiètent du risque que les sites soient en mesure de "fausser le système" pour cibler les utilisateurs tout en respectant la confidentialité ou en réduisant la pertinence des annonces. Chrome souhaite obtenir des commentaires et évaluer les changements potentiels. |
| Rubriques | Signaux de bruit | Proposer un sujet aléatoire 5% du temps peut créer trop de bruit ou de faux signal. | Le bruit est une méthode importante pour protéger la confidentialité des utilisateurs, et les niveaux de bruit par rapport à l'utilité des sujets seront étudiés par le biais de tests. |
| Rubriques | Autorisation de tiers contrôlée par le site | Demandez aux sites de choisir les technologies publicitaires qui peuvent appeler l'API Topics à partir de leur site. | Cette fonctionnalité demandée est déjà compatible avec la règle d'autorisation "browsing-topics", comme indiqué dans l'explication. |
| Rubriques | Effet de l'API Topics sur les performances des pages | Inquiétudes concernant les retards d'affichage de la première annonce en raison de la dépendance à l'API Topics | Chrome vise qu'il soit possible d'utiliser les thèmes dans les en-têtes de requête HTTP afin d'améliorer les performances. Nous nous sommes basés sur des tests pour vérifier si de telles modifications sont nécessaires. |
| Rubriques | Confidentialité / Règles | Questions sur la raison pour laquelle le filtrage des réponses par appelant est possible si des tiers partagent leurs sujets avec tous les appelants | En nous appuyant sur les commentaires d'un grand nombre de personnes dans l'écosystème, Chrome a choisi cette conception afin de limiter l'accès aux informations à ceux qui n'y auraient pas accès autrement. Bien entendu, les éditeurs et les tiers qui reçoivent des Topics peuvent choisir eux-mêmes les informations qu'ils partageront avec les parties sur leur site. Si les utilisateurs optent pour ce type de partage, Chrome les encourage vivement à les informer de façon transparente vis-à-vis de leurs utilisateurs et à leur proposer des options de partage. |
| Rubriques | Documentation | Intérêt pour une documentation présentant en détail le modèle de classificateur et la taxonomie utilisés par Chrome comme vous l'avez fait pour FLoC, comme la fréquence de modification du classificateur et de la taxonomie | Chrome fournit déjà la taxonomie utilisée dans le cadre des phases d'évaluation, et le modèle de classificateur qui classe les sites Web en Topics est disponible dans le code base de Chrome dans le code Open Source. Dans le cadre des phases d'évaluation, Chrome se réserve le droit d'apporter des modifications en fonction des commentaires reçus et des enseignements tirés de son fonctionnement. |
| FLEDGE | Limitation de la fréquence d'exposition | Vous souhaitez pouvoir contrôler la fréquence par utilisateur au sein d'une campagne ou d'un groupe d'annonces. | FLEDGE sera compatible avec la limitation de la fréquence d'exposition pour les enchères sur l'appareil. Il existe un problème non résolu pour que FLEDGE soit également compatible avec les campagnes contextuelles et de branding. Vous pouvez également utiliser d'autres contrôles de limitation de la fréquence d'exposition à l'aide d'un espace de stockage partagé, d'une autre API en cours de développement et de limites propres à chaque site. |
| FLEDGE | Impact de FLEDGE sur les performances | Des inquiétudes ont été soulevées concernant l'impact potentiel des enchérisseurs utilisant beaucoup de ressources de calcul dans la mise aux enchères FLEDGE | Chrome fait l'objet de discussions actives avec les développeurs au sujet de l'impact potentiel sur les performances du site. Chrome offre l'opportunité d'en savoir plus pendant les tests. |
| FLEDGE | Tester FLEDGE avec d'autres fonctionnalités | Quand et comment les tests avec d'autres fonctionnalités (serveur de k-anonymat, serveurs de clés-valeurs, etc.) auront-ils lieu ? | Afin de faciliter les tests, Chrome déploie volontairement des fonctionnalités par phases lors de la phase d'évaluation initiale. Nous savons qu'il est important de clarifier le calendrier concernant les autres fonctionnalités et dans la mesure du possible. |
| FLEDGE | Coordination des tests | Coordonner les tests de plusieurs technologies publicitaires | Chrome s'efforce de fournir une assistance supplémentaire pour coordonner les tests afin que différentes technologies publicitaires testent les mêmes utilisateurs. Il s'agit également d'une priorité majeure pour les initiatives de sensibilisation aux partenariats Chrome. Les organismes commerciaux du secteur ont également exprimé leur intérêt à jouer un rôle. |
| FLEDGE | Limites applicables aux groupes de centres d'intérêt | Le nombre de groupes de centres d'intérêt auxquels un utilisateur peut être ajouté sera-t-il limité ou pouvant être inclus dans l'enchère ? | Pendant la période de test, Chrome est disposé à affiner ces limites pour des raisons de performances des pages Web ou d'expérience utilisateur, en fonction des commentaires recueillis et de l'impact de la latence mesuré. Les testeurs continuent d'échanger sur d'autres moyens de permettre aux acheteurs et aux vendeurs d'ajuster l'utilisation des ressources. |
| FLEDGE | Fonctionnalités multi-API | Comment les rapports sur l'attribution fonctionneront-ils avec FLEDGE ? | Les détails complets restent à déterminer, et Chrome devrait avoir une mise à jour à ce sujet au deuxième trimestre. Chrome prévoit de continuer à fournir des rapports au niveau des événements pour les résultats des enchères (victoires et défaites) pendant la phase d'évaluation. |
Mesurer la publicité numérique
| API / Technologie | Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| Attribution Reporting (et autres API) | Tester le trafic | Inquiétudes concernant l'existence d'un trafic suffisant pour effectuer des tests | Chrome démarre la phase d'évaluation avec un trafic très faible pour éviter les bugs ou problèmes graves au niveau des commandes utilisateur. Les premiers testeurs jouent un rôle important pour vérifier que les API fonctionnent comme prévu d'un point de vue technique, ce qui permet d'accélérer l'augmentation du trafic. Une fois que vous aurez la certitude que les API fonctionnent comme prévu, Chrome étend la phase d'évaluation pour permettre les tests d'utilité. |
| Rapports sur l'attribution | Ergonomie pour l'enregistrement d'événements | Questions sur les modalités d'inscription aux événements. | Chrome a publié une réponse sur GitHub afin de clarifier les formes d'enregistrement acceptées aujourd'hui. Chrome recueille les commentaires de l'écosystème sur la conception actuelle afin de déterminer si les modifications proposées répondent suffisamment à ces préoccupations ou si d'autres mises à jour sont nécessaires. |
| Rapports sur l'attribution | Génération de bruit | Vous souhaitez en savoir plus sur la façon dont le bruit est généré pour les rapports globaux. | Chrome a publié une réponse sur GitHub afin de fournir plus de détails sur la façon dont le bruit est généré de manière systématique. Chrome prévoit de fournir une bibliothèque pour simuler le bruit et effectuer des tests avec toute une gamme de paramètres pendant les heures de pointe. Chrome prévoit également de fournir des documents et des guides supplémentaires pour les développeurs concernant le mode de création de rapports globaux. |
| Rapports sur l'attribution | Données moins précises pour les petits sites | Crainte que les sites ou les campagnes de petite taille reçoivent des données moins précises. | Chrome reconnaît que les protections de la confidentialité basées sur le bruit ont un impact plus important sur de petites tranches de données. Cependant, il est possible que des méthodes telles que l'agrégation sur des périodes plus longues résolvent ce problème. Nous ne savons pas non plus si les conclusions basées sur de très petits segments de données (comme un ou deux achats) sont pertinentes pour les annonceurs. Pendant la phase d'évaluation, Chrome encourage les testeurs à profiter de la possibilité de tester un large éventail de paramètres de confidentialité et de bruit afin de fournir des commentaires plus spécifiques sur ce problème. |
| Rapports sur l'attribution | Impact des délais de conversion sur l'énergie | Crainte que les délais de conversion n'affectent la configuration et la validation des campagnes, ou leur optimisation. | Des commentaires contradictoires ont été envoyés à Chrome concernant l'impact des délais d'affichage des rapports sur les conversions. Toutefois, étant donné que l'API Attribution Reporting introduit des retards aléatoires dans les rapports afin de protéger la confidentialité des utilisateurs, Chrome s'attend à ce que des cas d'utilisation ou des préoccupations spécifiques deviennent plus clairs au cours de la période de test et peuvent être résolus par l'assistance de débogage ou les conseils aux développeurs. |
| Rapports sur l'attribution | Période d'attribution plus longue | Demande d'extension de la période d'attribution de 30 jours | Chrome a publié une réponse visant à obtenir plus de commentaires sur la durée de la période d'attribution, en tenant compte à la fois de la minimisation et de l'utilité des données. |
| Rapports sur l'attribution | Impressions non visibles | Déterminez si les impressions non visibles sont comptabilisées dans les rapports sur les conversions après affichage. | Chrome a publié une réponse sur GitHub pour fournir plus de précisions sur les impressions visibles. |
Limiter le suivi dissimulé
| API / Technologie | Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| User-Agent Reduction | Performances | La latence d'obtention des indications via Critical-CH (au premier chargement de la page) pose problème. | Chrome étudie actuellement des moyens d'améliorer les performances. |
| Réduction user-agent / Hints client user-agent | Lutte contre la fraude et les abus | Avoir autant d’informations que possible est important lors du débogage de certains types d’attaques, y compris par déni de service. La perte de certaines informations de la chaîne UA peut poser problème. | Chrome est actuellement en train de discuter et de réfléchir aux moyens de préserver la confidentialité tout en fournissant suffisamment d'informations qui seront utiles pour le débogage. |
| User-Agent Reduction | Confusion autour de la configuration de la prolongation de l'expérience | Plusieurs participants à la phase d'évaluation ont recommandé d'améliorer la documentation en y incluant des exemples de procédure d'inscription à la phase d'évaluation. | La phase d'évaluation UA réduite se termine, mais Chrome prévoit d'améliorer les instructions de l'essai d'abandon (y compris en améliorant la visibilité de l'exemple de démonstration). |
| User-Agent Reduction | Préoccupations concernant les valeurs d'une indication spécifique | Questions pour savoir si Sec-CH-UA-Model est identique à <deviceModel> dans la chaîne user-agent | Sec-CH-UA-Model est identique à <deviceModel> dans la chaîne user-agent. Chrome tentera de clarifier cela dans une documentation ultérieure. |
| Réduction user-agent | Inquiétudes concernant l'inscription à l'essai d'abandon | Questions sur l'inscription d'un grand nombre de domaines à l'essai d'abandon | Chrome a envisagé des approches centralisées lors de la conception de la phase d'évaluation, mais la phase d'évaluation existante est considérée comme la meilleure option, car elle donne tout le contrôle aux développeurs (puisqu'ils peuvent choisir d'envoyer l'en-tête ou non). |
| Hints client user-agent | Préoccupations concernant la nature normative d'UA-CH | Le fait qu'UA-CH ne soit pas trop normatif par rapport à la flexibilité offerte par l'en-tête user-agent, tel que défini par le document rfc7231, pose problème. | Chrome considère la nature prescriptive des en-têtes UA-CH comme une amélioration importante par rapport à la flexibilité de la chaîne UA, à la fois du point de vue de l'interopérabilité entre les navigateurs à terme et de la protection de la confidentialité des utilisateurs (en empêchant l'ajout arbitraire d'identifiants à entropie élevée).
Cependant, le problème reste ouvert au cas où d'autres personnes partageraient ce problème et voudraient vous faire part de leurs commentaires. |
| Hints client user-agent | Inquiétudes concernant l'utilisation de l'API pour bloquer certains navigateurs | Inquiétudes concernant le fait qu'un site utilise l'API pour rechercher "Google Chrome" ou "Microsoft Edge" et bloque tous les autres navigateurs | Pour cela, le concept d'une liste de marques a été conçu : un navigateur peut envoyer "Google Chrome" en plus de ses propres marques. |
| Hints client user-agent | Requête d'une méthode pour énumérer tous les indices compatibles | Intérêt pour un moyen programmatique de connaître tous les indices compatibles pour un navigateur. | Chrome évalue la demande de fonctionnalité. |
| Réduction user-agent / Hints client user-agent | Lutte contre la fraude et les abus | Les indications client ne sont pas disponibles au premier chargement pour HTTP1 | L'une des API Client Hints Reliability (ACCEPT_CH) n'est disponible que sur HTTP2 et HTTP3. Pour les serveurs toujours servis via HTTP1, ils devront s'appuyer uniquement sur Critical-CH. |
| Réduction user-agent | Impact sur Chrome pour Android | Questions sur l'impact de ce changement sur Chrome sur Android en particulier. | UA Reduction et UA-CH seront disponibles dans Chrome sur Android, en plus de la version pour ordinateur. Pour Chrome sur Android, les modifications n'auront lieu que lors de la "Phase 6", actuellement planifiée pour Chrome 110. |
| Gnatcatcher (WIPB) | Méthodes et utilisations non conformes | Clarification sur ce que seraient les utilisations et méthodes non conformes. | Chrome mettra à jour l'explication avec plus de détails. |
| Gnatcatcher + Réduction user-agent | Réduire les signaux de lutte contre la fraude | Impact antifraude de la réduction simultanée de la réduction des accès IP et d'UA. | Attendre des dispositions du règlement antifraude (pour permettre l'utilisation de la propriété intellectuelle pour des cas d'utilisation de lutte contre la fraude) permettra de résoudre les problèmes de défensibilité liés aux proxys IP. |
| Suivi de la navigation | Inquiétudes concernant les futures défaillances | Les annonceurs s'inquiètent des dysfonctionnements potentiels. Les fournisseurs d'identité ont également exprimé leur intérêt pour les plans de Chrome. | Chrome n'effectue pas de modifications majeures imminentes et examine toujours les cas d'utilisation. |
| SameSite Cookies | Interopérabilité avec d'autres navigateurs | Questions sur les plans de correction de Chrome concernant crbug.com/1221316, car il s'agit d'un domaine dans lequel les implémentations de Chrome diffèrent de celles des autres navigateurs. | Chrome a détecté un bug dans les métriques et en a importé de nouvelles. Chrome recueille des données pour mieux comprendre l'impact de la correction du bug. |
| Storage Partitioning | Problème concernant le partitionnement des canaux des messages | Les canaux de messagerie (par exemple, SharedWorker et BroadcastChannel) doivent être partitionnés. | Chrome examine les commentaires, mais il estime que le partitionnement des canaux de messagerie et de l'espace de stockage est nécessaire pour éviter le suivi dissimulé. |
Renforcez les limites de confidentialité intersites
| API / Technologie | Thème des commentaires
(Classement par prévalence) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| First Party Sets | Exigence courante des règles de confidentialité | Il est impossible d'appliquer des règles de confidentialité communes à l'ensemble des produits et aux juridictions qui doivent faire partie du même ensemble. | Nos règles sont toujours en cours de définition et nous tiendrons compte de vos commentaires. |
| First Party Sets | L'IEE (Independent Enforcement Entity) est susceptible de recevoir un grand nombre de questions de vérification de la validité du lecteur d'empreinte digitale. | Résumé des difficultés prévisibles pour déterminer la validité du lecteur d'empreinte digitale: le texte ou les règles de confidentialité ne correspondent pas pour tous les membres de l'ensemble, clarté sur la façon de définir clairement les exigences liées à l'adhésion à l'ensemble, à la bande passante et au timing, et expertise spécialisée en matière de structure d'entreprise. | Nos règles sont toujours en cours de définition et nous tiendrons compte de vos commentaires. |
| First Party Sets | Processus de maintenance de la liste FPS des navigateurs | Inquiétudes concernant les obstacles à l'accès aux sites Web dans des pays non occidentaux, incohérences des versions de la liste FPS selon les navigateurs en raison des différences de fréquence des mises à jour et capacité des navigateurs plus petits ou plus récents à utiliser cette liste | Nous continuons de définir les règles requises, le processus d'acceptation et les droits d'utilisation de la liste, et nous tiendrons compte de ces commentaires.
Chrome s'appuie également sur les enseignements tirés d'autres listes statiques utilisées sur la plate-forme Web, telles que la liste des suffixes publics. |
| First Party Sets | Conception dynamique d'assertions par site | Une conception dynamique (par opposition à une liste statique) peut être plus sujette aux fausses déclarations de propriété commune, ainsi qu'à la latence ou aux échecs de chargement des pages. | Chrome opte actuellement pour une approche basée sur des listes statiques, et tiendra compte de ces commentaires si l'approche basée sur les assertions signées est réévaluée par la suite. |
| First Party Sets | Cas d'utilisation potentiels des ensembles internes (si une version fiable et équitable de la liste de FPS peut être créée) | Authentification unique, invites de données personnalisables et possibilités de création de rapports plus transparents pour les utilisateurs. | Chrome prendra en compte ces commentaires pour déterminer les prochaines étapes pour les ensembles internes |
| CHIPS | Compatibilité du navigateur | Volonté de comprendre comment d'autres navigateurs ont géré les attributs de cookies partitionnés | Chrome continue de travailler au sein des groupes de normes publiques tels que le W3C pour identifier les conceptions et les implémentations qui peuvent fonctionner sur tous les navigateurs. |
| CHIPS | Exigences concernant la conception | Problème lié au fait qu'il n'est peut-être pas possible d'inclure le préfixe du nom d'hôte | Chrome a supprimé l'obligation de dénomination pour la phase d'évaluation. Envisagez de la rendre permanente à la fin de la période de test. |
| CHIPS | Utilisation des CHIPS pour les cas d'utilisation publicitaires | Savoir s'il est possible d'utiliser les CHIPS pour les cas d'utilisation publicitaires | CHIPS permet à un tiers de créer des cookies côté client qui sont partitionnés en fonction du site de premier niveau (ou de son ensemble interne). Si le cas d'utilisation nécessite un état partitionné, et non un état intersite, les CHIPS peuvent être utilisés pour ce cas d'utilisation. |
| CHIPS | Intégration des CHIPS au lecteur d'empreinte digitale | Il est possible que les tests avec les CHIPS ne soient pas possibles parallèlement à d'autres propositions de la Privacy Sandbox, comme les ensembles internes | Chrome cherche activement à faciliter la création d'environnements de test permettant d'effectuer de tels tests. Chrome a également publié des instructions concernant les tests en local des systèmes FPS et CHIPS, qui peuvent être utilisées en attendant. |
| FedCM | Expressivité | Inquiétudes : étant donné que le navigateur effectue une partie du flux d'identité fédérée, il est difficile de saisir toutes les nuances que les IdP souhaitent présenter à leurs utilisateurs | Chrome est conscient de ce compromis et va continuer à travailler avec l'écosystème pour couvrir autant de sujets que possible et le rendre aussi expressif que possible. Parmi les idées envisagées par Chrome, citons la personnalisation du branding (par exemple, les logos ou les couleurs) et la personnalisation des chaînes (par exemple, "accéder à cet article" et non "connexion avec"). |
| FedCM | Implication du navigateur | Le navigateur est plus impliqué qu'auparavant dans le flux de fédération d'identité. Il est donc plus explicitement informé des sites Web auxquels l'utilisateur est connecté (et avec quel IdP). | Chrome reconnaît que le navigateur joue désormais un rôle plus actif, mais ce niveau supplémentaire d'implication est nécessaire pour que le navigateur identifie et empêche le suivi intersites, tout en continuant à accepter la fédération. |
| FedCM | Applicabilité et interopérabilité | Inquiétudes concernant l'absence d'adoption ou d'implémentation de FedCM par d'autres navigateurs | L'équipe Chrome a également collaboré avec d'autres fournisseurs de navigateurs au sein du FedID Community Group, afin de trouver des solutions communes à ces problèmes. |
| FedCM | Divers défis liés aux API | Inquiétudes concernant le fait que FedCM n'en est encore qu'à ses débuts ou n'est pas encore mature, et qu'il faudra beaucoup de temps pour proposer toutes les fonctionnalités dont l'écosystème a besoin | Chrome l'explorera plus en détail lors des tests de l'écosystème. |
| FedCM | Règles d'entreprise et commandes utilisateur | Déterminez si un contrôle (par exemple, des règles d'entreprise et/ou des paramètres utilisateur) qui permettra aux entreprises de conserver leur déploiement de l'identité fédérée sans y apporter de modifications. De nombreux déploiements sur site de l'identité fédérée sont exceptionnellement difficiles à redéployer ou à modifier. Il existe donc une grande résistance face à la nouvelle API de navigateur qui nécessite le redéploiement par les IdP. | Chrome explore actuellement des options qui, selon lui, permettront aux administrateurs d'entreprise et aux utilisateurs de répondre à ces préoccupations. Chrome souhaite que les entreprises partagent leurs commentaires sur les cas d'utilisation spécifiques qu'elles aimeraient voir apparaître. |
Lutter contre le spam et la fraude
| API / Technologie | Thème des commentaires
(classées par prévalence par API) |
Récapitulatif des questions et préoccupations | Réponse Chrome |
| API Trust Token | Limites d'utilisation | On craint que deux images par page soient trop restrictives, en particulier dans les cas où l'une peut être intégrée plusieurs fois sur la même page ou avoir un deuxième domaine d'émetteur au sein de l'organisation. L'une d'entre elles atteindrait probablement la limite elle-même si elle ne tenait pas compte des autres acteurs du marché. | Chrome est disposé à étendre légèrement la limite d'utilisation par page si cela augmente l'adoption, mais doit la maintenir relativement faible pour introduire une entropie excessive. De plus, la mise en cache d'un enregistrement d'utilisation peut réduire le besoin qu'un émetteur ait besoin d'utiliser plusieurs jetons pour un même utilisateur sur une courte période. |
| API Trust Token | Latence | Elles ont généralement besoin de répondre aux demandes d'enchères dans un délai de 10 ms maximum. Par conséquent, l'utilisation d'un jeton lors du chargement de la première page rend impossible de l'inclure dans la décision concernant le trafic incorrect avant enchère. | Chrome essaie de comprendre l'impact de la latence sur les cas d'utilisation avant enchère via des tests. |
| API Trust Token | Adoption d'OpenRTB | Pour les cas d'utilisation avant enchère, il est essentiel de transmettre les informations du jeton échangé aux SSP et aux DSP afin de les utiliser pour la prise de décision concernant les annonces. | Chrome est ouvert à la collaboration avec l'IAB pour aider à s'assurer que tous les signaux utiles de lutte contre la fraude et les utilisations abusives peuvent être propagés via openRTB, bien que ce soit le standard pour l'ajout de nouveaux champs par défaut. |
| API Trust Token | Confidentialité | Questions sur la viabilité à long terme de toute forme de propagation de données intersites, bien que faible d'entropie (~2,5 bits) | Compte tenu de la robustesse des protections qui empêchent l'identification des utilisateurs uniques, Chrome considère qu'il existe de bonnes raisons d'accepter les éventualités comme l'adoption de l'écosystème. Chrome travaille en étroite collaboration avec les principaux partenaires pour garantir la viabilité à long terme. |
| Signaux d'attestation de plate-forme | Évaluer l'intérêt pour une nouvelle idée/proposition | Solide compatibilité avec divers signaux réalisables (et impossibles) tels que la transmission de signaux d'intégrité de l'appareil que la plate-forme peut fournir | Chrome prévoit de transmettre cette idée au groupe de la communauté antifraude du W3C afin de recueillir des commentaires. |
| Serveurs de confiance pour la lutte contre la fraude | Évaluer l'intérêt pour une nouvelle idée/proposition | Concept intéressant, mais nécessitera probablement davantage d'informations sur les cas d'utilisation applicables | Selon les niveaux d'intérêt, Chrome peut approfondir la conceptualisation de ce concept et l'utiliser comme un message explicatif pour les futurs commentaires de l'écosystème. |