隐私合规治理阶段性总结

1,537 阅读5分钟

导言

    最近一段时间都在做APP-隐私合规,做个简单总结。本文的主要切入点是Android端

非技术问题

    非技术问题主要集中在隐私政策上,对使用权限的说明,个人信息第三方共享清单(包含三方SDK收集的信息、目的、使用场景),个人信息收集与使用清单等。隐私政策可以参考很多大厂的APP(微信、手淘、天猫等,抖音的双清单在设置里愣是没找到),基本上都是大同小异。

附上第一批设立双清单的互联网企业名单

123123.png

个人信息第三方共享清单

    这个主要是列出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实现。 具体可以参考这个类

实名羡慕ios
    从技术上说,ios要比Android方便很多,因为ios没有那么多hook框架去检查调用了哪些api,更多的是解决隐私政策(双清单等)、具体业务场景下的业务合规问题。

写在最后

    官方政策一直在更新,肉眼可见的预期是隐私合规这块会越来越严格,如果不想APP或者自家的SDK被通报下架,后面的工作也会越来越多。后续再更新~