导言
最近一段时间都在做APP-隐私合规,做个简单总结。本文的主要切入点是Android端非技术问题
非技术问题主要集中在隐私政策上,对使用权限的说明,个人信息第三方共享清单(包含三方SDK收集的信息、目的、使用场景),个人信息收集与使用清单等。隐私政策可以参考很多大厂的APP(微信、手淘、天猫等,抖音的双清单在设置里愣是没找到),基本上都是大同小异。附上第一批设立双清单的互联网企业名单
个人信息第三方共享清单
这个主要是列出App内引用的第三方SDK,包括使用他们的业务场景、这些SDK收集了什么信息、收集信息的目的等等。当然也不是所有三方的SDK都要一一罗列,只有涉及到收集敏感信息的SDK才需要加入清单。 这块内容大部分可以直接参考大厂的APP个人信息收集与使用清单
这块内容不同公司之间的差距着实有点大。主要是体现在不同数据的规则和精细度方面。 在参考了几个大厂后(个人意见,仅做参考),做的比较好的是微信,手淘,苏宁,各种数据信息收集展示的很详细,与之相反的是,拼多多一点动态数据都没有,全是静态的文案。 这块问题,做为技术人员,最主要的就是做好技术支持工作,为法务和产品提供对应的技术支持。技术上的问题
随着隐私合规的标准越来越高,隐私合规的技术问题也越来越多;在处理的问题中,对碰到的技术问题做了几个大的分类。
- 用户同意隐私政策前做了不合规操作,比如读取了敏感api字段,申请了其他权限等,严格来说,用户同意隐私政策前最好不用执行其他代码
- 使用风险的api,例如几个手机硬件识别相关的字段(imei,imsi,mac地址,serial设备序列号等,android_id等),这些字段应该要尽量减少调用,最好是一次,次数多了就会有超频风险(据最新消息,后面可能一次都不让调用,android_id还是可以的)
- 和业务场景相关的问题。比如调用了剪贴板但是没有实际业务的具体场景说明、一进入APP就申请权限但没有业务实际说明的,这些都是不合规的。举个例子,大部分APP都会申请地理位置,但申请 权限的时机很重要,必须和实际业务相关的场景相结合才行。
- 三方SDK的问题,大部分SDK都会读取imei,imsi,mac地址,serial、Android_id等字段,这部分问题可以通过技术手段去解决(后文会提到),但最好还是通过升级SDK来解决。
如何自我检测
推荐隐私检测SDK,通过编译期替换敏感api方法调用,实现拦截和替换,可以解决大部分技术问题。
应对超频问题
什么是超频问题?简单来说就是不可变字段,在单次进程生命周期内读了好几次。比如Android_id,单个进程的生命周期内肯定是不可变的,所以针对这种字段不要在短时间内连续读取多次,不过现实是很多三方SDK我们控制不了,所以这个时候只能通过技术手段来解决,等待三方SDK来解决不现实。在不升级三方SDK的情况下,可以通过隐私检测SDK(上文中有提到)把代码里所有读取Android_id的地方收敛到一处,通过增加静态缓存来解决,当然这个时候要注意多线程问题,部分三方SDK都是在子线程里初始化的。所以超频问题如何解决呢?
多进程问题
这问题一般来说不致命,一般来说,我们只要控制好子进程不要重复初始化没必要的SDK就行。游客模式
游客模式很多APP都实现了,一般都是在拒绝用户协议后,提供几个独立的页面给用户使用(好鸡肋的功能,我愿称之为应付型功能...真有用户下载APP只为了点击个不同意隐私政策吗?)。简单介绍下游客模式,用户在拒绝隐私政策后不能结束APP,并且能正常使用一部分功能。
想要实现的话,还是要借助隐私检测SDK做到数据的拦截和替换,接着在业务上对无用SDK做到不初始化,游客模式的页面单独做开发,应该就能解决(这部分功能笔者还没做,目前还在设计阶段,因为牵扯到的东西比较多)
几个小tips
主进程判断方法,绕过敏感api
主要是绕过判断主进程方法的调用,一般判断主进程都会通过getRunningAppProcesses实现。 具体可以参考这个类