¿Puede un proveedor de VPN ver el nombre de tu Wi-Fi? Tres filtraciones distintas
Una puerta de enlace lee paquetes, una aplicación nativa lee permisos y una página lee coordenadas. La etiqueta de Wi-Fi se sitúa en un canal diferente en cada caso.
La pregunta suena simple y tiene al menos tres respuestas. Cuál se aplica depende de quién recibe la información, y los componentes implicados no comparten un canal. Cada respuesta pertenece a una parte diferente, así que la pregunta útil es de qué parte estás preguntando.
Ordenar esos canales lleva un par de minutos. También evita toda una categoría de conclusiones equivocadas.
Tres observadores, tres canales
Una puerta de enlace que reenvía tráfico de túnel ve paquetes. Una aplicación nativa instalada en el dispositivo puede llamar a interfaces de la plataforma si la plataforma lo permite. Una página en un navegador se ejecuta dentro de lo que el navegador y el usuario han concedido. Ninguna de ellas ve lo mismo.
No son variaciones de una sola capacidad. Son mecanismos separados con permisos separados, y cada uno responde a una pregunta ligeramente distinta.
| Observer | What it receives | What it needs |
|---|---|---|
| Tunnel gateway | Forwarded IP packets, which carry no SSID field | No device permission at all |
| Installed client app | Local network details, when the platform exposes them | The specific permission and context the platform requires |
| Page using browser geolocation | Position properties such as coordinates | User consent plus the browser's own checks |
La primera fila es la que importa para una afirmación de proveedor. El nombre de la red inalámbrica no forma parte de la cabecera del paquete. Ninguna cantidad de inspección de enrutamiento lo produce, y ningún registro de tráfico reenviado lo contiene.
El caso de Android muestra el límite de los permisos
La documentación de WifiInfo de Android es un ejemplo concreto del segundo canal. Algunos detalles de Wi-Fi allí se tratan como sensibles a la ubicación, y la documentación describe resultados censurados cuando falta el acceso necesario, incluido un valor de SSID desconocido.
Ese comportamiento merece una lectura atenta. Dice que la plataforma puede retener el valor a una aplicación que carece de acceso. No dice que una aplicación de VPN lo reciba automáticamente, ni que un proveedor de VPN lo reciba por el túnel.
Una aprobación de túnel de red es una concesión estrecha. Permite que la aplicación enrute tráfico. No entrega todos los datos del dispositivo que la plataforma protege. Tratar ambas cosas como el mismo permiso es donde fallan la mayoría de estas afirmaciones.
Las coordenadas no son un nombre de red
La API de Geolocation devuelve una posición. No devuelve la lista de nombres de Wi-Fi a tu alrededor, aunque la plataforma subyacente puede usar varias señales, incluida información de red, para calcular esa posición.
Recibir una ciudad no es lo mismo que recibir un identificador. Una página que muestra tu barrio ha aprendido algo sobre dónde está el dispositivo, y no ha aprendido el SSID que lo llevó allí.
Una extensión, un asistente nativo o una aplicación con privilegios propios merecen su propia revisión. Ninguno de ellos es intercambiable con una página corriente que llama a la geolocalización, y una extensión del navegador funciona con permisos que una página no tiene.
Qué demuestra un informe o una exportación de diagnóstico
Cuando un cliente produce un paquete de diagnóstico, la pregunta útil es qué campos recogió, quién los recibe y bajo qué permiso. El transporte cifrado te dice que el paquete viajó de forma segura, no qué contiene.
Los nombres de red también se pueden reutilizar y cambiar. Una etiqueta por sí sola es una prueba débil de un lugar físico, mientras que una dirección pública es una observación distinta con una fiabilidad distinta.
Mantén las etiquetas de red reales fuera de los hilos públicos de ayuda. La pregunta que merece respuesta es más estrecha y más útil. ¿Qué componente obtuvo qué campo, mediante qué permiso y qué flujo?