Changer de serveur VPN vous déconnecte-t-il d’une boutique ?
Une nouvelle adresse de sortie ne vide pas le pot à cookies. Décidez d’abord si vous testez le chemin réseau, la session connectée ou les données stockées du site.
Changez la sortie du VPN pendant qu’une boutique est ouverte dans un autre onglet, et le panier est généralement toujours là. Ce n’est pas une panne du VPN ; c’est le navigateur qui fait exactement ce qu’on lui a dit. Un cookie est envoyé par le navigateur, et un nouveau chemin réseau ne change pas ce que le navigateur stocke. Derrière « le site me connaît encore » se cachent trois questions différentes, et la réponse dépend de celle que vous posez réellement.
Trois questions, un symptôme
Première : le site reconnaît-il un cookie stocké ? Deuxième : reconnaît-il un compte connecté, qui subsiste indépendamment de tout cookie pris isolément ? Troisième : reconnaît-il quelque chose du navigateur ou de l’appareil plutôt qu’un état stocké ? Chacune a son propre test et son propre remède.
| What you changed | What it actually tests |
|---|---|
| VPN exit address | Whether the site treats a different network origin differently |
| Cookie jar for one site | Whether a stored identifier was doing the recognition |
| Browser profile or account | Whether identity, rather than storage, links the visits |
L’essentiel de la confusion vient de changer la première et d’attendre que la seconde suive. Une adresse réseau et un stockage de navigateur sont deux systèmes distincts que la même page utilise par hasard.
Ce qu’un cookie transporte réellement
La gestion d’état HTTP, telle que spécifiée dans la RFC 6265, est volontairement simple : le serveur définit un nom et une valeur avec une portée, et le navigateur les renvoie pour les requêtes qui correspondent à cette portée. La valeur peut être un identifiant de session, une préférence ou un jeton opaque que le serveur associe à un enregistrement de panier. Rien dans le mécanisme ne mentionne l’adresse du client.
C’est ce choix de conception qui permet aux connexions et aux paniers ordinaires de survivre à un changement de réseau, et c’est aussi ce qui leur permet d’y survivre chez les traqueurs. Le même mécanisme sert les deux usages et ne les distingue pas. Le protocole ne comporte aucun champ pour l’adresse du client, donc une nouvelle sortie n’a rien à invalider. Un site qui voudrait lier un cookie à une origine réseau devrait ajouter cette logique lui-même.
Lorsqu’un site renvoie un cookie, le serveur recherche l’enregistrement vers lequel cette valeur pointe. Changer l’itinéraire emprunté par la requête ne change pas cette recherche, et c’est toute l’explication de l’observation sur le panier.
Décidez ce que votre test mesure
Avant de changer quoi que ce soit, notez l’état dont vous partez : quel profil de navigateur, quel compte, quelles données de site, quel chemin réseau. Changez ensuite exactement l’un d’entre eux et observez. Un test qui change à la fois l’adresse de sortie et le profil du navigateur ne prouve rien sur l’un ni sur l’autre.
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' https://shop.example/cart
curl -sS -c /tmp/jar.txt -b /tmp/jar.txt -o /dev/null -w '%{http_code}\n' --interface 198.51.100.44 https://shop.example/cartLes deux commandes réutilisent le même fichier de cookies, et la seconde force une adresse source locale différente là où l’hôte le permet. La réponse du panier est la même dans les deux cas, car le serveur n’a jamais vu une identité de client différente, seulement un chemin différent. Voilà le mécanisme en une paire de requêtes reproductible.
Si l’objectif est de voir si le site vous reconnaît sans état stocké, effacez les données de ce site et recommencez. S’il vous reconnaît encore, les suspects suivants sont le compte connecté, un lien que vous avez suivi ou des caractéristiques du navigateur plutôt qu’un cookie.
Effacez le bon état, pas le réseau
La suppression du stockage d’un seul site relève des contrôles propres au navigateur, et elle vous déconnectera souvent ou réinitialisera des préférences en effet secondaire. Elle ne supprime ni le compte ni les enregistrements que le service détient déjà ; ceux-ci relèvent de sa propre procédure.
Les restrictions entre sites traitent une autre partie du problème. Les navigateurs peuvent bloquer ou cloisonner un stockage que des services intégrés partageraient autrement entre sites, tandis qu’une connexion en première partie continue de fonctionner. Une connexion réussie n’est donc pas la preuve que le suivi entre sites fonctionne.
Les fenêtres privées sont un autre outil à la portée plus étroite qu’on ne l’imagine. Les sites peuvent encore déposer des cookies pendant la session, et une connexion identifie encore le compte. C’est la fin de la session privée qui écarte l’état temporaire, ce qui suppose de fermer toutes les fenêtres privées et non un seul onglet.
Enfin, traitez l’identification par empreinte comme une possibilité et non comme la première explication. Les caractéristiques de l’appareil et du navigateur peuvent relier des visites sans aucun cookie stocké, et effacer le stockage ne les touchera pas. Vérifiez d’abord les causes simples, élargissez ensuite l’enquête, et notez quel état vous avez modifié pour que la comparaison suivante ait un sens.