小贝案语
11月14日，国家互联网信息办公布了《网络数据安全管理条例（征求意见稿）》。为此，小贝说安全设立《网络数据安全管理条例（征求意见稿）》（后文简称《条例》）解读专栏，以百问百答的形式对《条例》进行系列解读。
需要指出，这些解读只是专家个人观点，不代表官方意见；且这些解读针对的是征求意见稿，未来条文本身可能会发生变化，不排除会有新增和删除。
对应条款
第二十条 数据处理者处理个人信息，应当制定个人信息处理规则并严格遵守。个人信息处理规则应当集中公开展示、易于访问并置于醒目位置，内容明确具体、简明通俗，系统全面地向个人说明个人信息处理情况。
个人信息处理规则应当包括但不限于以下内容：
（一）依据产品或者服务的功能明确所需的个人信息，以清单形式列明每项功能处理个人信息的目的、用途、方式、种类、频次或者时机、保存地点等，以及拒绝处理个人信息对个人的影响；
（二）个人信息存储期限或者个人信息存储期限的确定方法、到期后的处理方式；
（三）个人查阅、复制、更正、删除、限制处理、转移个人信息，以及注销账号、撤回处理个人信息同意的途径和方法；
（四）以集中展示等便利用户访问的方式说明产品服务中嵌入的所有收集个人信息的第三方代码、插件的名称，以及每个第三方代码、插件收集个人信息的目的、方式、种类、频次或者时机及其个人信息处理规则；
（五）向第三方提供个人信息情形及其目的、方式、种类，数据接收方相关信息等；
（六）个人信息安全风险及保护措施；
（七）个人信息安全问题的投诉、举报渠道及解决途径，个人信息保护负责人联系方式。
解读
这里的“个人信息处理规则”实际上就是大家日常所说的“隐私政策”或“隐私协议”。在学术界，关于“隐私”与“个人信息”的关系，一直都有争论。《民法典》在第一千零三十三条列出了不得实施六类侵害自然人隐私权的行为，同时也在第一千零三十四条对个人信息作了定义。这种处理方式是否合理，迄今仍在争议，因为两者的重合内容太多，而且两者的定义是从不同角度作出的，不宜在法中并列。但无论如何，《民法典》的做法合乎常理，毕竟只使用“隐私”或“个人信息”都不足以反映人们对维护自身权益的客观需求。
但互联网行业长期以来的做法，是个人信息处理规则称为“隐私政策”，这个词从国外泊来（英文为Privacy Policy），已经成为了行业惯例。但就技术原理而言，其所针对的内容，更多侧重于个人信息保护，而不是隐私保护。因此，在《个人信息保护法》中，就没有再使用“隐私政策”的概念，甚至全然没有涉及“隐私”这个词。代替“隐私政策”的，是“个人信息处理规则”。
《个人信息保护法》第十七条规定：
个人信息处理者在处理个人信息前，应当以显著方式、清晰易懂的语言真实、准确、完整地向个人告知下列事项：
（一）个人信息处理者的名称或者姓名和联系方式；
（二）个人信息的处理目的、处理方式，处理的个人信息种类、保存期限；
（三）个人行使本法规定权利的方式和程序；
（四）法律、行政法规规定应当告知的其他事项。
前款规定事项发生变更的，应当将变更部分告知个人。
个人信息处理者通过制定个人信息处理规则的方式告知第一款规定事项的，处理规则应当公开，并且便于查阅和保存。
从上述条款的内容看，法律主要是要求对个人履行告知义务，但没有强制指定一定要通过制定一份文档的方式。但是如果制定了个人信息处理规则，则应当公开并便于查阅和保存。
但在实际生活中，虽然不排除有音频、视频等方式告知方式，但多数还是通过文档方式。况且，如果不是通过文档而是其他方式告知，那么《个人信息保护法》第十七条所列告知事项，难道不是“个人信息处理规则”吗？“个人信息处理规则”是指一个具体的文档，还是指“处理个人信息的规则”？这其中存在歧义。
《个人信息保护法》第十七条存在的另一个歧义是，既然该法第二章本来就叫做“个人信息处理规则”，即第二章所有的要求都是对个人信息处理规则的规定，那么为什么又在第十七条要求“制定”个人信息处理规则呢？显然，《个人信息保护法》同时使用了广义和狭义的“个人信息处理规则”。前者侧重“规则”，后者侧重展现形式（文档）。
为此，《条例》从现实出发，绕过了其中存在的歧义，直接要求数据处理者制定个人信息处理规则，且没有在其他条款中使用广义的“个人信息处理规则”。即，无论是在法的层面，还是条例的层面，都不再使用业内常用的“隐私政策”，而代之以“个人信息处理规则”。
但《个人信息保护法》第十七条规定的告知事项较少，从保护用户权益、更多履行告知义务的角度看，有必要增加告知事项，这是《条例》对个人信息处理规则作了进一步细化的原因。
另一点需要强调的是，一些人往往把“告知”和“同意”混为一谈，或者认为“告知”和“同意”是一个有着前后因果关系的关联动作。之所以有这种错觉，是因为以前的“同意”都是要求用户同意隐私政策。这实际上是错误的，隐私政策（个人信息处理规则）可以在一定时间内对所有人都是一致的，但每个人同意的事项怎么可能是一致的呢？否则用户的“选择权”怎么体现呢？“告知”和“同意”显然不是一回事，也不必然关联。存在的不一定是合理的，业内存在几十年的惯例应当作出改变。
对应条款
第二十条 数据处理者处理个人信息，应当制定个人信息处理规则并严格遵守。个人信息处理规则应当集中公开展示、易于访问并置于醒目位置，内容明确具体、简明通俗，系统全面地向个人说明个人信息处理情况。
个人信息处理规则应当包括但不限于以下内容：
（一）依据产品或者服务的功能明确所需的个人信息，以清单形式列明每项功能处理个人信息的目的、用途、方式、种类、频次或者时机、保存地点等，以及拒绝处理个人信息对个人的影响；
……
解读
一些人认为，《条例》第二十条第（一）项的“清单”有特殊含义，为此纠结于什么叫做“清单”。实际上，该项的立法目并不在于“清单”的具体形式，而是要求必须按照功能分别列出不同功能需要收集、使用的个人信息。因为必须按功能分别列出，所以自然就有了“list”（列表）的含义，按常识理解这就是一种“清单”。因此，这里强调的是功能与个人信息的对应关系，即不能脱离功能而笼统地要求收集处理一揽子的个人信息。
而且，“所需的个人信息”是指最小必要个人信息集，是为了完成功能所必需的个人信息，在没有此个人信息的情况下，该功能无法实现。例如，位置信息便是网约车功能的必需信息。
还有人提出，这个“功能”的颗粒度是多大？什么叫做“功能”？显然，存在着有的企业笼统、泛化描述一个软件的功能，从而规避对清单要求的可能性。目前，《条例》或其他权威文件还没有对此作出明确规定，但按照一般理解，这应当从用户角度考虑，满足用户一种特定需求的可以理解为是一种功能。这个“用户特定需求”是不能分拆的。如果可以分拆成多种需求，而且每种需求所需的个人信息不同，那么就不能认为这是最小粒度的功能。
此外，针对《条例》第二十条第（一）项还有一种质疑。即，该项的“依据产品或者服务的功能”同《条例》第二十一条（一）项的“按照服务类型”是什么关系？到底是按“功能”还是“服务”？“功能”和“服务”区别何在？
实际上，《条例》对此并无特殊考虑。《条例》第二十条第（一）项与第二十一条（一）项的出发点是完全相同的。至于两者在用语上的不同，可以在后续进一步修改完善。
对应条款
第二十条 数据处理者处理个人信息，应当制定个人信息处理规则并严格遵守。个人信息处理规则应当集中公开展示、易于访问并置于醒目位置，内容明确具体、简明通俗，系统全面地向个人说明个人信息处理情况。
个人信息处理规则应当包括但不限于以下内容：
……
（四）以集中展示等便利用户访问的方式说明产品服务中嵌入的所有收集个人信息的第三方代码、插件的名称，以及每个第三方代码、插件收集个人信息的目的、方式、种类、频次或者时机及其个人信息处理规则；
……
解读
《条例》第二十条第（四）项对产品服务中嵌入的第三方代码、插件提出了个人信息保护要求。之所以要强调此类要求，原因在于两点。
一是，在如今的App中，第三方代码、插件的应用十分广泛，很多第三方代码、插件大肆违法违规收集使用个人信息，已成个人信息安全事件高发地带。由于其不是App提供者开发的，故对App提供者的个人信息处理规则要求，会被很多人解释为不涵盖第三方代码、插件的提供者，从而造成事实上的法律真空地带。
二是，App中嵌入第三方代码、插件后，涉及到了平台与第三方的共同责任问题，需要法律法规作出规范。现实中，已经出现大量这样的案例：某软件声明，其内置的第三方代码与其无关，故第三方代码导致的个人信息安全事件也与其无关；但当该软件被集成到某平台时，其同时还作出声明，有关个人信息安全事件完全是平台责任，谁集成谁负责。这种“一推三六五”的情况比比皆是。
目前，最常见的第三方代码、插件是SDK（软件开发工具包，Software Development Kit，简称SDK）。一般用于提供某一明确、共性的功能，如果单独去开发这些功能可能会耗费App运营者的资源。为避免相同功能重复开发、提高新产品的研发效率，App提供者一般都会选择使用不同功能的SDK。使用场景一般是：SDK提供者将实现特定功能的代码进行封装，并提供简单的调用接口；App提供者将SDK嵌入App代码中，调用SDK提供的接口实现相应的功能，如果某些SDK具有独立交互界面，App交互页面也会将其嵌入。最终用户使用App时，通常对SDK及其提供者没有感知。当然，App提供者和SDK提供者可能为同一方，即App提供者使用自身开发的SDK。如果App提供者和SDK提供者不是同一方，通常将SDK称为第三方SDK。
显然，SDK作为一种功能明确的特定程序，其本身可以直接收集使用个人信息。但由于用户通常无感，SDK一般都是“偷偷摸摸”活动，故SDK曾长期脱离监管视野。目前，全国信息安全标准化技术委员会正在组织起草国家标准《信息安全技术 移动互联网应用程序（APP）SDK安全指南》，旨在压实SDK提供者的个人信息保护责任。
SDK带来的个人信息安全问题有多么严重呢？据统计，当前平均每款App都内置了不止20款SDK，基本上没有哪一款App无内嵌SDK，可见SDK的问题影响范围之大。
常见SDK类型包括但不限于推送、统计、支付、即时通信、第三方登录等，如下表所示（来源：《信息安全技术 移动互联网应用程序（APP）SDK安全指南（征求意见稿）》）。
对应条款
第二十条 数据处理者处理个人信息，应当制定个人信息处理规则并严格遵守。个人信息处理规则应当集中公开展示、易于访问并置于醒目位置，内容明确具体、简明通俗，系统全面地向个人说明个人信息处理情况。
个人信息处理规则应当包括但不限于以下内容：
……
（四）以集中展示等便利用户访问的方式说明产品服务中嵌入的所有收集个人信息的第三方代码、插件的名称，以及每个第三方代码、插件收集个人信息的目的、方式、种类、频次或者时机及其个人信息处理规则；
解读
鉴于SDK类型众多，《条例》只是规范了有“收集个人信息”功能的第三方代码、插件。但要求较为严格，数据处理者应当说明此类第三方代码、插件的名称，以及每项第三方代码、插件收集个人信息的目的、方式、种类、频次或者时机及其个人信息处理规则。且应以集中展示等方式进行说明，便利用户访问。
有人对此有疑问，如果不了解第三方代码、插件的个人信息收集功能及其个人信息处理规则怎么办？特别是，如果是开源的第三方代码、插件，其开发者本身是作公益贡献，到哪里去联系开发者了解个人信息处理规则？
这种情况有可能存在，但一个基本逻辑是，如果找不到开发者，你怎么敢使用他的代码呢？既然使用了第三方代码，你怎么能不为其收集个人信息的行为负责呢？显然，这完全不能成为App提供者豁免个人信息保护义务的理由。
《条例》第二十条第（四）项实际上对App提供者增加了新的义务，即App提供者要对内嵌的所有SDK的个人信息保护情况负责。那么，SDK实际在实施哪些个人信息处理活动？App提供者不能懵懂无知。为了避免合规风险，今后App提供者必须有能力监控内嵌SDK的个人信息处理活动，甚至能够阻断违法违规行为。这无疑将开创一个新的产业方向。
另外一个与此相关的事项是，为了减轻App提供者的合规压力，今后政府有关部门有必要建立对SDK的直接监管制度，以确保App提供者在内嵌SDK时，SDK的合规已经完成。
相关文章：
数安条例百问15、16、17、18、19：关于数据处理者安全保护义务
数安条例百问27、28、29、30：关于“一般要求”中的几个特定考虑
数安条例百问46、47、48：关于生物特征应用和一百万人以上个人信息处理者的适用
数安条例百问55、56、57、58、59：关于年度评估与对外提供数据的风险评估
RacentYY
Anna艳娜
RacentYY
Anna艳娜
安全侠
安全侠
Anna艳娜
FreeBuf
Anna艳娜
Anna艳娜
安全侠
