VPN 服务商能看到你的 Wi-Fi 名称吗？三种不同的泄露
网关读取数据包，原生应用读取权限，网页读取坐标。Wi-Fi 名称在每种情况下都处在不同的信道上。
这个问题听起来很简单，却至少有三个答案。适用哪一个，取决于谁在接收信息，而涉及的组件并不共享同一个信道。每个答案属于不同的一方，所以有用的问题是：你问的是哪一方。
理清这些信道只需要几分钟。它还能避免一整类错误结论。
三个观察者，三条信道
转发隧道流量的网关看到的是数据包。安装在设备上的原生应用，在平台允许时可以调用平台接口。浏览器中的网页，运行在浏览器和用户授予的范围内。这三者看到的并不是同一件事。
它们不是同一种能力的不同形式。它们是彼此独立、权限各异的机制，各自回答一个略有不同的问题。
| 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 |
第一行才是对服务商主张有意义的那一行。无线网络的名称不在数据包头部。再多的路由检查也变不出它，任何转发流量的日志里也不会有它。
Android 的例子说明了权限的边界
Android 的 WifiInfo 文档是第二条信道的具体例子。那里的一些 Wi-Fi 细节被视为与位置相关，文档也说明在缺少所需访问权限时结果会被隐去，包括未知的 SSID 值。
这种行为值得仔细读。它说的是平台可以把值挡在没有权限的应用之外。它没有说 VPN 应用会自动拿到它，也没有说 VPN 服务商能通过隧道拿到它。
网络隧道的授权是一项很窄的许可。它允许应用转发流量。它不会交出平台保护的每一项设备事实。把这些混为一谈，正是这类说法里大多数出错的所在。
坐标不是网络名称
Geolocation API 返回的是一个位置。它不会返回你周围的 Wi-Fi 名称列表，尽管底层平台可能通过包括网络信息在内的多种信号来计算这个位置。
收到一个城市，和收到一个标识符并不一样。显示你所在街区的网页，确实知道了设备在哪里，但它并没有得知把设备带到那里的 SSID。
扩展程序、原生辅助工具或单独获得特权的应用，都值得单独审视。它们都不能和调用地理定位的普通网页互换，而浏览器扩展运行时拥有的权限，网页并没有。
报告或诊断导出能证明什么
当客户端生成诊断包时，有用的问题是它收集了哪些字段、谁接收这些字段、依据哪项权限。加密传输只说明诊断包安全送达，并不说明里面有什么。
网络名称也可以被重复使用和更改。单看一个标签，对某个物理位置来说是弱证据；而公网地址是另一种可信度不同的观察。
不要把真实的网络标签发到公开求助帖里。值得回答的问题更窄，也更有用。哪个组件、通过哪项权限和哪条流程，取得了哪个字段？