看书的小蜗牛

App隐私合规现状与防范措施

2022/11/23

背景

2021年11月1《个人信息保护法》正式施行，标志信息保护进入强监管时代，同时，APP监管也被提升到前所未有的高度，数据安全、用户隐私、甚至功能体验等各个方面都出台了相应的规则规范，监管的初衷是：从各个层面保障用户的权益，避免用户的隐私、体验、数据被滥用，甚至威胁国家安全，一旦违规被查处面临的惩罚是非常严厉的，因此产品运营方必须高度重视。一方面，在产品设计、开发阶段就要充分考虑并满足各种监管要求；另一方面，一旦查出隐患问题，要积极响应，及时整改，否则可能面临工信部通报，甚至全面下架风险，首当其冲的一块是：APP隐私合规。

APP隐私合规指简单说就是：用户隐私的收集、存储、使用、加工、传输、提供、公开、删除等都要合乎法规个人信息保护法，遵守原则。从APP端来看，它关系到用户的切身体验，用户自身也能直观感受到自己的隐私是否被过分索取。比如，申请与自身功能毫不相关的权限，不给还拒绝提供服务等场景。

APP隐私合规监察的重点场景

据信息通信研究院统计，截至2021.12.10，工信部共检测共244万款App，累计对5000+发出整改通知，通报2000+整改不利的APP，并下架600+ 拒不整改的APP。其中，重灾区在非法获取用户隐私、超范围收集个人信息、过度频繁过度索取权限、违规使用个人信息等， 其中违规收集个人信息占比48%、过度索取权限占比17%、超范围收集个人信息占比10%、违规使用个人信息占比8%、强制定向推送占比8%，这些也是APP检测与整改的重点区。

image.png

违规非法收集个人隐私

这里所说的信息主要是指可以追踪、定位、识别个人身份的能力，多采用隐式方式获取。参考个人信息保护法、《App违法违规收集使用个人信息行为认定方法》，违规收集个人信息主要指如下场景：

（一 ） 未公开收集规则、目的、方式、范围 ，常见的表现有 ：

  • App缺少隐私政策，或者隐私策略不规范 【隐私策略H5落地页 】
  • 首次运行时未通过弹窗等明显方式提示用户阅读隐私政策等收集规则； 【启动隐私策略弹窗 】
  • 隐私政策难以访问、难以阅读[文字过小过密、颜色过淡、模糊不清] 【隐私策略规范】
  • App或者SDK收集目的、方式、范围披露不完整 【SDK披露列表 】
  • 隐私策略变更时，未以显著方式通知用户 【更新弹窗 】
  • 申请权限，或户身份证号、银行账号、位置等个人敏感信息时，未同步告知用户其目的，或者目的不明确【说明弹窗 】

（二） 未经用户同意就开始搜集个人信息，具体表现有

  • 用户未同意前就开始收集 【隐私策略点击同意前，调用敏感API 】
  • 用户明确表示不同意后仍搜集，或频繁征求用户同意，影响使用 【拒绝后不应频繁请求】
  • 搜集信息超出用户授权范围或者违反其策略声明收集个人信息。 【没纰漏】
  • 默认选择同意隐私政策 【默认选中】
  • 定向推送信息，未提关闭 【千人千面】
  • 未向用户提供撤回同意收集个人信息的途径、方式；**【可操作性太低，这个没经历】**

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

这里所说的权限主要是指在系统层面需要用户授权，只有授权才能拿到部分信息，多采用显示方式获取。违规场景一般是指：在用户明确拒绝某些权限申请后，仍然频繁弹窗反复申请某项非必须权限，或者因为用户拒绝而整体拒绝提供服务。常见的表现有：

  • 频繁索取： 在商详用户明确拒绝了位置申请，仍在后续App运行期间，通过多种方式申请
  • 强制索取：App首次启动时，向用户索取IMEI权限用作设备ID，用户选择拒绝授权，直接退出
  • 过度索取权限: 阅读工具索取通讯录权限等

《隐私政策》必须明确所有权限申请目的，并保证权限与功能的相关，拒绝某项功能性授权，不应该影响其他功能的正常使用，对于高风险的权限包括麦克风、短信、摄像头、定位等应谨慎对待。

Android与iOS在隐私合规上的区别对待

  • （一）Android是隐私合规的重点处理对象

整体来讲，iOS的生态更加健康、完善，相对于Google，苹果对隐私的重视程度更高，在系统层面支持的更好。并且，由于iOS系统不开源，国内的手机厂商全部是Android系统，每个厂商还都有自己的应用市场，导致生态特别混乱，Android的开源导致Google对于系统的话语权不是特别高，系统的碎片化很严重，通过系统升级来解决隐私问题几乎不可能，所以国内隐私合规审查的重点一直就是Android，而且基本上只能是Android，无论是从技术上，还是从话语权上，苹果都比较强势。

  • （二）Android的合规审查标准比较混乱

隐私合规主要是工信部、网信办、各地通管局在一起推动的，但是具体的审查工作并不是这些部门在承办，而是交给第三方进行审查。一些应用市场为了保证自己市场的APP的质量，也会自定定义一套审查规则，所以就会导致这么一种乱象：A市场审查通过的APP，在B市场仍然有隐私合规问题，工信部审查合规的APP，无法通过部分应用市场的的审核标准。目前国内的主要的应用市场如下：

image.png

相对iOS的唯一性，Android要处理的厂商是非常复杂，要处理的合规问题，也更加混乱，虽然隐私合规政策是正向的，但是在执行层面缺乏统一的认证标准，给开发、产品运营带来了很多额外的适配工作。比如，对于某些用户信息搜集的初衷，有些市场要求的会非常细，而且这个衡量并非机器在操作，而是有人工审核参与，主观性的判断就给这部分带来很多不确定性。

APP隐私合规上的审查方式

目前，隐私合规基本是人工+自动化工具配合来共同完成，100%自动化审核还是比较困难，合规检测一般由专门的机构提供服务。这里检测分两种，一种是工信部、通管局发起的合规检测，另一种是开发者自己主动检测，工信部一般会雇佣第三方机构，对批量APP进行合规检查，根据结果出具整改通知，并后续审查，其审查流程一般是：

image.png

工信部通管局的审查对开发者而言，一般是被动的，但是结果检测后，必须主动并积极解决，一旦处理不好导致通报或者下架的后果将是灾难性的。相对而言另一种就是开发或者法务主动检测，很多平台提供隐私合规检测服务，当然，并不是完全免费的，可以参考某个平台的报价：一次4000，可以看到价格并不低，主动检测的目的就是自查，将风险提前暴露。

image.png

不过对于开发人员来说，这种方式并不是很友好，更需要一种实时、方便、廉价的自查方式

APP开发人员隐私合规自查

各厂商或者平台审查使用的手段基本都类似，人工审查负责功能层面的校对，比如：是否提供定向推送的开关、是否提供隐私策略、隐私策略内容是否完整，规范、权限的申请是否合规等，更关注法务法规上显性的要求；工具审查更注重隐私信息的获取，是否调用了某些系统接口非法获取了用户信息，更注重隐式合规需求。显式的合规比较容易满足，而且在交互设计阶段基本都已经处理了，所以重点关注下工具审查审查部分。

用户敏感信息的获取都是通过调用系统API来实现的，所以目前的做法基本都是HOOK掉系统API，让后将调用的堆栈输出，看看在当前节点是否符合合规需求，比如在用户统一隐私策略前，任何调用敏感API的操作都是属于不合规的，开发过程中怎么处理呢？以Android系统为例，对于系统API的HOOK，有多种方案，比如XPOSED框架、Frida框架等，针对这两个的使用分别介绍下：

  • XPOSED框架方式

XPOSED本身是一个HOOK框架，它通过污染zygote进程，来HOOK整个系统中所有的进程，开发人员将ROOT过的手机安卓XPOSED框架后，就可以自定义HOOK规则，在隐私合规审查的场景中，针对所有的合规API添加钩子函数，在调用前打印出调用堆栈即可，之后将自己开发的模块安装到XPOSED框架中，通过日志即可实时看到敏感API的调用情况。

public class CheckPlugin implements IXposedHookLoadPackage {
try {
    XposedHelpers.findAndHookMethod(
            TelephonyManager.class.getName(),
            lpparam.classLoader,
            "getImei",
            String.class,
            new XC_MethodHook() {
                @Override
                protected void beforeHookedMethod(MethodHookParam param) {
                    if (!TextUtils.isEmpty(packaname) && !packaname.equals(lpparam.packageName)) {
                        return;
                    }
                    Log.e(TAG, lpparam.packageName + " 调用getImei获取了IMEI");
                    collectionExceptionAllinformation(param);
                }
            }
    );
} catch (Throwable ignored) {
}
	    ...
    <!--其他合规API-->
}

该方式主要的工作在于编写XPOSED模块，实现代码为Java，可以在Android Studio中直接开发，对于Android开发来说，实现比较简单，但是每次修改都要重新部署到手机上，并且需要重启设备才能生效，开发初期效率可能比较低，但是固化下来之后，还是比较方便的。安装参考 P以上用Magisk+ruri+ LSposed

  • Frida框架方式

同XPOSED框架相比，Frida更灵活一些，不需要安装什么框架，只需要在Root的手机上运行Frida-server即可参考，它可以通过编写JS、Python代码来和frida_server进行交互，Frida使用的是动态二进制插桩技术（DBI），在程序运行时实时地插入额外代码和数据，从而达到跟踪和拦截函数的功能。Hook脚本写法：

Java.perform(function(){

 var macAddress = Java.use("android.net.wifi.WifiInfo");
    macAddress.getMacAddress.overload().implementation = function () {
        console.log("getMacAddress()");
        this.private_func();
    };
    ...
    <!--其他合规API-->

});

该方式的虽然说比较灵活，但是使用起来稍微有些不便，每次都要直接或者间接的方式，通过命令启动脚本注入

frida -U -l  privacy.js -f com.netease.yanxuan

两种方式的对比：

XPOSED框架在手机改造上比较麻烦，，除了ROOT，还要安装XPOSED，XPOSED的兼容性较差，但是后续的收益比较方便 XPOSED早期开发效率低，但是一旦Module固定后，后期几乎没有成本 Frida的配置比较简单，只需要ROOT Frida开发比较灵活，适合灵活变动的API检测，但是后续每次检测都要通过命令行启动，稍微麻烦一些

开发使用，倾向于XPOSED，如果考虑自动化部署，倾向于Frida，可操作性更强。

APP隐私合规整改

原则：隐私策略同意之前，不获取任何用户的隐私数据，在未到达特定业务场景，不申请任何权限，用了任何权限跟隐私都要需要给出合理的公示

就APP多次整改的实践来看，违规非法收集个人隐私是最常见的，其中未经用户同意就搜集又是其中之最，这里的的原因有很多，其中系统设计跟法规审查的不一致是最关键点，隐私合规这个检查跟Android系统的设计就不是同频共振的，甚至还有些互斥，系统中并不存在这么一个暂停环节，让用户同意隐私策略后再继续后面的操作，这个隐私弹窗的展示在Android系统中，就已经属于业务的范畴，而非可定制的系统阻塞点，所以，并不容易处理。正常的开发是在APP启动之初就要初始化很多环境、参数，而这些初始化很可能涉及一些隐私API的调用，在隐私合规的框架下，这些调用只能被人为延后，或者取消。其次，虽然自身业务合规比较容易处理，但一些三方SDK的合规比较麻烦，部分可通过升级解决，而年久失修的SDK可能只能通过切面编程来解决不合规的问题，写插件是一个投入，而且插件多了影响编译效率，维护也麻烦。

对于动态权限的获取，有两点需要注意：一是在相关联的界面才申请，不要提前申请，第二是，申请权限之前必须要给出合理解释，即使有时候这个解释看起来有些多余，Google官方也是建议在某些敏感权限申请前添加提醒，但是在系统上不是必须的，不过国内的合规基本一刀切，强制必须添加。

对于隐私策略而言，主要关注点在于其一：隐私的搜集、存储、使用是否披露的详细、彻底；第二：三方SDK罗列的是否有遗漏，基本上满足这两点就可以。

总结

目前国内的隐私合规审查稍有些过于严苛，但是重病需猛药，先拨乱反正一下，将来也许会稍微放开一些，

Search

    Table of Contents