Pour gérer vos consentements :

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

Recent Posts

IT souveraine : 6 pépites made in France

Digital workplace, formation logicielle, ITSM, IoT… Coup d’œil sur six entreprises françaises qui ont accroché…

5 heures ago

Gestion du risque IT : le top 10 des fournisseurs

Qui sont les têtes d'affiche de l'ITRM (gestion du risque IT) et comment leurs offres…

7 heures ago

Orange : qui est Christel Heydemann, la nouvelle directrice générale ?

Christel Heydemann devrait être nommée directrice générale du groupe Orange ce 28 janvier. Retour sur…

9 heures ago

ESN : Inetum reprise par Bain Capital

Le fonds qatari Mannai qui possède 99% du capital d'Inetum est entré en négociation exclusive…

11 heures ago

CircleCI étend son offre gratuite face à GitHub Actions

CircleCI a procédé à un élargissement de son offre gratuite. Comment se positionne-t-elle désormais par…

12 heures ago

Log4j : SolarWinds rattrapé par la faille

On a découvert, dans l'un des logiciels de SolarWinds, une faille susceptible de favoriser des…

14 heures ago