专题研讨 | “隐私政策”的书写、展示、使用方式如何能兼顾监管要求、用户体验？

在国内外个人信息保护相关的法律法规中，“告知-同意”一直是重要的处理个人信息的合法性基础，“隐私政策”或“个人信息保护政策”作为向用户告知其个人信息处理规则的最主要载体，是长期以来最广泛使用的告知方式，点击同意“隐私政策”也成为了用户做出“同意”个人信息处理的最常见方式。然而，《个人信息保护法》中，明确强调了个人可以拒绝同意收集非必要信息，规定了“单独同意”的适用情形和要求，以及个人撤回同意的权利等，这些要求对“告知-同意”规则提出了更进一步的要求，仅依靠“隐私政策”弹窗等方式已经无法满足合规要求，如何让“隐私政策2.0版“，更好地适应监管要求和用户体验成为了合规实务工作的重中之重。

尤其是在第三方提供服务的场景下，第三方到底该如何展示隐私政策和承担责任，本次研讨会也得出了如下结论：

①如第三方以小程序、插件等形式并以自己的名义独立提供服务，则第三方在被嵌入的App或平台中应主动露出其身份，并向用户展示第三方的隐私政策。

②如果第三方的服务对象为企业，且第三方服务涉及到处理个人信息，则第三方宜在网站、社交媒体页面等公开渠道上披露相关的隐私政策，方便合作方、公众查阅。（TalkingData即属于此类型）

针对上述难点，CCIA数据安全工作委员会于近日组织各方专家进行了研讨，研讨会在TalkingData举办。与会专家从理清基础概念、探索实践路径、提出安全建议等角度各抒己见。现就研讨中形成的主要观点以会议纪要方式公开，供各界参考、指正。

参与此次研讨的专家来自：中国电子技术标准化研究院、国家信息技术安全研究中心、中国网络安全审查技术与认证中心等研究机构以及包括TalkingData在内的部分CCIA数据安全工作委员会委员单位。

以下观点仅代表专家个人观点。

研讨问题1：如何理解公布“隐私政策”的根本出发点和主要特点？

精彩观点如下：

☆ “隐私政策”的根本和法律意义就是实现个人信息处理规则的公开透明，不宜对其赋予太多的功能和期待。

☆ “隐私政策”的主要特点就是对个人信息处理活动的“全量告知”，其最突出的优点就是全面，同时由于其告知内容涵盖个人信息处理、个人信息主体权利等方方面面，从而难免冗长繁琐。

☆ 隐私政策的读者涵盖了用户（未成年人、青少年、老年人）、社会监督力量（如律师等专业人士、协会等专业组织）、监管部门等多种角色虽然难以兼顾读者的需求和体验，但重点还是要在不断追求合规性的同时，多注重用户体验，即隐私政策的语言、展示和使用方式是否得当，避免让用户重复被打扰、频繁要求同意、文本过度冗长。可向用户发起调研，多一些基于用户声音而做出的优化措施，不宜仅仅为了“避坑监管”而不断调整隐私政策。

研讨问题2：“隐私政策”哪些内容适合以重点摘要形式（又称“简版隐私政策”）展示，哪些内容适合以链接形式展示？

精彩观点如下：

☆ 简版隐私政策的内容宜突出用户关心的问题，披露核心的个人信息处理规则，方便用户获取关键信息，但不宜作为取得有效“同意”前的告知。

☆ 简版隐私政策适宜在用户更新App、重新安装App时主动向用户展示。

☆ 简版隐私政策可以放到完整版隐私政策全文页的顶部，或与完整版隐私政策以并列标签页或按钮展示，用户可根据自己的需要进行查看。

☆ 简版隐私政策的内容通常包括：主要业务功能收集的必要个人信息、敏感个人信息，用户关心的权限调用目的，如麦克风、位置，剪切板等。

☆ 简版隐私政策仅是一种实践探索，内容及结构不宜固化，而是根据产品或服务的功能特点、用户群体特点及用户反馈不断调整。

☆ 如使用海报、漫画、音视频等新颖的模式展示简版隐私政策，可以通过真实的用户点击数据、反馈分析展示的效果并优化展示的位置和方式。

☆ 在完整版的隐私政策中插入一些细分方向的个人信息处理规则的链接属于一种保证内容完备性的常见做法。以链接展示的处理规则还可以单独文本的方式独立在产品或服务的交互页面中展示。

☆ 可以链接方式展示的个人信息处理清单或单行规则通常包括：个人信息收集清单、SDK接入列表、App申请使用的权限列表、向第三方共享的个人信息清单、儿童个人信息保护规则等。

研讨问题3：App“隐私政策”首次展示的时机该如何选择？哪些时机属于告知？哪些时机可被用于征得用户同意？

精彩观点如下：

☆ 目前市面上绝大部分App还是选择在用户首次打开App时主动以弹窗形式展示用户协议和隐私政策，用户点击或勾选“同意”后才收集设备信息等个人信息。但从用户体验和法律效力的角度考虑，如果App明确设置了基本功能模式，用户在选择该模式时，App向用户告知基本功能所必需的个人信息后，用户可直接使用，无需设置同意隐私政策才能使用基本功能的环节。

☆ 注册、登录过程中，如果必须同意隐私政策才能继续使用App，隐私政策中应当明确只有触发到具体的业务场景才会收集个人信息，处理活动涉及敏感个人信息，或对个人权益可能产生显著影响的，还需要再次告知并取得用户单独同意。

☆ 如果在使用产品或服务过程中，需要用户对隐私政策进行多次同意的，宜将第一次视为构成对收集个人信息的同意，除非有证据证明第一次同意的用户与注册后使用的用户不是同一个人。

☆ 目前，很多App将同意隐私政策与安全风控、个性化推荐等功能的开启相关联，而具体业务功能则会在用户实际触发使用时才开始收集该功能下的个人信息。如果App未使用安全风控、个性化推荐功能，或将安全风控、个性化推荐功能设置成用户可在后续功能中自主选择的，并在基本业务功能下可以基于“履约之必要”处理个人信息而免去同意时，“隐私政策”与“用户同意”两者剥离才能成为可能。比如App首次打开时展示隐私政策，可以要求用户“知道”而无需用户“同意”隐私政策，然后用户还可以使用基本业务功能。

研讨问题4：“隐私政策”是否能被用于单独同意或书面同意的场景？

精彩观点如下：

☆ 点击同意“隐私政策”全文是典型的“概括同意”，而非单独同意。因此，“隐私政策”不能应用于“单独同意”场景下的告知内容，但在该场景下展示告知内容时，可以提供“隐私政策”的访问链接作为补充说明，以便用户可在单独同意的增强告知之外，还可以查看个人信息保护安全措施、主体权利实现方式、具体投诉联系方式等更多内容。

☆ “隐私政策”全文可以作为书面同意的对象。尤其是在特定领域的业务中，如银行开户、征信、保险、医疗健康等服务中，多需要用户以线上或线下方式对服务内容进行书面签署、确认同意，企业可以在用户做出这些书面同意之前或同时展示隐私政策文件以便用户知悉其同意的内容。

研讨问题5：如何将其他的告知同意与“隐私政策”进行更好地衔接，比如如何处理基本业务功能或扩展业务功能的告知同意与展示隐私政策之间的关系？

精彩观点如下：

☆ 如果产品或服务中的扩展业务功能较复杂、与基本业务功能相对独立，可以制定发布扩展业务功能下的单行隐私政策文本，以提升该功能下个人信息处理规则的透明度。

☆ 如果产品或服务的扩展业务功能比较简单，则可以在用户开启该扩展功能前，把隐私政策中扩展功能相关信息增强告知，而不用强制要求用户再次同意整个隐私政策。当然，如扩展业务功能涉及的个人信息处理活动是需要单独同意的，则需根据“单独同意”的要求实施。

研讨问题6：如何处理对集团下多个产品或服务隐私政策的关系？如何处理隐私政策中涉及关联公司的问题？

精彩观点如下：

☆ 隐私政策应能体现本产品或服务处理个人信息的具体规则，即便是使用相对统一的隐私政策结构，个人信息的处理目的、方式、种类等核心内容也应能和产品或服务的功能有所对应。

☆ 同一集团下多个产品和服务的隐私政策合并时，宜综合考虑多种因素，如不同产品或服务功能比较同质化，处理的个人信息种类和方式差别不大，且个人信息保护水平相当，则可以取“全集”的方式撰写统一的隐私政策，对个别功能的差异予以说明即可。如果“全集”会导致隐私政策内容过长、动辄两三万字的，则宜选择使用拆分版本的方式展示。

☆ 如果不同产品或服务的功能差异大、个人信息处理规则也有较大差别，如处理个人信息的种类和目的、共享的对象、个人权利的实现方式等都不一样，则不宜使用同一个隐私政策。

☆ 隐私政策中如提及关联公司的，比如共享用户个人信息给关联公司的，则需要明确界定关联公司的范围，必要时注明关联公司的名称。

研讨问题7：涉及一些特殊情形时，如适老化模式、青少年模式、嵌入第三方代码或插件、隐私政策的更新，隐私政策的使用有哪些注意点？

精彩观点如下：

☆ 适老化模式、青少年模式通常只是App完整业务功能的某些子集和服务体验部分调整，个人信息处理的目的等没有变化，通常无需制定单独的隐私政策，只用在触发App的这些模模式时，可就该模式下收集的个人信息情况予以简要说明（如说明仅收集较少信息），以实现增强告知效果。

☆ 如第三方以小程序、插件等形式并以自己的名义独立提供服务，则第三方在被嵌入的App或平台中应主动露出其身份，并向用户展示第三方的隐私政策。

☆ 如果第三方的服务对象为企业，且第三方服务涉及到处理个人信息，则第三方宜在网站、社交媒体页面等公开渠道上披露相关的隐私政策，方便合作方、公众查阅。

☆ 如果隐私政策的内容变更不会减损用户权益，则更新后可不通过弹窗等强打扰的方式进行提示和获得同意，以免引起用户不必要的担忧。

TalkingData——用数据说话

每天一篇好文章，欢迎分享关注