[OBSOLÈTE] Ensembles internes et attribut SameParty

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

Les navigateurs tendent à rendre obsolètes les cookies tiers pour améliorer la confidentialité sur le Web, mais des sites comme celui-ci s'appuient souvent sur les cookies pour des fonctionnalités qui nécessitent de gérer et d'accéder à l'état dans les domaines (comme la connexion unique et la gestion du consentement).

Les ensembles propriétaires peuvent permettre de traiter les noms de domaine associés appartenant à la même entité et gérés par elle comme des propriétaires dans les situations où les propriétaires et les tiers sont traités différemment. Les noms de domaine d'un ensemble first party sont considérés comme de même partie et peuvent indiquer les cookies à définir ou à envoyer dans le contexte de même partie. L'objectif est de trouver un équilibre entre l'interdiction du suivi intersites par des tiers et le maintien d'un chemin qui ne brise pas les cas d'utilisation valides.

La proposition d'ensembles propriétaires est actuellement en phase de test. Lisez la suite pour découvrir son fonctionnement et comment l'essayer.

Quelle est la différence entre les cookies first party et les cookies tiers ?

Les cookies ne sont pas intrinsèquement propriétaires ou tiers. Cela dépend du contexte actuel dans lequel le cookie est inclus. Cela se produit soit dans une requête dans l'en-tête cookie, soit via document.cookie en JavaScript.

Par exemple, si video.site possède un cookie theme=dark, lorsque vous consultez video.site et qu'une requête est envoyée à video.site, il s'agit d'un contexte SameSite 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 de my-blog.site à video.site, il s'agit d'un contexte intersite et le cookie theme est tiers.

Schéma illustrant un cookie de video.site dans deux contextes. Le cookie est de type SameSite lorsque le contexte racine est également video.site. Le cookie est intersite lorsque le contexte de premier niveau est my-blog.site avec video.site dans une iFrame.

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

  • Le contexte Same-site avec SameSite=Lax, Strict ou None rend le cookie propriétaire.
  • Le contexte intersites avec SameSite=None rend le cookie tiers.

Toutefois, ce n'est pas toujours aussi simple. Imaginons 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 voitures. Au cours de la réservation d'un voyage, les visiteurs passent d'un site à l'autre pour sélectionner leurs différentes options. Ils s'attendent à ce que leur "panier" de sélections persiste sur ces sites. brandx.site gère la session de l'utilisateur avec un cookie SameSite=None pour l'autoriser dans des contextes intersites. L'inconvénient est que le cookie ne dispose plus de protection contre la falsification de requêtes intersites (CSRF). Si evil.site inclut une requête à brandx.site, il inclura ce cookie.

Le cookie est intersites, 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 qu'ils souhaitent la même session, en d'autres termes, une identité partagée.

Diagramme illustrant comment un cookie peut toujours être inclus dans un contexte intersites si les sites font partie du même ensemble propriétaire, mais qu'il sera refusé pour les contextes intersites en dehors de l'ensemble.

Règlement sur les ensembles propriétaires

Les ensembles internes proposent une méthode permettant de définir explicitement cette relation sur plusieurs sites appartenant à la même partie et gérés par elle. Cela permettrait à brandx.site de définir sa relation first party avec fly-brandx.site, drive-brandx.site, etc.

Le modèle de confidentialité qui sous-tend les différentes propositions de la Privacy Sandbox est basé sur le concept de partitionnement de l'identité pour empêcher le suivi intersites. Il établit une limite entre les sites qui limite l'accès à toute information pouvant être utilisée pour identifier les utilisateurs.

Schéma illustrant l'état non partitionné, où le même cookie tiers est accessible dans plusieurs contextes intersites, contrairement à un modèle partitionné où chaque contexte de niveau supérieur dispose d'une instance distincte du cookie intersites, ce qui empêche l'activité d'association entre ces sites.

Bien que l'option par défaut soit la partition par site, ce qui résout de nombreux cas d'utilisation first party, l'exemple brandx.site montre qu'un first party peut être plus grand qu'un seul site.

Diagramme illustrant comment la même instance d'un cookie pour un ensemble peut être incluse dans des contextes intersites lorsque tous ces sites font partie du même ensemble.

Une partie importante de la proposition d'ensembles propriétaires consiste à s'assurer que les règles appliquées à tous les navigateurs empêchent les utilisations abusives ou malveillantes. Par exemple, les ensembles first party ne doivent pas permettre l'échange d'informations utilisateur entre des sites sans rapport ni le regroupement de sites qui ne sont pas la propriété de la même entité. L'idée est de s'assurer qu'un ensemble first party est mappé sur un élément qu'une personne comprend comme étant first party et qu'il n'est pas utilisé pour partager l'identité entre différentes parties.

Un site peut enregistrer un ensemble first party en envoyant son groupe de domaines proposé à un outil de suivi public (tel qu'un dépôt GitHub dédié) avec les informations nécessaires pour respecter le règlement du navigateur.

Une fois l'assertion d'ensemble propriétaire validée conformément aux règles, les navigateurs peuvent récupérer des listes d'ensembles via un processus de mise à jour.

Le test d'origine est régi par une stratégie définie qui n'est pas définitive, mais les principes devraient rester les mêmes:

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

Définir un ensemble propriétaire

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

Pour déclarer un ensemble propriétaire, les ressources JSON statiques qui listent 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 first party brandx, le domaine propriétaire héberge les éléments suivants à l'emplacement 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. À 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" }

Les ensembles propriétaires sont soumis à quelques contraintes:

  • 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 doit rester relativement lisible et ne pas être trop longue.

En quoi les ensembles propriétaires 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

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.

Schéma illustrant le cookie brandx.site autorisé ou bloqué dans les contextes multisites, comme décrit.

Tant que SameParty n'est pas largement pris en charge, utilisez l'attribut SameSite avec lui pour définir le comportement de remplacement des cookies. Vous pouvez considérer l'attribut SameParty comme un paramètre entre SameSite=Lax et SameSite=None.

  • SameSite=Lax; SameParty étend la fonctionnalité Lax pour inclure les contextes de même partie, le cas échéant, mais revient aux restrictions Lax si ce n'est pas le cas.
  • SameSite=None; SameParty limite la fonctionnalité None aux contextes de même partie, le cas échéant, mais utilise les autorisations None plus larges si ce n'est pas le cas.

Voici quelques exigences supplémentaires:

  • 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 cookie intersite. Vous devez atténuer ces risques en veillant à ce que les connexions soient sécurisées (HTTPS). De même, comme il s'agit d'une relation intersites, SameSite=Strict n'est pas valide, car il permet toujours une protection CSRF stricte basée sur le site dans un ensemble.

Quels cas d'utilisation sont adaptés aux ensembles first party ?

Les ensembles propriétaires sont adaptés lorsque votre organisation a besoin d'une forme d'identité partagée sur différents sites racine. Dans ce cas, l'identité partagée peut aller d'une solution d'authentification unique complète à une simple préférence partagée entre les sites.

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 à un pays pour activer la localisation: google.co.in, google.co.uk
  • Domaines de service avec lesquels les utilisateurs n'interagissent jamais directement, mais qui 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 qui existent pour des raisons de sécurité: googleusercontent.com, githubusercontent.com

Comment vous impliquez-vous ?

Si vous disposez d'un ensemble de sites qui répondent aux critères ci-dessus, vous pouvez participer de différentes manières. L'investissement le plus léger consiste à lire et à participer à la discussion sur les deux propositions:

Pendant la phase de test, vous pouvez essayer la fonctionnalité à l'aide de 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 cela 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 si vous souhaitez essayer d'ajouter l'attribut SameParty dans un environnement en ligne pour voir comment un ensemble first party affecterait les cookies.

Si vous avez la bande passante nécessaire pour tester et donner votre avis, vous pouvez également vous inscrire à la phase d'évaluation de l'origine pour les ensembles propriétaires et SameParty, disponible dans Chrome de la version 89 à la version 93.

Mettre à jour les cookies pour le test de l'origine

Si vous participez au test de l'origine et que vous testez l'attribut SameParty sur vos cookies, voici deux modèles à prendre en compte.

Option 1

Tout d'abord, si vous avez des cookies que vous avez marqués comme SameSite=None, mais que vous souhaitez les limiter aux contextes propriétaires, vous pouvez leur ajouter l'attribut SameParty. Dans les navigateurs où l'essai d'origine est actif, le cookie n'est pas envoyé dans les contextes intersites en dehors de l'ensemble.

Toutefois, pour la majorité des navigateurs en dehors du test d'origine, le cookie continuera d'être envoyé entre les sites comme d'habitude. Considérez-la 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 demande plus de travail, mais vous permet de séparer complètement le test d'origine de la fonctionnalité existante et, plus précisément, de tester 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 les requêtes entrantes, vous ne devriez voir le cookie cname-fps que dans une requête intersites si les sites concernés font partie de l'ensemble et que le navigateur est en phase de test d'origine. Considérez cette approche comme un 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 first party ?

Pour la plupart des sites, la limite du site est un endroit acceptable pour tracer la partition ou la limite de confidentialité. C'est l'approche proposée avec les cookies ayant un état partitionné indépendant (CHIPS), qui donnerait aux sites un chemin d'activation via l'attribut Partitioned pour conserver ces éléments intégrés, ressources, API et services critiques entre les sites, tout en empêchant la fuite d'informations d'identification entre les sites.

Voici quelques autres éléments à prendre en compte pour déterminer si votre site peut fonctionner sans ensemble:

  • Vous hébergez sur différentes origines, et non sur différents sites. Dans l'exemple ci-dessus, si brandx.site avait fly.brandx.site et drive.brandx.site, il s'agit de sous-domaines différents sur le même site. Les cookies peuvent utiliser SameSite=Lax et aucun ensemble n'est nécessaire.
  • Vous fournissez des éléments intégrés tiers à d'autres sites. Dans l'introduction, l'exemple d'une vidéo de video.site intégrée sur my-blog.site est une division claire entre tiers. Les sites sont gérés par différentes organisations et les utilisateurs les considèrent comme des entités distinctes. Ces deux sites ne doivent pas être inclus dans un même ensemble.
  • Vous proposez des services de connexion via les réseaux sociaux tiers. Les fournisseurs d'identité qui utilisent des éléments tels que OAuth ou OpenID Connect s'appuient souvent sur des cookies tiers pour offrir une expérience de connexion plus fluide aux utilisateurs. Il s'agit d'un cas d'utilisation valide, mais il n'est pas adapté aux ensembles propriétaires, car il existe une différence claire entre les organisations. Les premières propositions telles que WebID explorent des moyens de permettre ces cas d'utilisation.