查看原文
其他

结合良好实践,细说APP自评估指南之一(DPO社群成员观点)

袁立志 胡科 网安寻路人 2020-02-26

编者按:


本公号在刊登DPO沙龙和相关社群活动的同时,还将刊登DPO社群成员的精彩文章。本篇作者为竞天公诚律师事务所的袁立志律师和胡科律师。


 正文:


2019年初,中央网信办、工信部、公安部及市场监管总局四部门联合发布了《关于开展App违法违规收集使用个人信息专项治理的公告》,要求相关机构依据法律法规和国家标准编制App违法违规收集使用个人信息治理评估要点。随后,APP专项治理工作组编制了《App违法违规收集使用个人信息自评估指南》(以下简称“《评估指南》”),该指南为App运营者自查自纠、提高个人信息保护能力提供了重要参考。


《评估指南》针对3大评估内容,共提出9项32个评估要点。本文结合App企业的良好实践,对这些要点进行深入讨论,以帮助App企业自查自纠,进行整改。

 

第一部分 隐私政策文本


在《网络安全法》下,获得用户的授权是企业收集、使用个人信息的主要合法性基础,企业应结合具体的业务场景合理选择获得授权的方式。在移动互联网场景下,引导用户阅读《隐私政策》并点击同意是获得用户授权的主要方式。因此,《评估指南》将隐私政策作为首要评估对象,对文本内容和形式均提出了详细要求。

 

评估项1. 隐私政策的独立性、易读性


评估点(1)  是否具备隐私政策


绝大多数企业都已经为其App配备了隐私政策。因此,是否具备隐私政策不再是行业的普遍问题。


除配备隐私政策外,企业还应确保其可查阅。在用户注册或首次开启服务时,应先通过弹窗提示核心条款,再在相关页面提供完整隐私政策文本的链接供用户点击查阅。用户注册完成后,仍可通过应用界面查找到隐私政策。隐私政策可置于产品或服务的主界面底部,或置于二级或三级页面中。


需要注意的是,有些企业同时通过多个渠道收集用户的个人信息,除了运营独立的App外,可能还运营网站、小程序、公众号等,这些渠道也应当配置隐私政策,而且最好做到统一维护和更新。比如每日优鲜就在其微信小程序中展示了隐私政策,这是值得推荐的做法。

 

评估点(2)  是否单独成文


目前大部分企业的隐私政策基本上都是单独成文的。有些企业将隐私政策作为用户协议的附件展示,或与用户协议放置在同一页面展示。我们理解,这符合“单独成文”的要求,但是与用户协议等置于同一页面,可能导致页面过长,用户查阅不方便。


还有一些企业的隐私政策是单独成文的,但在展示时,不是作为一个整体呈现在同一个页面,而是拆分成几个部分,分别配置链接,点开后不同页面展示不同的部分。这当然也符合“单独成文”的要求,也便于用户迅速查阅隐私政策的特定条款,但弊端是需要增加一个链接层级。

综合来看,主流做法是为隐私政策建立单独链接,在单一页面展示完整的隐私政策文本。

 

评估点(3)  是否易于访问


《评估指南》要求,进入主功能界面后,经过4次以内的点击可以到达隐私政策页面。4次的计算,起始页面是主功能界面,通常也就是打开App后的页面,有些App打开后会先跳出广告页,关闭广告页或等待其自然关闭后,才会出现主功能界面,因为关闭广告页的操作是在进入主功能界面之前,所以我们理解,这次点击是不计入4次之中的。4次点击的结果,应该是进入隐私政策文本页面,而不是链接隐私政策的标签(这样还需要一次点击)。


4次的上限显然是考虑了用户的忍耐程度,同时也兼顾了App页面设计的可行性。即使是功能复杂的App,如微信、支付宝都是在4次以内。如支付宝的隐私政政策的访问路径为:我的/设置/隐私/支付宝隐私权政策。也有的App层级非常简单,如东方航空App,只需2次点击即可访问到隐私政策,具体路径为:我的/隐私政策。


除了页面层级,还有几个因素会影响用户访问隐私政策的便利性,包括中间页面的布局、页面元素的多寡、页面的长度、标签的命名等。在用户到达隐私政策页面之前,会经过多个中间页面,如果这些页面布局很复杂,或者页面元素过多,用户就很难找到链接下一层页面的标签。如果页面过长,而指向隐私政策的标签放在页面下部或底端,也不利于用户迅速查找。此外,每一层页面中指向隐私政策的标签的命名也有讲究,如果命名字段不符合惯例,看不出与隐私政策的联系,也会对用户查阅隐私政策造成困难。如在设置界面中同时存在“隐私”和“安全”的字段,但隐私政策却置于“安全”菜单项下,此时很可能导致用户错误点击。常见的与隐私政策有关的标签有“我的”、“账户”、“设置”、“协议与声明”、“关于××”、“隐私”等。

 

评估点(4)  是否易于阅读


易于阅读是从用户的阅读体验角度来考虑的,包括文本使用的字号、颜色、行间距等。从行业实践来看,隐私政策的字体颜色通常都是白底黑字,鲜有使用彩色字体的。重要内容如敏感信息、免责条款等,一般用加粗字体,以示区别。


通过比较多款App的字号,我们发现,字号与App的设置有关,也可能与用户手机的型号及设置有关。在常见手机尺寸及默认设置下,单行字数在20-28字为宜,超过28字就显得太小,看起来很不舒服,少于20字则字体偏大,导致篇幅很长。行距一般为1倍或1.5倍。另外,段落之间及章节之间宜适当留白。


举例而言,百度的隐私政策所使用的字号、颜色、行间距、排版等较为适当,阅读比较舒适。

 

评估项2. 清晰说明各项业务功能及收集个人信息类型


评估点(5)  是否明示业务功能


在针对《个人信息安全规范》修改稿的讨论中,很多人对“业务功能”的含义提出疑问。撇开争论,来看头部企业在隐私政策中的做法,我们发现各企业对“业务功能”的口径把握其实相差不大。


比如,微信列举了14项业务功能,包括注册、微信、朋友圈、公众号(含小程序、小游戏等)、附近的人(含摇一摇及面对面建群等)、运动、通讯录、搜索(含搜一搜及看一看)、语音输入(含语音与文字转换、翻译)、支付、互通、时刻视频、微信号登录腾讯游戏、第三方接入。


再比如,支付宝也列举了14项业务功能,包括履行反洗钱和实名制义务、余额支付、快捷支付、转账、红包、AA收款、消费、信用卡还款、账单查询、身份验证、安全管理、语音输入、基于位置信息的服务推荐、客户服务。


我们发现,上述所谓“业务功能”,并不处于同一逻辑层次,划分的标准也不是单一的,有些甚至不能称之为业务功能,比如注册、客户服务等。我们理解,在划分“业务功能”时,有两种思路,既要从“功能”到“信息”,也要从“信息”到“功能”。对于特定App来说,某些功能项是显而易见的,比如对于微信App来说,微信、朋友圈、公众号等,无论是从产品设计还是用户感知角度来说,都是独立的功能项,从这些功能项来确定其所收集和处理的个人信息集,对应关系就建立起来了。而对于另外一些事项,则要采用从“信息”到“功能”的思路。在注册微信时收集和处理的个人信息集有一定的独立性,不同于使用微信时,也不同于其他功能,因此要将其视为一项独立的“功能”,这样从“信息”到“功能”的对应关系就建立起来了。这样的“业务功能”,从功能角度看似乎不具有独立性,或者根本就不是一项功能,但从信息角度看,确实存在一个独立的个人信息集,因此需要单独划定一个功能项。


《评估指南》要求,在列举业务功能时,不应使用“等”、“例如”等字样,其目的在于督促企业建立功能与信息之间的一一对应关系,便于主管部门监督和用户知情和维权。但是,我们注意到,绝对不用这些字眼是很困难的。我们认为,在尽可能明确功能和信息的情况下,出于行文的需要而不是恶意隐瞒的目的,少量使用这类字样,应该是可以接受的。


还有一个问题企业可能会经常遇到,即按照《评估指南》的要求,隐私政策只能列举现有业务功能及其对应的个人信息集,不能为拟开发或待开发的业务功能所需的个人信息预先获取用户的授权。对于这种情况,企业可待新功能上线时再征求用户的授权,不能混在现有的功能和信息中。

 

评估点(6)  业务功能与个人信息类型是否一一对应


观察隐私政策的演变史,可以发现早期的很多隐私政策是先列举要收集的个人信息类别,再笼统说明收集这些个人信息的目的(即功能),功能与信息不能一一对应。


《评估指南》明确要求建立功能与个人信息之间的一一对应关系,而且要求,不能出现多项业务功能对应一类个人信息的情况。这意味着,在撰写隐私政策时,只能采用从功能到信息的表述方式,一项功能可对应一项或多项个人信息,反过来则不符合要求。不符合这种结构要求的隐私政策应当重新梳理结构。

 

评估点(7)  是否明示个人信息类型


在确定某项功能后,应一一列举为实现该功能而必须收集和处理的个人信息的类别,不能使用“等”、“例如”等方式概括说明。如未来需要新增某类个人信息,应重新获得用户授权。

 

评估点(8)  是否显著标识敏感信息类型


对于敏感信息,常见做法是在隐私政策文本中加粗显示。比如,支付宝的隐私政策中对身份信息、银行信息等敏感信息字体加粗显示。顺丰隐私政策中也采用加粗字体突出显示。


除了加粗显示,还有些企业采用*标星号、下划线、斜体、颜色等方式进行显著标识,对敏感信息的判断可参考《个人信息安全规范》中的示例。

 

评估项3.  清晰说明个人信息处理规则及用户权益保障


评估点(9)  运营者基本情况


很多情况下,用户不了解移动App的运营主体是谁,比如用户可能只了解到该应用是某集团旗下的,或者知道其商标或标志,至于负责App运营的具体是哪一家企业,出了问题谁来承担责任,用户往往不清楚。这是对用户知情权的损害,也不利于用户维护自身权利。因此,《评估指南》要求企业在隐私政策中记载运营者的基本情况。比如,百度在隐私政策首部明确了运营者的公司全称,即“北京百度网讯科技有限公司”。

除了直接写明运营者的公司全称之外,也有一些企业使用公司简称、集团名称、“我们”等表述方式。如果使用这些表述方式,应当在隐私政策中给出定义或解释,指明具体的某一个或多个企业,才满足合规要求。如果运营者是一个集团,包括多家关联企业,股权情况比较复杂且未来可能发生变动,则可以采用“列举+概括”的方式说明关联企业的范围。


《评估指南》还要求列明运营者的注册地址和个人信息保护负责人(即DPO)的联系方式,评估点16要求隐私政策提供至少一种投诉渠道。这三者之间看似相似,其实不同。我们理解,注册地址是一个企业法律意义上的地址,可能是也可能不是企业的实际经营地址或联系地址,记载注册地址的意义主要在于确认运营者的法律身份,而不是方便用户进行联系。公布DPO的联系方式是为了督促企业落实DPO制度,宣示DPO的职责,DPO个人一般不会直接处理用户的行权请求和投诉。投诉渠道则是用户与企业之间进行日常沟通的渠道,用户的行权请求和投诉应当通过投诉渠道进行。由于三者的目的和意义不同,在隐私政策中的记载方式也不同。运营者的注册地址应当是运营者营业执照记载的地址,DPO的联系方式可以是DPO的工作邮箱、办公电话等,而投诉渠道则应当是客服部门的邮箱、电话、传真、在线客服或在线表格等。

 

评估点(10)      个人信息存储和超期处理方式


关于存储地域,企业应在隐私政策中说明将境内收集的个人信息存储在中国境内还是境外,但无需指明具体的存储地点。


尽管大多数App的隐私政策均宣称将个人信息存储在中国境内,但这并不是必须的。目前《网络安全法》只对关键信息基础设施运营者收集的境内个人信息和重要数据有本地存储的要求,另外特定行业(如金融业)有数据本地化的要求,而一般行业的个人信息本地化存储规则还不明确,至少在当前本地化存储不是强制要求。


隐私政策还应说明存储期限。由于存储期限由个人信息的使用目的所决定,不同的场景和目的下存储期限不同,故企业难以给出一个明确的时间区间或到期日。通常的处理方式是将存储期限规定为实现目的所必须的期限或法律规定的最短期限。比如,支付宝的隐私政策表述为:隐私政策所述目的所须期间及法律法规规定的时限内。微信的隐私政策表述为:实现目的所必须的时间,并举例:手机号在微信App使用期间一直存储直至注销微信账号。新浪微博则表述为:按照个人信息的不同等级存储不同期限,按照法律规定最少6个月。


用户行使删除权和账户注销权也会影响存储期限。通常情形下,用户行使删除权或账户注销权后,企业就应当不再存储个人信息,但是要注意一些例外情况,比如为了保存证据。高德地图的做法值得关注,其隐私政策规定:为了保存证据,用户删除或注销账户后36个月内高德将继续保存个人信息;如果用户删除信息或注销账户时愿意放弃与删除信息有关的法律救济权利,则根据网安法在6个月内删除。这是一个有益的探索,但是用户自愿放弃法律救济权利的承诺是否有法律约束力,值得商榷。


关于超期处理方式,实际上是指保存期限届满后的处理方式。主要有两种处理方式,一是将个人信息从系统中删除,确保不可被检索或访问;二是进行匿名化处理。(未完待续)




关于DPO沙龙活动的有关情况,请见:


DPO社群成果

  1. 印度《2018个人数据保护法(草案)》全文翻译(中英对照版)(DPO沙龙出品)

  2. 巴西《通用数据保护法》全文中文翻译(DPO沙龙出品)

  3. 美国联邦隐私立法重要文件编译第一辑(DPO沙龙出品)

  4. 《非个人数据在欧盟境内自由流动框架条例》全文中文翻译(DPO沙龙出品)

  5. 第29条工作组《对第2016/679号条例(GDPR)下同意的解释指南》中文翻译(DPO沙龙出品)

  6. 第29条工作组“关于减轻对处理活动进行记录义务的立场文件”(DPO沙龙出品)

  7. 第29条工作组《第2/2017号关于工作中数据处理的意见》(DPO沙龙出品)

  8. “美国华盛顿哥伦比亚特区诉Facebook“起诉书全文翻译(DPO沙龙出品)

  9. 第29条工作组《关于自动化个人决策目的和识别分析目的准则》(DPO沙龙出品)

  10. 法国数据保护局发布针对与商业伙伴或数据代理共享数据的指南

  11. 第29条工作组《数据可携权指南》全文翻译(DPO沙龙出品)

  12. 德国联邦反垄断局对Facebook数据收集和融合行为提出严格限制(DPO沙龙出品)

  13. 德国联邦反垄断局审查Facebook数据收集融合行为的背景情况(DPO沙龙出品)

  14. EDPB“关于《临床试验条例》与GDPR间相互关系”意见的全文翻译(DPO沙龙出品)

  15. 第29条工作组关于GDPR《透明度准则的指引》全文翻译(DPO沙龙出品)

  16. “108号公约”全文翻译(DPO沙龙出品)


线下沙龙实录见:

  1. 数据保护官(DPO)沙龙第一期纪实

  2. 第二期数据保护官沙龙纪实:个人信息安全影响评估指南 

  3. 第三期数据保护官沙龙纪实:数据出境安全评估

  4. 第四期数据保护官沙龙纪实:网络爬虫的法律规制

  5. 第四期数据保护官沙龙纪实之二:当爬虫遇上法律会有什么风险

  6. 第五期数据保护官沙龙纪实:美国联邦隐私立法重要文件讨论

  7. 数据保护官(DPO)沙龙走进燕园系列活动第一期

  8. 第六期数据保护官沙龙纪实:2018年隐私条款评审工作

  9. 第八期数据保护官沙龙纪实:重点行业数据、隐私及网络安全

  10. 第十期数据保护官沙龙纪实:数据融合可给企业赋能,但不能不问西东


线上沙龙见:

  1. DPO社群对数据堂事件的精彩点评

  2. DPO社群线上讨论第二期:“出售 & 提供” 个人信息之法律与实务对话

  3. 用户授权第三方获取自己在平台的数据,可以吗?不可以吗?(DPO沙龙线上讨论第三期)


时评见:

  1. 数据安全事件时评第一期

  2. 数据安全事件时评第二期

  3. 【时事五】微软、Facebook、谷歌和Twitter联合推出数据迁移项目:数据可移植性的开源计划

  4. 【时事六】 星巴克、阿里巴巴牵手“新零售”之数据合规深度评论

  5. 【时事七】美国通过《NIST小企业网络安全法》

  6. 【时事八】国际数据流动:欧盟委员会启动对日本的充分性决定流程

  7. 【时评九】加州IoT设备网络安全法对物联网法律之影响(附法案翻译)

  8. 【时评十】五问五答《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》

  9. 【时评十一】社交网络平台,需要多点爱还是多点管?

  10. 日本拟效仿德国:对IT巨头非法收集个人信息适用“反垄断法”

  11. 扎克伯格最新愿景:将Facebook打造成“关注隐私的社交网络“


DPO社群成员观点

  1. 个人信息委托处理是否需要个人授权?(DPO社群成员观点)

  2. 企业如何告知与保护用户的个人信息主体权利(DPO社群成员观点)

  3. GDPR“首张”执行通知盯上AlQ公司的前期后后(DPO社群成员观点)

  4. 隐私条款撰写调研报告(DPO社群成员观点)

  5. 我看到的数据安全(DPO社群成员观点)

  6. 数据爬取的法律风险综述(DPO社群成员观点)

  7. 银行业金融数据出境的监管框架与脉络(DPO社群成员观点)

  8. 解析公安机关《互联网个人信息安全保护指引(征求意见稿)》(DPO社群成员观点)

  9. 详解GDPR向Google亮剑缘由(DPO社群成员观点)

  10. 从生产安全体系视角看数据安全(DPO社群成员观点)

  11. 从Android Q看安卓系统的授权机制的三次重大演进(DPO社群成员观点)

  12. APP安全认证公告和实施规则解读:治理思路的创新与多样化(DPO社群成员观点)

  13. 从数据融合角度分析CNIL处罚谷歌案(DPO社群成员观点)

  14. 历史和国际比较视角DPO法律制度探源(DPO社群成员观点)

  15. 谷歌数据融合合规之路:从欧盟监管机构调查与处罚来看——上篇(DPO社群成员观点)

  16. 数据保护官岗位角色技术能力分析(DPO社群成员观点)

  17. 中国企业境外投资中儿童个人信息保护(DPO社群成员观点)

  18. 企业上市过程面临的数据合规问题和相关风险:境内篇(DPO社群成员观点)

  19. 企业上市过程面临的数据合规问题和相关风险:境外篇(DPO社群成员观点)

  20. 数据保护岗位需求与能力发展(DPO社群成员观点)

  21. DPO互助平台对企业数据治理实务的指导(DPO社群成员观点)

  22. 对网络安全负责人岗位的思考(DPO社群成员观点)

 


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存