在移動互聯時代，如果單從收集環節來看個人信息保護，最突出的問題應是大衆應用程序（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中的“個人同意”。

實踐中，企業經常詢問如何區分核心和附件功能？這個問題，是打破強制收集的關鍵。有些投機取巧的開發者會將所有的功能全納入核心功能的框中，然後還是強迫個人用戶授權同意。如此一來，核心和附加功能的區分將流於形式。爲避免這個問題，存在兩種解決思路：

一是通過市場競爭或者社會監督的路徑來解決。比如說，同樣是通信軟件，有一家企業把核心功能定義得特別大，附加功能定義得特別小；另外一家把核心功能定義得很小，附加功能定義得很大。對如此大的差別，相信一定會有社會監督機構（如消費者保護組織、媒體、高校研究人員等）或監管機構對此展開調查或約談，要求企業對自己的劃分給出合理的解釋。如此一來，通過市場上的競爭和比較，逐漸能夠形成各行業關於核心功能和附加功能區分的慣例。換句話說，在這個思路下，標準只要求企業自主劃分功能，並對劃分提出具體、合理的解釋，然後交由市場和外部力量來對企業的劃分和解釋進行監督。概括起來，該思路提倡通過自下而上，形成對功能的合理劃分，打破強制收集的行爲。

另外一種思路是由標準化機構針對民衆經常使用的應用程序，提出各類應用程序的基礎功能和拓展功能的劃分指引，並提出具體功能或服務所必需收集、使用的個人信息的最小集合。如此一來，指引能夠打破前文所述的強制收集所存在兩類行爲。而且這樣的指引，在通過廣泛參與、廣泛徵集意見、反覆試點驗證的基礎上形成，並定期修訂更新。雖然指引不具備法律上的強制力，但是企業對於偏離指引的做法，應當承當具體的解釋義務。