Cookies ayant un état partitionné indépendant (CHIPS)

Permettre aux développeurs d'enregistrer un cookie dans le stockage "partitionné", avec un fichier de cookies séparé pour chaque site de premier niveau.

État de l'implémentation

Navigateurs pris en charge

  • 114
  • 114
  • x
  • x

Source

Qu'est-ce que les CHIPS ?

Les cookies ayant un état distinctif (CHIPS, Independent Partitioned State) permettent aux développeurs d'activer un cookie dans un stockage partitionné, avec des fichiers de cookies distincts pour chaque site de premier niveau, ce qui améliore la confidentialité et la sécurité des utilisateurs.

Sans partitionnement, les cookies tiers peuvent permettre aux services de suivre les utilisateurs et d'associer leurs informations à partir de nombreux sites de premier niveau sans rapport entre eux. C'est ce qu'on appelle le suivi intersites.

Les navigateurs sont déjà bien avancés dans l'abandon progressif des cookies tiers non partitionnés. Par conséquent, CHIPS, l'API Storage Access et les Ensembles de sites Web associés seront le seul moyen de lire et d'écrire des cookies à partir de contextes intersites, tels que les iFrames, lorsque les cookies tiers sont bloqués.

Diagramme illustrant comment des cuisiniers peuvent être partagés entre deux sites Web différents.
Sans le partitionnement des cookies, un service tiers peut définir un cookie lorsqu'il est intégré à un site de premier niveau et accéder à ce même cookie lorsque le service est intégré à d'autres sites de premier niveau.

CHIPS introduit un nouvel attribut de cookie, Partitioned, pour prendre en charge les cookies intersites partitionnés selon un contexte de premier niveau.

En-tête Set-Cookie:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

Un cookie tiers partitionné est lié au site de premier niveau où il a été défini initialement et n'est accessible nulle part ailleurs. Ainsi, les cookies définis par un service tiers ne peuvent être lus que dans le contexte intégré du site de premier niveau où ils ont été initialement définis.

Diagramme illustrant que deux sites Web différents intégrant un tiers commun ne partagent plus de cookies pour ce tiers.
Avec le partitionnement par cookie, un service tiers qui définit un cookie lorsqu'il est intégré à un site de premier niveau ne peut pas accéder à ce même cookie lorsque le service est intégré à d'autres sites de premier niveau.

Avec les cookies partitionnés, lorsqu'un utilisateur visite le site A et qu'un contenu intégré de ce site définit un cookie avec l'attribut partitionné, ce cookie est enregistré dans un fichier JAR partitionné exclusivement réservé aux cookies que le site C définit lorsqu'il est intégré au site A. Le navigateur n'enverra ce cookie que si le site de premier niveau est A.

Lorsque l'utilisateur visite un nouveau site, par exemple le site B, un frame C intégré ne reçoit pas le cookie défini lors de l'intégration de C sur le site A.

Si un utilisateur visite le site C en tant que site Web de premier niveau, le cookie partitionné défini par C lors de son intégration dans A n'est pas non plus envoyé dans cette requête.

Diagramme montrant que les cookies ne sont pas partagés lorsque le même tiers est intégré sur deux sites Web différents
Avec le partitionnement par cookie, un service tiers qui définit un cookie lorsqu'il est intégré à un site ne peut pas accéder à ce même cookie, même si les utilisateurs accèdent au service en tant que site de premier niveau.

Cas d'utilisation

Par exemple, le site retail.example peut collaborer avec un service tiers support.chat.example pour intégrer une fenêtre de chat d'assistance sur son site. Aujourd'hui, de nombreux services de chat intégrables s'appuient sur des cookies pour enregistrer l'état.

Schéma illustrant un site Web avec un widget de chat sous-jacent
Site de premier niveau retail.example présentant un service tiers support.chat.example.

Sans la possibilité de définir un cookie intersite, support.chat.example devrait trouver d'autres méthodes, souvent plus complexes, pour stocker l'état. Sinon, il doit être intégré à la page de premier niveau, ce qui présente des risques, car cela permet au script support.chat.example d'avoir des privilèges élevés sur retail.example, comme la possibilité d'accéder aux cookies d'authentification.

CHIPS permet de continuer à utiliser des cookies intersites plus facilement, sans les risques associés aux cookies non partitionnés.

Voici quelques exemples de cas d'utilisation des CHIPS : des sous-ressources intersites nécessitant une notion d'état de session ou persistant limitée à l'activité d'un utilisateur sur un site de premier niveau unique, par exemple :

  • Intégrations de chats tierces
  • Intégrations de cartes tierces
  • Intégrations de paiements tiers
  • Équilibrage de charge CDN de la sous-ressource
  • Fournisseurs de CMS sans interface graphique
  • Domaines de bac à sable pour la diffusion de contenus utilisateur non approuvés (tels que googleusercontent.com et githubusercontent.com)
  • CDN tiers qui utilisent des cookies pour diffuser du contenu dont l'accès est contrôlé par l'état d'authentification sur le site propriétaire (par exemple, les photos de profil sur les sites de réseaux sociaux hébergés sur des CDN tiers).
  • Frameworks front-end qui s'appuient sur des API distantes utilisant des cookies pour leurs requêtes
  • Annonces intégrées dont l'état doit être défini par éditeur (par exemple, en collectant les préférences des utilisateurs pour les annonces sur ce site Web)

Pourquoi CHIPS utilise-t-il un modèle de partitionnement facultatif ?

Alors que les navigateurs abandonnent progressivement les cookies tiers non partitionnés, deux autres approches du partitionnement ont été essayées.

Firefox a annoncé le partitionnement de tous les cookies tiers par défaut dans son mode ETP strict et son mode de navigation privée. Tous les cookies intersites sont donc partitionnés par le site de premier niveau. Toutefois, le partitionnement des cookies sans l'activation de la fonctionnalité tierce peut entraîner des bugs inattendus, car certains services tiers ont créé des serveurs qui attendent un cookie tiers non partitionné.

Safari a déjà essayé de partitionner les cookies selon des méthodes heuristiques, mais a finalement décidé de les bloquer complètement, citant la confusion des développeurs comme l'une des raisons. Récemment, Safari a exprimé son intérêt pour un modèle basé sur les activations.

Ce qui distingue CHIPS des implémentations existantes de cookies partitionnés, c'est l'activation par un tiers. Les cookies doivent être définis avec un nouvel attribut afin d'être envoyés dans des requêtes multipartites une fois que les cookies tiers (non partitionnés) sont obsolètes.

Même si les cookies tiers existent toujours, l'attribut Partitioned permet d'activer un type de comportement de cookie plus restrictif et plus sécurisé. Les CHIPS sont une étape importante pour aider les services à opérer une transition en douceur vers un avenir sans cookies tiers.

Aujourd'hui, les cookies sont associés au nom d'hôte ou au domaine du site qui les a définis, c'est-à-dire leur clé d'hôte.

Par exemple, pour les cookies de https://support.chat.example, la clé d'hôte est ("support.chat.example").

Sous CHIPS, les cookies qui activent le partitionnement seront appariés à deux clés sur leur clé hôte et sur leur clé de partition.

La clé de partition d'un cookie correspond au site (schéma et domaine enregistrable) de l'URL de premier niveau que le navigateur visitait au début de la requête adressée au point de terminaison qui a défini le cookie.

Dans l'exemple précédent, où https://support.chat.example est intégré à https://retail.example, l'URL de premier niveau est https://retail.example.

Dans ce cas, la clé de partition est ("https", "retail.example").

De même, la clé de partition d'une requête correspond au site de l'URL de premier niveau que le navigateur visite au début d'une requête. Les navigateurs ne doivent envoyer un cookie avec l'attribut Partitioned que dans les requêtes ayant la même clé de partition que ce cookie.

Voici à quoi ressemble la clé de cookie de l’exemple précédent avant et après CHIPS.

Le site A et le site intégré C partagent un cookie partitionné. Lorsqu'il n'est pas intégré, le site C ne peut pas accéder au cookie partitionné.
Le site A et le site intégré C partagent un cookie partitionné. Lorsqu'il n'est pas intégré, le site C ne peut pas accéder au cookie partitionné.

Avant les CHIPS

key=("support.chat.example")

Après les CHIPS

key={("support.chat.example"),("https", "retail.example")}

Conception de la sécurité

Afin d'encourager les bonnes pratiques de sécurité, les cookies CHIPS ne sont définis et envoyés que via des protocoles sécurisés.

  • Les cookies partitionnés doivent être définis avec Secure.
  • Il est recommandé d'utiliser le préfixe __Host lorsque vous définissez des cookies partitionnés pour les rendre liés au nom d'hôte (et non au domaine enregistrable).

Exemple :

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Alternatives aux CHIPS

L'API Storage Access et les Ensembles de sites Web associés (RWS) associés sont des mécanismes de plate-forme Web permettant d'activer un accès limité aux cookies intersites à des fins spécifiques et visibles par l'utilisateur.

Il s'agit d'alternatives au partitionnement CHIPS, où l'accès à des "cookes non partitionnés" intersites est requis.

Prenons l'exemple de l'API Storage Access et des ensembles de sites Web associés si vous avez besoin que le même cookie soit disponible pour un service intégré dans plusieurs sites associés.

CHIPS permet à un service d'agir en tant que composant isolé sur plusieurs sites, lorsque le même cookie n'a pas besoin d'être disponible sur plusieurs sites. Si le service définit un cookie partitionné, sa clé de partition sera le site de premier niveau et ce cookie ne sera pas disponible pour les autres sites qui l'utilisent également.

La conception des Ensembles de sites Web associés repose sur l'API Storage Access et n'est pas intégrée au partitionnement CHIPS. Si votre cas d'utilisation repose sur une partition de cookie partagée entre plusieurs sites dans un RWS, vous pouvez fournir des exemples et des commentaires sur le problème GitHub.

Démonstration

Cette démonstration vous explique comment fonctionnent les cookies partitionnés et comment les inspecter dans les outils de développement.

Le site A intègre un iFrame du site B qui utilise JavaScript pour définir deux cookies: un cookie partitionné et un cookie non partitionné. Le site B affiche tous les cookies accessibles à partir de cet emplacement à l'aide de document.cookie.

Lorsque les cookies tiers sont bloqués, le site B ne peut définir et accéder au cookie avec l'attribut Partitioned que dans un contexte intersites.

Lorsque les cookies tiers sont autorisés, le site B peut également définir le cookie non partitionné et y accéder.

Sites A et site B
À gauche: les cookies tiers sont bloqués. À droite: les cookies tiers sont autorisés.

Prérequis

  1. Chrome 118 ou version ultérieure.
  2. Accédez à chrome://flags/#test-third-party-cookie-phaseout et activez ce paramètre

Inspecter les cookies partitionnés à l'aide des outils de développement

  1. Accédez à https://chips-site-a.glitch.me.
  2. Appuyez sur Control+Shift+J (ou Command+Option+J sur Mac) pour ouvrir les outils de développement.
  3. Cliquez sur l'onglet Application.
  4. Accédez à Application > Storage > Cookies (Application > Stockage > Cookies).
  5. Cliquez sur https://chips-site-b.glitch.me.

Les outils de développement afficheront tous les cookies de l'origine sélectionnée.

Cookies du site B dans l'onglet "Application" des outils de développement

Le site B ne peut définir le cookie partitionné que dans un contexte intersite. Le cookie non partitionné sera bloqué:

  • __Host-partitioned-cookie doit s'afficher avec la clé de partition du site de premier niveau https://chips-site-a.glitch.me.
Clé de partitionnement pour le cookie partitionné par l'hôte.
  1. Cliquez sur Accéder au site B.
  2. Dans les outils de développement, accédez à Application > Storage > Cookies (Application > Stockage > Cookies).
  3. Cliquez sur https://chips-site-b.glitch.me.
Site B
Au niveau supérieur, le site B peut voir tous les cookies (partitionnés et non partitionnés)

Dans ce scénario, comme vous vous trouvez sur le site B dans un contexte de niveau supérieur, il peut définir les deux cookies et y accéder:

  • unpartitioned-cookie comporte une clé de partition vide.
  • Le cookie __Host-partitioned-cookie comporte la clé de partition https://chips-site-b.glitch.me.
Cookies du site B dans l'onglet "Application" des outils de développement lorsque l'utilisateur visite le site B en tant que site de premier niveau __Host-partition-cookie possède la clé de partition suivante : https://chips-site-b.glitch.me.

Si vous revenez au site A, unpartitioned-cookie est désormais stocké dans le navigateur, mais il ne sera pas accessible à partir du site A.

  1. Cliquez sur Accéder au site A.
  2. Cliquez sur l'onglet Réseau.
  3. Cliquez sur https://chips-site-b.glitch.me.
  4. Cliquez sur l'onglet Cookies.

Une fois sur le site A, vous devriez voir le __Host-partitioned-cookie avec la clé de partition du site de premier niveau https://chips-site-a.glitch.me.

Onglet "Réseau" affichant les cookies de l'iFrame du site B qui sont accessibles lorsqu'il est intégré au site A.

Si vous cochez l'option Afficher les demandes de cookies filtrées, les outils de développement indiqueront que le cookie non partitionné est bloqué. Cette option est surlignée en jaune avec une info-bulle: Ce cookie a été bloqué en raison des préférences utilisateur.

Onglet "Réseau" affichant les cookies bloqués de l'iFrame du site B.

Dans Application > Storage > Cookies (Application > Stockage > Cookies), cliquez sur https://chips-site-b.glitch.me pour afficher les éléments suivants:

  • unpartitioned-cookie par la clé de partition vide.
  • Cookie __Host-partitioned-cookie avec la clé de partition https://chips-site-a.glitch.me.
Cookies du site B dans l'onglet "Application" des outils de développement Le cookie __Host-partitioned-cookie comporte la clé de partition https://chips-site-a.glitch.me. unpartitioned-cookie s'affiche, mais l'iFrame du site B ne peut pas y accéder lorsqu'il est intégré au site A.

Effacer les cookies

Pour réinitialiser la démo, effacez tous les cookies du site:

  • Appuyez sur Control+Shift+J (ou Command+Option+J sur Mac) pour ouvrir les outils de développement.
  • Cliquez sur l'onglet Application.
  • Accédez à Application > Storage > Cookies (Application > Stockage > Cookies).
  • Effectuez un clic droit sur https://chips-site-b.glitch.me.
  • Cliquez sur Effacer.

Ressources