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 de l'utilisateur avec les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.
Sur cette page, vous trouverez 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, ou "embeds", incluent les contenus tiers (comme les vidéos, les cartes), les composants interactifs (comme le chat, les systèmes de commentaires ou les services 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 pour les développeurs qui créent des services intégrés.
Si votre site s'appuie sur une intégration qui utilise des cookies tiers, veillez à auditer et à tester vos parcours d'intégration, et contactez les fournisseurs d'intégration si vous constatez des erreurs.
Auditer et tester vos parcours utilisateur liés à l'intégration
Le meilleur moyen de déterminer si vos intégrations sont affectées par les cookies tiers consiste à tester vos flux utilisateur d'intégration 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 ne les voyez-vous pas en tant qu'abonné Premium ?
- Connexion:les connexions, y compris les connexions SSO, fonctionnent-elles pour les intégrations qui les prennent en charge ? 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 ont traditionnellement reposé sur des cookies tiers. Le tableau suivant présente certains workflows courants et les API recommandées à utiliser à titre de résumé général. 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:
Le diagramme de flux 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 toutes les deux la même solution de widget de chat. En fait, il est préférable de ne pas autoriser le partage de cookies dans de nombreux cas.
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 sur lequel il est intégré. Ces informations sont-elles partagées par des instances de votre intégration sur d'autres sites ?
Si les cookies ne doivent pas être partagés, la partition des cookies à l'aide de CHIPS est l'option la plus simple. Cette API associe les cookies tiers au site de premier niveau, plutôt que 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 ne nécessite que l'ajout d'un attribut Partitioned supplémentaire aux cookies existants. Cela permet aux services intégrés de continuer à enregistrer l'état, mais supprime l'espace de stockage intersites partagé qui permettrait le suivi intersites.
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 intégrations 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 le 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 de 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. Vous pouvez activer cette fonctionnalité 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à consulté le 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. Par conséquent, il est 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 à l'aide d'un pop-up de navigateur, en particulier lors de la première instance et périodiquement 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 scénario dans lequel 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. Par exemple, les marques qui disposent de sites spécifiques à un pays (comme example.com et example.co.uk) ou de sites Web spécifiques à la marque (comme 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 que Chrome 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 sera 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.) |
Prise en charge des cas d'utilisation dans les différents navigateurs
La compatibilité avec les navigateurs est l'un des principaux facteurs à prendre en compte lors du choix d'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 à l'heure actuelle 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 par les cookies tiers. Il est donc recommandé d'identifier les meilleures options et de les traiter 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 (par exemple, paramètres du navigateur, extensions), 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 l'utilisation de cookies tiers, plusieurs solutions sont disponibles pour atténuer l'impact potentiel, comme détaillé dans cette présentation. C'est 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.