Un compte VPN anonyme rend-il votre trafic anonyme ?
Une inscription sans e-mail modifie un champ d'un formulaire. L'adresse source, le jeton du compte et les cookies du navigateur répondent à trois questions différentes.
Une inscription sans adresse e-mail modifie un champ d'un formulaire. Elle ne change ni l'adresse source sur le réseau, ni l'identifiant que le service émet en interne, ni les cookies que votre navigateur envoie à chaque site que vous visitez. Ce sont trois questions distinctes, et seule la première concerne le compte. Voici ce que chaque couche retient réellement, et quelle décision vous revient plutôt qu'au fournisseur.
Traitez l'anonymat comme une propriété propre à chaque observateur. Demandez lequel, et la réponse honnête change.
Un compte pseudonyme reste un compte
Un fournisseur peut émettre un numéro de compte, une clé d'appareil ou un jeton d'abonnement sans jamais demander de nom légal. Cet objet relie malgré tout les sessions à l'intérieur du service : le même jeton sur la même offre, pendant des mois.
Ce que l'opérateur peut rattacher à ce jeton dépend d'autres systèmes. Des traces de paiement existent si vous avez payé par un moyen traçable, une adresse de support existe si vous avez écrit, et des identifiants d'appareil ou des horodatages de connexion peuvent figurer dans les journaux d'exploitation. Rien de tout cela n'est exigé par le formulaire d'inscription, et rien n'en est exclu par un formulaire sans e-mail. Le formulaire détermine ce qui a été demandé, pas ce qui existe ensuite.
Envoyer un profil de diagnostic ou ouvrir un ticket de support peut ajouter plus de détails que le formulaire initial n'en a jamais demandé.
Ce que le point de sortie du tunnel voit forcément
Le point de sortie termine votre connexion : il connaît donc l'adresse source que votre réseau d'accès a attribuée pour cette session et le moment où elle a commencé. Il sait aussi à quelle clé interne ou à quel compte cette connexion correspond, car c'est cette correspondance qui décide où envoyer le trafic.
La documentation de WireGuard est ici d'une franchise inhabituelle : l'identité du pair est la clé publique, pas un trait caché.
Ce qui quitte le point de sortie vers une destination est une autre connexion. Si l'adresse de sortie est partagée avec d'autres utilisateurs, le site d'en face voit une adresse commune au lieu de la vôtre. Cette séparation est réelle, et c'est aussi la seule qu'une sortie partagée offre. Elle ne cache pas votre session à l'opérateur et ne vous fond pas dans la foule pour qui peut observer les deux extrémités, ce qui est exactement le problème de corrélation auquel RFC 6973 consacre toute sa longueur.
Ce que la destination reçoit encore
Un site web voit l'adresse de sortie, la requête et tout ce que votre client livre volontairement. Les cookies, une session déjà ouverte, une empreinte de navigateur et un compte enregistré survivent tous à une connexion VPN sans modification, parce que le tunnel les transporte au lieu de les remplacer.
Se connecter à un compte personnel vous identifie auprès de ce site, quel que soit le libellé que porte le compte VPN.
La résolution de noms mérite sa propre ligne. Si les requêtes vont à un résolveur exploité par l'opérateur, l'opérateur voit les noms que vous demandez. Si elles vont à un résolveur public, ce résolveur les voit, tout comme quiconque sur le chemin peut observer un DNS en clair. Dans tous les cas, le choix du résolveur est une décision de confidentialité que le formulaire d'inscription n'a pas prise pour vous.
Où la corrélation se produit vraiment
L'analyse de trafic n'a pas besoin du contenu des pages. Le minutage des connexions, le volume transféré et la répartition de quel point de sortie parle à quelle destination peuvent aligner une connexion source avec une connexion de sortie lorsque les deux côtés sont observés. Une sortie partagée vous protège donc d'un seul observateur, pas de deux qui coopèrent.
Le chiffrement du transport change ce qui est lisible, pas ce qui est corrélable.
Trois questions à la place du slogan
Chacune a un responsable différent, et c'est pourquoi une promesse faite à une couche ne peut pas couvrir une autre. Les lignes ci-dessous sont tout l'argument sous forme compacte.
| Observer | What it can hold | What actually changes it |
|---|---|---|
| Your access network | The connection to the VPN endpoint, with volume and timing | Nothing on the account form |
| The VPN operator | Source address, session times, key-to-account mapping, names if it runs the resolver | Retention policy, payment method, whether you contact support |
| The destination site | Exit address, cookies, logged-in identity, request content | Browser hygiene, logging out, separate profiles |
| An observer at both ends | Correlated timing and volume across the two connections | Padding, cover traffic, a different exit at a different time |
Seule la ligne du milieu concerne le compte, et seulement en partie. Les lignes au-dessus et en dessous sont décidées par le routage, par la conservation et par votre propre navigateur.
Lisez l'inventaire, pas l'étiquette
Un fournisseur qui publie un inventaire des données, une durée de conservation et un processus d'identité vous a dit quelque chose de vérifiable. Un fournisseur qui dit anonyme vous a dit un mot. Cherchez ce qui est collecté à l'inscription, ce qui subsiste après la fin de la session, et selon quelle procédure les données sont transmises à un tiers.
Si ces trois éléments manquent, l'étiquette ne prouve rien.
Partez de l'observateur qui vous importe vraiment, puis suivez une ligne du tableau : quelle adresse il voit, quel identifiant il détient, combien de temps il est conservé. Corrigez la ligne qui échoue plutôt que de renommer le compte. C'est la seule étape ici qui change un résultat.