手电筒索要定位、壁纸软件要读通讯录、算命小程序要相册权限——大家被这些操作烦久了,反而觉得「反正都这样」。但个人信息保护法第六条把线画得很清楚:收集个人信息应当限于实现处理目的的最小范围,不得过度收集;处理要有明确合理的目的,且与目的直接相关、对个人权益影响最小。配套的第十六条再加一道锁:不得以用户不同意或撤回同意为由拒绝提供产品服务。理解 APP最小必要原则,就是学会用这两条做判断。本文把第六条拆成三条标尺,逐个场景过筛,告诉你哪些收集合法、哪些越界,不同意授权时你有权用什么。

⁠​‌​‌​​‌​‌‌‌​‌​‌​​​​​‌​‌​‌‌​‌‌‌​‌‌​​‌‌​‌​‌​‌​‌‌​​⁠

先看这三个要点

关键结论
  • 三条标尺:目的明确合理、处理与目的直接相关、方式对个人权益影响最小;收集范围限「实现目的的最小范围」。
  • 不得捆绑断供:非必需信息用户不给,App 不得拒绝提供服务;确属必需的除外——必需与否逐项业务判断,不是 App 说了算。
  • 诚信底线:第五条同步要求不得以误导、欺诈、胁迫方式处理信息——一揽子勾选、不同意就闪退,都在被禁止之列。

一、条文原文

法条依据
  • 《中华人民共和国个人信息保护法》第六条
  • 处理个人信息应当具有明确、合理的目的,并应当与处理目的直接相关,采取对个人权益影响最小的方式。
  • 收集个人信息,应当限于实现处理目的的最小范围,不得过度收集个人信息。
法条依据

二、最小必要的三条标尺

要件标尺条文要求典型对照
目的正当目的明确、合理,不是「改善体验」式空泛兜底支付核身目的明确;「用于营销及合作方使用」属捆绑兜底
直接相关处理与目的直接相关外卖需要地址电话;需要「通讯录好友排行」就无关
影响最小+范围最小方式影响最小、收集限于实现目的的最小范围核身可用运营商三要素就不必传身份证照片原件

三条标尺是递进适用的:先问目的站不站得住,再问这项信息跟目的有没有直接关系,最后问能不能用影响更小、范围更窄的方式达到同样效果。通讯录案例里,目的(语音通话)合理,但完成通话不需要上传整个通讯录——直接相关和最小范围两道关都过不了。

三、「必需」怎么判:逐项业务对号

第十六条的但书是「处理个人信息属于提供产品或者服务所必需的除外」——必需与否不是 App 自封的,而是按功能逐项判断:

  • 不提供就无法完成交易:网购的收货人姓名、地址、电话;购票的乘客身份信息;酒店入住的实名登记——必需,用户不提供,商家可以不成交;
  • 不提供也能用基础功能:地图 App 的个性化推荐、电商的好友关系、新闻 App 的精准推送——不属必需,拒绝授权只能导致该附加功能不可用,基础服务照常;
  • 权限最小化:即使必需,也要用最小权限形态——扫码功能用相机时申请,用完可关;需要位置推荐的,给「仅使用期间」而非后台持续定位。

把「必需」做成了「全家桶」:不同意读通讯录就闪退、不同意开全部权限就锁死 App——这同时踩了第六条的最小范围和第十六条的捆绑禁止。

四、边界与误区

  • 误区一:「用户协议写了收集范围就合规」。写在协议里不等于必需;超范围收集公示了也违法,告知义务与最小必要是两道独立的闸门。
  • 误区二:「撤回同意后之前收集的都得立刻清零」。撤回影响的是之后的处理;已进行的处理效力不受影响,但撤回后不得再继续处理,且应提供便捷的撤回方式(第十五条)。
  • 误区三:「必需信息也要我反复同意」。必需信息的收集仍要过合法告知关,但商家确可因不提供而不成交;混淆点在于必需按功能拆分——不能拿核心交易必需为由把营销信息一并搭走。
  • 不适用:为订立履行合同所必需的处理本来无需同意(第十三条第二项),但仍受最小必要约束;国家安全、公共安全类信息收集有特别法规则的,从其规定。

五、延伸问答

问:App 说「不授权相册就退款」,算不算捆绑? 关键看功能对应:买东西用不到相册的,以退款、锁功能逼用户授权,就是第十六条禁止的捆绑;相反,图片编辑功能要求相册权限,不给权限确实用不了该功能——只能限制该功能,不能限制整个 App。

问:一次问全所有权限再让用户勾,合规吗? 一次性打包申请本身就是超范围的高发形态:权限申请应与功能触发对应,用到相机时才申请相机。首启弹一个「全部权限授权书」勾选框,即便用户同意,也难以满足最小必要与逐项必需。

问:SDK 嵌进 App 里收集,责任算谁的? 算 App 运营者的。SDK 以 App 名义向用户收集信息,用户面对的仍是 App;运营者对嵌入的第三方代码收集行为负管理义务,接入前审核、接入后监测,出了超范围收集不能拿「是 SDK 干的」脱责。

问:用户改过主意,之前拒绝的权限能再问吗? 可以,但要有节制:在与功能使用场景直接相关时再次请求,并说明用途;反复弹窗轰炸、不给授权就不停打断使用,属于变相胁迫,与第五条禁止的胁迫式处理背道而驰。

问:手机厂商的权限弹窗合规了,App 内部还要再做吗? 系统权限只是入口管控;App 对收集到信息的使用仍要过第六条的目的与范围检验——拿到了相册权限,不代表可以把相册数据用于广告画像。系统合规不等于业务合规。

问:临时活动要收集额外信息,怎么办? 活动目的要明确、信息范围要最小,并单独告知;活动结束、目的实现,收集基础消失,按第四十七条该删的删。把「活动收集」悄悄沉淀进用户画像长期使用,是典型越界。

问:把「不同意隐私政策就不能安装」设成开关,违法吗? 分内容看:隐私政策里属于基础服务必需的部分,用户不接受确实无法提供服务;但政策里捆绑的营销、共享条款一并打包成「不同意就不给装」,超出的部分就是捆绑,第十六条的评价是逐项的。

问:用户拒绝授权后,App 降级运行的「降级」有边界吗? 有:降级只能落在与该信息相关的功能上。拒绝定位,导航功能受限合理;拒绝定位,导致连网页浏览、支付都被锁死,就是把拒绝权变成了惩罚,属变相强制。

问:间接收集(合作方提供)也要守最小必要吗? 要。处理包括接收——从第三方获取的信息同样要有明确目的、与目的直接相关;来路不明、范围超目的的第三方数据,接进系统的那一刻处理活动就开始了,责任同样落在接收方头上。

问:必要性的举证在谁? 监管检查与诉讼中,处理者要能说清每类信息的必要性逻辑——为什么收、不收会怎样。说不出必要性论证的「习惯性收集」,就是最小必要原则的重点清理对象;个人质疑时,可以要求平台说明。

问:精简收集会影响业务,企业怎么平衡? 平衡的尺子就是三条标尺:目的正当、直接相关、影响最小。先做功能与信息的映射表,把「想要」和「需要」分开;确有业务诉求的超范围收集,走明确告知加用户主动同意的附加通道,而不是混进必需清单。

问:老 App 版本仍在跑旧权限逻辑,怎么办? 版本治理也是合规义务:下架旧版本或推动升级,对无法升级的存量用户按新标准收缩权限调用;监管测评不看版本新旧,只看当下行为是否超范围。

问:用户自己愿意多给信息,可以收吗? 自愿不等于合规:超范围收集不因用户「愿意」而获得合法性,目的与必要性审查是客观标准。用户主动提供的额外信息,企业要么拒收,要么单独评估其处理依据,不能默认「用户给了就能用」。

问:监管通报过的「常见超范围」有哪些? 高频形态包括:无相关功能却申请通讯录/短信权限、频繁索权、一揽子打包授权、不同意非必需权限即闪退、SDK 超范围回传。对照这五类自查,能解决绝大多数APP的收集问题。

问:位置信息的「最小」怎么把握? 分场景给粒度:导航需要精确定位,天气服务给到城市级即可,门店推荐给到商圈足够;再按时段收紧——仅使用期间优于后台持续。粒度与时长双收敛,是位置类收集的最小化公式。

问:注销后 App 还推送「我们想你了」,用什么数据发的? 能推送到你,说明联系方式仍在处理;若推送基于画像判断「流失用户」,画像处理也未停。注销场景下的召回营销,目的已灭失,多数站不住,用户可据此直接投诉。

六、实操建议:两头的自查动作

用户侧:安装新 App 先看权限清单与功能对不对得上,明显超范围的截图留证;被「不同意就不给用」卡住的,按第十六条交涉或向网信、工信渠道投诉(站内有投诉渠道专文);用完非必需权限随手关闭。

企业侧:把每个功能列成「目的→所需信息→最小权限→是否必需」四栏表,逐格过三条标尺;权限申请与功能调用解耦,营销类信息一律不进必需清单;把「拒绝非必需授权不影响基础功能」做成可验证的产品逻辑。

站内《过度收集、一次概括授权、默认勾选:个人信息这几条线不能踩》《App 过度收集个人信息:怎么用删除权和注销权让 App 放手》《不经同意也能用你的个人信息?六种合法情形与企业最容易踩的两个坑》对场景细化有专文,可对照使用。

一句话总结:最小必要就是三问——目的正不正、相关直不直接、范围能不能再小;「必需」逐功能判断,借必需捆营销、不给授权就断服务,两条法条一起管。


以上内容为一般性法律知识介绍,不构成正式法律意见。具体案件请结合 App 功能与权限设置,咨询执业律师后主张。