对《常见类型移动互联网应用程序必要个人信息范围规定》的再理解

编者按：

今天，国家互联网信息办公室秘书局、工业和信息化部办公厅、公安部办公厅、国家市场监督管理总局办公厅联合发布了《常见类型移动互联网应用程序必要个人信息范围规定》【全文见：关于印发《常见类型移动互联网应用程序必要个人信息范围规定》的通知】。

如何理解该规定，在第一篇文章中，公号君从两个方面（必要个人信息和基本功能服务）入手，分别结合《个人信息保护法（草案）》和《个人信息安全规范》的相关条款进行分析，供大家参考批判。详见：对《常见类型移动互联网应用程序必要个人信息范围规定》的两点理解

在第二篇文章中，公号君将对为什么要提出基本功能服务这个概念，做深度的分析。主要内容来自于公号君2019年出发表的文章【过度收集个人信息如何破解】

在《常见类型移动互联网应用程序必要个人信息范围规定》发布之后，公号君遇到最多的一个问题是：为什么要界定基本功能服务？GDPR都只是规定了数据最小化的要求，中国的监管机构直接要求APP做这样的划分，理由和正当性何在？

以下为2019年年初发表文章的内容

------------------------------------------------------------------------------

---

在移动互联时代，如果单从收集环节来看个人信息保护来看，最突出的问题应是大众应用程序（app）过度收集用户的个人信息。开发、经营app的网络运营者如违反了《网络安全法》关于“不得收集与其提供的服务无关的个人信息”的规定，掌握了本不该获得的个人信息，一旦发生信息的滥用、误用，或发生了信息的泄露、毁损、丢失，对用户合法权益造成的损害将成倍地放大。

另一方面，数据即石油、数据是黄金，已经成为数字经济的常识。在经济利益的驱使下，网络运营者有着天然的冲动最大程度地收集个人信息，用于自己的经营活动中。现实中，他们往往采取以下两条路径：

一是隐瞒收集个人信息的功能、类型、范围等，偷偷地收集个人信息。这方面不仅直接面向用户的网络运营者会这么做（即直接欺瞒用户），那些给app提供功能模块或组件的第三方开发者也会偷偷嵌入收集个人信息的指令或功能，试图“搭便车”收集个人信息（即同时欺瞒app开发者和用户）。

二是强迫用户同意授权其收集个人信息，即通过“一揽子协议”强制用户授权。如果细究起来，“一揽子协议”还可分为两个方面：服务或功能捆绑，以及故意扩大服务或功能所必需的个人信息。面对这样的“一揽子协议”，用户要么只能全盘接受，要么只能退出走人。

那现有的法律提出了应对之策吗？目前，在《个人信息保护法》还未出台前，《网络安全法》提出了对个人信息最为完整、全面的保护设计。如下表所示：

	细分行为	《网安法》对应条款
过度收集个人信息	隐秘收集	直接面向个人用户的网络运营者欺瞒收集行为	1.   22条第2款：“网络产品、服务具有收集用户信息功能的，其提供者应当向用户明示并取得同意；涉及用户个人信息的，还应当遵守本法和有关法律、行政法规关于个人信息保护的规定。” 2.   41条第1款：“网络运营者收集、使用个人信息，应当遵循合法、正当、必要的原则，公开收集、使用规则，明示收集、使用信息的目的、方式和范围，并经被收集者同意。”
向上述网络运营者提供功能模块或组件的第三方开发者隐瞒收集行为
强制收集	服务或功能强制捆绑	无直接对应的条款
扩大单个功能必需收集的信息类型、数量等	41条第1款：“网络运营者不得收集与其提供的服务无关的个人信息”

一、对隐秘收集的分析

从上表可知，针对隐秘收集，《网安法》有直接规范该行为的条款。无论是直接面向个人用户的开发者（以下简称“第二方开发者”），还是第三方开发者，均需要明示其收集的功能，不能偷偷摸摸地收集。具体情况如下：

如果第三方开发者承当个人信息控制者的角色（即有权决定个人信息处理目的和方式），则第三方开发者所明示的用户有两类，分别是个人用户和嵌入其服务的第二方开发者。此时明示的方式可以又分为两种：第一种是第三方开发者直接向个人用户明示并取得同意；

第二种是第二方开发者在其向个人用户的告知文本中明确点出第三方开发者的存在，明确说明第三方开发者收集个人信息的目的、规则、范围等，并代替第三方开发者取得个人用户的同意。

实践中，在第二种明示方式下，往往个人用户只能一次性给出对第二方开发者和第三方开发者的同意授权，因此存在“服务或功能强制捆绑搭售”（对其分析见下文）的情况，个人用户的同意实际上被架空。

还要注意的是：第三方开发者如果不决定其所收集的个人信息的处理目的和方式，仅仅依照控制者的指令行事，且绝不截留私自存储个人信息另做它用，其仅仅承当个人信息处理者的角色（此处借用欧盟GDPR的定义）。此时，第二方开发者在向个人用户的告知文本中，可以自主选择是否披露第三方存在，因为本质上其需要承担的法律责任并不会转移给个人信息处理者。

二、对强制收集的分析

强制收集是民众非常厌烦的问题，但如何破解却又是非常困难的课题。第一，按照《网安法》第41条第1款从字面上，可理解为仅要求第二方开发者明示其提供的服务或功能即可（无论这些功能或服务有多少）。

第二，该条款将“必要”作为基本原则，“必要”原则又可以理解为仅提供必要功能（及服务），还可以理解为要求单个功能中仅收集必要的信息。但对于“必要功能”或“必要信息”，开发者往往能提出各种各样的理由来证明必要性，同时由于存在严重的信息不对称，个人用户基本无法辩驳。

第三，当服务或功能捆绑在一起了，或者每个服务或功能所明示的是一种“扩大版”的必要信息后，个人用户面临的是要么接受，要么走人的局面（take it or leave it）。

由于存在上述三点，第二方开发者只需要修改隐私政策文本，强制用户点击同意，即在表面上完成了《网络安全法》的合规，就可以大肆收集个人信息了。因此，要过度收集个人信息，最重要的议题就是破解强制收集，实际上则是要遏制两种行为：一是强制捆绑服务或功能；二是夸大单个服务（或功能）所必要的个人信息。很可惜，我国现行的法律法规在这方面并没有给予足够的指导。

三、外国经验的分析

1、欧盟《通用数据保护条例》

在破除服务或功能强制捆绑方面，GDPR主要通过个人信息处理的合法事由的设计来实现。GDPR第六条规定了个人信息处理合法的六项事由：一是数据主体对出于单个或多个特定目的而处理其个人数据表示同意；二是处理是为向身为合同当事人的数据主体履行合同所必须的，或在缔约前，应数据主体的要求所必须采取的步骤；三是因履行数据控制者承担的法律义务而必须处理个人数据的；四是为保护数据主体重大利益或其他自然人重大利益而必须处理个人数据的；五是为公共利益而执行任务，或数据控制者履行赋予的公共职能时，必须处理个人数据的；六是因数据处理者正当利益或第三方正当利益而必须处理个人数据的，但当数据主体的利益或基本权利和自由（特别当数据主体尚未成年时）高于上述正当利益时，不得使用该事由。

个人信息控制者基于特定目的而开始收集个人信息之前，需要事先确定自己所依赖的合法事由，且不能在后期随意更改。而且每项合法事由使用有着严格的限制，不同合法事由后期搭配的个人信息主体的权利也不尽相同。因此，可以说选择合法事由，是个人信息控制者开展业务前最核心的工作。

合法事由的选择，在很大程度上破除了服务或功能的强制捆绑。例如当个人用户要求物流公司送货到其住所时，这是用户主动要求的服务，因此物流公司处理个人信息（个人用户的姓名、地址、电话等）的合法事由是“合同所必需”。这是如果物流公司将其特定时期其收集的个人信息汇总分析，目的是优化其配送服务，此时物流公司不能够再依赖“合同所必需”，转而应该要求“个人信息主体的同意”或者其“正当利益”这两个选项。

换句话说，通过强制个人信息控制者为不同的处理目的（包括目的所涵摄的一系列处理行为）来选择不同的合法事由，GDPR自然打破了服务或功能的强制捆绑。因为不同功能或服务，很可能需要不同的合法事由，不能混为一谈，一次性征求个人同意。反过来看我国，上述物流公司的例子在我国目前的商业实践中，基本是将所有的个人信息用途打包在一起，征求个人用户的同意。

我国目前的法律法规中，关于个人信息处理的合法事由是个人同意，缺乏像GDPR那样的设计。因此欧盟破解强制捆绑的路径在我国无法借鉴。

2、美国FTC的路径

美国并没有欧盟上述的合法事由的设计，但美国联邦贸易委员会（FTC）事实上区分了三个层次的同意和退出机制，也在一定程度上遏制了功能或服务强制捆绑的问题：

首先，对于个人用户在具体场景中能够合理预期（reasonable expectation）到会被收集、使用的个人数据，可以推定为用户已经明确授权同意。但对于这个场景中按照推定收集所获得的数据，转做它用，或者提供给与具体场景中无关的第三方做其他用途时，个人用户很可能无法合理预期，这时候还出现以下两种路径：一是对于个人敏感信息，需要用户自主选择同意（opt-in）是否专做其他用途或者提供给第三方；二是对于非敏感信息，用户通过选择退出的途径（opt-out）来形式选择权。

其次，第二方开发者需要收集在具体场景用户可合理预期之外的个人敏感信息时，最开始就需要用户自主选择同意（opt-in）。

再次，第二方开发者需要收集在具体场景用户可合理预期之外的非敏感信息时，需要给用户提供选择退出（opt-out）的机制。

以上三层次的同意和退出机制，均不能免除向用户告知的义务。只不过告知的形式，按照FTC的要求，也应该根据符合或偏离用户预期的程度、个人信息敏感程度、时机等方面综合考虑。同时，FTC还非常强调，当个人用户在市场上选择较少时，服务提供者不得以提供服务为条件强迫用户同意不合理条款。例如用户选择宽带服务时，宽带服务提供者不得强迫用户同意其记录、追踪用户所有的上网行为并用于推送广告目的，特别是用户如选择不同意就不提供宽带服务。

将上述路径对照欧盟GDPR的设计，可发现很大程度的重合。在具体场景中符合合理预期，与GDPR中的“合同所必需”异曲同工。个人用户自主选择进去某个服务或者功能场景，与用户主动要求签订合同相近。在这样的场景中，用户应当知道，也愿意提供完成服务或功能所必需的信息。

对于这之外的场景，如果是个人敏感信息，美国要求自主选择同意，与GDPR中的同意相近。对于非敏感信息，美国要求选择退出，与GDPR合法事由中的“正当利益”相近。

但美国FTC的路径为中国所借鉴存在困难，原因主要有两点：一是我国法律中并没有明确区分自主选择同意、选择退出、个人敏感信息等实施美国路径所必需的核心概念。二是合理预期这个概念难以落地，在实践中，（不同群体、特征的）用户、第二方、第三方、监管机构、消费者保护组织、律师、咨询机构、媒体等，对某个场景下合理预期都可能存在各自的理解。这就意味着，作为FTC路径中的核心要素，落实起来需要很高的外部条件。我国目前的监管资源和条件（如理解难以统一、管理水平不一、央地同时管辖等）似乎不足以支撑以不确定的法律概念开展个人信息保护的路径。

3、收费和非收费的路径

国内外具有学者提出可采用区分收费和非收费服务的路径，来开展个人信息保护。该路径基本逻辑如下：

首先，开发者提供服务或功能是有成本的，只能通过对个人用户的信息进行商业化开发利用（目前主要形式是通过推送个性化广告）取得回报，以对免费提供服务或功能进行补贴。其次，如果个人用户愿意付费，贴补开发者提供服务或功能的成本，则开发者就应当避免对付费用户的个人信息进行商业化开发利用。再次，对于不愿意付费的用户，则开发者保持对其个人信息开发利用的权利。

仔细分析上述模式，可知该路径并不避免个人信息的收集。为完成个人用户所需要的服务或功能，个人用户应当同意开发者收集、使用某些类别和数量的个人信息。只不过，由于用户付费了，开发者不得再将提供服务或功能过程中所必需的个人信息转而用于商业化开发利用。

从这个角度来看，这个路径和欧盟GDPR有很强的共通之处。为完成用户所需要的服务或功能，都需要允许收集、使用一定的个人信息，类似于GDPR中“合同所必需”。但是由于用户付费了，所以开发者不得再向用户提出将信息转于它用的请求，也就是说在收费路径中，开发者不得再采取GDPR中“用户同意”和“正当利益”这两个合法事由。

落实上述路径，应主要通过市场竞争的方式细分出愿意采取收费路径的商业模式。因此国内外鲜见通过公权力推行该路径的例子。

四、目前我国类似的法律规定

实际上，我国法律法规存在着类似的GDPR和FTC的路径区分。以下以《中国人民银行关于银行业金融机构做好个人金融信息保护工作的通知》(银发〔2011〕17号)，以及《中国人民银行金融消费者权益保护实施办法》(银发〔2016〕314号)为例。其主要规定总结如下：

目的	具体要求	规定条目
1、建立业务关系	可以使用格式条款；	银发〔2016〕314号第30条
1)格式条款应明确（消费者要求的）金融产品和服务所必需的个人金融信息； 2)不得收集与业务无关的信息。	银发〔2016〕314号第28条
1)在格式条款中明确该授权或者同意所适用的向他人提供个人金融信息的范围和具体情形；应当在协议的醒目位置使用通俗易懂的语言明确向金融消费者提示该授权或者同意的可能后果，即必须明示； 2)对于（消费者要求的）金融产品和服务所必需的向他人提供个人金融信息的（以及他人获得个人金融信息后的使用），可以用概括授权的方式取得消费者同意，即可以一揽子概括授权；  3)金融机构可以将“该业务关系的性质决定需要”所必需向他人提供个人金融信息的（以及他人获得个人金融信息后的使用），作为“与金融消费者建立业务关系的先决条件”，即可以强制要求消费者同意。	银发〔2016〕314号第30条 银发〔2016〕314号第31条
1) 对于（消费者要求的）金融产品和服务无关的向他人提供个人金融信息的（包括他人获得个人金融信息后的使用），不得以概括授权的方式取得消费者同意，只能单独要求授权； 2) 对于与（消费者要求的）金融产品和服务无关的向他人提供个人金融信息（包括他人获得个人金融信息后的使用），金融机构不得将金融消费者授权或者同意其将个人金融信息对外提供等作为与金融消费者建立业务关系的先决条件，即不得强制要求消费者授权或同意；	银发〔2016〕314号第30条 银发〔2016〕314号第31条
2、办理相关业务过程中	使用个人金融信息时，应当符合收集该信息的目的，并不得进行以下行为： 1) 出售个人金融信息； 2) 向本金融机构以外的其他机构和个人提供个人金融信息，但为个人办理相关业务所必需并经个人书面授权或同意的，以及法律法规和中国人民银行另有规定的除外； 3) 在个人提出反对的情况下，将个人金融信息用于产生该信息以外的本金融机构其他营销活动。	银发〔2011〕17号第四点
3、第一方营销	1) 对于与（消费者要求的）金融产品和服务相关的营销，如果该营销为“该业务关系的性质决定需要”，可以直接通过格式条款获得“概括性授权”，也可以强制要求消费者同意； 2) 对于与（消费者要求的）金融产品和服务相关的营销，如果该营销不为“该业务关系的性质决定需要”，不得直接通过格式条款获得“概括性授权”，不得强制要求消费者同意； 3) 对于与（消费者要求的）金融产品和服务无关的营销，金融机构不得将金融消费者授权或者同意其将个人金融信息对外提供等作为与金融消费者建立业务关系的先决条件，即不得一揽子概括授权，且不得强制要求消费者授权或同意。 4) 对于将个人金融信息用于与（消费者要求的）金融产品和服务不相关的（即“产生该信息以外的”  金融产品和服务的）营销，如果个人前期选择同意了，但是后期个人提出反对，金融机构应当停止相关营销活动，即应当给予个人反对或退出的权利。	银发〔2016〕314号第31条 银发〔2011〕17号第四点
4、业务之外的非营销事项	1)  必须明示； 2)  不得概括性授权； 3)  不得强制授权。	银发〔2016〕314号第20条

上述要求总结如下：

1.   对于（消费者要求的）业务所必需的个人金融信息的收集、（机构内部办理业务所必需的）使用，金融机构应当明示，可以通过格式条款要求概括性授权，可以要求用户必须给予同意或授权；

2. 对于（消费者要求的）业务所必需的对他人提供（包括他人获得个人金融信息后的使用），金融机构应当明示，可以通过格式条款要求概括性授权，可以要求用户必须给予同意或授权；

3. 对于（消费者要求的）金融产品和服务相关的营销活动，如果该营销为“该业务关系的性质决定需要”，可以直接通过格式条款获得“概括性授权”，也可以强制要求消费者同意；

4. 对于与（消费者要求的）金融产品和服务相关的营销，如果该营销不为“该业务关系的性质决定需要”，不得直接通过格式条款获得“概括性授权”，不得强制要求消费者同意；

5. 对于与（消费者要求的）金融产品和服务不相关的营销，不得一揽子概括授权，且不得强制要求消费者授权或同意；如果前期个人选择同意但后期反对，金融机构应当停止营销活动；

6. 对于（消费者要求的）金融产品和服务之外的非营销事项，必须明示、不得概括性授权、不得强制授权。

可以看出，人民银行的上述规定，基本上遵循了GDPR中“依合同所必需”以及“同意”两项合法性事由的区分，以及FTC关于“合理预期”和“合理预期”之外的个人敏感信息收集的要求。

五、《个人信息安全规范》所选择破解强制收集的路径

在国家标准《个人信息安全规范》的制定过程中，标准编制组充分研究了国内现行的法律法规，以及国外破解强制收集的主要路径（如前所述），最终标准编制组决定避免直接照搬国外的做法，而是借鉴国外路径的本质思路，创设出产品或服务核心功能（或称为基本功能）、附加功能（或称为拓展功能）的概念，做出了如下制度设计：

首先，产品或服务应当自行区分核心和附加功能。其次，对于核心功能或服务，个人用户应当允许运营者收集实现该功能或服务所必需的个人信息，否则该功能或服务无法完成。此时如果用户选择不同意，则允许运营者不向用户提供功能或服务。但对于附加功能，应当允许用户逐一选择是否需要。同时标准要求，“当个人信息主体拒绝时，可不提供相应的附加功能，但不应以此为理由停止提供核心业务功能，并应保障相应的服务质量”。

上述核心功能和附件功能的设计，意在打破“强制收集”的行为。本质上，核心功能仿造了GDPR中的“合同所必需”，以及FTC的“合理期待”；附加功能仿造了GDPR中的“个人同意”，以及FTC要求的“合理期待”之外的个人敏感信息的收集。

实践中，企业经常询问如何区分核心和附件功能？这个问题，是打破强制收集的关键。有些投机取巧的开发者会将所有的功能全纳入核心功能的框中，然后还是强迫个人用户授权同意。如此一来，核心和附加功能的区分将流于形式。为避免这个问题，我们存在两种思路：

一是通过市场竞争或者社会监督的路径来解决。比如说，同样是通信软件，有一家企业把核心功能定义得特别大，附加功能定义得特别小；另外一家把核心功能定义得很小，附加功能定义得很大。对如此大的差别，相信一定会有社会监督机构（如消费者保护组织、媒体、高校研究人员等）或监管机构对此展开调查或约谈，要求企业对自己的划分给出合理的解释。如此一来，通过市场上的竞争和比较，逐渐能够形成各行业关于核心功能和附加功能区分的惯例。换句话说，在这个思路下，标准只要求企业自主划分功能，并对划分提出具体、合理的解释，然后交由市场和外部力量来对企业的划分和解释进行监督。概括起来，该思路提倡通过自下而上，形成对功能的合理划分，打破强制收集的行为。

另外一种思路是由标准化机构针对民众经常使用的应用程序，提出各类应用程序的基础功能和拓展功能的划分指引，并提出具体功能或服务所必需收集、使用的个人信息的最小集合。如此一来，指引能够打破前文所述的强制收集所存在两类行为。而且这样的指引，在通过广泛参与、广泛征集意见、反复试点验证的基础上形成，并定期修订更新。虽然指引不具备法律上的强制力，但是企业对于偏离指引的做法，应当承当具体的解释义务。（完）

------------------------------------------------------------------------------

在2020版本的《个人信息安全规范》的正文部分，并没有要求明确区分核心功能或附加功能（也就是《常见类型移动互联网应用程序必要个人信息范围规定》要求的基本功能服务，以及其他功能服务），而是将所有的功能服务一视同仁，平等要求。这背后主要参考了当时编制组成员企业代表的意见。

在正文中最后达成了一个compromise——

大家可以看到，《个人信息安全规范》正文中：所有功能服务一视同仁的同时，用户应该能够随时开启或关闭各个功能服务。其实公号君认为这个要求更加难以实现。

相反，如果区分基本功能服务和其他功能服务，如果用户不同意收集必要个人信息的话，确实APP可以停止运行或退出，因为基本功能服务无法实现。在公号君看来，这样的方式相对容易实现。

但当时出于在工作组内部达成合意的考虑，最终选择了“所有功能服务一视同仁”的方案，将“区分基本功能服务和其他功能服务”的方案，放到了附录C。

现在来看附录C中相关要求——

很多企业代表很不理解如何划分基本功能服务，因为目前APP大多为平台型的APP，同时承载了很多功能服务。

公号君认为，在注1和注2中阐释得很清楚。最最核心的是，站在用户角度做划分，而非是从企业自身的角度做出划分。

其实大家只要打开自己手机，查看已经安装的各个APP，都会发现，当初下载时，都是为了一个主要功能。这个主要功能，或是从APP的名字，或是从APP的推广等，都能够很容易的辨识。毕竟APP运营者在推广时，一定会希望自己的APP的名字和图片非常醒目和传神，就如和文章取名一样。

其实无论是安卓还是苹果的开发者文档，也都要求开发者确定APP具备core functionality. 

而且希望大家多读几遍注1和注2，里面传递了很多的信息和内容。（完）

数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过300人。关于DPO社群和沙龙更多的情况如下：

域外数据安全和个人信息保护领域的权威文件，DPO社群的全文翻译：

DPO线下沙龙的实录见：

美国电信行业涉及外国参与的安全审查系列文

中国的网络安全审查系列文章：

自动驾驶系列文章：

数据安全法系列文章：

个人数据与域外国家安全审查系列文章

围绕着TIKTOK和WECHAT的总统令，本公号发表了以下文章：

中国个人信息保护立法系列文章

第29条工作组/EDPB关于GDPR的指导意见的翻译：

关于美国出口管制制度，本公号发表过系列文章：

供应链安全文章：

人脸识别系列文章：

数据跨境流动政策、法律、实践的系列文章：

传染病疫情防控与个人信息保护系列文章

人脸识别系列文章：

关于欧盟技术主权相关举措的翻译和分析：