Les ensembles propriétaires sont conçus pour améliorer l'expérience de navigation sur le Web des utilisateurs après l'abandon des cookies tiers dans Chrome. La proposition a évolué de manière significative sur les forums du Web ouvert pendant l'incubation du FPS, d'abord dans le groupe de la communauté sur la confidentialité du W3C, puis dans le groupe de la communauté de l'incubateur Web.
Dans cet article de blog, nous allons résumer le processus d'évolution, mettre en avant les principaux changements et expliquer pourquoi nous pensons que ces changements améliorent la confidentialité sur le Web tout en continuant à soutenir l'écosystème.
Contexte
Les sites s'appuient souvent sur l'accès à leurs cookies dans un contexte tiers pour offrir aux utilisateurs une expérience fluide et personnalisée. En plus des API Ads protégeant la confidentialité (Topics, API Protected Audience et Attribution), l'équipe Chrome a cherché à comprendre l'étendue des scénarios dans lesquels les cookies tiers étaient utilisés, au-delà des objectifs de personnalisation ou de mesure des annonces, afin de fournir une expérience de navigation améliorée aux utilisateurs.
Nous avons constaté que les organisations peuvent s'appuyer sur des cookies tiers, car leur architecture Web est conçue pour utiliser plusieurs domaines. Par exemple, une organisation peut avoir un domaine pour son blog de randonnée et un autre pour son magasin de camping, et souhaiter faciliter les parcours utilisateur sur ces sites. Une organisation peut également gérer plusieurs domaines de code pays avec une infrastructure partagée pour son service Web. Dans ce cas, nous avons décidé de créer une solution adaptée aux besoins de ces organisations, tout en préservant les attentes des utilisateurs en matière de confidentialité sur le Web.
Nos débuts
Étant donné que le navigateur utilise actuellement la limite au niveau du site pour interpréter les termes "first-party" et "third-party", afin de tenir compte de la gamme de domaines qu'une organisation peut gérer, il a semblé approprié de remplacer cette limite technique par une définition plus nuancée.
En 2021, Chrome a initialement proposé l'attribut de cookie SameParty pour les ensembles propriétaires afin que les sites puissent définir des cookies provenant de sites appartenant à la "même partie". Nous avons utilisé une règle d'user-agent pour définir ce qui constitue une "même partie". Cette définition de la politique a tenté de s'appuyer sur les frameworks existants de "partie" (par exemple, de la spécification DNT du W3C) et a intégré les recommandations issues des discours pertinents sur la confidentialité (comme le rapport de la Federal Trade Commission de 2012 intitulé "Protecting Consumer Privacy in an Era of Rapid Change" (Protéger la confidentialité des consommateurs à l'ère du changement rapide)).
À l'époque, nous pensions que cette approche offrait suffisamment de flexibilité pour différents types d'organisations, dans différents secteurs, tout en respectant notre objectif fondamental de limiter le suivi généralisé via les cookies tiers.
Commentaires sur la proposition initiale
Après de nombreuses discussions avec les personnes concernées de l'écosystème Web, nous avons constaté que cette conception initiale présentait des limites.
Défis liés à la confidentialité avec l'accès aux cookies passifs via l'attribut SameParty
D'autres fournisseurs de navigateurs ont préféré une approche active de l'accès aux cookies tiers, qui nécessite une invocation d'API explicite, plutôt que d'établir une limite au-delà de laquelle l'accès aux cookies passifs pourrait être maintenu. Les requêtes actives d'accès aux cookies offrent au navigateur une visibilité et un contrôle permettant de réduire le risque de suivi masqué via des cookies tiers. De plus, cette visibilité permettrait aux navigateurs de permettre aux utilisateurs d'autoriser ou de bloquer l'accès à ces cookies.
Dans un souci d'interopérabilité Web entre les navigateurs et d'amélioration des avantages en termes de confidentialité, nous avons décidé d'aller dans cette direction.
Défis d'implémentation de la règle proposée
Le règlement d'origine proposait trois exigences pour que les domaines soient regroupés dans un même ensemble: "propriété commune", "règles de confidentialité communes" et "identité de groupe commune".
Dans l'ensemble de l'écosystème, les commentaires que nous avons reçus sur le règlement suivent quatre thèmes principaux.
La propriété commune est trop restrictive
Concernant l'exigence de "propriété commune", nous avons reçu des commentaires indiquant qu'une définition de FPS axée uniquement sur la propriété d'entreprise donnerait aux grandes entreprises une plus grande capacité à regrouper des données dans un large éventail de domaines et de services destinés aux utilisateurs, par rapport aux petites entreprises. Notre objectif étant de créer la Privacy Sandbox pour l'ensemble de l'écosystème, nous avons pris ces commentaires au sérieux et avons privilégié une solution plus inclusive.
Une seule règle limite l'extensibilité aux cas d'utilisation
Bien que l'idée d'une stratégie globale pour régir une limite ait été conçue pour offrir de la flexibilité aux différents types de domaines qui doivent figurer dans le FPS d'une organisation, nous avons constaté que certains cas d'utilisation critiques ne pouvaient pas répondre à cette conception de stratégie. Par exemple, les domaines de service (comme ceux qui hébergent du contenu généré par les utilisateurs) peuvent nécessiter l'accès à leurs cookies dans un contexte tiers pour authentifier ou identifier les utilisateurs. Ces domaines ne disposent que rarement d'une page d'accueil accessible aux utilisateurs. Par conséquent, les exigences d'une "identité de groupe commune" ou d'"une politique de confidentialité commune" avec d'autres domaines du même FPS ne pouvaient pas être satisfaites.
La perception et la compréhension de l'identité de groupe par les utilisateurs peuvent varier
Nous avons initialement proposé des garde-fous pour définir une "identité de groupe commune" dans le but de limiter le champ d'application des domaines d'un même ensemble à ceux qui peuvent facilement être associés à une identité de groupe commune. Toutefois, nous n'avons pas pu définir de moyen technique pour mesurer et évaluer si l'identité de groupe commune pouvait être "facilement découverte par les utilisateurs". Cela a laissé la place à des abus et à des questions sur l'application.
Nous avons également reçu des commentaires indiquant que la compréhension des limites de la "propriété commune" peut varier d'un utilisateur à l'autre, ce qui rend difficile la création de consignes applicables à tous les sites.
Une règle subjective est difficile à appliquer à grande échelle
Nous avons reçu de nombreuses demandes de consignes plus détaillées, compte tenu de la nature subjective de certaines exigences (telles que "identité de groupe commune") et de la nécessité de couvrir des exceptions ou des cas particuliers pour d'autres (concernant les "Règles de confidentialité communes").
Pour s'assurer que le règlement était appliqué de manière équitable et cohérente, Chrome aurait dû fournir aux auteurs de sites des consignes beaucoup plus spécifiques. Nous avons déterminé que tenter de créer des consignes plus strictes pourrait nuire à l'écosystème.
Bien que nous ayons initialement proposé qu'une entité d'application indépendante prenne en charge le rôle d'enquête et d'application du respect des règles, dans l'écosystème actuel, il était difficile de trouver une entité d'application indépendante disposant de l'expertise appropriée pour s'acquitter de ces responsabilités de manière impartiale. Nous avons plutôt cherché à opter pour une stratégie qui pourrait être appliquée techniquement pour garantir que l'implémentation pourrait être appliquée de manière cohérente et objective.
L'évolution
Nous avons repensé les FPS en tenant compte des commentaires. Nous sommes revenus aux problèmes spécifiques que nous essayions de résoudre et avons décidé de structurer plus directement la proposition autour de cas d'utilisation spécifiques que nous essayions de résoudre.
Répondre aux principaux cas d'utilisation
Chrome a développé trois "sous-ensembles" différents conçus pour répondre aux principaux cas d'utilisation sur le Web. L'approche par sous-ensembles améliore l'ancienne approche en étant plus privée, plus spécifique et plus facile à appliquer de manière cohérente.
- "ccTLD" (domaines de premier niveau avec code pays) : les organisations peuvent gérer des sites avec différents ccTLD pour des expériences localisées, et ces sites peuvent toujours nécessiter un accès à des services et une infrastructure partagés.
- Domaines de "service" : les sites peuvent utiliser des domaines distincts à des fins de sécurité ou de performances, et ces sites peuvent nécessiter l'accès à l'identité d'un utilisateur pour effectuer leurs fonctions.
- Domaines "associés" : les organisations peuvent gérer plusieurs sites pour différentes marques ou produits associés. Ils peuvent souhaiter accéder aux cookies intersites pour des cas d'utilisation tels que l'analyse des parcours utilisateur sur des sites associés afin de mieux comprendre comment la base d'utilisateurs d'une organisation interagit avec ses sites, ou pour mémoriser l'état de connexion d'un utilisateur sur un site associé qui s'appuie sur la même infrastructure de connexion.
Pour chacun de ces cas d'utilisation, des exigences de règles distinctes, des vérifications de validation techniques correspondantes et un comportement de gestion des navigateurs spécifique s'appliquent (pour en savoir plus, consultez les Consignes d'envoi). Ces modifications répondent aux limites de la proposition initiale en abandonnant une conception "tout-en-un" et en privilégiant un framework compartimenté, axé sur les cas d'utilisation.
Possibilité d'interopérabilité via des requêtes actives pour l'accès aux cookies tiers
Chrome souhaite promouvoir l'interopérabilité avec d'autres navigateurs afin de préserver la santé de la plate-forme Web. Étant donné que d'autres navigateurs tels que Safari, Firefox et Edge utilisent actuellement l'API Storage Access (SAA) pour faciliter les requêtes de cookies actives, nous avons choisi d'exploiter la SAA dans Chrome non seulement pour répondre aux principaux commentaires que nous avons reçus, mais aussi pour favoriser l'interopérabilité Web.
Pour offrir plus de flexibilité aux développeurs et répondre aux limites connues de la SAA, nous avons également proposé l'API requestStorageAccessForOrigin.
Possibilité d'utiliser l'API Storage Access et FPS ensemble
Lors de l'implémentation de l'API Storage Access (SAA), les navigateurs peuvent choisir de demander directement aux utilisateurs l'autorisation, tandis que d'autres peuvent autoriser un nombre limité de requêtes sans invite d'autorisation.
Chrome pense que les FPS peuvent fournir une couche transparente sur le SAA, en limitant les frictions pour les utilisateurs et en évitant la fatigue des invites pour les principaux cas d'utilisation limités. FPS permet également aux navigateurs de fournir aux utilisateurs des informations contextuelles supplémentaires sur l'appartenance à un ensemble, s'ils choisissent de demander leur autorisation.
Avec FPS, les développeurs peuvent identifier leurs propres sites concernés qui servent des cas d'utilisation clés. Cela permet aux développeurs de l'agence d'anticiper le fonctionnement de leurs sites pour les utilisateurs et de prendre des mesures pour limiter l'impact sur l'expérience utilisateur, en exploitant les FPS ou une alternative aux cookies tiers. De plus, les FPS offrent aux développeurs une prévisibilité de la plate-forme, contrairement aux heuristiques qui peuvent changer au fil du temps ou entraîner des comportements différents pour différents utilisateurs.
Enfin, les développeurs qui implémentent le SAA pour travailler avec les FPS dans Chrome pourront également exploiter le SAA pour les performances de leurs sites sur d'autres navigateurs, même ceux qui n'envoient pas de FPS.
Poursuite de la discussion
Nous pensons que notre dernière proposition trouve le juste équilibre dans un espace de compromis difficile qui tient compte des besoins des utilisateurs et des développeurs. Nous sommes reconnaissants des commentaires des personnes concernées par l'écosystème Web qui nous ont aidés à faire évoluer la proposition de FPS.
Nous sommes conscients que les personnes concernées par l'écosystème Web se familiarisent encore avec la proposition mise à jour. N'hésitez pas à nous contacter pour que nous puissions continuer à améliorer la conception de manière plus utile pour les développeurs et pour continuer à améliorer la confidentialité sur le Web. Google continuera également de collaborer avec la CMA (Competition and Markets Authority) du Royaume-Uni pour s'assurer de la conformité avec les engagements.
Pour interagir avec vos utilisateurs, consultez les ressources suivantes:
- Incubation dans WICG
- Instructions de test des FPS
- Ensembles internes: guide d'intégration
- Consignes pour envoyer des informations sur les FPS
Utiliser l'écosystème
Nous sommes ravis de voir des entreprises comme Salesforce et CafeMedia s'engager dans l'élaboration de commentaires clés et le développement d'ensembles first party. Ils ont joué un rôle crucial dans le développement de cette technologie. Plusieurs autres personnes ont également partagé leur avis sur les ensembles propriétaires et les efforts de Chrome pour travailler avec l'écosystème Web:
"Chrome développe des ensembles internes pour s'adapter à de nombreux cas d'utilisation, comme la préservation des parcours utilisateur. Cela nous montre que l'équipe Google s'efforce de comprendre les différents types de besoins des propriétaires de sites sur le Web." – Mercado Libre
"Chez VWO, nous apprécions les efforts de Google pour élever les normes de confidentialité, tout en veillant à ce que les cas d'utilisation réels soient pris en charge. Nous sommes ravis que l'équipe collabore avec l'écosystème des développeurs et améliore en permanence l'implémentation de la proposition de sets first party en fonction des commentaires des personnes concernées par le Web. Nous sommes ravis de participer au processus de test de la proposition et nous avons hâte de l'intégrer au navigateur." - Nitish Mittal, directeur de l'ingénierie, VWO