Kan en VPN-leverantör se ditt Wi-Fi-namn? Tre olika läckor
En gateway läser paket, en inbyggd app läser behörigheter och en sida läser koordinater. Wi-Fi-etiketten sitter på en annan kanal i varje fall.
Frågan låter enkel och har minst tre svar. Vilket svar som gäller beror på vem som tar emot informationen, och komponenterna som är inblandade delar inte en kanal. Varje svar tillhör en annan part, så den användbara frågan är vilken part du frågar om.
Att sortera dessa kanaler tar några minuter. Det förhindrar också en hel kategori dåliga slutsatser.
Tre observatörer, tre kanaler
En gateway som vidarebefordrar tunneltrafik ser paket. En inbyggd app på enheten kan anropa plattformens gränssnitt om plattformen tillåter det. En sida i en webbläsare körs inom det webbläsaren och användaren har tillåtit. Ingen av dem ser samma sak.
Det här är inte varianter av en enda förmåga. Det är separata mekanismer med separata behörigheter, och var och en svarar på en något annan fråga.
| 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 |
Den första raden är den som spelar roll för ett leverantörspåstående. Namnet på det trådlösa nätverket är inte en del av pakethuvudet. Ingen mängd routinginspektion frambringar det, och ingen logg över vidarebefordrad trafik innehåller det.
Android-fallet visar behörighetsgränsen
Dokumentationen för WifiInfo på Android är ett konkret exempel på den andra kanalen. Vissa Wi-Fi-detaljer där behandlas som positionskänsliga, och dokumentationen beskriver redigerade resultat när den nödvändiga åtkomsten saknas, inklusive ett okänt SSID-värde.
Det beteendet är värt att läsa noga. Det säger att plattformen kan hålla tillbaka värdet från en app som saknar åtkomst. Det säger inte att en VPN-app får det automatiskt, och det säger inte heller att en VPN-leverantör får det genom tunneln.
Ett godkännande av en nätverkstunnel är en snäv behörighet. Det låter appen dirigera trafik. Det överlämnar inte varje enhetsfakta som plattformen skyddar. Att behandla de två som samma behörighet är där de flesta av dessa påståenden går fel.
Koordinater är inte ett nätverksnamn
Geolocation API returnerar en position. Det returnerar inte listan över Wi-Fi-namn runt dig, även om plattformen under kan använda flera signaler, inklusive nätverksinformation, för att beräkna positionen.
Att ta emot en stad är inte samma sak som att ta emot en identifierare. En sida som visar ditt område har lärt sig något om var enheten är, och den har inte lärt sig det SSID som förde den dit.
Ett tillägg, en inbyggd hjälpare eller ett separat privilegierat program förtjänar sin egen granskning. Ingen av dem är utbytbar mot en vanlig sida som anropar geolokalisering, och ett webbläsartillägg körs med behörigheter som en sida inte har.
Vad en rapport eller en diagnostisk export bevisar
När en klient producerar ett diagnostikpaket är den användbara frågan vilka fält den samlade in, vem som tar emot dem och under vilken behörighet. Krypterad transport berättar att paketet reste säkert, inte vad det innehåller.
Nätverksnamn kan också återanvändas och ändras. En etikett ensam är svagt bevis för en fysisk plats, medan en offentlig adress är en annan observation med en annan tillförlitlighet.
Håll riktiga nätverksnamn utanför offentliga hjälptrådar. Frågan som är värd att besvara är smalare och mer användbar. Vilken komponent fick vilket fält, genom vilken behörighet och vilket flöde?