Pourquoi la sortie VPN et la langue du navigateur ne concordent pas

Ouvrez les outils de développement, chargez la page et lisez les en-têtes de requête avant de conclure quoi que ce soit sur le VPN. Vous trouverez généralement une ligne Accept-Language qui demande un ensemble précis de langues, et cette ligne vient des réglages de votre navigateur, pas de votre adresse de sortie. Un francophone sur une sortie à Tokyo envoie toujours du français, et un site qui répond en français répond à l’en-tête. Le tunnel ne fuit pas simplement parce que la page est arrivée dans une langue familière.

Lisez d’abord l’en-tête

Dans un navigateur de bureau, ouvrez le panneau Réseau, rechargez, cliquez sur la requête du document et regardez sous les en-têtes de requête. Depuis un terminal, vous voyez la même chose sans navigateur, et vous pouvez remplacer la valeur pour tester le comportement du site :

curl -sS -D /tmp/h1 -o /tmp/b1 https://example.com
curl -sS -D /tmp/h2 -o /tmp/b2 -H 'Accept-Language: fr,en;q=0.6' https://example.com
grep -o 'lang="[^"]*"' /tmp/b1 /tmp/b2
diff /tmp/b1 /tmp/b2 | head -40

Maintenant le corps est sur le disque, la comparaison porte donc sur la page et non sur un en-tête qui ne sera peut-être jamais envoyé. Regardez l’attribut lang de la balise html et le texte visible, car Content-Language est facultatif et beaucoup de serveurs l’omettent. Un site qui fait passer toute la page de l’anglais au français sur la même URL peut donc sembler inchangé dans une comparaison portant uniquement sur les en-têtes. Si la langue du document suit l’en-tête tandis que la sortie reste fixe, l’en-tête était l’entrée décisive et le VPN n’a rien à voir avec cette observation.

Utilisez un second profil de navigateur plutôt que le sélecteur de langue du site pour ce test. Un sélecteur écrit généralement un cookie, qui est une autre entrée, et vous finirez par mesurer le cookie au lieu de l’en-tête.

Ce que signifient les valeurs q, et ce qu’elles ne signifient pas

La RFC 9110, section 12.5.4, définit Accept-Language comme une liste de langues naturelles préférées pour la réponse. Chaque entrée peut porter un poids de 0 à 1, une plage sans poids a un poids de 1, et un poids de 0 marque une langue comme inacceptable. C’est un ordre de préférence, rien de plus.

La valeur n’est pas un rapport de localisation, ni un score de confiance, ni une identité. Un serveur est libre de l’ignorer, de servir la seule traduction dont il dispose ou de laisser gagner une redirection par pays. La négociation de contenu est le choix du serveur, et l’en-tête est une entrée de ce choix, pas un ordre.

C’est ce que les gens manquent lorsqu’ils traitent une page localisée comme un test de localisation. L’en-tête indique quelles langues la personne préfère lire, et une préférence peut voyager n’importe où.

Trois entrées décident de la langue que vous obtenez réellement

Isolez-les une par une, car de l’extérieur vous ne voyez pas laquelle l’a emporté :

• L’en-tête. Testez avec un second profil configuré pour une autre liste de langues et observez si la page change, tout le reste restant constant.
• Un choix enregistré. Testez dans une fenêtre privée sans cookie, ou effacez le stockage du site. Les réglages du compte et les entrées de localStorage peuvent figer une langue pendant des mois.
• Une URL ou une redirection. Testez en demandant le chemin de langue explicite, par exemple /fr/, et en observant les codes de statut d’une redirection fondée sur l’adresse source.

Exécutez les trois tests dans cet ordre et notez lequel a déplacé le résultat. Un seul chargement de page qui change de langue après l’activation du VPN est une preuve faible, car une redirection comme un cookie en cache peuvent produire cette impression.

Ce que le VPN change et ce qu’il ne change pas

Le tunnel change l’adresse source que voit un serveur, et avec elle tout ce que le serveur déduit de la géolocalisation par IP. Il ne réécrit pas les préférences de langue du navigateur, n’efface pas un réglage enregistré et ne change pas l’URL que vous avez saisie. Ces entrées restent exactement là où elles étaient, si bien qu’une page peut conserver son ancienne langue une fois la sortie déplacée.

La géolocalisation ajoute son propre bruit. Les bases d’adresses se contredisent, et une sortie enregistrée dans un pays peut être associée à un autre, ce qui fait paraître une redirection par pays erronée pour des raisons sans rapport avec votre navigateur.

Une vérification rapide les sépare : demandez la page à nouveau, notez l’adresse que vous présentez, puis comparez la langue de la réponse à votre liste d’en-têtes. Si la langue correspond à votre liste plutôt qu’au pays de sortie, l’en-tête était l’entrée décisive et il n’y a rien à corriger dans le tunnel.

Ce qu’une page localisée prouve et ce qu’elle ne prouve pas

Il y a ici un vrai point de confidentialité, et il est plus petit que celui que les gens mettent généralement en avant. Une liste complète de préférences linguistiques est une entrée d’empreinte et peut révéler quelque chose sur qui vous êtes ou ce que vous lisez. C’est une divulgation réelle de préférence, et ce n’est pas la même chose que prouver que le trafic a échappé au tunnel.

Une page localisée n’est pas un indicateur de fuite. Si vous voulez vraiment tester une fuite, vérifiez l’adresse de sortie que voit le site, le chemin du résolveur utilisé pour les recherches de noms et les candidats qu’expose une pile WebRTC. Ces tests répondent à la question à laquelle la langue de la page ne peut pas répondre.

La prochaine fois qu’un site semblera connaître votre pays, ouvrez d’abord les en-têtes de requête. Si la langue de la réponse correspond à la liste de votre navigateur, rien n’a fuité, et la couche à examiner est celle qui est devant vous.