Par Álex Masip, Head of Data chez Labelium Espagne

Parmi les changements que les principaux navigateurs tels que Safari et Firefox apportent à la gestion des cookies tiers, Chrome en prévoit également d’importants dans sa version 80, prévue pour février 2020.

Dans cet article, nous expliquons le contexte, les changements apportés par Chrome et leurs implications. Nous verrons également comment tester si notre site est prêt à les gérer correctement.

Cookies de première et tierce partie

En général, nous comprenons par données de première partie les données qui nous appartiennent directement, sans intervention de tiers. Dans le contexte des cookies, les cookies de première partie sont ceux qui sont directement gérés à partir du domaine principal du site. C’est-à-dire tous les cookies dans lesquels le domaine principal est le même que le site sur lequel nous nous trouvons.

Au contraire des cookies tiers qui sont ceux qui appartiennent à d’autres domaines principaux du site sur lequel nous nous trouvons. 

Cambios en la ley de cookies en Chrome

Les cookies tiers sont utiles pour maintenir une cohérence globale dans la navigation des utilisateurs. Par exemple, si nous mettons une vidéo de YouTube sur notre site, le fait que l’utilisateur soit connecté sur YouTube, qu’il ait vu la vidéo avant ou qu’il l’ait marquée pour la regarder par après, est géré par un cookie tiers. Sans ce cookie, l’utilisateur doit quitter notre site et aller sur YouTube pour s’y connecter à nouveau.

Le problème est le suivant : il existe de nombreuses utilisations pas si anodines de ce type de cookie. La plus connue est son emploi pour suivre l’utilisateur tout au long de sa navigation à des fins de profiling et de publicité en ligne. Mais il existe aussi des abus de sécurité potentiels beaucoup plus graves.

La gestion des cookies tiers sur les principaux navigateurs

Les modifications législatives telles que le RGPD et la sensibilisation du grand public à la gestion de la confidentialité en ligne ont entraîné des changements majeurs dans la manière dont les principaux navigateurs tels que Safari ou Firefox gèrent ces cookies tiers.

Safari a lancé cette croisade contre le tracking en ligne en 2017 avec son ITP (Intelligent Tracking Prevention) qui empêchait déjà l’utilisation de cookies tiers. L’ITP a évolué et nous en sommes déjà au 2.3, avec lequel Apple se protège également contre un certain type d’utilisation de cookies de première partie et l’utilisation d’autres tactiques telles que le local storage. 

Firefox a opté pour une tactique similaire, mais moins agressive.  Au lieu de bloquer tous les cookies par défaut, il utilise une méthode de liste noire. Il vérifie si le cookie appartient à un domaine identifié dans la liste des domaines faisant de la publicité et du tracking (liste de disconnect.me).

Jusqu’à présent, Chrome a opté pour des tactiques beaucoup moins agressives. Il ne bloque pas par défaut les cookies de première ou de tierce partie, même s’il offre cette option à ses utilisateurs par le biais de sa gestion de la confidentialité.

Le grand changement apporté par la version 80 de Chrome est que les modifications sont actives par défaut, sans que l’utilisateur n’ait à les activer explicitement.

La gestion des cookies sur Chrome 80

À partir de sa version 80, Chrome commencera à imposer l’utilisation sécurisée de l’attribut SameSite pour des applications tierces.

L’attribut SameSite n’est pas nouveau, mais il n’était pas utilisé régulièrement jusqu’à présent. L’attribut SameSite offre trois options de valeur :

 SameSite=Strict.- Utilisation purement de première partie

 SameSite=Lax.- Point intermédiaire qui permet certaines utilisations dans un contexte de tiers. L'utilisation du cookie est autorisée sur des domaines externes lorsqu'ils proviennent d'un lien direct, par exemple pour garder un utilisateur connecté.  Mais il n'autorise pas l'utilisation du cookie par d'autres méthodes comme POST.

 SameSite=None.-  Utilisation de tiers standard.

La grande différence dans cette mise à jour de Chrome est qu’il oblige à déclarer le SameSite=None comme sûr. En d’autres termes, il rejettera ceci :

Set-Cookie: promo=abc123; SameSite=None

Et il devra utiliser ceci :

Set-Cookie: promo=abc123; SameSite=None; Secure

Dans le premier cas, Chrome rejettera le cookie et s’il ne se déclare pas SameSite, il traitera le cookie comme s’il s’agissait d’un SameSite=Lax, bloquant ainsi son utilisation par une tierce partie.

Comment ce changement m’affecte-t-il ?

La gestion des cookies de Google ne doit pas nous inquiéter, mais si nous avons des fonctionnalités cross-sites avec d’autres cookies, il est important de s’assurer qu’ils répondent à la norme. Dans le cas contraire, certaines fonctionnalités cesseront de fonctionner.

Des difficultés importantes à prendre en compte :   

  • Actuellement, la valeur « None » n’est pas permise par tous les langages et bibliothèques. Dans ces cas, elle doit être directement déclarée dans le cookie header. Pour plus d’informations, vous pouvez consulter le répertoire Github suivant.
  • Certains navigateurs plus anciens sont incapables de gérer correctement l’attribut « None ». Voici la liste de navigateurs incompatibles.

Comment tester l’effet sur mon site ?

Il est fortement recommandé de vérifier dès que possible si ce changement aura un effet significatif sur nos propriétés en ligne.    

Pour tester sur les versions de Chrome 76+ :

  1. Aller sur chrome://flags et activer #same-site-by-default-cookies et #cookies-without-same-site-must-be-secure. Réinitialiser le navigateur.
  2. Débuter les tests. Il est particulièrement important de vérifier tout ce qui concerne les flux de navigation devant maintenir une connexion, les changements entre domaines et contenu cross-site. En raison de la limitation de 2 minutes de « Lax+POST », il est également recommandé de tester tout flux qui implique POST avec des retards de moins et de plus de deux minutes.  
  3. Si le site cesse de fonctionner comme il se doit :
    • a. Commencer par désactiver #cookies-without-same-site-must-be-secure. Si cela résout le problème, cela signifie que nous disposons des cookies avec la valeur SameSite=None qui ne sont pas sûrs.
    • b. Désactiver ces deux flags. Si cela ne résout pas le problème, il est nécessaire d’identifier les cookies auxquels on accède cross-site et d’appliquer les attributs SameSite et Secure.

Sources et informations supplémentaires :

Contactez-nous