Les cookies sont meilleurs lorsqu'ils sont frais. Quelles sont les dernières recettes pour vous permettre de profiter de la saison d'Halloween sans cookies rassis ?
Les cookies sont meilleurs lorsqu'ils sont frais. Quelles sont les dernières recettes pour vous assurer de profiter de la saison effrayante sans cookies rassis ?
Nous nous dirigeons vers l'abandon progressif des cookies tiers sur la plate-forme Web. Il s'agit d'une étape importante dans la lutte contre le suivi intersites, mais cela fait partie d'un parcours assez long. Voyons le chemin parcouru et les surprises à venir :
En surface, les cookies fournissent un magasin de clés-valeurs simple qui est envoyé entre le navigateur et le serveur. Cela peut fournir des fonctionnalités utiles sur un site, telles que l'enregistrement d'une préférence: theme=bats ou le stockage de l'ID de session d'un utilisateur connecté.
Si ce cookie est utilisé sur le même site qui l'a défini, nous avons tendance à l'appeler "cookie propriétaire". S'il est utilisé sur un site différent de celui qui l'a défini, nous parlons de "cookie tiers". Par exemple, mon cookie theme=bats serait propriétaire si je consulte le même site qui l'a défini, mais s'il est inclus dans une iFrame ou une autre ressource intersites dans le cadre d'un autre site, il s'agirait d'un cookie tiers.
Le problème avec les cookies tiers est qu'ils peuvent activer le suivi intersites. Au lieu de définir un thème, le service partagé peut y stocker un identifiant complet. Ce même identifiant est ensuite envoyé lorsque vous naviguez sur différents sites qui incluent un cookie de services partagés, ce qui signifie qu'un service peut observer et associer votre activité sur ces sites.
Cookies propriétaires par défaut
Nous avons déjà fait des progrès dans ce domaine. Auparavant, il suffisait de définir un cookie simple: theme=pumpkins était envoyé dans tous les contextes: même site ou cross-site. La plupart des sites ne souhaitent que leurs cookies soient envoyés dans un contexte de même site. Vous pouvez contrôler cela via l'attribut SameSite du cookie. Exemple :
Set-Cookie: theme=bats; SameSite=Lax
Cela indique au navigateur de n'envoyer le cookie que si la ressource correspond au site de niveau supérieur. Toutefois, cela signifiait que le site devait spécifier quand il voulait le cookie first party. C'est un peu à l'envers en termes de sécurité, car vous devriez vraiment demander quand vous souhaitez plus de droits, et non les obtenir par défaut.
SameSite=Lax est donc la valeur par défaut. Si vous définissez simplement theme=bats, il ne sera envoyé que dans un contexte de même site.
Si vous souhaitez un cookie intersites ou tiers (peut-être que vous avez besoin que le thème s'affiche dans un widget intégré), vous devez spécifier:
Set-Cookie: theme=bats; SameSite=None; Secure
Cela indique au navigateur que vous souhaitez que le cookie soit envoyé dans n'importe quel contexte intersites, mais nous souhaitons le limiter aux connexions sécurisées.
Cookies propriétaires encore plus savoureux
Bien que la recette par défaut ait été améliorée, vous pouvez toujours l'améliorer. Voici un aperçu:
Set-Cookie: __Host-theme=bats;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Vous obtiendrez ainsi un cookie propriétaire qui ne sera limité qu'à un seul domaine, avec des connexions sécurisées, sans accès par JavaScript, qui expirera automatiquement avant de devenir obsolète et (bien sûr) qui n'est autorisé que dans les contextes SameSite.
Les cookies sont meilleurs avec CHIPS !
L'un des aspects magiques du Web est la possibilité de composer plusieurs sites ensemble. Imaginons que je souhaite créer un widget de carte permettant à d'autres sites de présenter les meilleurs circuits de cueillette de citrouilles ou les meilleurs itinéraires de distribution de bonbons. Mon service utilise un cookie pour permettre aux utilisateurs de stocker leur progression tout au long de l'itinéraire. Le problème est que le même cookie tiers sera envoyé sur le site de la citrouille que sur le site de l'Halloween. Je ne souhaite pas suivre les utilisateurs entre les sites, mais le navigateur n'utilise qu'un seul cookie jar. Je ne peux pas séparer cette utilisation.
C'est là qu'intervient la proposition Cookies Having Independent Partitioned State (CHIPS). Au lieu d'un seul cookie jar partagé, il existe un cookie jar distinct et partitionné par site de premier niveau. Les sites doivent activer cette fonctionnalité en utilisant l'attribut Partitioned dans leur cookie.
Set-Cookie: __Host-route=123;
SameSite=None;
Secure;
Path=/;
Partitioned;
Au lieu de devoir partager le pot de biscuits, chacun a le sien. Plus simple, plus sûr et plus hygiénique.
Nous venons d'envoyer l'Intent to Ship pour les cookies avec état partitionné indépendant (CHIPS) dans Chrome 109. Cela signifie qu'ils seront disponibles en version bêta en décembre, puis en version stable en janvier 2023. Si vous cherchez une résolution pour la nouvelle année pour améliorer la recette des cookies de votre site, regardez si vous pouvez commencer à ajouter des CHIPS à ces cookies intersites.
Inviter des cookies à la fête avec des ensembles propriétaires
Concernant les commentaires des développeurs, vous avez également indiqué clairement que, dans certains cas, vous partagez des services sur des sites que vous contrôlez et que vous souhaitez pouvoir utiliser des cookies sur ces sites, mais sans les envoyer dans des contextes tiers. Par exemple, vous avez peut-être pretty-pumpkins.com et pretty-pumpkins.co.uk. Vous pouvez disposer d'un système d'authentification unique basé sur les cookies qui fonctionne sur ces sites. CHIPS ne fonctionnerait pas, car je devrais simplement me connecter sur les deux sites. L'exigence est que je dispose du même cookie sur ces sites associés.
Nous travaillons sur la proposition de sets propriétaires pour essayer de rendre cela possible. Nous avons effectué un test d'origine et de nombreuses discussions avec la communauté, ce qui nous a permis de proposer la dernière version, qui vise à:
- Permettre aux organisations de définir un groupe de sites qui doivent appartenir à la même partie.
- Exploitez l'API Storage Access pour demander l'accès aux cookies intersites dans cet ensemble propriétaire.
Ces cookies sont encore en train de cuire au four, mais vous pouvez consulter le guide du développeur sur les ensembles first party lorsque vous aurez plus de choses à tester. Vous pouvez également consulter la proposition WICG/first-party-sets si vous souhaitez contribuer à la discussion.
Ne laissez pas vos cookies s'abîmer !
Notre objectif est de commencer à abandonner les cookies tiers dans Chrome à partir de la moitié de l'année 2024. Vous avez le temps de vous préparer, mais vous devez commencer à planifier dès maintenant.
- Recherchez dans votre code tous les cookies avec
SameSite=None. Voici les cookies qui devront être mis à jour. - Si vous n'utilisez aucun cookie tiers, assurez-vous que vos cookies de même site utilisent les meilleures recettes de cookies propriétaires.
- Si vous utilisez ces cookies dans un contexte intégré entièrement contenu, examinez et testez la proposition CHIPS.
- Si vous avez besoin de ces cookies sur plusieurs sites qui forment un groupe cohérent, consultez la proposition de sets propriétaires.
- Si aucune de ces options ne vous convient, vous devrez examiner les autres propositions de la Privacy Sandbox, pour lesquelles nous développons des API conçues pour des cas d'utilisation individuels qui ne reposent pas sur le suivi intersites.
Il ne s'agit que d'un bref aperçu. Nous vous tiendrons informés au fur et à mesure de nos travaux. Si vous avez des questions, des problèmes ou souhaitez partager les résultats de votre propre travail, il existe de nombreuses façons de nous contacter.
N'oubliez pas: les cookies peuvent être délicieux, mais seulement quelques-uns à la fois et surtout, n'essayez pas de voler ceux des autres !