3000款APP被下架，原因竟然是......

自工信部2019年开展APP侵害用户权益专项整治工作以来，有超过3000款APP被通报或下架；随着个人信息保护法的实施，APP监管会成为常态。为尽可能避免企业因APP下架所带来的损失，我们特意编写了常见通报问题和整改方案。（扫描下面的二维码，即可下载完整方案）

数据统计来源于工信部官方网站：

目录

六、欺骗误导强迫用户

    典型问题1 启动屏广告

    典型问题2 奖励欺骗

七、附录

    附录1常见类型移动互联网应用程序必要个人信息范围规定

    附录2 常见第三方SDK列表

    附录3 安卓可收集个人信息权限

    附录4 常见服务类型并不建议申请的安卓系统权限

    附录5 移动互联网应用程序（APP）启动屏广告行为规范（征求意见稿）

一、违规收集个人信息

典型问题1 ：提前收集

        APP首次运行，用户同意隐私政策前，私自收集“设备MAC地址”等信息。

       解决方案：这部分的问题主要是因为在隐私政策弹窗之前，使用和初始化第三方的SDK，第三方SDK存在收集MAC地址等信息的情况，导致APP被下架。若是第三方SDK问题，可以先尝试前往官网查看是否有提供合规解决方案。针对这类问题常规检测方案，可以使用网络抓包工具和开源项目合规2.0去检测。

1.1抓包精灵

    运行APP之前，打开抓包功能，并设置过滤条件，限制为要检测的APP应用。然后启动APP，在未同意隐私政策之前，停止抓包行为，然后对抓到的数据包进行分析，可以看到具体的第三方SDK与云端通信的情况

通过包信息，能够发现未同意隐私政策之前，与云端通信的三方SDK行为，在数据包中可能能看到部分明文获取MAC地址、IMEI等信息的情况，如图所示：

1.2 合规3.0

    开源项目合规3.0实现了对APP进行hook，并对获取敏感信息的方法类进行了监测，当有调用的时候会输出日志进行告警。在使用前先打开源代码，修改要Hook的包名信息，如图：

在手机安装该APP之后，再将待检测APP、合规3.0等加入到VirtualXposed，然后打开Xposed日志，运行APP来查看是否存在敏感的获取设备敏感信息的行为，如图：

这类问题需要注意的是，APP中隐私政策链接的打开方式。如果APP是有内置浏览器SDK的方式来实现，可能也会存在问题。当用户启动APP，未同意隐私政策之前，点击隐私政策超链接，可能会存在内置浏览器SDK收集设备MAC的情况，在我们协助处理的案例中，遇到过多家APP因为此类细节问题，导致被下架的情况。

    典型问题2 ：默认勾选

    APP在征求用户同意环节，设置为默认勾选；未提供明确的同意或拒绝按钮，或者使用“好的”“我知道了”等词语

    解决方案：此类问题主要是因为功能设计导致的，通过APP的使用就可以发现这类问题。APP打开之后，隐私协议弹窗提供给用户自行勾选，功能设计上不设计成默认勾选就可以解决问题。

二、超范围收集个人信息

典型问题1 ：收集无关信息

    注册、使用阶段收集无关信息、强制收集非必要信息。

    解决方案：请根据附录1《常见类型移动互联网应用程序必要个人信息范围规定》仔细检查是否符合所属类型必要信息收集的规定。非必要但相关信息，用户是否可选择型填写且有明确的使用目的。

    发现您的应用后台状态下（静默状态下）获取了用户的MAC等个人信息，但未在隐私政策中进行说明。

    解决方案：请将后台状态下获取的个人信息在隐私政策中明示，如“xxxx获的取您的设备MAC地址，我们可能会在应用前台运行时、应用后台运行时收集。”

    检测方法：将App放置后台运行，按照1.1 抓包精灵、1.2合规3.0的方式进行检测。

    APP以隐私政策连接的形式向用户明示收集使用规则，未经用户同意，存在将“设备MAC地址”个人信息发送给xxx第三方SDK的行为，且隐私政策中未提及第三方SDK。

    解决方案：与开发沟通，将使用且收集个人信息的第三方SDK包含在隐私政策中，包括SDK名称、使用目的、收集个人信息、合作方名称、权限使用情况、SDK隐私政策链接。常见三方SDK类型包括推送类、浏览器、分享/登录类、支付类等，各类型常见第三方SDK列表见附录2。

    典型问题2 ：定向推送

    强制用户使用定向推送功能。隐私政策中存在定向推送功能，但未见提供退出或关闭个性化展示的选项。

    解决方案：首先应该确定是否存在定向推送功能，若无，直接修改隐私政策。若有，应在定向推荐页面进行显著标识，并在App内提供关闭定向推荐的选项并明示目的。

四、APP强制、频繁、过度索取权限

典型问题1 ：提前申请

    APP首次运行，未见使用权限对应的相关产品和服务时，提前向用户弹窗申请开启“位置”、“日历”、“电话”权限。APP首次启动后，再打开可手机个人信息的电话、存储权限，未同步告知用户其使用目的、范围。

    解决方案：App所有权限应为触发式申请，并且在申请前明示获取权限的目的（iOS及Android10以上可以写到弹窗里，但为了适配，建议Android做二次弹窗），包括电话权限、存储权限，也应该有对应的目的明示。

    典型问题2 ：频繁索权

    APP在用户明确拒绝“位置”、“日历”等非必要权限申请后，重新运行时，仍向用户弹窗申请开启与当前服务场景无关的权限，影响用户正常使用。

解决方案：明确拒绝后，48小时内不得再次申请该权限。

    典型问题3 ：不给权限不让用

    APP首次启动后，在用户明确拒绝“存储“、”电话“等非必要权限时，无法使用App。

解决方案：用户拒绝“存储“、”电话“等非必要权限后，仍可使用App。

    典型问题4 ：开机自启动和关联自启动

    未向用户告知且未经用户同意，或无合理的使用场景，频繁自启动或关联启动第三方APP。

    解决方案：检查权限列表是否声明了RECEIVE_BOOT_COMPLETED开机广播权限，该权限是否有合理使用场景，若有，请在隐私政策中明确具体使用目的，若无，请在AndroidManifest.xml文件中去掉该权限。

典型问题5 ：权限组问题

    使用App过程中申请无关权限。如上传照片功能申请存储权限组下“ACCESS_ME DIA_LOCAT ION 读取照片位置信息”功能。

    解决方案：细化权限申请的颗粒度，如仅需使用权限组中部分权限，不应在权限声明文件中声明同一权限组其他权限。详见《App系统权限申请使用指南》附录3 Android可收集个人信息权限列表、及附录4常见服务类型并不建议申请的安卓系统权限。

   App内未提供注销账号功能。

   解决方案：提供注销账号功能

 典型问题2 ：设置注销不合理条件

    例1：身份核验时要求用户再次提供的个人信息类型多于注册、使用等服务环节收集的个人信息类型，特别是注册和使用环节没有要求而在注册环节要求用户提交身份证正反面照片、手持身份证照片、人脸认证、绑定银行卡。

    例2：于采用同一账号注册登录多个App的情形，用户注销单个App时只能注销用户账号，导致用户无法使用其他相关App。在这种“注销单个账户视同注销多个产品或服务”的情况下，不同的应用相互独立的，却又不允许用户针对单一应用的账号提起注销，应为不合理的注销条件。

    例3：要求用户必须填写精确的历史操作记录，例如注册时间/注册地点/特定登录时间及地点等信息

    典型问题3 ：无效注销

App内未提供有效注销功能。注销后15个工作日无人处理/注销后仍然可以登录等。

    APP的信息窗口无显著标识，点击页面任意位置（设置虚假关闭按钮）即跳转至信息窗口详情页面（下载其他App）。

    解决方案：参考附录5《移动互联网应用程序（APP）启动屏广告行为规范（征求意见稿）》，需点击指定位置跳转。

    典型问题2：奖励欺骗

    非服务所必需或无合理场景，通过积分、奖励、优惠等方式欺骗误导用户提供身份证号码以及个人生物特征信息的行为。

    解决方案：给出合理必要收集的目的，不以获取积分、奖励等字眼诱导用户填写。

（附录及整改方案下载 扫描下面二维码，即可下载详细完整方案）

​