Ĉu VPN-provizanto povas vidi vian Wi-Fi-nomon? Tri malsamaj likoj
Pordego legas pakaĵojn, denaska aplikaĵo legas permesojn, kaj paĝo legas koordinatojn. La Wi-Fi-etikedo sidas sur malsama kanalo en ĉiu kazo.
La demando sonas simpla kaj havas almenaŭ tri respondojn. Kiu validas dependas de tio, kiu ricevas la informon, kaj la koncernaj komponantoj ne kunhavas kanalon. Ĉiu respondo apartenas al malsama partio, do la utila demando estas pri kiu partio vi demandas.
Ordigi tiujn kanalojn daŭras kelkajn minutojn. Ĝi ankaŭ malhelpas tutan kategorion de malbonaj konkludoj.
Tri observantoj, tri kanaloj
Pordego, kiu plusendas tunelan trafikon, vidas pakaĵojn. Denaska aplikaĵo instalita sur la aparato povas voki platformajn interfacojn se la platformo permesas tion. Paĝo en retumilo funkcias ene de tio, kion la retumilo kaj la uzanto donis. Neniu el ili vidas la saman aferon.
Tiuj ne estas variantoj de unu kapablo. Ili estas apartaj mekanismoj kun apartaj permesoj, kaj ĉiu respondas al iomete malsama demando.
| 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 unua vico estas tiu, kiu gravas por aserto de provizanto. La nomo de la sendrata reto ne estas parto de la pakaĵa kaplinio. Neniu kvanto de enkursigada inspektado produktas ĝin, kaj neniu protokolo de plusendita trafiko enhavas ĝin.
La Android-kazo montras la permesan limon
La dokumentaro WifiInfo de Android estas konkreta ekzemplo de la dua kanalo. Iuj Wi-Fi-detaloj tie estas traktataj kiel loksensitaj, kaj la dokumentaro priskribas redaktitajn rezultojn kiam la bezonata aliro mankas, inkluzive de nekonata SSID-valoro.
Tiu konduto indas atentan legadon. Ĝi diras, ke la platformo povas reteni la valoron de aplikaĵo, kiu ne havas aliron. Ĝi ne diras, ke VPN-aplikaĵo aŭtomate ricevas ĝin, kaj ĝi ankaŭ ne diras, ke VPN-provizanto ricevas ĝin tra la tunelo.
Aprobado de reta tunelo estas mallarĝa permeso. Ĝi lasas la aplikaĵon enkursigi trafikon. Ĝi ne transdonas ĉiun aparatan fakton, kiun la platformo protektas. Trakti la du kiel la saman permeson estas kie plej multaj el tiuj asertoj eraras.
Koordinatoj ne estas reta nomo
La Geolocation API redonas pozicion. Ĝi ne redonas la liston de Wi-Fi-nomoj ĉirkaŭ vi, kvankam la platformo sube povas uzi plurajn signalojn, inkluzive de reta informo, por kalkuli tiun pozicion.
Ricevi urbon ne samas al ricevi identigilon. Paĝo, kiu montras vian kvartalon, lernis ion pri tio, kie la aparato estas, kaj ĝi ne lernis la SSID-on, kiu kondukis ĝin tien.
Etendaĵo, denaska helpilo aŭ aparte privilegiita aplikaĵo meritvas propran revizion. Neniu el ili estas interŝanĝebla kun ordinara paĝo, kiu vokas geolokadon, kaj retumila etendaĵo funkcias kun permesoj, kiujn paĝo ne havas.
Kion pruvas raporto aŭ diagnoza eksporto
Kiam kliento produktas diagnozan pakaĵon, la utila demando estas kiujn kampojn ĝi kolektis, kiu ricevas ilin, kaj sub kiu permeso. Ĉifrita transporto diras al vi, ke la pakaĵo vojaĝis sekure, ne kion ĝi enhavas.
Retaj nomoj ankaŭ povas esti reuzataj kaj ŝanĝataj. Etikedo sola estas malforta pruvo de unu fizika loko, dum publika adreso estas alia observado kun alia fidindeco.
Tenu realajn retajn etikedojn ekster publikaj helpaj fadenoj. La demando inda je respondo estas pli mallarĝa kaj pli utila. Kiu komponanto akiris kiun kampon, per kiu permeso kaj kiu fluo?