 Salut à tous, je m'appelle Maud et aujourd'hui on va parler cookies. Bon, vous êtes sûrement déjà au courant. Plusieurs navigateurs bloquent les cookies tiers, ce qu'on appelle les sortes pour les cookies, et Chrome a annoncé qu'il allait les éliminer progressivement, c'est-à-dire au fur et à mesure que des alternatives viables sont mises en place. Pourquoi ? Parce que ces cookies peuvent être utilisées pour traquer les utilisateurs et leurs mouvements sur le web. Qu'est-ce que cette transition veut dire pour vous et pour vos cookies ? Alors, pour répondre à cette question, posez-vous d'abord cette autre question. Est-ce que votre cookie est utilisée sur plusieurs sites ? Premier cas, la réponse est non. Par exemple, si vous définissez un cookie pour gérer les sessions ou autres sur votre site et qu'il n'est jamais utilisé dans un iFrame sur un autre site, dans ce cas, ce cookie est toujours utilisé dans un contexte first-party ou interne en français. Et dans ce cas, c'est logique. Vous n'aurez pas besoin de faire de changements considérables pour vous préparer à la disparition des cookies tiers, telles qu'on les connaît. Mais cela dit, il est quand même conseillé de suivre quelques bonnes pratiques pour votre cookie interne, donc d'un côté, des bonnes pratiques de sécurité, mais aussi des bonnes pratiques de déclaration de votre cookie explicitement comme un cookie interne. Quoi ? Parce que l'idée, c'est que votre définition ne laisse pas d'ambiguïté sur la nature et le comportement de votre cookie, pour que les navigateurs, qui sont en train d'éliminer progressivement les cookies tiers, laissent votre cookie tranquille, en quelque sorte. On va regarder plus près à ces bonnes pratiques, ce qu'on appelle la recette de base pour un bon cookie interne, pour un bon cookie first-party. Alors, voilà la recette. Vous pouvez l'ajuster pour l'adapter à vos besoins, mais c'est un bon point de départ. Là, comme ça, c'est un peu abstrait, donc on va décortiquer cette recette. Tout ce que vous voyez ici, ce sont des attributs à pas host. Host, c'est un prefix. Et un prefix pour un cookie, ça fonctionne un peu comme une interface, dans le sens où ça rend certains attributs obligatoires, ça en interdit d'autres, alors ça contraint la valeur qu'ils peuvent faire. En bref, ça nous aide à respecter certaines règles. Concrètement, avec host, l'attribut secure est obligatoire. L'attribut pass doit aussi être présent et avoir la valeur de slash. Et l'attribut domaine, ici en rouge, est absent, doit être absent. Alors, pourquoi les règles imposées par host sont en général de bonnes pratiques ? D'abord, secure aide à protéger ce cookie contre le vol sur un réseau qui n'est pas sécurisé. Avec secure, le cookie est envoyé au serveur seulement dans des requêtes qui sont encryptées, donc HTTPS. Attention, cela dit, ce n'est pas une protection ultime, donc pour rappel, les cookies ne doivent pas contenir d'informations sensibles. Ensuite, pass et domaines définissent en fait sur quels URL les cookies vont être envoyées. Et ici, avec notre configuration, pass slash et pas de domaines, ce cookie, s'il est défini sur example.com, il sera envoyé dans toutes les requêtes faites à example.com et les URL d'exemple.com, mais dans aucune autre requête. Donc, pas dans les requêtes faites à autreexemple.com, et pas non plus dans les requêtes faites vers un sous-domaine, par exemple image.exemple.com. Donc, en fait, ça, ça revient à attacher votre cookie à votre origine uniquement, à limiter sa portée en quelque sorte, comme beaucoup d'API Web qui sont limités à l'origine d'un site, finalement. Si jamais vous avez besoin d'envoyer votre cookie sur des sous-domains, vous pouvez modifier cette recette. On l'a dit, c'est la recette de base, mais vous pouvez l'adapter selon vos besoins. Ensuite, on a HTTP-ANY. HTTP-ANY rend ce cookie inaccessible via JavaScript, et ça, ça aide à protéger le cookie, par exemple, au cas des scripts tiers mal intentionnés sur votre site en train de voler le cookie pour hijacker, donc voler une session. Ingression suivant, MaxH. Donc, c'est une bonne idée de spécifier un age maximum, une date d'expiration pour votre cookie. Pourquoi ? Parce qu'un cookie qui n'a pas de date d'expiration explicit va expirer quand la session du navigateur va se terminer. Mais les sessions dans un navigateur, elles peuvent durer longtemps. Beaucoup de gens laissent leur navigateur ouvert pendant des jours ou des semaines, ou alors le navigateur a un mécanisme qui restore les cookies. En bref, comme on ne veut pas avoir de vieux cookies qui traînent éternellement, on va configurer un MaxH. Ici, on a configuré 90 jours en seconde, ce qui est raisonnable comme défaut dans certains cas, par exemple si vous voulez mettre en place des préférences de thème. Mais selon votre cas, vous voudrez peut-être changer cette valeur. Un cookie de session, par exemple, il devrait avoir un MaxH bien inférieur à ça. Ici, on a choisi une journée, donc 24 heures en seconde. Enfin, on a SameSiteLax. Alors avec SameSiteLax, votre cookie est envoyé seulement avec un texte qui correspond au site que l'utilisateur visite. Y compris pour les navigations, et ça, ça peut être pratique, par exemple, si vous envoyez un lien à quelqu'un et que la personne doit être logée pour voir le contenu. Avec ça, votre cookie ne sera pas envoyé dans des contextes tiers ou à d'autres sites que le vôtre. L'année dernière, en 2020 SameSiteLax est devenu le défaut dans certains navigateurs comme Chrome. Mais c'est une bonne pratique de quand même le spécifier. Pourquoi ? Parce que comme ça, vous définissez le comportement que vous voulez pour votre cookie et vous n'êtes pas attributaires de ce que les navigateurs choisissent de faire par défaut et vous n'êtes pas non plus attributaires des différences dans le rythme d'adoption des mêmes défauts entre les navigateurs. Voilà. Pour finir cette recette, une petite variation. SameSiteLax couvre de nombreux cas, mais parfois vous aurez besoin de quelque chose de plus strict. Par exemple, pour que votre cookie soit envoyé que si l'utilisateur est vraiment déjà sur votre site et pas dans les requêtes de navigation d'utilisateur qui arrive sur votre site comme c'est le cas pour SameSiteLax. Dans ce cas, ce qu'il vous faut c'est SameSiteStrict et avec ça vous pouvez utiliser par exemple ce cookie comme un token pour des permissions d'écriture et le valider quand un utilisateur soumet un formulaire. Et voilà. Sur cette variation on termine la recette d'un bon cookie interne, un bon first-pollé cookie. On a vu les bonnes pratiques à suivre quand votre cookie n'est pas utilisé dans des contextes tiers. La première chose à faire que vous avez déjà sûrement remarqué et dû faire en 2020 si vous avez des cookies tiers c'est de configurer SameSiteNone. Avec ça, le navigateur sait qu'il n'y a pas de restriction et qu'il peut envoyer des cookies à n'importe quel site. Notez quand même que avec SameSiteNone l'attribut secure est quand même requis. Mais attention, au long terme SameSiteNone ne suffira pas. Ce qu'on a dit, les cookies tiers aujourd'hui sont en train d'être éliminés progressivement. Mais bien sûr les cookies tiers aujourd'hui ont de nombreux usages donc intégration de cartes ou de widgets SSO, publicité, etc. Ces fonctionnalités doivent être préservées. On ne peut pas juste bloquer ces cookies, il faut trouver des solutions. Et c'est là qu'on entre dans la zone d'exploration. On n'a pas encore toutes les réponses. Et Chrome et d'autres navigateurs ont des idées de solution. Mais l'idée bien sûr c'est que ces solutions soient intégrées au web en tant plateforme et spécifique pour différents navigateurs. Donc l'idée c'est d'avoir les navigateurs mais aussi nous les développeurs des acteurs de l'industrie et des acteurs de l'écosystème du web en général qui travaillent ensemble pour trouver des solutions d'en remplacement. Des solutions qui soient viables, qui soient propres techniquement et qui ne puissent pas être abusés pour compromettre la vie privée des utilisateurs. Je ne vais pas entrer dans les détails ici parce que tous les détails sur ces explorations les différentes solutions proposées qui sont participées à cette exploration sont disponibles dans la vidéo Google Iow qui s'appelle Preparing for a more private web et dont le lien est ici sur cette slide. Donc si vous utilisez un cookie tier un sort par les cookies allez voir cette vidéo et contribuez aux explorations qui sont en cours. Et voilà, merci à tous. J'espère que ça vous a été utile. Vous entendrez encore parler de cookies cette année et à l'avenir parce que c'est une technologie importante et qui est en train de se transformer. Merci d'avoir regardé la vidéo. A bientôt.