关于APP 内涉及用户个人敏感信息/权限的进一步整改

前言：

有一段时间没更新关于用户隐私相关的内容了。随着去年 11 月《个人信息保护法》的更新，四部委和工信部又下达了一批新的标准，这一篇就是记录一下这半年来项目里关于保护用户隐私部分的优化。

一、用户未同意隐私政策之前收集用户敏感信息/权限

这个问题是比较普遍的，就是用户安装完 APP 之后，未点同意之前，收集了敏感信息/权限。

所以在用户点击同意之前，不可以有任何获取 Android ID、 IP、Mac 、用户账号密码等用户个人隐私信息行为出现，包括动态权限申请。包括在 SDCard 写入数据，尽管没有申请存储权限无法写入成功写入数据，但这个行为也是会被检测到的，依旧是违规的。

这类问题严重程度偏高，侵犯用户隐私的，也是市面上 APP 被工信部通报的最多的。

二、动态权限申请和敏感信息收集

APP 在申请系统运行时权限时，必须针对特定场景，避免过度申请权限，并且要先弹框告知用户申请该权限的目的。遵循最小化原则。

最小化原则：例：调用系统相机，我们只需要申请 CAMERA 权限，如果同时又申请了存储权限，那么就是违规的，不合理的。

例：更换头像功能，调用系统相机需要申请 CAMERA 权限。那么应该在用户触发功能时，先弹框告知用户申请权限的具体目的：为了调起系统相机，拍照用于更换头像。如果用户拒绝授权，应该弹框告知用户拒绝授权会影响此功能。让用户体验好一点的做法，是同时提供按钮给用户跳转设置权限的页面。

例：用户转账（涉及银行卡号、转账账号），实名认证（涉及身份证信息），均要对应当次发起的交易，弹框告知用户收集银行卡号/身份证号，用于具体的某个目的。同时，要提供按钮供用户拒绝/同意。

注意：上诉所提到的弹框，均为自定义的弹框，包括动态授权时，尽管系统有弹框，也应该有一个自定义弹框，并且弹框均应该有“确定”和“取消”的选项，若当前申请的敏感信息为该业务流程的必要信息时，用户拒绝授权则终止流程，不应继续往下执行而违规获取用户信息。

三、前后台收集用户信息的频率是否超频

很多的 APP，收集用户的使用习惯用于大数据分析，会产生大量超频收集的行为。

比如用户点击某个按钮、进入某个页面，就上送用户信息（Android id、IP、手机号等），或者在后台运行服务，在一定的时间间隔（比如每分钟）就上送用户信息。这一类的做法都是违规的。最稳妥的又太不影响我们收集数据的做法，就是不要定频，后台服务收集信息的时间不要定死，用户点击的操作之类的也不要每次都产生收集行为。

四、过度申请权限

我们在 AndroidManifest.xml 中声明的运行时权限，都需要有特定场景触发且场景“合理”，才能满足监管要求。

对于“合理”一词做一个解释：例：如果我在首页获取 READ_PHONE_STATE，也弹框告知用户我们需要获取 IMEI 等设备信息作为登录唯一标识之类的目的。那么我们依旧是属于违规的，因为 Android 10 之后，就不允许获取 IMEI 等信息了，所以这个授权就显得不合理。

例：我在 AndroidManifest.xml 声明了 STORAGE 权限，但是我在实际的 app 功能没有用到，这种就属于过度申请权限。依旧是要遵循最小化原则，清单文件中只列出自己项目中实际用到的权限。

五、强制授权使用

这个问题是市面上绝大部分 APP 都存在的问题，目前真正提出解决方案]的 app 还是少数，成功的案例的话大家可以参考“今日头条极速版”，他们就做出了一个类似“游客模式”的解决方案，在用户拒绝同意隐私政策内容时，提供一个仅浏览的功能。

六、隐私政策更新机制

规定：隐私政策内容如果有更新，必须以弹框形式再次告知用户并提供按钮给用户同意或拒绝。

七、建立个人信息保护“双清单”制度

（1）APP 二级菜单，必须有隐私政策的简明版，或者隐私政策完整本开头需要有隐私政策摘要

（2）APP 二级菜单，必须有“个人信息”、“个人信息权限”、“第三方共享个人信息”清单链接（均需提供单独的入口）

《个人敏感信息清单》：以每个涉及个人敏感信息的场景（登录、转账等）独立为项，列举当前场景所收集的个人敏感信息（Android ID、IP 等）。

《个人信息权限清单》：APP 中所涉及的运行时权限，每一个权限单独为项，说明该权限所涉及的功能场景及使用目的。

《第三方共享信息清单》：APP 中所涉及的第三方厂商、第三方 SDK，每一个单独为项，说明改 SDK 收集的个人敏感信息以及作用。

八、APP 频繁自动和关联启动

关于这一点我当时另外写了一篇博客，以下是链接：

CSDN

九、必要个人信息是否满足告知同意通知要求

隐私政策弹框，需要向用户告知个人信息保护政策的核心内容（如：app类型、基本业务功能、必要个人信息等）

例如：

根据《常见类型移动互联网应用程序必要个人信息范围规定》，本APP属于“手机银行”类型，基本功能服务为“通过手机等移动智能终端设备进行银行账户管理、信息查询、转账汇款等服务”

具体描述可参考《常见类型移动互联网应用程序必要个人信息范围规定》，根据自己 APP 的类型来补充描述。

十、为用户提供第三方应用授权管理功能或渠道

如果 APP 中嵌入了第三方应用，应为用户提供第三方应用授权管理功能和渠道。

例如：

我在 APP 里使用了腾讯 Bugly ，OPPO 推送功能，那么我就需要有一个功能页面提供这两个功能的开关选项给用户，让用户自主决定是否开启这两个功能。

十一、是否同步告知申请打开个人信息权限目的

所有 APP 内使用用户个人敏感信息、敏感权限的，均需要弹框告知用户明确的使用目的。

注：弹框均需要提供两个按钮，同意和拒绝，不可只提供一个按钮强制用户授权敏感信息，如是业务流程必要收集的信息，用户拒绝后应结束流程，不可继续收集用户相关信息。

十二、App收集人脸信息应遵循“最小必要”原则，并告知用户收集使用规则

如果 APP 内有使用人脸/活体识别的场景，需要有独立的《人脸协议》，现在很多 app 为了强标识真人用户，都会在登录或者进行一些重要的操作时进行实人认证，也就是扫描人脸对接公安系统进行识别。一般都是对接大厂的 SDK（比如腾讯的人脸核身）。

那么在调起 SDK 进行人脸识别之前，需要先弹框说明收集的目的，并附上独立的《人脸协议》（类似于《隐私政策》，可以做成一个独立的链接，这样也比较美观）。

《人脸协议》具体应包含以下内容，当然只是粗略概括，集成的 SDK 也会有相关的协议，可以参考去写。

1) 收集、使用人脸信息的目的、方式、类型和范围，以及授权存储方式（人脸信息与人脸信息主体的身份信息分开存储）、时间等规则；
2) 收集的人脸信息处理方式的描述，如：仅本地收集、远程核验等；
3) 控制者的联系信息，至少包括的信息有：组织机构信息、联系方式；
4) 人脸信息主体实现查看、修改、删除其人脸信息以及撤回其授权同意的方式。

十三、撤回隐私授权

app 内应提供便捷的用户撤回隐私授权的功能，即当用户撤回授权后，再次打开 app ，需要再次统一隐私政策才能使用。

用户同意隐私的动作我们可以通过将结果存入内存来实现，具体是使用数据库还是缓存，看大家选择，撤回时只管将存储的内容重置即可。

十四、隐私政策文本

关于隐私政策文本的，在另外一篇文章做说明，等写完会再次附上链接：

CSDN

声明：

上述提及的违规点，都是自己项目中出现的问题，并不囊括所有的违规检测点，因为四部委所颁发的检测标准体量还是比较庞大的。

以上所列出的违规点，可供小伙伴作为自查参考，如需对 APP 做全面的检测，还是要找专业的检测机构。我们的 APP 都是委托“北京智游网安科技有限公司”所做的检测。也感谢整改期间机构同学的配合和指导以及提供的专业意见。