VPN 应用索要联系人与无障碍权限：该允许什么

安装程序先请求网络访问，接着请求联系人、无障碍和安装证书。只有第一项请求属于本职工作。真正需要做决定的是第二个屏幕。

对照你在所用平台上选定的功能，逐项判断每个请求。没有一份通用权限清单能覆盖所有 VPN 产品，清单再长本身也证明不了什么。

这项工作真正需要的一项权限

在任何隧道启动之前，Android 会通过系统对话框请用户批准 VPN 服务；应用的服务声明 BIND_VPN_SERVICE，系统才能绑定到它。从运营角度看，应用做的就是路由工作。同意来自设备持有者在点名该应用的对话框中所作的选择，之后撤销也是受支持的操作。

Apple 平台用网络扩展加安装批准来表达同一件事，而不是权限界面。Windows 使用虚拟网卡驱动和提权提示。两种形式，一个含义：这个程序可以处理数据包。该授权完全不涵盖读取你的通讯录，也不涵盖给自己签发证书颁发机构。

额外访问是另一项授权，另有其后果。想要它的路由客户端必须给出自己的理由。

额外请求在什么情况下需要自己的说明

无障碍服务可以读取屏幕内容并代你操作，这远远超出路由的范畴。设备管理可以强制执行锁定策略并清除数据。用户安装的根证书能让持有对应密钥的人读取 TLS 原本会保护的流量。

这些都可能合法。受管设备产品和家长控制产品可能需要策略权限，支持工具也可能需要无障碍权限来带你完成设置。

要求是可追溯：请求要指向一个具名功能，而该功能必须在你安装的产品中可见。没有面向联系人的界面却索要联系人，就无从解释。加密的理由也套不上，因为保护数据包与你的朋友是谁毫无关系。正当产品也可能通过捆绑的库过度索取，那是应当提出的缺陷，而不是应当报案的罪行。

记下请求及其对应的功能，再做决定。当某项功能在被拒绝后失效时，这份记录也是你向支持人员出示的依据。

在设备上查看请求

商店页面描述的是意图，已安装的软件包描述的是现实。在批准任何其他东西之前，先问软件包管理器声明了什么、授予了什么。当商店页面与清单不一致时，这一对信息最重要。

两条查询能覆盖大部分情况：

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

第一条列出已声明与已授予的权限，正是这种对比能暴露过宽的清单。第二条显示运行时的 app-ops，包括那些从不作为普通权限出现的特殊访问。若没有开发者工具，可从平台设置界面读取同样的事实。

这些界面花一分钟，且不需要任何软件。无障碍、设备管理和证书存储各自都会列出持有该授权的应用。

做决定，然后限制损害

把网络授权交给你选定的客户端，并把每一项额外请求当作独立决定。拒绝没有对应功能的请求，然后看哪里会坏。若一个路由客户端在联系人访问被拒后失败，那它从来就不是在替你索要联系人。

撤销一项权限通常会停用单个功能，而无需卸载应用或拆掉每个配置文件。之后重新连接，确认隧道仍能建立。

把提示框往往混为一谈的两个问题分开：这个程序在设备上可以做什么，以及隧道建立后它的运营方会如何处理流量。第一个问题在这里回答。第二个问题需要留存政策，任何对话框都不会提供。