La question semble simple et comporte au moins trois réponses. Celle qui s’applique dépend de qui reçoit l’information, et les composants concernés ne partagent pas un canal. Chaque réponse appartient à une partie différente, donc la question utile est de quelle partie vous parlez.

Trier ces canaux prend quelques minutes. Cela évite aussi toute une catégorie de mauvaises conclusions.

Trois observateurs, trois canaux

Une passerelle qui achemine le trafic du tunnel voit les paquets. Une application native installée sur l’appareil peut appeler des interfaces de la plateforme si celle-ci l’autorise. Une page dans un navigateur s’exécute dans les limites de ce que le navigateur et l’utilisateur ont accordé. Aucune d’elles ne voit la même chose.

Ce ne sont pas des variantes d’une même capacité. Ce sont des mécanismes distincts avec des permissions distinctes, et chacun répond à une question légèrement différente.

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

La première ligne est celle qui compte pour une affirmation de fournisseur. Le nom du réseau sans fil ne fait pas partie de l’en-tête du paquet. Aucune quantité d’inspection de routage ne le produit, et aucun journal de trafic acheminé ne le contient.

Le cas Android montre la limite des permissions

La documentation WifiInfo d’Android est un exemple concret du deuxième canal. Certains détails Wi-Fi y sont traités comme sensibles à la localisation, et la documentation décrit des résultats expurgés lorsque l’accès requis manque, y compris une valeur SSID inconnue.

Ce comportement mérite une lecture attentive. Il dit que la plateforme peut retenir la valeur à une application qui n’y a pas accès. Il ne dit pas qu’une application VPN la reçoit automatiquement, ni qu’un fournisseur VPN la reçoit par le tunnel.

Une autorisation de tunnel réseau est un droit étroit. Elle permet à l’application d’acheminer le trafic. Elle ne transmet pas chaque fait sur l’appareil que la plateforme protège. Traiter les deux comme la même permission est précisément là où la plupart de ces affirmations se trompent.

Les coordonnées ne sont pas un nom de réseau

L’API Geolocation renvoie une position. Elle ne renvoie pas la liste des noms Wi-Fi autour de vous, même si la plateforme sous-jacente peut utiliser plusieurs signaux, dont des informations de réseau, pour calculer cette position.

Recevoir une ville n’est pas la même chose que recevoir un identifiant. Une page qui affiche votre quartier a appris quelque chose sur l’emplacement de l’appareil, et elle n’a pas appris le SSID qui l’y a amené.

Une extension, un assistant natif ou une application privilégiée séparément méritent leur propre examen. Aucun d’eux n’est interchangeable avec une page ordinaire qui appelle la géolocalisation, et une extension de navigateur fonctionne avec des permissions qu’une page n’a pas.

Ce que prouve un rapport ou un export de diagnostic

Lorsqu’un client produit un paquet de diagnostic, la question utile est quels champs il a collectés, qui les reçoit et sous quelle permission. Le transport chiffré vous dit que le paquet a voyagé en sécurité, pas ce qu’il contient.

Les noms de réseau peuvent aussi être réutilisés et modifiés. Une étiquette seule est une preuve faible d’un lieu physique, tandis qu’une adresse publique est une observation différente avec une fiabilité différente.

Gardez les vraies étiquettes de réseau hors des fils d’aide publics. La question qui mérite une réponse est plus étroite et plus utile. Quel composant a obtenu quel champ, par quelle permission et quel flux ?

Articles similaires