Spørgsmålet lyder enkelt og har mindst tre svar. Hvilket svar der gælder, afhænger af, hvem der modtager oplysningerne, og de involverede komponenter deler ikke en kanal. Hvert svar hører til en forskellig part, så det nyttige spørgsmål er, hvilken part du spørger om.

At sortere de kanaler tager et par minutter. Det forhindrer også en hel kategori af dårlige konklusioner.

Tre observatører, tre kanaler

En gateway, der videresender tunnel-trafik, ser pakker. En indbygget app på enheden kan kalde platformens grænseflader, hvis platformen tillader det. En side i en browser kører inden for det, browseren og brugeren har givet. Ingen af dem ser det samme.

Det er ikke variationer af én evne. Det er separate mekanismer med separate tilladelser, og hver især besvarer et lidt anderledes spørgsmål.

ObserverWhat it receivesWhat it needs
Tunnel gatewayForwarded IP packets, which carry no SSID fieldNo device permission at all
Installed client appLocal network details, when the platform exposes themThe specific permission and context the platform requires
Page using browser geolocationPosition properties such as coordinatesUser consent plus the browser's own checks

Den første række er den, der betyder noget for en udbyderpåstand. Navnet på det trådløse netværk er ikke en del af pakkehovedet. Ingen mængde af ruteinspektion frembringer det, og ingen log over videresendt trafik indeholder det.

Android-sagen viser tilladelsesgrænsen

Dokumentationen for WifiInfo på Android er et konkret eksempel på den anden kanal. Nogle Wi-Fi-oplysninger der behandles som placeringsfølsomme, og dokumentationen beskriver redigerede resultater, når den krævede adgang mangler, herunder en ukendt SSID-værdi.

Den adfærd er værd at læse grundigt. Den siger, at platformen kan tilbageholde værdien fra en app uden adgang. Den siger ikke, at en VPN-app automatisk modtager den, og den siger heller ikke, at en VPN-udbyder modtager den gennem tunnelen.

En godkendelse af en netværkstunnel er en snæver tilladelse. Den lader appen rute trafik. Den overdrager ikke enhver enhedsfakta, som platformen beskytter. At behandle de to som den samme tilladelse er, hvor de fleste af disse påstande går galt.

Koordinater er ikke et netværksnavn

Geolocation API returnerer en position. Det returnerer ikke listen over Wi-Fi-navne omkring dig, selv om platformen nedenunder kan bruge flere signaler, herunder netværksoplysninger, til at beregne den position.

At modtage en by er ikke det samme som at modtage en identifikator. En side, der viser dit nabolag, har lært noget om, hvor enheden er, og den har ikke lært det SSID, der bragte den derhen.

En udvidelse, en indbygget hjælper eller en særskilt privilegeret applikation fortjener sin egen gennemgang. Ingen af dem kan udskiftes med en almindelig side, der kalder geolokation, og en browserudvidelse kører med tilladelser, som en side ikke har.

Hvad en rapport eller en diagnostisk eksport beviser

Når en klient producerer en diagnostisk pakke, er det nyttige spørgsmål, hvilke felter den indsamlede, hvem der modtager dem, og under hvilken tilladelse. Krypteret transport fortæller dig, at pakken rejste sikkert, ikke hvad den indeholder.

Netværksnavne kan også genbruges og ændres. En etiket alene er svagt bevis for ét fysisk sted, mens en offentlig adresse er en anden observation med en anden pålidelighed.

Hold rigtige netværksnavne ude af offentlige hjælpetråde. Spørgsmålet, der er værd at besvare, er smallere og mere nyttigt. Hvilken komponent fik hvilket felt, gennem hvilken tilladelse og hvilken flow?

Relaterede artikler