APP隐私合规现状与防范措施
2021年11月1《个人信息保护法》正式施行，标志信息保护进入时代，同时，APP监管也被提升到前所未有的高度，数据安全、用户隐私、甚至功能体验等各个方面都出台了相应的规则规范，监管的初衷是：从各个层面保障用户的权益，避免用户的隐私、体验、数据被滥用，甚至威胁国家安全，一旦违规被查处面临的惩罚是非常严厉的，因此产品运营方必须高度重视。一方面，在产品设计、开发阶段就要充分考虑并满足各种监管要求；另一方面，一旦查出隐患问题，要积极响应，及时整改，否则可能面临工信部通报，甚至全面下架风险，首当其冲的一块是：。APP隐私合规指简单说就是：用户隐私的收集、存储、使用、加工、传输、提供、公开、删除等都要，遵守原则。从APP端来看，它关系到用户的切身体验，用户自身也能直观感受到自己的隐私是否被过分索取。比如，申请与自身功能毫不相关的权限，不给还拒绝提供服务等场景。据信息通信研究院统计，截至2021.12.10，工信部共检测共244万款App，累计对5000+发出整改通知，通报2000+整改不利的APP，并下架600+ 拒不整改的APP。其中，重灾区在非法获取用户隐私、超范围收集个人信息、过度频繁过度索取权限、违规使用个人信息等， 其中违规收集个人信息占比48%、过度索取权限占比17%、超范围收集个人信息占比10%、违规使用个人信息占比8%、强制定向推送占比8%，这些也是APP检测与整改的重点区。这里所说的信息主要是指可以追踪、定位、识别个人身份的能力，多采用隐式方式获取。参考、，违规收集个人信息主要指如下场景：•••••••用户未同意前就开始收集•用户明确表示不同意后仍搜集，或频繁征求用户同意，影响使用•搜集信息超出用户授权范围或者违反其策略声明收集个人信息。•默认选择同意隐私政策•定向推送信息，未提关闭•这里所说的权限主要是指在系统层面需要用户授权，只有授权才能拿到部分信息，多采用方式获取。违规场景一般是指：在用户明确拒绝某些权限申请后，仍然频繁弹窗反复申请某项非必须权限，或者因为用户拒绝而整体拒绝提供服务。常见的表现有：•频繁索取：在商详用户明确拒绝了位置申请，仍在后续App运行期间，通过多种方式申请•强制索取：App首次启动时，向用户索取IMEI权限用作设备ID，用户选择拒绝授权，直接退出•过度索取权限: 阅读工具索取通讯录权限等《隐私政策》必须明确所有权限申请目的，并保证权限与功能的相关，拒绝某项功能性授权，不应该影响其他功能的正常使用，对于高风险的权限包括麦克风、短信、摄像头、定位等应谨慎对待。•（一）Android是隐私合规的重点处理对象整体来讲，iOS的生态更加健康、完善，相对于Google，苹果对隐私的重视程度更高，在系统层面支持的更好。并且，由于iOS系统不开源，国内的手机厂商全部是Android系统，每个厂商还都有自己的应用市场，导致生态特别混乱，Android的开源导致Google对于系统的话语权不是特别高，系统的碎片化很严重，通过系统升级来解决隐私问题几乎不可能，所以国内隐私合规审查的重点一直就是Android，而且基本上只能是Android，无论是从技术上，还是从话语权上，苹果都比较强势。•（二）Android的合规审查标准比较混乱隐私合规主要是工信部、网信办、各地通管局在一起推动的，但是具体的审查工作并不是这些部门在承办，而是交给第三方进行审查。一些应用市场为了保证自己市场的APP的质量，也会自定定义一套审查规则，所以就会导致这么一种乱象：A市场审查通过的APP，在B市场仍然有隐私合规问题，工信部审查合规的APP，无法通过部分应用市场的的审核标准。目前国内的主要的应用市场如下：相对iOS的唯一性，Android要处理的厂商是非常复杂，要处理的合规问题，也更加混乱，虽然隐私合规政策是正向的，但是在执行层面缺乏统一的认证标准，给开发、产品运营带来了很多额外的适配工作。比如，对于某些用户信息搜集的初衷，有些市场要求的会非常细，而且这个衡量并非机器在操作，而是有人工审核参与，主观性的判断就给这部分带来很多不确定性。目前，隐私合规基本是人工+自动化工具配合来共同完成，100%自动化审核还是比较困难，合规检测一般由专门的机构提供服务。这里检测分两种，一种是工信部、通管局发起的合规检测，另一种是开发者自己主动检测，工信部一般会雇佣第三方机构，对批量APP进行合规检查，根据结果出具整改通知，并后续审查，其审查流程一般是：工信部通管局的审查对开发者而言，一般是被动的，但是结果检测后，必须主动并积极解决，一旦处理不好导致通报或者下架的后果将是灾难性的。相对而言另一种就是开发或者法务主动检测，很多平台提供隐私合规检测服务，当然，并不是完全免费的，可以参考某个平台的报价：一次4000，可以看到价格并不低，主动检测的目的就是自查，将风险提前暴露。不过对于开发人员来说，这种方式并不是很友好，更需要一种实时、方便、廉价的自查方式各厂商或者平台审查使用的手段基本都类似，人工审查负责功能层面的校对，比如：是否提供定向推送的开关、是否提供隐私策略、隐私策略内容是否完整，规范、权限的申请是否合规等，更关注法务法规上的要求；工具审查更注重隐私信息的获取，是否调用了某些系统接口获取了用户信息，更注重合规需求。显式的合规比较容易满足，而且在交互设计阶段基本都已经处理了，所以重点关注下工具审查审查部分。用户敏感信息的获取都是通过调用系统API来实现的，所以目前的做法基本都是HOOK掉系统API，让后将调用的堆栈输出，看看在当前节点是否符合合规需求，比如在用户统一隐私策略前，任何调用敏感API的操作都是属于不合规的，开发过程中怎么处理呢？以Android系统为例，对于系统API的HOOK，有多种方案，比如XPOSED框架、Frida框架等，针对这两个的使用分别介绍下：•XPOSED本身是一个HOOK框架，它通过污染zygote进程，来HOOK整个系统中所有的进程，开发人员将ROOT过的手机安卓XPOSED框架后，就可以自定义HOOK规则，在隐私合规审查的场景中，针对所有的合规API添加钩子函数，在调用前打印出调用堆栈即可，之后将自己开发的模块安装到XPOSED框架中，通过日志即可实时看到敏感API的调用情况。该方式主要的工作在于编写XPOSED模块，实现代码为Java，可以在Android Studio中直接开发，对于Android开发来说，实现比较简单，但是每次修改都要重新部署到手机上，并且需要重启设备才能生效，开发初期效率可能比较低，但是固化下来之后，还是比较方便的。•同XPOSED框架相比，Frida更灵活一些，不需要安装什么框架，只需要在Root的手机上运行Frida-server即可，它可以通过编写JS、Python代码来和frida_server进行交互，Frida使用的是动态二进制插桩技术（DBI），在程序运行时实时地插入额外代码和数据，从而达到跟踪和拦截函数的功能。Hook脚本写法：该方式的虽然说比较灵活，但是使用起来稍微有些不便，每次都要直接或者间接的方式，通过命令启动脚本注入两种方式的对比：XPOSED框架在手机改造上比较麻烦，，除了ROOT，还要安装XPOSED，XPOSED的兼容性较差，但是后续的收益比较方便 XPOSED早期开发效率低，但是一旦Module固定后，后期几乎没有成本 Frida的配置比较简单，只需要ROOT Frida开发比较灵活，适合灵活变动的API检测，但是后续每次检测都要通过稍微麻烦一些开发使用，倾向于XPOSED，如果考虑自动化部署，倾向于Frida，可操作性更强。原则：隐私策略同意之前，不获取任何用户的隐私数据，在未到达特定业务场景，不申请任何权限，用了任何权限跟隐私都要需要给出合理的公示就APP多次整改的实践来看，，其中未经用户同意就搜集又是其中之最，这里的的原因有很多，其中，隐私合规这个检查跟Android系统的设计就不是同频共振的，甚至还有些互斥，系统中并不存在这么一个，让用户同意隐私策略后再继续后面的操作，这个隐私弹窗的展示在Android系统中，就已经属于业务的范畴，而非可定制的系统阻塞点，所以，并不容易处理。正常的开发是在APP启动之初就要初始化很多环境、参数，而这些初始化很可能涉及一些隐私API的调用，在隐私合规的框架下，这些调用只能被人为延后，或者取消。其次，虽然自身业务合规比较容易处理，但一些三方SDK的合规比较麻烦，部分可通过升级解决，而年久失修的SDK可能只能通过切面编程来解决不合规的问题，写插件是一个投入，而且插件多了影响编译效率，维护也麻烦。对于动态权限的获取，有两点需要注意：一是在相关联的界面才申请，不要提前申请，第二是，申请权限之前必须要给出合理解释，即使有时候这个解释看起来有些多余，Google官方也是建议在某些敏感权限申请前添加提醒，但是在系统上不是必须的，不过国内的合规基本一刀切，强制必须添加。对于隐私策略而言，主要关注点在于其一：隐私的搜集、存储、使用是否披露的详细、彻底；第二：三方SDK罗列的是否有遗漏，基本上满足这两点就可以。目前国内的隐私合规审查稍有些过于严苛，但是重病需猛药，先拨乱反正一下，将来也许会稍微放开一些，