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

Permettre aux développeurs d'activer le stockage "partitionné" pour un cookie, avec un pot de cookies distinct pour chaque site de premier niveau.

État de l'implémentation

• Fonctionnalité par défaut disponible dans Chrome 114 et versions ultérieures.
• Une phase d'évaluation, désormais terminée, était disponible des versions 100 à 116 de Chrome.
• Lisez les articles Intention de test et Intention de livraison.

Qu'est-ce que CHIPS ?

Les cookies ayant un état partitionné indépendant (CHIPS) permettent aux développeurs d'activer le stockage partitionné pour un cookie, avec des boîtes à cookies distinctes 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 de regrouper leurs informations provenant de nombreux sites de premier niveau sans lien entre eux. C'est ce qu'on appelle le suivi multisite.

CHIPS, l'API Storage Access et les ensembles de sites Web associés sont les seuls moyens de lire et d'écrire des cookies à partir de contextes multisites, tels que les iFrames, lorsque les cookies tiers sont bloqués.

CHIPS introduit un nouvel attribut de cookie, Partitioned, pour prendre en charge les cookies intersites partitionnés par 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 associé au site de premier niveau où il est initialement défini et ne peut pas être consulté ailleurs. Ainsi, les cookies définis par un service tiers ne peuvent être lus que dans le même contexte intégré du site de premier niveau où ils ont été initialement définis.

Avec les cookies partitionnés, lorsqu'un utilisateur visite le site A et que du contenu intégré du site C définit un cookie avec l'attribut "Partitioned", le cookie est enregistré dans un pot de cookies partitionné désigné uniquement pour les cookies que le site C définit lorsqu'il est intégré au site A. Le navigateur n'enverra ce cookie que lorsque le site de premier niveau est A.

Lorsque l'utilisateur visite un nouveau site (le site B, par exemple), un frame C intégré ne reçoit pas le cookie qui a été défini lorsque C était intégré au site A.

Si un utilisateur visite le site C en tant que site Web de premier niveau, le cookie partitionné que C a défini lorsqu'il était intégré à A ne sera pas non plus envoyé dans cette requête.

Cas d'utilisation

Par exemple, le site retail.example peut souhaiter collaborer avec un service tiers support.chat.example pour intégrer une boîte de chat d'assistance sur son site. De nombreux services de chat intégrables s'appuient aujourd'hui sur des cookies pour enregistrer l'état.

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

CHIPS offre une option plus simple pour continuer à utiliser les cookies multisites, sans les risques associés aux cookies non partitionnés.

Voici quelques exemples de cas d'utilisation pour les CHIPS : tous les scénarios dans lesquels des sous-ressources multisites nécessitent une notion de session ou d'état persistant limité à l'activité d'un utilisateur sur un seul site de premier niveau, par exemple :

• Intégrations de chat tiers
• Intégrations de cartes tierces
• Intégrations de paiements tiers
• Équilibrage de charge CDN de sous-ressources
• Fournisseurs de CMS headless
• Domaines bac à sable pour diffuser du contenu utilisateur non fiable (comme 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 de frontend qui s'appuient sur des API distantes utilisant des cookies dans leurs requêtes
• Annonces intégrées nécessitant un état limité à chaque éditeur (par exemple, pour enregistrer les préférences des utilisateurs concernant les annonces sur ce site Web)

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

Lorsque l'accès aux cookies tiers non partitionnés est bloqué, d'autres approches de partitionnement ont été tentées.

Firefox a annoncé qu'il partitionnait tous les cookies tiers par défaut dans son mode Strict ETP et son mode de navigation privée. Tous les cookies multisites sont donc partitionnés par le site de premier niveau. Toutefois, le partitionnement des cookies sans consentement tiers peut entraîner des bugs inattendus, car certains services tiers ont créé des serveurs qui s'attendent à un cookie tiers non partitionné.

Safari a déjà essayé de partitionner les cookies en fonction d'heuristiques, mais a finalement choisi de les bloquer complètement, en invoquant, entre autres, la confusion des développeurs. Récemment, Safari a exprimé son intérêt pour un modèle basé sur le consentement.

Ce qui distingue CHIPS des implémentations existantes de cookies partitionnés, c'est l'activation par les tiers. Les cookies doivent être définis avec un nouvel attribut pour pouvoir être envoyés une seule fois sur les requêtes cross-party une fois que les cookies tiers (non partitionnés) seront obsolètes.

Bien que les cookies tiers existent toujours, l'attribut Partitioned permet d'activer un comportement de cookie plus restrictif et plus sécurisé. CHIPS est une étape importante pour aider les services à passer en douceur à un avenir sans cookies tiers.

Conception technique du partitionnement des cookies

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 provenant de https://support.chat.example, la clé hôte est ("support.chat.example").

Avec CHIPS, les cookies qui choisissent d'être partitionnés seront collectés deux fois sur leur clé hôte et leur clé de partition.

La clé de partition d'un cookie correspond au site (schéma et domaine pouvant être enregistré) de l'URL de premier niveau que le navigateur visitait au début de la requête envoyé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 avec la même clé de partition que ce cookie.

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

Avant CHIPS

key=("support.chat.example")

Après CHIPS

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

Conception de la sécurité

Pour 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- lors de la définition de cookies partitionnés pour les lier au nom d'hôte (et non au domaine pouvant être enregistré).

Exemple :

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

Alternatives à CHIPS

L'API Storage Access et les ensembles de sites Web associés (RWS) sont des mécanismes de plate-forme Web qui permettent un accès limité aux cookies multisites à des fins spécifiques et orientées utilisateur.

Il s'agit d'alternatives au partitionnement CHIPS lorsque l'accès aux cookies non partitionnés multisites est requis.

Envisagez d'utiliser l'API Storage Access et les ensembles de sites Web associés dans les situations où vous avez besoin que le même cookie soit disponible pour un service intégré à plusieurs sites associés.

CHIPS permet à un service d'agir en tant que composant isolé sur plusieurs sites, où 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. Ce cookie ne sera pas disponible pour les autres sites qui utilisent également le service.

La conception des ensembles de sites Web associés s'appuie sur l'API Storage Access et ne s'intègre pas au partitionnement CHIPS. Si vous avez un cas d'utilisation qui repose sur une partition de cookie partagée sur plusieurs sites d'un même ensemble de sites associés, vous pouvez fournir des exemples et des commentaires dans le problème GitHub.

Démo

Cette démonstration vous montrera 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 intersite.

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

Prérequis

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

Utiliser les outils de développement pour inspecter les cookies partitionnés

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 > Stockage > Cookies.
5. Cliquez sur https://chips-site-b.glitch.me.

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

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

• Vous devriez voir __Host-partitioned-cookie avec la clé de partition du site de premier niveau https://chips-site-a.glitch.me.

1. Cliquez sur Go to Site B (Accéder au site B).
2. Dans les outils de développement, accédez à Application > Stockage > Cookies.
3. Cliquez sur https://chips-site-b.glitch.me.

Dans ce scénario, comme vous vous trouvez sur le site B dans un contexte de premier niveau, vous pouvez définir et accéder aux deux cookies :

• unpartitioned-cookie a une clé de partition vide.
• Le cookie __Host-partitioned-cookie possède la clé de partition https://chips-site-b.glitch.me.

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

1. Cliquez sur Go to Site A (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.

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

Si vous cochez la case Afficher les cookies de requête filtrés, les outils de développement indiquent que le cookie non partitionné est bloqué. Il est mis en surbrillance en jaune et un info-bulle s'affiche : Ce cookie a été bloqué en raison des préférences de l'utilisateur.

Dans Application > Stockage > Cookies, cliquez sur https://chips-site-b.glitch.me pour afficher :

• unpartitioned-cookie avec la clé de partition vide.
• Cookie __Host-partitioned-cookie avec la clé de partition https://chips-site-a.glitch.me.

Supprimer 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 > Stockage > Cookies.
• Effectuez un clic droit sur https://chips-site-b.glitch.me.
• Cliquez sur Effacer.

Ressources

• GitHub : lisez l'explication, posez des questions et suivez la discussion.
• Assistance pour les développeurs : posez des questions et participez à des discussions sur le dépôt d'assistance pour les développeurs Privacy Sandbox.