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

Autoriser les développeurs à activer un cookie en mode "partitionnée" avec un pot à cookies distinct pour chaque site de premier niveau.

État d'implémentation

Navigateurs pris en charge

• 114
• 114
• x
• x

Source

• 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.

Pour en savoir plus sur les CHIPS et Android WebView, consultez Intention d'abandon et de redémarrage: CHIPS sur WebView.

Que sont les CHIPS ?

Les développeurs peuvent activer un cookie dans un espace de stockage partitionné grâce à des bacs à cookies distincts pour chaque site de premier niveau, ce qui permet aux développeurs d'améliorer 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. C'est ce qu'on appelle le suivi intersites.

Les navigateurs sont en bonne voie pour éliminer progressivement les cookies tiers non partitionnés. Par conséquent, CHIPS, l'API Storage Access et les Ensembles de sites Web associés seront les seuls moyens de lire et d'écrire des cookies à partir de contextes intersites, tels que des iFrames, lorsque les cookies tiers sont bloqués.

<ph type="x-smartling-placeholder">

</ph>

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 accepter les cookies intersites partitionnés en fonction du 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 pas accessible depuis d'autres emplacements. De cette façon, les cookies définis par un service tiers ne peuvent être lus que dans le même contexte embarqué que celui du site de premier niveau où ils ont été définis initialement.

<ph type="x-smartling-placeholder">

</ph>

Avec le partitionnement des cookies, 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 que le contenu intégré du site C définit un cookie avec l'attribut partitionné, celui-ci est enregistré dans un fichier JAR partitionné conçu 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, par exemple le site B, un cadre C intégré ne reçoit pas le cookie défini lors de l'intégration de C dans le 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 lors de son intégration dans A ne sera pas non plus envoyé dans cette requête.

<ph type="x-smartling-placeholder">

</ph>

Grâce au partitionnement des cookies, 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 lorsque 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 y intégrer une fenêtre de chat d'assistance. Aujourd'hui, de nombreux services de chat intégrables utilisent des cookies pour enregistrer l'état.

<ph type="x-smartling-placeholder">

</ph>

Site de premier niveau retail.example intégrant un service tiers support.chat.example.

S'il n'était pas possible de définir un cookie intersites, 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 droits élevés sur retail.example, tels que la possibilité d'accéder aux cookies d'authentification.

Les CHIPS offrent une option plus simple pour continuer à utiliser des cookies intersites, sans les risques associés aux cookies non partitionnés.

Voici quelques exemples de cas d'utilisation des CHIPS dans lesquels des sous-ressources intersites requièrent une notion d'état de session ou d'état persistant, limitée à l'activité d'un utilisateur sur un seul site de premier niveau:

• Intégrations de chat tierces
• Intégrations de cartes tierces
• Intégrations de paiements tiers
• Équilibrage de charge CDN des sous-ressources
• Fournisseurs de CMS headless
• Domaines bac à sable permettant de diffuser du contenu utilisateur non approuvé (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, des photos de profil sur des 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 qui nécessitent un état limité par éditeur (par exemple, pour capturer les préférences des utilisateurs pour les annonces sur ce site Web)

Pourquoi CHIPS utilise un modèle de partitionnement facultatif

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

Firefox a annoncé qu'il partitionnait tous les cookies tiers par défaut en mode ETP strict et en mode de navigation privée. Tous les cookies intersites sont donc partitionnés en fonction du site de premier niveau. Toutefois, le partitionnement des cookies sans activation 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 sur la base d'heuristiques, mais il a finalement décidé de les bloquer complètement, d'où la confusion des développeurs. Récemment, Safari a exprimé son intérêt pour un modèle basé sur l'acceptation des utilisateurs.

Ce qui différencie les CHIPS des implémentations existantes de cookies partitionnés est l'acceptation tierce. 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.

Bien que les cookies tiers existent toujours, l'attribut Partitioned permet d'activer un type de comportement des cookies plus restrictif et plus sécurisé. Les CHIPS constituent une étape importante pour faciliter la transition des services vers 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 définit, 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").

Avec les CHIPS, les cookies qui activent le partitionnement sont à double clé sur leur clé d'hôte et leur clé de partitionnement.

La clé de partition d'un cookie correspond au site (schéma et domaine enregistrable) de l'URL de premier niveau consultée par le navigateur 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 partitionnement d'une requête correspond au site de l'URL de premier niveau à laquelle le navigateur accède 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 dans l'exemple précédent avant et après CHIPS.

<ph type="x-smartling-placeholder">

</ph>

Le site A et le site intégré C partagent un cookie partitionné. S'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")}

Remarque:Chrome est limité à 180 cookies par partition, sans dépasser 10 Ko par site intégré.

Conception de la sécurité

Pour encourager de bonnes pratiques de sécurité, avec les CHIPS, les cookies sont uniquement définis et envoyés 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 afin de les lier au nom d'hôte (et non au domaine enregistrable).

Exemple :

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

Remarque:Si vous ajoutez SameSite=None, votre cookie sera envoyé dans des contextes tiers où l'attribut Partitioned n'est pas compatible, à condition que les cookies tiers soient autorisés dans les paramètres du navigateur.

Alternatives aux CHIPS

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

Il s'agit d'alternatives au partitionnement CHIPS qui nécessitent un accès à des tables de cuisine intersites non partitionnées.

Envisagez d'utiliser l'API Storage Access et les ensembles de sites Web associés lorsque vous souhaitez 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 est le site de premier niveau et ce cookie ne sera pas disponible pour les autres sites qui utilisent également le service.

La conception des ensembles de sites Web associés repose sur l'API Storage Access et ne s'intègre pas au partitionnement CHIPS. Si votre cas d'utilisation repose sur une partition de cookies partagée entre les sites d'un RWS, vous pouvez fournir des exemples et des commentaires sur le problème GitHub.

Démo

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 ce lieu à l'aide de document.cookie.

Lorsque les cookies tiers sont bloqués, le site B ne peut définir le cookie et y accéder qu'avec l'attribut Partitioned 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.

<ph type="x-smartling-placeholder">

</ph>

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 > 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.

<ph type="x-smartling-placeholder">

</ph>

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 intersites. 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 __cookie partitionné par l'hôte.

Remarque:Cette vue affiche tous les cookies de cette partition ainsi que tous les cookies non divisés, même s'ils ne sont pas accessibles sur la page actuelle. Si vous consultez le site B en tant que site de premier niveau, vous verrez le cookie non partitionné ici, mais il ne sera pas disponible pour le site B lorsqu'il est intégré au site A.

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.

Au niveau supérieur, le site B peut voir tous les cookies, qu'ils soient partitionnés ou non

Dans ce scénario, étant donné que vous vous trouvez sur le site B dans le contexte de premier niveau, il peut définir et accéder aux deux cookies:

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

Cookies du site B dans l'onglet Application des outils de développement lorsque vous visitez le site B en tant que site de premier niveau. __Host-partitioned-cookie possède la clé de partition https://chips-site-b.glitch.me.

Si vous revenez au site A, unpartitioned-cookie est désormais stocké dans le navigateur, mais 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.

<ph type="x-smartling-placeholder">

</ph>

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 indiquent que le cookie non partitionné est bloqué. Il est surligné en jaune avec une info-bulle: Ce cookie a été bloqué en raison des préférences de l'utilisateur.

<ph type="x-smartling-placeholder">

</ph>

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

Remarque:Étant donné que vous avez consulté B en tant que site de premier niveau, le site B possède également un cookie partitionné doté de la clé de partitionnement https://chips-site-b.glitch.me, qui n'est pas disponible dans ce contexte. Par conséquent, le message suivant s'affiche: "Ce site contient des cookies dans une autre partition qui n'ont pas été envoyés avec cette requête".

Dans Application > Stockage > Cookies cliquant sur https://chips-site-b.glitch.me affichera:

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

Cookies du site B dans l'onglet Application des outils de développement. Le cookie __Host-partitioned-cookie a la clé de partition https://chips-site-a.glitch.me. unpartitioned-cookie s'affiche, mais l'iFrame du site B n'est pas accessible depuis l'iFrame du site B 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 > 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 aux développeurs: posez des questions et participez à des discussions dans le dépôt de l'assistance aux développeurs Privacy Sandbox.