Chrome 80 : Google change de recette pour les cookies

Chrome 80 vient de passer en version stable sur Windows, Mac, Linux et Android.

De nouvelles stratégies de cookies s’appliquent par défaut. On pouvait les expérimenter* depuis Chrome 76.
Elles sont fondées sur l’attribut SameSite, qui permet de contrôler le comportement des cookies.

SameSite peut prendre trois valeurs :

• Strict : le cookie n’est envoyé que si la requête provient du site web qu’on visite (contexte first-party).
  C’est l’idéal pour des fonctionnalités qui requièrent une première étape de navigation sur le site (faire un achat, changer de mot de passe…)
• Lax : même chose que pour Strict, avec une exception applicable dans le cas où la requête ne provient pas du site d’origine (contexte third-party).
  Le cookie est envoyé en cas de recours à des méthodes HTTP dites « sûres » (comme GET) et dans le cadre d’une navigation de premier niveau (changement d’URL dans la barre d’adresse).
• None : pas de restrictions

Avec Chrome 80, les cookies sans attribut SameSite sont traités comme s’ils avaient la valeur Lax. Ils ne peuvent donc par défaut être utilisés que dans un contexte first-party.

Quant aux cookies dotés de la valeur None, ils sont rejetés s’ils n’ont pas également la valeur « Secure » signifiant que la requête peut se faire en HTTP sécurisé.

Contenu mixte : une nouvelle étape

Chrome 80 marque aussi l’évolution du système par lequel les sites demandent l’autorisation d’envoyer des notifications. Pour plus de discrétion, exit les pop-up, place à une icône cliquable sur la droite de la barre d’adresse.

Google avance également sur le chantier du contenu dit « mixte ».
Ce cas se présente lorsqu’un site chargé en HTTP sécurisé fait appel à des ressources non disponibles en HTTP sécurisé.
Comme d’autres navigateurs, celui de Google bloque par défaut certaines de ces ressources.

Avec Chrome 79, une option avait fait son entrée au niveau de la barre d’adresse pour permettre de désactiver ce blocage sur « des sites spécifiques ».
En version 80, le navigateur tente de forcer le chargement des contenus audio et vidéo en HTTPS. En cas d’impossibilité, il les bloque, sauf si l’utilisateur en décide autrement.
Les images qui ne peuvent être chargées en HTTPS déclenchent quant à elles l’affichage d’un message « non sécurisé ».

Chrome 81 va plus loin en bloquant ces images par défaut.

* À noter une fonctionnalité expérimentale introduite dans Chrome 80 avec le drapeau chrome://flags/#enable-heavy-ad-intervention. Elle permet de bloquer les publicités qui consomment trop de ressources.

Photo d’illustration © Tati___Tata via Visual Hunt / CC BY-NC