Pot un proveïdor de VPN veure el nom de la teva Wi-Fi? Tres fuites diferents
Una passarel·la llegeix paquets, una aplicació nativa llegeix permisos i una pàgina llegeix coordenades. L’etiqueta de Wi-Fi se situa en un canal diferent en cada cas.
La pregunta sembla simple i té almenys tres respostes. Quina s’aplica depèn de qui rep la informació, i els components implicats no comparteixen cap canal. Cada resposta pertany a una part diferent, així que la pregunta útil és de quina part estàs preguntant.
Ordenar aquests canals requereix un parell de minuts. També evita tota una categoria de conclusions errònies.
Tres observadors, tres canals
Una passarel·la que reenvia trànsit de túnel veu paquets. Una aplicació nativa instal·lada al dispositiu pot cridar interfícies de la plataforma si la plataforma ho permet. Una pàgina al navegador s’executa dins del que el navegador i l’usuari han concedit. Cap d’elles no veu el mateix.
No són variacions d’una sola capacitat. Són mecanismes separats amb permisos separats, i cadascun respon una pregunta lleugerament diferent.
| 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 és la que importa per a una afirmació de proveïdor. El nom de la xarxa sense fil no forma part de la capçalera del paquet. Cap quantitat d’inspecció d’encaminament no el produeix, i cap registre de trànsit reenviat no el conté.
El cas d’Android mostra el límit dels permisos
La documentació de WifiInfo d’Android és un exemple concret del segon canal. Alguns detalls de Wi-Fi allà es tracten com a sensibles a la ubicació, i la documentació descriu resultats redactats quan falta l’accés necessari, incloent-hi un valor SSID desconegut.
Aquest comportament val la pena llegir-lo amb atenció. Diu que la plataforma pot retenir el valor a una aplicació que no té accés. No diu que una aplicació VPN el rebi automàticament, ni diu que un proveïdor de VPN el rebi pel túnel.
Una aprovació de túnel de xarxa és una concessió estreta. Permet que l’aplicació encamini trànsit. No lliura tots els fets del dispositiu que la plataforma protegeix. Tractar les dues coses com el mateix permís és on fallen la majoria d’aquestes afirmacions.
Les coordenades no són un nom de xarxa
L’API de Geolocation retorna una posició. No retorna la llista de noms de Wi-Fi del teu voltant, tot i que la plataforma de sota pot fer servir diversos senyals, incloent-hi informació de xarxa, per calcular aquesta posició.
Rebre una ciutat no és el mateix que rebre un identificador. Una pàgina que mostra el teu barri ha après alguna cosa sobre on és el dispositiu, i no ha après l’SSID que el va portar allà.
Una extensió, un ajudant natiu o una aplicació amb privilegis propis mereixen la seva pròpia revisió. Cap d’ells no és intercanviable amb una pàgina corrent que crida geolocalització, i una extensió del navegador funciona amb permisos que una pàgina no té.
Què demostra un informe o una exportació de diagnòstic
Quan un client produeix un paquet de diagnòstic, la pregunta útil és quins camps ha recollit, qui els rep i sota quin permís. El transport xifrat et diu que el paquet ha viatjat de manera segura, no què conté.
Els noms de xarxa també es poden reutilitzar i canviar. Una etiqueta per si sola és una prova feble d’un lloc físic, mentre que una adreça pública és una observació diferent amb una fiabilitat diferent.
Mantén les etiquetes de xarxa reals fora dels fils públics d’ajuda. La pregunta que val la pena respondre és més estreta i més útil. Quin component ha obtingut quin camp, amb quin permís i per quin flux?