SDK数据收集场景:必要权限与敏感信息识别

这一章咱们聊点实际的。你在App里集成一个SDK,它要拿位置、读通讯录、开摄像头……这些权限到底该不该给?哪些属于敏感信息?弄不好,审核被拒不说,还可能被用户投诉到网信办。我刚开始做合规改造那会儿,也踩过不少坑,今天就把这些经验摊开说。

说白了,必要权限就是App实现核心功能必须申请的权限。没有它,功能跑不起来。敏感信息呢?就是一旦泄露可能对用户造成人身、财产损害的个人信息。这两个概念听起来简单,实际操作中经常混淆。你想想看,一个手电筒App要读取通讯录,这合理吗?

什么是必要权限

必要权限跟App提供的服务直接挂钩。举个例子:外卖App要用定位,是因为要确定送餐地址;地图App要用定位,是因为核心就是导航。但如果一个计算器App要定位,那就说不过去了。

我在项目中遇到过一家公司,他们的拍照修图App申请了“读取通话记录”权限。对方给的借口是“方便用户分享时直接打电话”,但仔细一分析,分享功能完全可以用系统分享接口实现,根本不需要通话记录权限。最后被市场监督部门约谈,修改了SDK配置才过关。

我的判断原则: 每次申请权限之前,问问自己:
“没有这个权限,用户能否正常使用核心功能?”
如果不能 → 必要权限
如果能 → 非必要权限,属于过度收集

敏感信息的识别标准

根据《个人信息保护法》和《App违法违规收集使用个人信息行为认定方法》,敏感个人信息包括:生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹等,以及不满十四周岁未成年人的个人信息。注意,不只是这几种,还有个“等”字——只要信息泄露可能导致歧视或严重损害,都算。

我记得有一次做SDK安全评估,对方提供了一份数据收集清单。其中“用户所在的WiFi SSID”看起来好像不敏感,但细想:SSID能暴露用户家庭或公司位置,一旦结合其他数据就可以精准定位。所以我们把它列为了敏感信息。

信息类型 是否敏感 典型场景
IMEI / Android ID 敏感(设备标识) 统计分析、广告归因
精确位置(GPS) 敏感 导航、外卖
粗略位置(基站) 敏感(法规明确) 天气、本地资讯
通讯录 敏感 社交邀请、电话拦截
相册/相机 敏感 拍照、扫码
MAC地址 敏感(可追踪) 网络诊断、设备管理
App版本号 非敏感 版本兼容检测

代码层面的权限声明示例

这里我贴一段Android权限声明的典型写法。注意区分正常权限和危险权限(敏感权限)。在AndroidManifest.xml里声明,但运行时还要弹窗申请。

<!-- 必要权限:地图功能需要定位 -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- 非必要权限,但SDK文档里写了——这是坑,千万别照抄 -->
<!-- 我曾经见过某个SDK文档里直接声明了CHANGE_WIFI_STATE,说是为了“优化连接”,实际上根本不需要 -->
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />

iOS这边,Info.plist里的描述一定要写清楚。不要写“用于提升用户体验”这种废话,要具体到“用于在App内为您推荐附近的餐厅”。

<key>NSLocationWhenInUseUsageDescription</key>
<string>我们需要您的位置来显示附近的餐厅,并规划送餐路线。</string>
踩坑提醒: 我曾经接手过一个项目,SDK的文档里列了一大堆权限,开发同学直接复制粘贴到manifest里。结果上架时被应用商店驳回,理由是“过度收集权限”。后来一一对照功能流程,删掉了5个不必要的权限。所以,不要信SDK文档里“推荐”的权限列表,自己手动梳理功能依赖。

必要权限的识别流程图

下面这张图展示了SDK对接时,判断一个权限是否必要、以及是否属于敏感信息的完整流程。我建议你在做SDK合规检查时,对着这个流程逐条过一遍。

必要权限与敏感信息识别流程 收到SDK权限申请 是否为 App 核心功能所必需? 是 数据是否属于敏感个人信息? 是 必须获取用户单独同意 允许收集(需必要 + 合规) 非必要,拒绝 否 非敏感 一般同意即可 说明 1. 核心功能判断:删除该权限后,App主要功能是否可用? 2. 敏感信息识别:凡涉及个人隐私、行踪、金融、生物特征等均属敏感。 3. 单独同意:敏感权限必须弹窗单独征求用户同意,不能打包在一般协议中。 4. 非敏感但非必要:仍然不能收集,因为违背最小必要原则。

实战中对SDK的合规检查清单

每次接一个新SDK,我都会对照下面这个清单过一遍。省得后期返工。

  1. 拉权限清单:把SDK的AndroidManifest.xml或Info.plist里声明的所有权限列出来。
  2. 逐条贴功能:每个权限对应到App的哪个功能模块。找不到对应功能的,标记为可疑。
  3. 识别敏感字段:权限对应的数据是否属于敏感个人信息。
  4. 评估必要性:即使敏感,如果核心功能确实需要,也必须收集,但需要单独弹窗。
  5. 检查SDK配置选项:有些SDK提供了关闭某些收集的开关,一定要关掉非必要的。
  6. 做静态分析:反编译SDK的aar/framework,看它实际调用了哪些系统API,防止隐蔽收集。

记住这条铁律: 能不收的,坚决不收;能收到匿名化级的,绝不收精确的;能后台跟的,绝不额外申请权限。最小化原则是合规第一生命线。

好了,以上就是关于必要权限和敏感信息识别的主要内容。你下次再看到SDK文档里那一长串权限清单,应该知道怎么审查了吧?