[OBSOLÈTE] Ensembles internes et attribut SameParty

Avertissement:La proposition d'ensembles internes a été mise à jour et cet article n'est plus à jour. Pour obtenir les informations les plus récentes, consultez l'explication et les instructions de test.

De nombreuses organisations possèdent des sites associés avec des noms de domaine différents, tels que brandx.site et fly-brandx.site, ou des domaines pour différents pays, tels que example.com, example.rs, example.co.uk, etc.

Les navigateurs envisagent de rendre les cookies tiers obsolètes pour améliorer la confidentialité sur le Web. Toutefois, des sites comme ceux-ci s'appuient souvent sur des cookies pour des fonctionnalités qui nécessitent de conserver l'état de plusieurs domaines et d'y accéder (comme l'authentification unique et la gestion du consentement).

Les ensembles internes peuvent permettre aux noms de domaine associés qui sont détenus et gérés par la même entité d'être traités comme des noms propriétaires dans les cas où les noms propriétaires et tiers sont traités différemment. Les noms de domaine d'un ensemble propriétaire sont considérés comme identiques et peuvent indiquer les cookies destinés à être définis ou envoyés dans le contexte de la même partie. L'objectif est de trouver un équilibre entre le fait d'empêcher le suivi intersites par des tiers tout en conservant un chemin qui n'enfreint pas des cas d'utilisation valides.

La proposition d'ensembles internes est actuellement en phase de test. Lisez la suite pour découvrir comment elle fonctionne et comment la tester.

Quelle est la différence entre les cookies propriétaires et les cookies tiers ?

Les cookies ne sont pas fondamentalement des êtres propriétaires ou tiers. Cela dépend du contexte dans lequel le cookie est inclus. Pour une requête dans l'en-tête cookie ou via document.cookie en JavaScript.

Par exemple, si video.site comporte un cookie theme=dark, lorsque vous parcourez video.site et qu'une requête est envoyée à video.site, il s'agit d'un contexte sur le même site et le cookie inclus est propriétaire.

Toutefois, si vous utilisez my-blog.site, qui intègre un lecteur iFrame pour video.site, lorsque la requête est envoyée par my-blog.site à video.site, il s'agit d'un contexte intersite et le cookie theme est tiers.

L'inclusion d'un cookie est déterminée par l'attribut SameSite du cookie:

• Le contexte sur le même site avec SameSite=Lax, Strict ou None rend le cookie propriétaire.
• Le contexte intersites avec SameSite=None rend le cookie tiers.

Cependant, ce n'est pas toujours aussi clair. Imaginez que brandx.site soit un site de réservation de voyages, qui utilise également fly-brandx.site et drive-brandx.site pour séparer les vols et la location de voiture. Au cours de la réservation d'un parcours, les visiteurs passent d'un site à l'autre pour sélectionner leurs différentes options. Ils s'attendent à ce que les sélections de leur "panier" soient conservées d'un site à l'autre. brandx.site gère la session de l'utilisateur avec un cookie SameSite=None pour l'autoriser dans un contexte intersites. Toutefois, l'inconvénient est que le cookie ne dispose plus de protection contre la falsification des requêtes intersites (CSRF). Si evil.site inclut une requête pour brandx.site, ce cookie est inclus.

Le cookie est intersite, mais tous ces sites sont détenus et gérés par la même organisation. Les visiteurs comprennent également qu'il s'agit de la même organisation et souhaitent avoir la même session, en d'autres termes, une identité partagée entre eux.

Remarque:Les ensembles internes permettent de définir les situations dans lesquelles un contexte intersite reste propriétaire. Le cookie peut être inclus dans l'ensemble propriétaire et exclu dans des contextes tiers.

Règlement sur les ensembles internes

Les ensembles internes proposent une méthode pour définir explicitement cette relation entre plusieurs sites détenus et gérés par la même partie. Cela permet à brandx.site de définir sa relation propriétaire avec fly-brandx.site, drive-brandx.site, etc.

Le modèle de confidentialité qui alimente les différentes propositions de la Privacy Sandbox repose sur le concept de partitionnement des identités pour empêcher le suivi intersites. Il définit une limite entre les sites limitant l'accès à toute information pouvant être utilisée pour identifier les utilisateurs.

Bien que l'option par défaut consiste à partitionner par site, ce qui résout de nombreux cas d'utilisation propriétaires, l'exemple brandx.site montre qu'un propriétaire peut comporter plus d'un site.

Une partie importante de la proposition d'ensembles internes consiste à s'assurer que les règles appliquées aux navigateurs empêchent tout usage abusif. Par exemple, les ensembles internes ne doivent pas permettre l'échange d'informations sur les utilisateurs entre des sites non liés, ni le regroupement de sites n'appartenant pas à la même entité. L'objectif est de s'assurer qu'un ensemble interne correspond à quelque chose qu'une personne interprète en tant que propriétaire et n'est pas utilisé comme un moyen de partager une identité entre différentes parties.

Pour enregistrer un ensemble propriétaire, un site peut, par exemple, envoyer le groupe de domaines qu'il propose à un outil de suivi public (tel qu'un dépôt GitHub dédié), ainsi que les informations nécessaires pour respecter les règles du navigateur.

Remarque:Le processus d'acceptation d'un nouvel ensemble propriétaire est en cours de discussion avec le W3C. L'une des options envisagées consiste à faire en sorte que la validation soit gérée par une entité indépendante et non par une société de navigateurs.

Une fois que l'assertion d'ensemble propriétaire a été vérifiée conformément à la règle, les navigateurs peuvent ensuite extraire des listes d'ensembles via un processus de mise à jour.

La phase d'évaluation est associée à une règle définie qui n'est pas définitive, mais les principes sont probablement les mêmes:

• Les domaines d'un ensemble propriétaire doivent être détenus et exploités par la même organisation.
• Les domaines doivent être identifiables par les utilisateurs en tant que groupe.
• Ces domaines doivent partager des règles de confidentialité communes.

Remarque:En savoir plus sur la règle proposée pour les ensembles internes

Définir un ensemble propriétaire

Une fois que vous avez identifié les membres et le propriétaire de l'ensemble propriétaire de votre organisation, il est crucial d'envoyer l'ensemble proposé pour approbation. Le processus exact est toujours en cours de discussion.

Attention:Un ensemble propriétaire n'est pas destiné à être une liste exhaustive de sites qui appartiennent à la même organisation. Vous n'avez besoin de créer un ensemble entre les sites que si vous avez explicitement besoin qu'un cookie intersites soit autorisé sur chacun d'entre eux. Veillez à consulter Quels sont les cas d'utilisation adaptés à la phase d'évaluation des ensembles internes ci-dessous.

Pour déclarer un ensemble propriétaire, les ressources JSON statiques qui répertorient les membres et les propriétaires doivent être hébergées sur /.well-known/first-party-set, au niveau supérieur de chaque domaine inclus.

Dans l'exemple de l'ensemble propriétaire brandx, le domaine du propriétaire héberge les éléments suivants sur https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Chaque membre de l'ensemble héberge également une ressource JSON statique pointant vers le propriétaire de l'ensemble. Chez https://fly-brandx.site/.well-known/first-party-set, nous avons:

{ "owner": "brandx.site" }

Et à https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Quelques contraintes s'appliquent aux ensembles propriétaires:

• Un ensemble ne peut avoir qu'un seul propriétaire.
• Un membre ne peut appartenir qu'à un seul ensemble, sans chevauchement ni mélange.
• La liste des membres est destinée à rester relativement lisible par l'humain et à ne pas être trop volumineuse.

Remarque:Vous hébergez peut-être déjà un fichier similaire si vous utilisez Digital Asset Links pour associer des sites qui partagent le même backend de gestion de compte. Cela permet spécifiquement de permettre au gestionnaire de mots de passe Chrome de suggérer les mêmes identifiants sur les sites affiliés.

Comment les ensembles internes affectent-ils les cookies ?

L'ingrédient correspondant pour les cookies est l'attribut SameParty proposé. Spécifier SameParty indique au navigateur d'inclure le cookie lorsque son contexte fait partie du même ensemble propriétaire que le contexte de premier niveau.

Cela signifie que si brandx.site définit ce cookie:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Ensuite, lorsque le visiteur se trouve sur fly-brandx.site et qu'une requête est envoyée à brandx.site, le cookie session est inclus dans cette requête. Si un autre site qui ne fait pas partie de l'ensemble propriétaire, par exemple hotel.xyz, envoie une requête à brandx.site, le cookie ne sera pas inclus.

En attendant que SameParty soit largement accepté, utilisez l'attribut SameSite avec lui pour définir le comportement de remplacement des cookies. Considérez l'attribut SameParty comme un paramètre compris entre SameSite=Lax et SameSite=None.

• SameSite=Lax; SameParty étend la fonctionnalité Lax pour inclure les contextes de même partie lorsqu'ils sont compatibles, mais utilise les restrictions Lax dans le cas contraire.
• SameSite=None; SameParty limite la fonctionnalité None aux seuls contextes de même partie le cas échéant, mais utilise les autorisations None plus larges dans le cas contraire.

D'autres exigences sont à respecter:

• Les cookies SameParty doivent inclure Secure.
• Les cookies SameParty ne doivent pas inclure SameSite=Strict.

Secure est obligatoire, car il s'agit toujours d'un trafic intersite. Vous devez atténuer ces risques en assurant des connexions (HTTPS) sécurisées. De même, étant donné qu'il s'agit d'une relation intersite, SameSite=Strict n'est pas valide, car il permet toujours une protection CSRF stricte basée sur le site dans un ensemble.

Important:L'attribut SameParty n'affecte que les contextes dans lesquels un cookie peut être envoyé. Il ne crée pas de fichier JAR partagé. Un cookie provenant de brandx.site n'est disponible que pour les requêtes ou les documents concernant brandx.site. Il n'est jamais directement disponible pour fly-brandx.site. Cela peut prêter à confusion, car cela peut être désigné comme étant une identité partagée, mais cela signifie que la limite assouplie entre les sites leur permet de définir ou d'envoyer des cookies dans des contextes communs et intersites, et non que les cookies sont partagés directement.

Dans quels cas d'utilisation les ensembles internes sont-ils adaptés ?

Les ensembles internes conviennent parfaitement aux cas où une organisation a besoin d'une forme d'identité partagée entre différents sites de premier niveau. Dans ce cas, l'identité partagée désigne tout ce qui se passe, d'une solution d'authentification unique complète à un simple besoin d'une préférence partagée entre les sites.

Remarque:Vous pouvez identifier des candidats potentiels pour ces cas d'utilisation, car il s'agit de cas pour lesquels vous avez déjà marqué un cookie comme SameSite=None, même si ce n'est que pour les contextes intersites où vous êtes propriétaire de tous les sites concernés.

Votre organisation peut avoir différents domaines de premier niveau pour:

• Domaines de l'application: office.com,live.com, microsoft.com
• Domaines de marque: amazon.com, audible.com / disney.com, pixar.com
• Domaines spécifiques au pays pour lesquels la localisation doit être activée: google.co.in, google.co.uk
• Domaines de service avec lesquels les utilisateurs n'interagissent jamais directement, mais fournissent des services sur les sites de la même organisation: gstatic.com, githubassets.com, fbcdn.net
• Domaines de bac à sable avec lesquels les utilisateurs n'interagissent jamais directement, mais existent pour des raisons de sécurité: googleusercontent.com et githubusercontent.com

Comment participez-vous ?

Si un ensemble de sites correspond aux critères ci-dessus, plusieurs options s'offrent à vous. L'investissement le plus léger consiste à lire et à participer à la discussion sur les deux propositions:

• Discussion de groupe communautaire sur la confidentialité des ensembles internes
• Discussion sur les attributs de cookie SameParty

Pendant la phase de test, vous pouvez essayer la fonctionnalité en utilisant l'option de ligne de commande --use-first-party-set et en fournissant une liste de sites séparés par une virgule.

Vous pouvez essayer cette fonctionnalité sur le site de démonstration à l'adresse https://fps-member1.glitch.me/ après avoir démarré Chrome avec l'indicateur suivant:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Cela est utile si vous souhaitez effectuer des tests dans votre environnement de développement ou essayer d'ajouter l'attribut SameParty dans un environnement en ligne pour voir comment un ensemble propriétaire affecte les cookies.

Si vous disposez de suffisamment de bande passante pour les tests et les commentaires, vous pouvez également vous inscrire à la phase d'évaluation pour les ensembles internes et SameParty, disponible dans Chrome de la version 89 à la version 93.

Terme clé:les essais rigoureux permettent à Chrome de permettre aux développeurs externes de tester les premières propositions dans des scénarios réels, afin de fournir les commentaires nécessaires pour évoluer et itérer vers quelque chose qui répond aux besoins de la plate-forme Web. Pour en savoir plus, consultez Premiers pas avec les phases d'évaluation de Chrome.

Mettre à jour les cookies pour la phase d'évaluation

Si vous rejoignez la phase d'évaluation et que vous testez l'attribut SameParty sur vos cookies, voici deux formats à prendre en compte.

Option 1

Tout d'abord, si vous avez des cookies que vous avez libellés comme SameSite=None, mais que vous souhaitez limiter à des contextes propriétaires, vous pouvez leur ajouter l'attribut SameParty. Dans les navigateurs où la phase d'évaluation est active, le cookie ne sera pas envoyé dans des contextes intersites en dehors de l'ensemble.

Toutefois, pour la plupart des navigateurs en dehors de la phase d'évaluation, le cookie continuera d'être envoyé depuis d'autres sites comme d'habitude. Considérez cela comme une approche d'amélioration progressive.

Avant:set-cookie: cname=cval; SameSite=None; Secure

Après:set-cookie: cname=cval; SameSite=None; Secure; SameParty

Option 2

La deuxième option est plus complexe, mais vous permet de séparer complètement la phase d'évaluation des fonctionnalités existantes et de tester spécifiquement la combinaison SameSite=Lax; SameParty.

Avant:set-cookie: cname=cval; SameSite=None; Secure

Après :

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Lorsque vous recherchez le cookie dans des requêtes entrantes, attendez-vous à voir le cookie cname-fps dans une requête intersite uniquement si les sites impliqués sont inclus dans l'ensemble et si le navigateur est en phase d'évaluation. Considérez cette approche comme le lancement simultané d'une fonctionnalité mise à jour avant de désactiver la version précédente.

Pourquoi n'avez-vous pas besoin d'un ensemble propriétaire ?

Pour la plupart des sites, les limites de leur site permettent d'établir la limite de partition ou de confidentialité. C'est la voie proposée avec CHIPS (Cookies Has Independent Partitioned State), qui donnerait aux sites une route d'activation via l'attribut Partitioned pour conserver ces intégrations, ressources, API et services intersites essentiels, tout en évitant les fuites d'informations d'identification entre les sites.

D'autres éléments sont à prendre en compte afin que votre site puisse fonctionner sans nécessiter d'ensemble:

• Vous hébergez des origines différentes, et non des sites différents. Dans l'exemple ci-dessus, si brandx.site comporte fly.brandx.site et drive.brandx.site, il s'agit de sous-domaines différents au sein du même site. Les cookies peuvent utiliser SameSite=Lax, et aucun paramètre n'est nécessaire.
• Vous proposez des intégrations tierces à d'autres sites. Dans l'introduction, l'exemple d'une vidéo de video.site intégrée à my-blog.site est une division tierce claire. Les sites sont gérés par différentes organisations, et les utilisateurs les voient comme des entités distinctes. Ces deux sites ne doivent pas faire partie d'un même ensemble.
• Vous fournissez des services de connexion aux réseaux sociaux tiers. Les fournisseurs d'identité utilisant des outils tels que OAuth ou OpenId Connect s'appuient souvent sur des cookies tiers pour faciliter la connexion des utilisateurs. C'est un cas d'utilisation valide, mais n'est pas adapté aux ensembles internes, car il existe une nette différence entre les organisations. Les premières propositions telles que WebID étudient les moyens d'activer ces cas d'utilisation.