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

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

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

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

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

一、对隐秘收集的分析

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

如果第三方开发者承当个人信息控制者的角色（即有权决定个人信息处理目的和方式），则第三方开发者所明示的用户有两类，分别是个人用户和嵌入其服务的第二方开发者。此时明示的方式可以又分为两种：第一种是第三方开发者直接向个人用户明示并取得同意；第二种是第二方开发者在其向个人用户的告知文本中明确点出第三方开发者的存在，明确说明第三方开发者收集个人信息的目的、规则、范围等，并代替第三方开发者取得个人用户的同意。

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

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

二、对强制收集的分析

强制收集是民众非常厌烦的问题，但如何破解却又是非常困难的课题。

第一，按照《网络安全法》第41条第1款的字面表述，可理解为仅要求第二方开发者明示其提供的服务或功能即可（无论这些功能或服务有多少）。

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

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

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

三、对国外经验的分析

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

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

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

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

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

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

2. 美国FTC的路径

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

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

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

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

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

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

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

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

3. 收费和非收费的路径

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

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

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

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

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

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

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

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

上述核心功能和附件功能的设计，意在打破“强制收集”的行为。本质上，核心功能仿造了GDPR中的“合同所必需”，附加功能仿造了GDPR中的“个人同意”。

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

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

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