第一时间 | 《App违法违规收集使用个人信息行为认定方法》逐条对比解读

Original 刘新宇等中伦视界 2022-03-20

作者：刘新宇宋海新张功俐吴豪雳

2019年12月30日8:00，国家互联网信息办公室秘书局、工业和信息化部办公厅、公安部办公厅、国家市场监督管理总局办公厅正式公开发布《App违法违规收集使用个人信息行为认定方法》（国信办秘字〔2019〕191号，以下简称“《App违法违规认定办法》”或“本办法”）。从2019年5月5日公开征求意见，到11月28日正式稿下发，再到12月30日公开发布，效率之快，有目共睹。

笔者在本文中将通过对比征求意见稿与正式稿，为大家逐条解读《App违法违规认定办法》。

根据《关于开展App违法违规收集使用个人信息专项治理的公告》，为监督管理部门认定App违法违规收集使用个人信息行为提供参考，为App运营者自查自纠和网民社会监督提供指引，落实《网络安全法》等法律法规，制定本方法。

解读：

文首定义了本办法的制定依据、制定目的和适用方法，“一参考+一指引”，决定了本办法在认定App违法违规收集使用个人信息行为方面的重要影响力。App运营者只有对照本办法及时、有效地自查自纠，才能减少或者避免被认定为违法违规收集使用个人信息行为，才能充分经受起网民的社会监督。

一

以下行为可被认定为“未公开收集使用规则”

1.在App中没有隐私政策，或者隐私政策中没有收集使用个人信息规则；

解读：

该条主要明确应有隐私政策和收集使用个人信息规则。

相较于征求意见稿，该条删减了对用户协议的相关要求，单独强调应有隐私政策和收集使用个人信息规则。从建议的角度，可以在用户协议中设置收集使用个人信息版块加以简单介绍，并通过链接或突出提示的方式，提醒用户阅读《隐私政策》。

2.在App首次运行时未通过弹窗等明显方式提示用户阅读隐私政策等收集使用规则；

解读：

该条主要明确首次运行时的明显提示。

相较于征求意见稿，该条将明显提示用户阅读隐私政策等收集使用规则的时间点固定在了App首次运行时，更加符合现行App运行的生态。从展示方式上，建议采取弹窗方式，在弹窗内展示内容摘要并放置《隐私政策》全文链接。

3.隐私政策等收集使用规则难以访问，如进入App主界面后，需多于4次点击等操作才能访问到；

解读：

该条主要明确隐私政策应易于访问。

相较于征求意见稿，该条扩充了适用范围，除沿用4次以内点击等操作应访问到隐私政策的要求外，隐私政策链接无效、文本无法正常显示等情形可能也会被纳入隐私政策难以访问的情形。从隐私政策放置位置看，一般放置在“我的-设置”或“我的-关于”的子栏目，相对方便用户查找。建议通过点击次数和位置的设置，确保隐私政策易于访问。

4.隐私政策等收集使用规则难以阅读，如文字过小过密、颜色过淡、模糊不清，或未提供简体中文版等。

解读：

该条主要明确隐私政策的易读性。

相较于征求意见稿，该条内容对易读性进行了细化要求，降低了在隐私政策文本上动手脚的可行性。建议确保收集使用规则的内容清晰易懂，符合通用的语言习惯，使用标准化的数字、图示等，避免使用有歧义的语言。

二

以下行为可被认定为“未明示收集使用个人信息的目的、方式和范围”

1.未逐一列出App(包括委托的第三方或嵌入的第三方代码、插件)收集使用个人信息的目的、方式、范围等；

解读：

该条主要明确逐项列举收集使用个人信息的目的、方式、范围等。

相较于征求意见稿，该条明确了逐项列举的要求不仅适用于App自身收集使用个人信息的目的、方式和范围，亦适用于App嵌入的第三方代码、插件，直指实践中泛滥的SDK隐瞒收集个人信息的问题。

建议逐项列示每个业务功能收集的个人信息的目的、方式和范围，并列明App嵌入的所有SDK及各SDK所收集的个人信息目的、方式和范围，并按照本办法第4.4条的要求，根据满足所使用的业务功能需要的频率来收集个人信息。

2.收集使用个人信息的目的、方式、范围发生变化时，未以适当方式通知用户，适当方式包括更新隐私政策等收集使用规则并提醒用户阅读等；

解读：

该条主要明确在重要情况变更时需要对用户以适当方式进行通知。

相较于征求意见稿，从文字意思看，该条将意见稿中重要变更情况下“应提醒用户重新阅读授权”调整为“应提醒用户阅读”，不再要求获得用户重新授权。这似乎可以理解为运营者在最开始获得用户授权后后续可以随意变更授权文本和内容，而对用户要做的仅仅是告知。该规定有待进一步商榷，具体适用有待监管部门进一步明确。

从建议角度，建议运营者在收集使用个人信息的目的、方式和范围发生变化时，应更新隐私政策、个人信息查询授权书等授权文本，通过弹窗、推送通知、红点提示、电子邮件、信函、电话等适当方式提醒用户重新阅读，并通过用户手动点击确认、手动勾选等方式获得用户的再次授权。

3.在申请打开可收集个人信息的权限，或申请收集用户身份证号、银行账号、行踪轨迹等个人敏感信息时，未同步告知用户其目的，或者目的不明确、难以理解；

解读：

该条主要明确每次在需要用户提供个人敏感信息时应同步告知用户其目的。

相较于征求意见稿，该条沿用其第4.5条要求，针对个人敏感信息提出更加细化、更加严格的要求，充分体现对于个人敏感信息的突出保护。

建议参照《个人信息安全规范（征求意见稿）》附录对于个人敏感信息的举例，明确个人敏感信息的范围。结合《App自评估指南》评估点20的规定，“在每次要求用户提供个人敏感信息时，通过弹窗提示等显著方式同步告知收集使用目的、方式、范围等原因，并明确告知对应的业务功能及拒绝提供的影响。”

4.有关收集使用规则的内容晦涩难懂、冗长繁琐，用户难以理解，如使用大量专业术语等。

解读：

该条主要明确收集使用规则内容的易读性。

相较于征求意见稿，该条沿用其内容，并与本办法第1.4条相关联，直指实践中制造阅读障碍的情形。建议结合《个人信息安全规范（征求意见稿）》及《App自评估指南》评估点4的要求，“确保收集使用规则的内容清晰易懂，符合通用的语言习惯，使用标准化的数字、图示等，避免使用有歧义的语言。”

三

以下行为可被认定为“未经用户同意收集使用个人信息”

1.征得用户同意前就开始收集个人信息或打开可收集个人信息的权限；

解读：

该条主要明确收集使用个人信息的起始点。

相较于征求意见稿，该条对措辞进行了完善，意思表达更加明确。用户同意作为《网络安全法》规定的收集用户信息的法定基础，也是在我国现行网络安全生态下收集用户信息的合法来源。运营者要合法合规收集使用个人信息，就需要能够证明获得用户同意，且能够证明用户同意的时间点先于收集使用行为。

2.用户明确表示不同意后，仍收集个人信息或打开可收集个人信息的权限，或频繁征求用户同意、干扰用户正常使用；

解读：

该条主要明确不得违反用户意愿收集个人信息和不得频繁弹窗、干扰使用。

该条将征求意见稿第3条第2款和第8款进行了合并。实践中存在相当数量的App在不提供权限或者拒绝收集个人信息请求时通过闪退、反复弹窗等方式影响用户使用其他功能的情形。运营者应尊重用户意愿，在用户明确拒绝收集个人信息请求后，不得频繁征求用户同意。用户明确拒绝个人信息请求应仅影响与拒绝提供个人信息相关的业务功能，不得影响用户正常使用其他业务功能。

3.实际收集的个人信息或打开的可收集个人信息权限超出用户授权范围；

解读：

该条主要明确不得超出授权范围收集个人信息。

相较于征求意见稿，该条增加了对打开权限的规定，内容无实质变化。隐私政策等获得用户授权的文本公示收集使用个人信息规则，用户对App运营者会按照隐私政策收集使用个人信息会形成合理期待。运营者不应利用隐私政策等用户授权文本宣示合法合规收集使用个人信息，但实际中却不按照用户授权范围收集使用个人信息；当面一套背地一套，主观恶意明显，不可取。

4.以默认选择同意隐私政策等非明示方式征求用户同意；

解读：

该条主要明确应征得用户明示同意。

相较于征求意见稿，该条系新增内容，但相较于《个人信息安全规范（征求意见稿）》和《App违法违规收集使用个人信息自评估指南》（以下简称“《App自评估指南》”），该条系沿用明示同意的要求。实践中常见的非明示方式包括默认勾选同意、注册即表示同意等。

5.未经用户同意更改其设置的可收集个人信息权限状态，如App更新时自动将用户设置的权限恢复到默认状态；

解读：

该条主要明确不得未经用户同意私自更改用户权限设置。

相较于征求意见稿，该条内容未发生实质变化。建议申请调用个人信息权限应获得用户的同意，不得未经用户同意私自更改用户权限设置，不得利用系统更新升级更改原有的系统权限设置。

6.利用用户个人信息和算法定向推送信息，未提供非定向推送信息的选项；

解读：

该条主要明确定向推送时应提供非定向推送信息的选项。

相较于征求意见稿，该条将“提供终止定向推送的选项”调整为“提供非定向推送信息的选项”。以电商场景为例，基于用户兴趣爱好、消费习惯等进行定向推送时，应同时推送不针对用户个性化特征的商品或服务。

7.以欺诈、诱骗等不正当方式误导用户同意收集个人信息或打开可收集个人信息的权限，如故意欺瞒、掩饰收集使用个人信息的真实目的；

解读：

该条主要明确不应以欺诈、诱骗、误导的方式收集个人信息。

相较于征求意见稿，该条系新增内容，强调收集个人信息的合法性。较于《个人信息安全规范（征求意见稿）》来说，该条系对《个人信息安全规范（征求意见稿）》5.1a)条的沿用和细化，强调应如实、全面、准确告知收集使用个人信息的目的，不得采取欺诈、诱骗、误导等违法方式。

8.未向用户提供撤回同意收集个人信息的途径、方式；

解读：

该条主要明确应向用户提供撤回同意的途径和方式。

相较于征求意见稿，该条系新增内容，强调用户个人信息权利的保障。较于《个人信息安全规范（征求意见稿）》，该条系对《个人信息安全规范（征求意见稿）》7.11a)条的沿用，防止一次授权终身使用等情形。参照第7.11a)条规定，撤回授权同意后，运营者后续不应再处理相应的个人信息，但不影响撤回前基于授权同意的个人信息处理。从建议角度，应确保提供的途径和方式切实可用，避免流于形式和在用户撤回同意时故意设置多种障碍。

9.违反其所声明的收集使用规则，收集使用个人信息。

解读：

该条主要明确运营者言行一致。

相较于征求意见稿，该条将隐私政策声明的收集使用规则进行了扩充，个人信息查询授权书等收集使用规则都可能被纳入声明的收集使用政策范围内。该条与本办法第3.3条具有关联性，旨在强调运营者应言行一致，收集使用规则不仅是告知用户，更是对运营者的约束。收集使用个人信息的目的、方式、范围发生变化时，应按照本办法第2.2条进行更新、通知和提醒。

四

以下行为可被认定为“违反必要原则，收集与其提供的服务无关的个人信息”

1.收集的个人信息类型或打开的可收集个人信息权限与现有业务功能无关；

解读：

该条主要明确收集个人信息应为现有业务功能所必需。

该条将征求意见稿第4.1条和第4.7条合并，指向过度收集和过度索权问题。需要强调的是，该条突出“现有业务功能”，将适用范围限定于业务功能，并且是现有的而非过去或者准备开发的新的业务功能。

结合《App自评估指南》评估点6、评估点7和评估点26，建议实际收集的个人信息类型及索取的权限与现有业务功能逐项对应，并且与现有业务功能直接相关，缺少该信息则现有业务功能无法实现。

2.因用户不同意收集非必要个人信息或打开非必要权限，拒绝提供业务功能；

解读：

该条主要明确不得因用户拒绝提供非必要个人信息或打开非必要权限而拒绝提供业务功能。

相较于征求意见稿，该条对原有内容进行了扩充，主要针对实践中通过拒绝提供业务功能变相强迫用户同意收集非必要个人信息或打开非必要权限的行为。结合《个人信息安全规范（征求意见稿）》附录C.3c)的规定，在用户拒绝某非必要个人信息或打开非必要权限的请求时，不得因此拒绝向用户提供业务功能或降低业务功能的服务质量。

3.App新增业务功能申请收集的个人信息超出用户原有同意范围，若用户不同意，则拒绝提供原有业务功能，新增业务功能取代原有业务功能的除外；

解读：

该条主要明确新增业务功能超出用户原有同意范围的处理。

相较于征求意见稿，该条内容无实质区别。实践中，随着公司战略、市场行情、消费需求等的变化，新增业务功能的情况非常普遍。对此需要参照该条的要求，超出原有个人信息同意范围收集个人信息的，如用户不同意，只影响新增业务功能的使用，不得拒绝提供原有业务功能。但新增业务取代原有业务功能导致业务功能发生变更的除外。

4.收集个人信息的频度等超出业务功能实际需要；

解读：

该条主要明确收集个人信息的频率应限于实现该业务功能的需要。

相较于征求意见稿，该条取消了频率要求的时间限制，不再限于用户使用业务功能时。《个人信息安全规范（征求意见稿）》第5.2b)条要求“自动采集个人信息的频率应是实现产品或服务的业务功能所必需的最低频率”。建议在收集个人信息时，按照实现产品或服务的业务功能所必需的最低频率收集个人信息。

5.仅以改善服务质量、提升用户体验、定向推送信息、研发新产品等为由，强制要求用户同意收集个人信息；

解读：

该条主要明确收集使用个人信息需要符合必要性原则的要求。

相较于征求意见稿，该条无实质区别。在实践中，相当数量的App在隐私政策中将改善服务质量、提高用户体验、定向推送信息、研发新产品单独表述为业务功能和收集使用目的，并将其作为“利器”而肆意收集使用与业务功能无关的用户个人信息。建议将改善服务质量、提高用户体验、定向推送信息、研发新产品等目的与其他业务功能相结合，确保收集使用个人信息的类型与具体业务功能相对应。

6.要求用户一次性同意打开多个可收集个人信息的权限，用户不同意则无法使用。

解读：

该条主要明确不得一揽子授权。

相较于征求意见稿，该条沿用了其第4.3条及《App自评估指南》评估点24的相关要求，主要针对实践中普遍存在的强制捆绑授权问题，特别是在安卓系统下，所声明的TargetSdkVersion值小于23的App大量存在“用户安装时就声明索要所有权限，一旦安装，这些权限就默认打开”的情形。（TargetSdkVersion值对应着App开发时设置的API等级，App对应的API等级越高，通常在权限管理和安全设计机制方面更加完善）。

结合《App自评估指南》评估点23、评估点24、评估点25，建议不得通过捆绑多项业务功能的方式要求用户一次性接受并授权同意多项业务功能收集个人信息的请求。用户不同意应仅影响与所拒绝提供个人信息相关的业务功能，不得影响其他业务功能的正常使用，不得以不同意一揽子授权为理由不提供任何单一服务。

五

以下行为可被认定为“未经同意向他人提供个人信息”

1.既未经用户同意，也未做匿名化处理，App客户端直接向第三方提供个人信息，包括通过客户端嵌入的第三方代码、插件等方式向第三方提供个人信息；

解读：

该条主要明确客户端向第三方提供个人信息应征得同意或匿名化处理。

该条与征求意见稿无实质区别，与本办法第2.1条相关联。12月20日，App专项治理工作组曾发布《关于61款App存在收集使用个人信息问题的通告》，其中涉及44款App在既未经用户同意，也未做匿名化处理的情况通过客户端嵌入的SDK向第三方提供用户设备IMEI号、地理位置等个人信息。

结合《App自评估指南》评估点22的要求，建议如果通过嵌入第三方代码、插件（如SDK）等方式向第三方提供个人信息，应通过弹窗提示等方式明确告知用户并获得用户的同意。但经匿名化处理无法识别特定个人且不能复原的无需获得用户的同意。

2.既未经用户同意，也未做匿名化处理，数据传输至App后台服务器后，向第三方提供其收集的个人信息；

解读：

该条主要明确后台服务器向第三方提供个人信息应征得同意或匿名化处理。

该条与征求意见稿无实质区别，与上条规定相似，区别之处在于规范数据传输至App服务器后对外提供个人信息的合法性。

参照《个人信息安全规范（征求意见稿）》第8.2条的要求，建议对外提供个人信息时，应通过隐私政策等授权文本告知用户对外提供的目的、第三方的类型并获得用户的授权同意，准确记录和保存对外提供个人信息的情况，包括共享、转让的日期、规模、目的以及第三方基本情况，并开展个人信息安全影响评估进而采取有效的个人信息保护措施。但对外提供经过匿名化处理无法识别特定个人且不能复原的无需获得用户的同意。

3.App接入第三方应用，未经用户同意，向第三方应用提供个人信息。

解读：

该条主要明确接入第三方应用提供个人信息应经用户同意。

相较于征求意见稿，该条从兜底条款调整为明确App接入第三方应用场景下的规范要求。在App接入小程序等第三方应用的情况下，如需通过API等方式向第三方应用提供个人信息，应通过隐私政策文本等获得用户的同意。

六

以下行为可被认定为“未按法律规定提供删除或更正个人信息功能”或“未公布投诉、举报方式等信息”

1.未提供有效的更正、删除个人信息及注销用户账号功能；

解读：

该条主要明确应提供删除或更正个人信息和注销账号功能。

相较于征求意见稿，该条内容未实质变化，主要指向实践中无法更正、删除个人信息和注销用户账号的问题，旨在保护用户个人信息的权利。结合《App自评估指南》评估点30、评估点31，建议提供查询、更正、删除个人信息和注销用户账号的途径，并且应确保该等途径能够切实有效实现对应功能，避免流于形式。

2.为更正、删除个人信息或注销用户账号设置不必要或不合理条件；

解读：

该条主要明确不得妨碍用户权利行使。

相较于征求意见稿，该条属于新增条款，也是工信部近期开展App整治活动重点关注的问题之一。该条系对《个人信息安全规范（征求意见稿）》第7.8-第7.14条的部分沿用。结合前述条款规定和实践中常见问题，建议：（1）便于用户操作，不应通过隐蔽入口、操作繁琐等方式影响用户权利的实现；（2）用户行使该等权利时，如需核验身份信息，重新提供的个人信息不应多于注册、使用等服务环节收集的个人信息；（3）不应设置注销单个账户视同多个产品或服务的条件；（4）不应要求用户填写精准的历史操作记录作为必要注销条件；（5）不应客服之间来回推诿，集团公司之间来回推诿；（6）不应仅提示存在积分、参与活动、授权登陆解绑等影响权利行使的问题，而不提供解决具体问题的通道。

3.虽提供了更正、删除个人信息及注销用户账号功能，但未及时响应用户相应操作，需人工处理的，未在承诺时限内（承诺时限不得超过15个工作日，无承诺时限的，以15个工作日为限）完成核查和处理；

解读：

该条主要明确对用户权利要求进行及时响应。

相较于征求意见稿，该条将其第6.2条和6.3条进行了合并，旨在防止更正、删除个人信息及注销账户的功能流于形式和消极处理。一般来说，用户提请相应操作的方式包括在线操作、客服电话、电子邮件等，应确保前述方式的有效性和及时性，保证相关操作能够及时得到响应。该条增加明确了最长承诺时限的限制，用户的相应操作若需要人工处理，则应按照与用户约定的承诺时限完成核查和处理，并且最长以15个工作日为限，切实保障用户得到及时反馈的权利。

4.更正、删除个人信息或注销用户账号等用户操作已执行完毕，但App后台并未完成的；

解读：

该条主要明确App后台操作应与用户操作保持一致。

相较于征求意见稿，该条对内容进行了明确和优化，旨在防止更正、删除或注销操作流于形式，欺骗、误导用户误以为已经完成相关操作。

建议如实告知用户更正、删除个人信息及注销账户的实际进展，在App后台完成相应操作后，再向用户提示相关操作已执行完毕。如在操作过程中出现突发情况导致暂时无法实现更正、删除或注销操作，应及时告知用户原因并如实告知操作进展，不得在未完成操作之前提示用户操作已完成。

5.未建立并公布个人信息安全投诉、举报渠道，或未在承诺时限内（承诺时限不得超过15个工作日，无承诺时限的，以15个工作日为限）受理并处理的。

解读：

该条主要明确建立、公布投诉、举报渠道并在承诺时限内受理并处理。

相较于征求意见稿，该条属于新增条款，在《个人信息安全规范（征求意见稿）》和《App自评估指南》关于投诉管理相关规定的基础上，进一步明确要求建立并公布投诉、举报渠道，且明确最长承诺时限不得超过15个工作日。

结语

整体来说，《App违法违规认定办法》（正式稿）是对征求意见稿的一次优化提升。正式稿中删减了很多征求意见稿中的争议内容，完善了细节规定，提高了严谨性和可执行性。

本办法并未明确规定生效的时间，似乎可以理解为下发或者公开发布之日起生效。对于App运营者收集使用个人信息来说，多了相对明确的限制，但也多了相对明确的合规指引。