Pode un provedor de VPN ver o nome da túa Wi-Fi? Tres fugas diferentes
Unha pasarela le paquetes, unha aplicación nativa le permisos e unha páxina le coordenadas. A etiqueta Wi-Fi sitúase nun canal diferente en cada caso.
A pregunta parece simple e ten polo menos tres respostas. Cal se aplica depende de quen recibe a información, e os compoñentes implicados non comparten un canal. Cada resposta pertence a unha parte diferente, así que a pregunta útil é de que parte estás preguntando.
Ordenar eses canais leva un par de minutos. Tamén evita toda unha categoría de conclusións erróneas.
Tres observadores, tres canais
Unha pasarela que reenvía tráfico de túnel ve paquetes. Unha aplicación nativa instalada no dispositivo pode chamar interfaces da plataforma se a plataforma o permite. Unha páxina nun navegador execútase dentro do que o navegador e o usuario concederon. Ningunha delas ve o mesmo.
Non son variacións dunha soa capacidade. Son mecanismos separados con permisos separados, e cada un responde a unha pregunta lixeiramente 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 |
A primeira fila é a que importa para unha afirmación de provedor. O nome da rede sen fíos non forma parte da cabeceira do paquete. Ningunha cantidade de inspección de enrutamento o produce, e ningún rexistro de tráfico reenviado o contén.
O caso de Android mostra o límite dos permisos
A documentación de WifiInfo de Android é un exemplo concreto do segundo canal. Algúns detalles de Wi-Fi alí trátanse como sensibles á localización, e a documentación describe resultados censurados cando falta o acceso necesario, incluído un valor de SSID descoñecido.
Ese comportamento merece unha lectura atenta. Di que a plataforma pode reter o valor a unha aplicación que carece de acceso. Non di que unha aplicación de VPN o reciba automaticamente, nin que un provedor de VPN o reciba polo túnel.
Unha aprobación de túnel de rede é unha concesión estreita. Permite que a aplicación enrute tráfico. Non entrega todos os datos do dispositivo que a plataforma protexe. Tratar ambas as cousas como o mesmo permiso é onde fallan a maioría destas afirmacións.
As coordenadas non son un nome de rede
A API de Geolocation devolve unha posición. Non devolve a lista de nomes de Wi-Fi ao teu redor, aínda que a plataforma subxacente pode usar varias sinais, incluída información de rede, para calcular esa posición.
Recibir unha cidade non é o mesmo que recibir un identificador. Unha páxina que mostra o teu barrio aprendeu algo sobre onde está o dispositivo, e non aprendeu o SSID que o levou alí.
Unha extensión, un asistente nativo ou unha aplicación con privilexios propios merecen a súa propia revisión. Ningún deles é intercambiable cunha páxina corrente que chama á xeolocalización, e unha extensión do navegador funciona con permisos que unha páxina non ten.
Que demostra un informe ou unha exportación de diagnóstico
Cando un cliente produce un paquete de diagnóstico, a pregunta útil é que campos recolleu, quen os recibe e baixo que permiso. O transporte cifrado diche que o paquete viaxou de forma segura, non que contén.
Os nomes de rede tamén se poden reutilizar e cambiar. Unha etiqueta por si soa é unha proba feble dun lugar físico, mentres que un enderezo público é unha observación distinta cunha fiabilidade distinta.
Mantén as etiquetas de rede reais fóra dos fíos públicos de axuda. A pregunta que merece resposta é máis estreita e máis útil. Que compoñente obtivo que campo, mediante que permiso e que fluxo?