01 · App生态治理格局与制度工具
App是个人信息保护执法的第一线战场。2019年1月，中央网信办、工信部、公安部、市场监管总局四部门联合发布《关于开展App侵害用户权益专项整治工作的通知》，成立App专项治理工作组；2020年起，工信部建立全国App技术检测平台并开展常态化通报，对存在侵害用户权益行为的App（含小程序、SDK）分批通报、限期整改，拒不整改的下架。此后治理工具持续加密，形成「技术检测平台+通报下架+规则细化」的常态机制。据工信部历年通报公告统计，累计被通报的App达数千款次，覆盖超范围收集个人信息、强制频繁过度索权、违规自启动、欺骗误导强迫行为、账号注销难等高频问题。
| 制度工具 | 发布时间 | 核心内容 |
|---|---|---|
| 《App违法违规收集使用个人信息行为认定方法》 | 2019年11月四部门联合印发 | 以六类31种行为界定「违法违规收集使用个人信息」，为执法与企业自查提供统一认定标准（见下节） |
| 《常见类型移动互联网应用程序必要个人信息范围规定》 | 2021年3月发布、5月1日施行 | 明确地图导航、网络约车、即时通信、网络购物、新闻资讯等39类常见App的「必要个人信息」范围；用户不同意收集非必要信息时，App不得拒绝提供基本功能服务 |
| TC260《网络安全标准实践指南——App使用软件开发工具包（SDK）安全指引》 | 2020年11月发布 | 指导App提供者与SDK提供者规范SDK集成使用：SDK基本信息披露、权限与数据收集最小化、同意前不初始化、安全评估与监测 |
| 《关于进一步提升移动互联网应用服务能力的通知》 | 2023年2月（工信部信管函〔2023〕26号） | 压实开发运营者与分发平台主体责任：服务续期及退订便捷、账号注销应在受理后15个工作日内完成、不得通过「偷梁换柱」「强制捆绑」等方式诱导安装；分发平台须落实上架审核与日常巡查 |
| 《网络数据安全管理条例》 | 2025年1月1日施行 | 将告知同意、委托处理、自动化决策等义务上升为行政法规层级，违规处理个人信息的应用程序可被责令暂停或终止服务（第66条衔接） |
治理逻辑：App治理已从「运动式整治」转入「常态化检测+社会公示」阶段。对开发运营者而言，工信部通报不仅是行政处罚前奏，更是商誉事件（通报名单公开可查）；对分发平台而言，上架审核与巡查责任压实意味着「带病上架」将同时追究平台责任。合规自查应与监管检测口径对齐（即本页检测能力矩阵）。
02 · 六类违规形态与认定标准
《认定方法》将App违法违规收集使用个人信息归纳为六类，每类下设具体认定情形。企业自查与监管检测均以此为基线：
| 类别 | 认定要点（典型情形） |
|---|---|
| 一、未公开收集使用规则 | 未提供隐私政策等收集使用规则；隐私政策难以访问（如进入路径超过4层）或难以阅读（文字过小、颜色过淡等） |
| 二、未明示收集使用目的、方式、范围 | 收集使用规则内容晦涩冗长、难以理解；收集使用个人信息的目的、方式、范围发生变化时未以适当方式通知用户、未获必要同意；申请打开可收集个人信息的权限或收集个人敏感信息时未同步告知目的 |
| 三、未经用户同意收集使用个人信息 | 征得同意前开始收集个人信息或打开可收集个人信息的权限；实际收集的个人信息或打开的超范围权限超出用户授权范围；以默认、捆绑、停止安装使用等方式变相强迫用户授权；以欺诈、诱骗等不正当方式误导用户同意收集个人信息或打开可收集个人信息的权限 |
| 四、违反必要性原则收集与其提供服务无关的个人信息 | 收集的个人信息类型或打开的可收集个人信息权限与现有业务功能无关；因用户不同意收集非必要个人信息或打开非必要权限，拒绝提供业务功能（新增业务功能申请收集超出原有范围的信息，用户不同意则拒绝原有业务功能）；收集个人信息的频度等超出业务功能实际需要；仅以改善服务质量、提升用户体验、定向推送信息、研发新产品等为由强制要求用户同意收集个人信息 |
| 五、未经同意向他人提供个人信息 | 既未经用户同意，也未做匿名化处理，向第三方提供个人信息；通过嵌入第三方代码、插件等方式向第三方提供个人信息，未征得用户同意、未作匿名化处理 |
| 六、未按法律规定提供删除或更正功能、未公布投诉举报渠道 | 未提供有效的更正、删除个人信息及注销用户账号功能；为更正、删除或注销设置不必要或不合理条件（如注销需提交超出注册时收集的信息）；虽提供功能但未及时响应、承诺时限不合理；未建立并公布个人信息投诉、举报渠道，或超过承诺时限未受理处理 |
高频误区：①「改进体验」不是收集非必要信息的合法性理由（认定方法第四类明文否定）；②向第三方提供信息若未匿名化且未经同意，无论通过SDK、H5嵌套还是API接口，均构成第五类违规；③注销渠道须与注册渠道同等可达，仅提供人工客服电话注销可能被认定为未提供有效注销功能。
03 · SDK生态治理：风险与对策
SDK是App个人信息泄露的「暗渠」：一个App平均嵌入数十个SDK（统计、推送、支付、广告、风控、地图等），用户感知与开发者掌控力均弱。TC260指引将SDK风险归纳为：自身安全漏洞被利用、违规收集使用个人信息（超范围、静默收集）、违规向第三方提供信息、热更新引入恶意行为等。
| 治理动作 | 操作要点 |
|---|---|
| SDK清单与披露 | 建立全量SDK台账：名称、提供者、版本、使用目的、收集的个人信息类型、调用方式（aar/maven/动态加载）；隐私政策中以显著方式逐项披露第三方SDK信息，不得笼统表述为「我们可能会使用第三方服务」 |
| 延迟初始化 | 在用户同意隐私政策前，不得初始化任何收集个人信息的SDK（推送、统计、广告SDK须等待同意回调后再启动；Android端注意ContentProvider自动初始化问题） |
| 集成前评估 | 引入新SDK前开展安全与合规评估：审查其权限申请、数据采集字段、加密传输、隐私承诺；签订数据处理协议（明确处理角色、信息类型、保护措施、删除安排） |
| 持续监测 | 发版前自动化扫描SDK行为（网络流量+权限调用）；监控SDK版本更新带来的行为变化；跟踪监管通报中问题SDK名单并及时替换 |
| 动态加载管控 | 对热更新、插件化框架实施白名单管控，防止运行时引入未评估的第三方代码 |
角色定性提示：SDK提供者并不当然是「受托人」。若SDK提供者以自身目的（如广告联盟的用户画像）处理个人信息，其实质构成独立的个人信息处理者或共同处理者，App运营者向其提供信息须履行第23条「告知+单独同意」程序；仅当SDK严格按App指令、为App目的处理且不另作他用时，才成立第21条委托关系。定性错误是通报案例中「未经同意向他人提供」高频发生的根源。
04 · 自动化检测技术能力矩阵
监管检测与企业自查正在走向「静态分析+动态行为+文本比对」的自动化融合。下表给出检测能力矩阵：
| 检测层 | 技术方法 | 能发现的问题（示例） |
|---|---|---|
| 静态分析 | 逆向反编译、权限清单解析、API与第三方库识别、隐私政策文本NLP解析 | 申请与功能无关的权限（如手电筒App申请通讯录）、硬编码收集行为、SDK清单与政策披露差异、政策文本要素缺失 |
| 动态行为 | 沙箱运行监测、系统调用钩子、网络流量抓包与字段识别、启动链追踪 | 同意前初始化SDK、超范围字段上传、明文HTTP传输、后台静默采集、违规自启动与关联启动 |
| 文本比对 | 隐私政策机器可读化解析、告知内容与实际采集行为交叉验证、39类必要信息范围规则库 | 「告知了但没做」或「做了但没告知」、保存期限缺失、必要信息超范围 |
| 平台能力 | 工信部全国App技术检测平台（监管侧）；企业侧可构建CI/CD集成检测流水线 | 监管侧：批量抽检与通报；企业侧：发版前卡点检测，未过检不发版 |
注：监管检测以「实际行为+用户感知」为准绳——即使隐私政策披露完备，只要动态行为与披露不符（如政策承诺不收集通讯录而实际采集），仍构成违规。文本完备≠行为合规。
4.1 检测指标建议（企业自查基线）
- 同意前零采集：首次启动至同意前，网络请求中个人信息字段数为0（允许必要的设备基础信息用于安全校验）。
- 权限与功能匹配率：每个危险权限须有对应功能场景说明，匹配率100%方可发版。
- 加密传输覆盖率：含个人信息请求HTTPS/TLS覆盖率100%，证书校验不得绕过。
- SDK披露完整率：政策披露清单与代码扫描发现的SDK集合一致（差异为0）。
05 · 隐私政策与告知界面设计规范
隐私政策是告知义务的载体，其质量以「可感知、可理解、可执行」为标尺：
| 设计原则 | 具体要求 |
|---|---|
| 显著可达 | 首次运行弹窗展示核心条款；设置页与注册页常驻入口；路径层级不超过4层（《认定方法》明确超过4层属「难以访问」） |
| 清晰易懂 | 避免纯法律术语堆砌；关键条款（敏感信息、共享对象、出境）用加粗/表格/示例呈现；字号与对比度保障可读性 |
| 真实完整 | 第17条四要素齐备：处理者名称与联系方式、处理目的/方式/种类/保存期限、权利行使方式与程序、其他法定事项；SDK与共享方逐项列明 |
| 动态同步 | 功能新增、SDK变更、出境安排调整时同步修订政策；变更部分重新告知，涉及处理目的/方式/种类变更的重新取得同意（第14条第2款） |
| 拒绝便捷 | 不同意非必要授权不得阻断基本功能；撤回同意入口与授权入口同等可达（第15、16条）；提供非个性化选项（第24条） |
5.1 常见缺陷清单
- 大段复制模板与自身业务不符（政策承诺的功能实际不存在，或实际功能政策未覆盖）；
- 关键事项藏入超链接层层嵌套（保存期限藏在第9层链接内）；
- 「等」「包括但不限于」过度概括共享对象；
- 政策更新仅公告提示，未对变更事项定向告知；
- 默认勾选营销同意、拒绝路径设多层确认（「残忍拒绝」式交互存在被认定胁迫的风险）。
06 · 通报整改复盘机制
6.1 高频通报问题根因对照
| 高频问题 | 技术根因 | 管理根因 |
|---|---|---|
| 超范围收集个人信息 | 历史功能遗留字段未下线；埋点SDK采集全量字段 | 需求阶段无字段必要性评审；缺数据字段台账 |
| 违规自启动/关联启动 | Android广播监听滥用；推送SDK保活机制 | 第三方SDK版本老旧未升级；无启动行为监测 |
| 强制频繁过度索权 | 权限申请时序设计错误（启动即申请全部权限） | 产品为转化指标强制前置授权 |
| 账号注销难 | 注销流程依赖人工；多系统账号未打通 | 未将注销纳入标准功能需求；留存策略与法律冲突 |
| 欺骗误导强迫行为 | 弹窗按钮文案诱导（「一键同意」vs灰色「暂不」） | 合规评审未覆盖交互细节；A/B测试缺乏伦理约束 |
07 · 延伸场景：小程序、快应用与IoT
- 小程序/快应用：平台方与开发者构成「平台—入驻者」关系。平台须落实分发审核与巡查责任（2023年工信部通知明确）；开发者不得因小程序形态豁免告知同意义务。平台调用用户信息能力（头像、昵称、位置）须由用户逐项授权。
- 车载与智能座舱：车辆采集的位置轨迹、座舱语音、人脸疲劳监测均属个人信息（部分属敏感信息）；车机App适用与移动端同等规则，OTA升级引入新采集行为须重新告知评估。
- 智能电视与穿戴设备：开机广告、语音遥控采集的语音数据、儿童智能手表的定位与语音功能，是监管关注重点（儿童场景叠加《儿童个人信息网络保护规定》）。
- IoT家居：摄像头、门铃涉及家庭成员与访客的个人信息，共享观看权限应最小化并显著提示；家用摄像头不得指向公共通道（与第26条公共场所设备规则区分但精神一致）。
跨端一致性原则：同一业务在App、小程序、Web、IoT端的告知同意标准应保持一致——监管检测已覆盖多端形态，「小程序没人管」是过时认知。各端共享同一同意状态与用户偏好中心（第7页CMP技术方案）。
08 · 本节参考来源（第5页）
《App违法违规收集使用个人信息行为认定方法》（国信办秘字〔2019〕191号，2019年11月四部门联合印发）：中国网信网。
《常见类型移动互联网应用程序必要个人信息范围规定》（2021年5月1日施行，覆盖39类App）：工业和信息化部。
《关于进一步提升移动互联网应用服务能力的通知》（工信部信管函〔2023〕26号）：工业和信息化部。
TC260《网络安全标准实践指南——移动互联网应用程序（App）使用软件开发工具包（SDK）安全指引》（2020年11月）：全国信安标委。
工信部历年App侵害用户权益通报公告（2020年至今常态化机制）：工业和信息化部。
《个人信息保护法》第14、16、17、21、23、55条：中国政府网。