Les cookies tiers ont de nombreuses utilisations, mais ils sont également un élément clé du suivi intersites.
Chrome propose une nouvelle expérience de choix pour les utilisateurs avec les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.
Cette page contient des informations sur les solutions protégeant la confidentialité pour les scénarios intégrés qui reposaient traditionnellement sur des cookies tiers, ainsi que des stratégies pour vous aider à choisir la solution la plus adaptée à vos besoins.
Les services intégrés incluent les contenus tiers (comme les vidéos, les cartes), les composants interactifs (comme les systèmes de chat, de commentaires ou de paiement), les services de connexion, etc.
La majeure partie du travail de transition des cookies tiers doit être effectuée par les développeurs d'intégration, et non par les sites qui hébergent des intégrations. Ce guide concerne principalement les solutions destinées aux développeurs qui créent des services intégrés.
Si votre site s'appuie sur un élément intégré qui utilise des cookies tiers, veillez à auditer et à tester vos parcours associés à l'élément intégré, et contactez les fournisseurs d'éléments intégrés si vous constatez des erreurs.
Auditer et tester vos parcours utilisateur liés à l'intégration
Le meilleur moyen de déterminer si vos composants intégrés sont affectés par les cookies tiers consiste à tester vos flux utilisateur de composants intégrés tiers avec l'indicateur de test des cookies tiers activé.
Une fois que vous avez limité les cookies tiers, testez ces scénarios d'intégration courants:
- Widgets Chat:pouvez-vous démarrer une session de chat ? Pouvez-vous actualiser la page sans perdre votre session ? Pouvez-vous accéder à d'autres pages et conserver votre session ?
- Contenu intégré:pouvez-vous regarder des contenus vidéo ou d'autres contenus intégrés ? Les préférences de l'utilisateur (langue ou sous-titres, par exemple) sont-elles conservées ? Voyez-vous des annonces au moment prévu, par exemple si vous êtes abonné à un service premium ?
- Connexion:les connexions, y compris les connexions SSO, fonctionnent-elles pour les intégrations qui les acceptent ? Sont-ils conservés lors des actualisations de page et de la navigation vers des pages qui utilisent les mêmes éléments intégrés ?
- Widgets de commentaires:pouvez-vous laisser des commentaires, les "aimer" et les "upvoter" ?
- Solutions de paiement intégrées:pouvez-vous effectuer des paiements ?
Dans les sections suivantes, vous trouverez des informations plus spécifiques sur l'impact potentiel de ces flux.
Cas d'utilisation courants
Plusieurs API peuvent être utilisées pour les éléments intégrés qui reposaient traditionnellement sur des cookies tiers. Le tableau suivant présente certains workflows courants et les API recommandées à utiliser. Les sections suivantes expliquent le raisonnement derrière ces recommandations.
| Cas d'utilisation | API recommandée pour l'utilisation de cookies tiers |
|---|---|
| Widget Chat | CHIPS |
| Intégrations de cartes | CHIPS |
| Domaines de bac à sable pour le contenu utilisateur non approuvé (par exemple, googleusercontent.com et githubusercontent.com) qui nécessitent un champ d'application de l'état par éditeur |
CHIPS |
| Annonces intégrées nécessitant un champ d'application de l'état par éditeur | CHIPS |
| Se connecter via un fournisseur d'identité | FedCM |
| Intégration hébergée sur des origines différentes, mais associées. | API Storage Access avec des ensembles de sites Web associés |
| Intégration de contenu avec des préférences basées sur la connexion (par exemple, contenu vidéo sans annonces ou préférences de langue/sous-titres) |
API Storage Access |
| Widget de commentaires sur les réseaux sociaux nécessitant une connexion | API Storage Access |
Choisir l'API à utiliser pour les cas d'utilisation tiers intégrés
Cette section explique comment choisir une API de remplacement appropriée et présente les API recommandées.
L'organigramme suivant vous aide à choisir parmi les options disponibles:
L'organigramme pose trois questions principales. Nous allons les examiner plus en détail et expliquer pourquoi une API donnée est recommandée dans chaque cas.
1. Les cookies sont-ils spécifiques au site d'intégration ?
De nombreux éléments intégrés tiers sont utilisés indépendamment sur des sites totalement différents. Par exemple, les widgets de chat pour le service client nécessitent souvent des cookies pour fonctionner, mais il n'est pas nécessaire de les partager entre deux organisations complètement différentes qui utilisent la même solution de widget de chat. Dans de nombreux cas, il est préférable de ne pas autoriser le partage de cookies.
Si vous fournissez un service d'intégration tiers à d'autres sites et qu'il repose sur des cookies, demandez-vous si ces cookies sont spécifiques au service sur le site où il est intégré. Les instances de votre intégration sur d'autres sites les partagent-elles ?
Si les cookies ne doivent pas être partagés, la solution la plus simple consiste à les partitionner à l'aide de CHIPS. Cette API associe les cookies tiers au site de premier niveau, au lieu de les autoriser à être partagés par tous les sites qui utilisent le même élément intégré tiers. CHIPS est facile à implémenter, car il suffit d'ajouter un attribut Partitioned supplémentaire aux cookies existants. Les services intégrés peuvent ainsi continuer à enregistrer l'état, mais le stockage intersites partagé qui permettrait le suivi intersites est supprimé.
Les sites doivent également vérifier si les cookies sont utilisés pour les bonnes raisons. Les cookies ne doivent être utilisés que lorsqu'ils sont définis ou doivent être envoyés avec des requêtes HTTP. Si ce n'est pas le cas et que les cookies ne sont utilisés que comme une option de stockage pratique, les différentes API de stockage doivent être envisagées à la place. Les données restent locales lorsqu'elles n'ont pas besoin d'être envoyées. Les API de stockage sont déjà partitionnées dans tous les principaux navigateurs, de la même manière que CHIPS partitionne les cookies.
2. Les cookies sont-ils destinés à un fournisseur d'identité tiers ?
Les cookies tiers sont couramment utilisés dans les éléments intégrés pour fournir des fonctionnalités de connexion gérées par un fournisseur de connexion tiers, tel que Se connecter avec Google. Les cookies partitionnés ne sont pas une option dans ce cas.
La gestion des identifiants fédérés (FedCM) est une API dédiée à ce cas d'utilisation. Elle fonctionne sans cookies tiers. Si le fournisseur d'identité est compatible avec FedCM, les cookies tiers peuvent ne plus être nécessaires.
Pour en savoir plus sur la gestion des effets des cookies tiers sur les workflows de connexion, consultez le guide sur l'identité.
3. Les cookies sont-ils utilisés sur un petit nombre de sites associés ?
Si aucune des options précédentes ne convient comme remplacement des cookies, vous devez envisager de réactiver l'accès aux cookies tiers pour l'intégration. Cette fonctionnalité peut être activée dans des cas d'utilisation spécifiques et contrôlés avec l'API Storage Access. Cette API réactive l'accès complet aux cookies tiers (sous réserve de contrôles). Il s'agit donc de l'option la plus puissante. C'est pourquoi nous vous recommandons de l'éviter si une alternative plus restrictive suffit.
Pour utiliser l'API Storage Access, vous devez remplir certaines conditions:
- L'utilisateur doit avoir déjà accédé au site de l'intégration au niveau racine. Par exemple, si vous intégrez un système de commentaires, l'utilisateur doit également accéder au site de ce système.
- L'utilisateur doit interagir avec l'intégration avant que les cookies puissent être partagés. Il est donc possible que vous ne puissiez pas charger l'intégralité du contenu intégré avant l'interaction de l'utilisateur.
- L'utilisateur peut être invité à approuver le partage des cookies via un pop-up du navigateur, en particulier lors de la première instance et de façon périodique par la suite.
- Le site d'intégration peut également avoir besoin de définir des attributs de bac à sable supplémentaires.
Ces restrictions garantissent que l'action puissante de réactivation des cookies tiers n'est effectuée que lorsque l'utilisateur et le site s'y attendent. Toutefois, dans certains cas, les actions de l'utilisateur peuvent être ignorées. Par exemple, si l'utilisateur a récemment approuvé l'accès, il n'est peut-être pas nécessaire de le relancer pendant un certain temps (tel que défini par le navigateur).
Un autre cas où l'utilisateur s'attend probablement à ce que cela se produise est celui des sites associés. Par exemple, certaines organisations utilisent un certain nombre d'origines différentes, qui sont considérées comme intersites par le navigateur. L'utilisation des cookies entre elles est donc traitée comme des tiers. Il peut s'agir, par exemple, de sites spécifiques à un pays (example.com et example.co.uk) ou de sites Web spécifiques à une marque (example.car et example.house).
Dans ce cas, si vous disposez d'un petit nombre de sites Web associés, vous pouvez utiliser les ensembles de sites Web associés. Les sites sont envoyés à Chrome pour qu'il sache qu'ils sont associés. Cela permet d'accéder à l'API Storage Access de manière plus conviviale, avec moins d'invites à l'utilisateur.
Pour les sites Web sans rapport qui sont en réalité des tiers et pour lesquels un accès complet aux cookies tiers est requis, car les API alternatives ne sont pas suffisantes, l'utilisation de l'API Storage Access est soumise à des exigences et des invites complètes.
Comparaison des différentes API
Chacune des solutions présente des caractéristiques et des limites légèrement différentes, ce qui les rend plus adaptées à certains cas d'utilisation. Le tableau suivant récapitule les principales différences:
| CHIPS | Stockage partitionné | FedCM | API Storage Access avec des ensembles de sites Web associés | API Storage Access | |
|---|---|---|---|---|---|
| L'utilisateur n'a pas besoin d'avoir déjà accédé à la partie intégrée en tant que site racine. | |||||
| Ne nécessite pas d'invite à l'utilisateur pour approuver l'accès | |||||
| L'utilisateur n'a pas besoin d'interagir avec l'intégration. | (Peut également être vrai pour les sites intégrés avec accès de niveau supérieur.) |
||||
| Effort d'implémentation | Très faible | Faible | Élevée | Moyenne | Moyenne |
| Peut être utilisé pour partager des cookies entre plusieurs sites/origines de premier niveau | (Proposition en cours de discussion.) |
||||
| Disponible sur les navigateurs autres que Chromium | (Recours à l'API Storage Access.) |
Prendre en charge les cas d'utilisation dans les différents navigateurs
La compatibilité avec les navigateurs est l'un des principaux facteurs à prendre en compte pour choisir une solution, comme indiqué dans la dernière ligne du tableau. Certaines API (CHIPS, FedCM, ensembles de sites Web associés) ne sont disponibles que sur les navigateurs Chromium. Les deux seules solutions inter-navigateurs actuellement disponibles sont les API de stockage partitionné (lorsque les cookies ne sont pas obligatoires) ou l'API Storage Access (lorsque les cookies sont obligatoires).
Toutefois, comme indiqué précédemment, l'API Storage Access comporte un certain nombre de restrictions qui peuvent affecter l'expérience utilisateur sur votre site Web. L'équipe Chrome a travaillé sur l'ajout des autres API, qui sont conçues pour répondre à des cas d'utilisation spécifiques et offrir une expérience semblable à celle proposée avec les cookies tiers. Il est donc recommandé de déterminer les meilleures options et de les considérer comme des améliorations progressives, avec un retour à l'API Storage Access pour les navigateurs non compatibles.
Étant donné que les cookies peuvent être bloqués pour diverses raisons (paramètres du navigateur, extensions, par exemple), la détection des fonctionnalités de prise en charge de l'API peut ne pas être suffisante. Il est préférable de vérifier si les cookies attendus existent et, si ce n'est pas le cas, de revenir au workflow de l'API Storage Access pour demander l'accès aux cookies tiers.
Agissez dès maintenant !
Si votre intégration tierce ne fonctionne plus sans cookies tiers, plusieurs solutions sont disponibles pour atténuer l'impact potentiel, comme détaillé dans cette présentation. C'est maintenant le moment d'auditer votre service pour détecter les cookies tiers.
Si vous rencontrez des problèmes avec vos éléments intégrés maintenant que Chrome teste la suppression des cookies tiers, plusieurs options à court terme sont disponibles pour vous aider à migrer vers des alternatives décrites dans cet article. Pour en savoir plus, consultez la documentation sur la préservation des expériences utilisateur critiques.
Si vous avez des questions concernant les cas d'utilisation des composants intégrés tiers non abordés dans ce guide, vous pouvez signaler un nouveau problème à l'aide de la balise "abandon des cookies tiers" dans notre dépôt d'assistance pour les développeurs.