Unha conta VPN anónima fai anónimo o teu tráfico?
O rexistro sen correo cambia un campo dun formulario. O enderezo de orixe, o token da conta e as cookies do navegador responden a tres preguntas distintas.
O rexistro sen enderezo de correo cambia un campo dun formulario. Non cambia o enderezo de orixe na rede, nin o identificador que o servizo emite internamente, nin as cookies que o teu navegador envía a cada sitio que visitas. Son tres preguntas separadas, e só a primeira ten que ver coa conta. Velaquí o que retén realmente cada capa e que decisión che corresponde a ti e non ao provedor.
Trata o anonimato como unha propiedade fronte a cada observador. Pregunta cal observador, e a resposta honesta cambia.
Unha conta pseudónima segue sendo unha conta
Un provedor pode emitir un número de conta, unha clave de dispositivo ou un token de subscrición sen pedir nunca un nome legal. Ese obxecto segue unindo sesións dentro do servizo: o mesmo token no mesmo plan, durante meses.
O que o operador pode vincular a ese token depende doutros sistemas. Existen rexistros de pagamento se pagaches por un método rastrexable, existe un enderezo de soporte se escribiches, e pode haber identificadores de dispositivo ou marcas de tempo de conexión nos rexistros operativos. Nada diso o esixe o formulario de rexistro, e nada diso o exclúe un formulario sen correo. O formulario determina que se pediu, non que existe despois.
Enviar un perfil de diagnóstico ou abrir un tícket de soporte pode engadir máis detalle do que o formulario orixinal pediu xamais.
O que o extremo do túnel ve necesariamente
O extremo termina a túa conexión, así que sabe que enderezo de orixe asignou a túa rede de acceso para esa sesión e cando comezou. Tamén sabe a que clave interna ou conta corresponde esa conexión, porque esa correspondencia é a que decide onde enviar o tráfico.
A documentación de WireGuard é inusualmente directa aquí: a identidade do par é a clave pública, non un trazo oculto.
O que sae do extremo cara a un destino é outra conexión. Se o enderezo de saída se comparte con outros usuarios, o sitio do outro lado ve un enderezo común en lugar do teu. Esa separación é real, e é tamén a única separación que ofrece unha saída compartida. Non oculta a túa sesión ao operador nin te funde coa multitude para quen poida observar ambos extremos, que é exactamente o problema de correlación ao que RFC 6973 dedica toda a súa extensión.
O que o destino segue recibindo
Un sitio web ve o enderezo de saída, a petición e todo o que o teu cliente entrega voluntariamente. As cookies, unha sesión xa iniciada, unha pegada de navegador e unha conta gardada sobreviven a unha conexión VPN sen cambios, porque o túnel as transporta en lugar de substituílas.
Iniciar sesión nunha conta persoal identifícate ante ese sitio, independentemente da etiqueta que leve a conta VPN.
A resolución de nomes merece a súa propia liña. Se as consultas van a un resolutor que opera o provedor, o provedor ve os nomes que pides. Se van a un resolutor público, ese resolutor veos, e tamén calquera na ruta que poida observar DNS sen cifrar. En calquera caso, que resolutor se usa é unha decisión de privacidade que o formulario de rexistro non tomou por ti.
Onde ocorre realmente a correlación
A análise de tráfico non necesita o contido das páxinas. O momento das conexións, o volume transferido e o patrón de que extremo fala con que destino poden aliñar unha conexión de orixe cunha de saída cando se observan ambos lados. Por iso unha saída compartida protéxete dun observador e non de dous que cooperen.
O cifrado de transporte cambia o que se pode ler, non o que se pode enlazar.
Tres preguntas que substitúen o eslogan
Cada unha ten un responsable distinto, e por iso unha promesa feita nunha capa non pode cubrir outra. As filas de abaixo son todo o argumento en forma compacta.
| 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 |
Só a fila central ten que ver coa conta, e só en parte. As filas de arriba e de abaixo décidenas o enrutamento, a retención e o teu propio navegador.
Le o inventario en lugar da etiqueta
Un provedor que publica un inventario de datos, unha xanela de retención e un fluxo de traballo de identidade díxoche algo comprobable. Un provedor que di anónimo díxoche unha palabra. Busca que se recolle no rexistro, que sobrevive cando remata a sesión e baixo que procedemento se entregan datos a un terceiro.
Se faltan esas tres cousas, a etiqueta non é proba de nada.
Comeza polo observador que de verdade che importa, e despois segue unha fila da táboa: que enderezo ve, que identificador garda, canto tempo se conserva. Arranxa a fila que falla en lugar de renomear a conta. Ese é o único paso aquí que cambia un resultado.