2026年1月10日，国家互联网信息办公室就《互联网应用程序个人信息收集使用规定（征求意见稿）》（以下简称《征求意见稿》）向社会公开征求意见。《征求意见稿》共分七章三十九条，以互联网应用程序为管理对象，详细规定了互联网应用程序个人信息收集使用的要求，同时明确了软件开发工具包（SDK）、分发平台、智能终端等为互联网应用程序提供服务的主体责任。
互联网应用程序个人信息收集使用规则主要集中在第二章，虽然目前还是征求意见稿，但还是很有必要从监管角度和技术视角解析其中的道与术。
写在前面：
对互联网应用程序而言，立法和执法越来越技术化：
弹窗是否在首次启动前出现、权限是不是“随用随要”、拒绝后有没有频繁再弹、相机和麦克风有没有在后台偷偷工作、生物识别数据有没有走出设备……这些问题，本质上都可以被代码和检测工具直接验证。
这也意味着，数据合规彻底跳出了传统合规工作的边界：
法律条文要被翻译成可执行的技术规则，产品设计要与“最小必要”原则对齐，研发在代码层面落实调用时机和频度，上线前通过自动化或半自动化工具做检测，上线后还要持续监测，确保代码行为、UI提示和隐私声明始终一致。
换句话说，今天的数据合规，更像是一套“持续运行的系统”，而不是一次性完成的合规项目。
在这样的监管环境下，真正的风险，来自“我以为已经合规了，但技术事实并不是这样”。
第七条 互联网应用程序收集使用个人信息应当遵循公开、透明原则，制定公开个人信息收集使用规则，通过清晰易懂的语言真实、准确、完整、逐项列明下列事项： （一）运营者名称或者姓名和有效的联系方式； （二）以结构化清单形式列明每项功能服务收集使用个人信息的目的、方式、种类，调用权限名…… 第八条 收集使用个人信息的目的、方式、种类、保存期限或者保存期限的确定方法，调用权限名称、频度和嵌入的软件开发工具包收集使用个人信息行为等情况发生变化的，互联网应用程序应当及时修订、更新个人信息收集使用规则。 |
如果只看条文，第7 条和第8 条很容易被理解成一件事：把隐私政策写完整、写规范。但从监管的设计逻辑看，它们真正想解决的并不是“写得好不好看”，而是能不能被核验。这为之后更全面的技术扫描检测提供基础。
第7 条要求的那种“结构化清单”“逐项列明”，并不是仅仅是为了方便用户阅读，而是在逼着应用先给自己画一张清晰的行为画像：这个功能在什么场景下运行、会调用哪些权限、收集哪些数据、频率是多少、涉及哪些敏感信息、对用户权益可能产生什么影响。写到这个程度，其实已经不再是泛泛的信息披露，而是一种可被技术复现的承诺。
第8 条看起来只是一个“及时更新”的义务，但它解决的是另一个长期存在的现实问题：企业常说业务变了、功能调整了、以前不是这么做的。监管并不是不允许变化，而是要求变化留下痕迹。当数据收集的目的、方式、权限调用发生变化，却没有同步更新披露规则，本身就已经构成了风险信号，不需要再额外证明有没有造成损害。
从这个角度看，第7 条和第8 条其实是同一套逻辑的两端：先把你“打算怎么做”说清楚，再确保你“一直在按自己说的做”。这也为后续的检查方式奠定了基础——执法不再只是抽象地讨论是否“必要”“合理”，而是把披露内容当作对照表，通过静态和动态扫描，以及人工核查去验证事实行为是否一致。
第九条互联网应用程序应当在首次启动时，通过弹窗等显著方式向用户告知个人信息收集使用规则，并在用户充分知情的前提下，取得用户同意规则的明确表示。 互联网应用程序向第三方提供个人信息的，应当取得用户的单独同意。互联网应用程序应当在设置页面等醒目位置提供个人信息收集使用规则一键访问功能，方便用户查阅和保存。 互联网应用程序更新个人信息收集使用规则，符合第八条第一款所列情形的，应当通过弹窗、消息推送等显著方式及时向用户告知更新的具体内容，并重新征得用户同意。 |
本文认为，这并不意味着在弹窗出现之前，应用连最基本的技术行为都不能发生。现实中，App启动本身就离不开一些必要的技术处理，比如基础渲染、安全校验、稳定性保障。这类与“让应用跑起来”直接相关、且不涉及明显个人画像和扩展用途的数据处理，通常不会成为执法的重点。真正的风险在于，在用户尚未知情、尚未选择之前，就已经开始收集大量敏感数据，或者将数据上报给第三方组件，用于分析、画像或营销。这类行为很难被解释为“不可避免”，也是监管真正想提前挡住的。所以，本文理解第九条强调一种顺序：先让用户知道你要做什么，再去做那些与个人信息密切相关、且并非技术必需的个人信息处理。
同样的逻辑也体现在“向第三方提供个人信息是否都要单独同意”这个问题上。此条文看起来很严格，但监管并不是不理解现实业务。关键不在于“是不是第三方”，而在于用户是否能够合理预期这一步数据流转会发生。在电商下单、发货这种场景中，把收货信息提供给快递公司，本身就是交易履约的一部分，大多数用户在操作时就已经默认理解这一点。
如果数据被提供给与当前功能无直接关系的主体，比如广告合作方、分析服务商，或者以“优化体验”为名进行扩展使用，情况就完全不同了。这类行为超出了用户的直观预期，单独同意就不再是形式问题，而是必要的合规边界。本文理解监管关注的重点，更多是有没有说清楚、有没有超范围、有没有被二次滥用，而不是要求每一次履约都反复弹窗授权。
第十条互联网应用程序不得通过调用通讯录、通话记录、短信权限收集使用用户以外其他个人信息主体的个人信息，确需用于满足通讯联系、添加好友、数据备份的除外。 互联网应用程序收集使用前款个人信息，属于通信秘密的，应当符合本规定第五条第二款规定。 |
第十条表面上是在讲权限，其实真正盯住的并不是“你要不要通讯录权限”，而是你拿到权限之后，拿这些数据去干了什么。监管很清楚，一旦应用获得了通讯录、通话记录、短信这类高敏感权限，业务几乎不可能只“看一眼”。所以这条规定的重点并不是授权本身，而是用途边界。
本条明确点出“用户以外的其他个人信息主体”，其实已经说得很直白了。通讯录里的那些人，并不是你的用户，也没有与你发生直接关系。监管不接受“我拿到了权限，所以顺手就用了”的逻辑。只有在非常有限、也非常好理解的场景下，这种使用才被认为是正当的，比如为了实现通讯联系、添加好友，或者在用户明确选择的情况下做数据备份。
如果把通讯录里的信息拿来做画像、匹配、推荐、营销，本质上是把“工具性权限”变成了“扩展性数据来源”，而且影响的还是并未与应用建立关系的第三人。这在监管视角下几乎没有辩护空间。
但更深一层看，第十条其实是在逼企业面对一个很现实、也很难的管理问题：你是否真的在内部区分了数据处理的目的。不仅仅只在隐私政策里写清楚目的，而是在系统、流程和权限设计里，把“数据的使用目的”真正控制住。
第十一条大家都熟悉了，先略过了。
第十二条互联网应用程序应当在用户使用具体功能时方可索要对应的必要个人信息权限，并同步告知使用目的，不得提前索要。用户拒绝的，互联网应用程序不得频繁索要影响用户正常使用其他功能。 |
第十二条开始“为技术检测而写”。
第十二条的核心是索要权限的时机和方式。只有在用户进入具体功能、明确触发某个操作时，权限弹窗才可以出现；如果在用户还没点任何相关按钮、甚至还不知道这个功能存在时就弹出来，那几乎等于主动暴露风险。对于检测系统来说，这件事非常好判断：只要复现用户路径，就能看到权限弹窗出现的节点是否合理。或者结合技术的手段：通过在定制的沙箱环境中运行App，利用Frida等动态插桩工具对目标API进行Hook监控。当App在沙箱中运行时，一旦调用特定的敏感API（如定位、设备标识获取等），即可实时拦截和分析其行为。
而“用户拒绝后不得频繁索要”，更是一个典型的可量化指标。推荐性国标《信息安全技术 移动互联网应用程序（App）收集个人信息基本要求》对“频繁"的形式给出定义，包括但不限于：1）单个场景在用户拒绝授权后，48h内弹窗提示用户打开权限的次数超过1次；2）每当用户重新打开App或使用无关的业务功能时，都会再次向用户索要授权或提示用户缺少相关授权。
虽然这是推荐性标准，但在现实执法中，它往往会被当作一种合理性参照。也就是说，监管未必会说“你违反了这条标准”，但很可能会说：“你的行为，已经明显超出了行业普遍认可的合理范围。”
第十三条 互联网应用程序不得在用户同意个人信息收集使用规则前收集使用个人信息，不得超出用户同意的目的、方式、种类、保存期限收集使用个人信息。 互联网应用程序调用权限需与当前功能场景直接相关，应当仅在用户使用具体功能时以所需的最低频度、最小范围收集个人信息。在当前功能场景不再需要权限时停止调用权限，不得收集非必要个人信息、调用非必要权限。 |
第13条，第一款看起来像一句老生常谈的原则，但之所以反复被写进规范，是因为它真的可以被技术验证。在用户点击“同意”之前，应用有没有发生个人信息的收集和使用，不再只是靠企业自述。现在的检测方式完全可以通过静态分析和动态运行去看：SDK有没有在初始化阶段就上报数据、网络请求里有没有已经带上可识别信息、本地是否生成了与用户相关的标识。
第二款其实比第一款更重要，基于“场景”逻辑：即便App拿到了同意，权限的调用也必须和当前功能场景直接相关，而且只在这个场景里、只用最低频度、最小范围。换句话说，同意不是一张空白支票，它并不能覆盖所有时间、所有路径、所有用途。
这一点在技术上同样是可被验证的。动态检测并不需要理解你的业务逻辑，只需要通过自动化脚本复现用户操作路径：当用户进入某个功能时，是否才开始调用对应权限；当用户离开这个功能，权限调用是否随之停止。
第十四条 互联网应用程序应当仅在用户主动选择使用拍照、发送语音、录音录像等功能时调用相机、麦克风权限，不得在用户停止使用相关功能或者无关场景调用相机、麦克风权限。 互联网应用程序在地图导航、路径记录、外卖闪送、位置共享等需要实时定位的场景，持续调用位置权限的频率应当限于实现业务功能的最低频度；在添加地点、内容搜索、内容推荐、广告营销等需单次定位场景，应当仅在用户进入功能界面或者用户主动刷新时调用一次位置权限。除法律、行政法规另有规定或者所提供业务功能确需后台持续获取位置外，互联网应用程序不应索要后台访问用户位置信息权限。 用户选择使用上传或者发送图片、文件等功能，互联网应用程序可使用智能终端提供的存储访问框架实现的，不得索要手机相册、通讯录、短信、存储等权限。互联网应用程序通过提供文件编辑、文件备份等功能获得存储权限的，不得访问用户主动选择以外的文件。 |
第十四条是对前一条的进一步具象化。
对于相机和麦克风这类权限，监管给出的判断非常直白：只有在用户主动选择使用拍照、语音、录音录像这些功能时，调用才有合理性。一旦用户退出功能、页面切换，或者进入完全无关的场景，权限仍然被占用，就很难再解释为“误触”或“技术需要”。动态检测跑一遍完整路径，很容易就能看出来有没有越界调用。
定位权限更是被拆分得非常清楚。哪些场景可以持续定位，哪些只能单次调用，甚至连广告营销、内容推荐这种常见用途，都被明确划进了“只允许一次”的范围。这意味着监管已经放弃围绕“是否必要”的讨论，而是直接给出了操作层面的预期答案。检测工具只要区分前台、后台、调用频率和时间跨度，就能判断是否超过了“最低频度”。
至于存储权限，第十四条其实是在顺着操作系统的发展趋势走。既然系统已经提供了更细粒度的存储访问框架，那么再一概索要相册、通讯录、存储权限，就很难被认为是技术上“没办法”。更重要的是，即便因为文件编辑、备份确实获得了存储权限，访问范围也必须被限制在用户主动选择的文件之内。这里同样不是靠解释，而是靠访问路径和文件调用记录说话。
第十五条互联网应用程序收集人脸、指纹、声纹等生物识别信息应当具有特定的目的和充分的必要性，采取对个人权益影响最小的方式，并实施严格的保护措施。 除法律、行政法规另有规定或者取得用户单独同意外，互联网应用程序收集使用人脸、指纹、声纹等信息应当存储于生物识别设备内，不得通过互联网对外传输。除法律、行政法规另有规定外，生物识别信息的保存期限不得超过实现处理目的所必需的最短时间。 |
第十五条之所以强调生物识别信息应当存储在生物识别设备内，核心原因只有一个：把风险压缩在最小的范围里。
人脸、指纹、声纹这类信息有一个非常特殊的属性——一旦泄露，几乎不可更换。密码泄露了可以改，手机号可以换，但生物识别信息一旦外泄，对个人的影响是长期甚至不可逆的。本文认为监管的要求是：如果出事，后果有多严重，影响能不能被止住。
把生物识别信息留在设备内，本质上是在减少三个风险面：
首先是减少集中存储带来的系统性风险。如果生物识别数据被集中上传、集中存储，那么一旦服务器、接口或权限出现问题，泄露的就可能是成批、成规模的敏感信息。相比之下，设备内存储把风险拆散了，即使单个设备出问题，影响范围也是局部的。
其次是切断不必要的数据流动。生物识别信息一旦通过互联网传输，就不可避免地会经过网络链路、接口服务、日志系统、备份体系。每多经过一个环节，就多一个暴露点。监管要求“原则上不得对外传输”，其实是在强调：如果这个业务本身不需要把数据拿出来，那就不要让它进入数据流转体系。
第三个原因是降低二次利用和功能漂移的可能性。生物识别信息一旦存在后台系统里，就很容易被用于超出最初目的的场景，比如交叉验证、行为分析、甚至模型训练。存储在设备内，天然就限制了这种扩展使用。
不过，条文里留了两个例外——法律、行政法规另有规定，或者取得用户单独同意。监管并不否认云端处理的可能性，而是要求企业在偏离“设备内处理”这个低风险路径时，必须有更强的理由、更清晰的授权和更严格的保护措施。
从技术检测的角度看，这条规定同样非常清晰。只要生物识别数据发生了网络传输、出现在服务器日志、接口返回或备份系统里，就很难再解释为“设备内存储”。所以第十五条既是原则性要求，也是一个极其明确的技术边界：生物识别信息，默认不进入数据流转体系。
声明：本文来自数据合规与治理，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
