不同意处理个人信息能否拒绝提供服务,是每个人打开 App 都会碰到的问题。《个人信息保护法》第十六条给的答案很明确:不得以个人不同意处理其个人信息或者撤回同意为由,拒绝提供产品或者服务;处理个人信息属于提供产品或者服务所必需的除外。先给结论:能不能拒,只看一个标准——这项信息与你要用的核心功能是否不可分离。是,可以拒;不是,不能拒,也不许用“不同意就不能用”逼用户点头。

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

先说结论

先说结论

① 原则(第十六条):不得以“个人不同意处理”或者“撤回同意”为由拒绝提供产品或者服务。

② 唯一例外:处理个人信息属于提供产品或者服务所必需。判断标准是必要性与不可分离性,不是企业单方声明。

③ “必需”的三层判断:与核心功能不可分离、不处理就无法实现功能、且没有对个人权益影响更小的替代方案。

④ 捆绑授权不合法:把非必需信息与必需信息打成“一揽子同意”,用户不同意就整体拒用,实质违反本条。

⑤ 救济路径:要求说明必要性 → 关闭非必要权限 → 撤回同意 → 向监管部门投诉举报 → 造成损害的可依第六十九条主张赔偿。

一、条文原文

法条依据

这一条只有一句话,但包含两个规范:前半句是禁止性规范,后半句是例外条款。争议几乎全部集中在“什么是必需”上。

二、本条适用的四个要件

构成要件具体内容判断要点
主体要件行为人是“个人信息处理者”,即自主决定处理目的、处理方式的组织或个人自主研发运营的算;仅提供技术接入、不决定目的方式的,通常不算
行为要件实施了“拒绝提供产品或者服务”的行为,包括完全不提供、限制核心功能、反复弹窗阻断使用变相拒绝也属于拒绝,例如只保留浏览不能下单
因果要件拒绝的原因是个人的“不同意”或者“撤回同意”因未实名认证、因不符合资质而拒绝的,不属于本条规定的情形
例外抗辩处理该个人信息属于提供产品或者服务所必需举证责任在处理者一方,须说明必需性而非仅援引协议条款

四个要件里,实务中真正拉开胜负的是第四项。前三个基本是事实问题,第四个是价值判断加技术判断。

三、“必需”怎么判断:三步法

第十六条的“必需”,与第五条“合法、正当、必要和诚信原则”、第六条“与处理目的直接相关、采取对个人权益影响最小的方式、收集个人信息限于实现处理目的的最小范围”是一套逻辑。落到个案,可以按三步走:

第一步:这项信息与核心功能是否不可分离。

先问清楚这个产品或者服务的“核心功能”是什么。地图导航的核心功能是路线规划与实时导航,位置信息与它不可分离;而通讯录、短信权限与导航功能可以分离。购物平台的核心功能是展示商品与完成交易,收货地址、手机号与它不可分离;而人脸、声纹、精确位置与购物可以分离。

第二步:不处理这项信息,功能是否真的无法实现。

这一问最容易被企业含糊过去。门禁可以刷卡、可以密码、可以二维码,人脸只是其中一种方案,不采集人脸门禁照样能用,那么人脸就不属于“必需”。反过来,人脸识别支付如果不采集人脸就无法完成支付,这一类场景下才更接近必需。

第三步:有没有对个人权益影响更小的替代方案。

第六条明确要求“采取对个人权益影响最小的方式”。有替代方案而不用,直接选影响最大的那种,即使功能确实需要这项能力,也很难认定为“必需”。

三步全过,才构成第十六条的例外。任何一步不成立,“不同意就不能用”就是违法。

四、常见场景对照

场景要求的信息是否“必需”理由
地图导航实时位置通常属于与导航核心功能不可分离
地图导航通讯录、通话记录不属于与导航无直接关系
网购下单收货地址、联系电话通常属于不提供无法完成配送
网购下单人脸、声纹不属于支付方式可多元化,非唯一方案
短视频浏览手机号、身份证通常不属于浏览无需身份识别
短视频发布手机号(实名要求范围内)视法规要求依法律、行政法规规定需要实名的,属法定义务而非“必需”抗辩
小区门禁人脸一般不属于刷卡、密码、二维码可替代
在线问诊症状、既往病史通常属于与诊疗服务不可分离
健身 App健康数据视功能而定若核心功能是运动数据分析,可能属于;若仅记录步数则不属于
银行开户身份证件信息、人脸核验通常属于履行反洗钱等法定义务所必需

这张表只是判断框架,不是结论清单。同一项信息,在不同产品里可能得出相反结论——关键看核心功能是什么、有没有替代方案。

五、捆绑授权:本条最常被违反的形态

实践中,本条被违反的方式通常不是“直接说不同意就滚”,而是更隐蔽的三种:

其一,一揽子同意。 打开 App 弹一个框,内容是“同意《用户协议》和《隐私政策》”,其中混杂了位置、通讯录、设备信息、人脸等全部授权。用户只有一个“同意并继续”按钮,不同意就退出。这不是单独同意,也违反本条——因为其中大量信息并非必需。

其二,功能与授权强绑定。 想用记笔记功能,必须开放通讯录权限;想查快递,必须允许读取短信。功能与权限之间没有技术上的必然联系,属于典型的过度索权。

其三,撤回同意即断供。 用户在设置里关闭了某项授权,App 直接退出登录或者限制主要功能。第十五条明确个人有权撤回同意,第十六条明确不得因撤回而拒绝提供服务。这两种行为放在一起,就是完整的违法链条。

法条依据
  • 《中华人民共和国个人信息保护法》第十五条
  • 第十五条 基于个人同意处理个人信息的,个人有权撤回其同意。个人信息处理者应当提供便捷的撤回同意的方式。
  • 个人撤回同意,不影响撤回前基于个人同意已进行的个人信息处理活动的效力。

注意“便捷”二字。撤回入口藏在五级菜单里、需要提交书面申请、需要客服人工审核七天——形式上给了撤回权,实质上没有,同样不符合第十五条。

六、企业端的合规做法

对经营者来说,本条不是“不许要信息”,而是“不许拿不必要的信息换服务”。可操作的合规路径有四条:

第一,做权限清单。 把每项权限与具体功能一一对应,标注“必需”或“可选”。清单本身就是必要性的书面证明。

第二,分开授权。 必需信息与可选信息分开征得同意,可选部分拒绝后功能照常可用,只是对应增值功能不可用。

第三,提供替代方案。 门禁保留刷卡通道,支付保留密码通道,登录保留账号密码通道。有替代方案,“必需”抗辩才站得住。

第四,随功能触发。 不在启动时一次性索要全部权限,而在用户实际使用某功能时才申请对应权限。这是监管一贯倡导的做法,也最能减少争议。

七、边界:这些情形确实可以拒绝

第十六条的例外不止“技术必需”一种,还有几类容易混淆的情形需要分开:

第一,法定义务要求的信息。 依法律、行政法规规定必须收集、必须实名、必须核验的,属于第十三条第三项“为履行法定职责或者法定义务所必需”。这类情形下不提供信息,业务本身就无法合法开展,拒绝服务有正当依据。但要注意:法定义务的范围由法律、行政法规确定,企业内部规定、行业惯例不算。

第二,合同履行所必需。 第十三条第二项允许“为订立、履行个人作为一方当事人的合同所必需”处理个人信息。例如外卖必须知道送餐地址。但“合同里写了”不等于“合同所必需”——格式条款里塞进去的授权,仍要接受必要性审查。

第三,用户不符合其他法定条件。 因年龄、资质、地域限制而拒绝提供服务,与“不同意处理个人信息”无关,不适用本条。

第四,用户要求的功能本身依赖该信息。 用户主动要用“附近的人”功能,却拒绝提供位置,此时无法提供该功能,属于功能层面的客观不能,不属于本条禁止的“以不同意为由拒绝”。

第五,匿名化或者不依赖个人信息的功能。 如果企业能在不处理个人信息的前提下提供同等服务,那更应该走这条路,而不是索要授权——这属于合规优化,不是例外。

八、被“不同意就不让用”卡住,可以这样做

第一步,先分清必需与可选。 看弹窗里到底要什么:位置、通讯录、相册、麦克风、人脸。对照核心功能逐项判断。多数情况下,只有一两项真正必需。

第二步,只给必需,拒绝可选。 现在的手机系统都支持“仅本次允许”“模糊位置”“拒绝”等精细选项。能单选就不要整体同意。

第三步,要求说明必要性。 第十七条要求处理者告知处理目的、方式、种类。可以要求其说明某项信息与功能的对应关系,书面答复本身就是证据。

第四步,撤回并观察反应。 在设置里关闭非必要权限或撤回同意。如果 App 因此拒绝提供核心服务,即落入第十六条的禁止范围,注意录屏保存。

第五步,投诉举报。 向履行个人信息保护职责的部门投诉。违法处理个人信息的,监管部门可依第六十六条责令改正、警告、没收违法所得,对应用程序责令暂停或者终止提供服务;拒不改正的并处罚款。

第六步,主张赔偿。 造成实际损害的,依第六十九条起诉。该条实行过错推定:处理者不能证明自己没有过错的,应当承担损害赔偿责任。

九、条文关系网

关联条文内容要点与本条的关系
《个人信息保护法》第五条合法、正当、必要、诚信原则本条“必需”判断的总纲
《个人信息保护法》第六条与处理目的直接相关、影响最小、最小范围“必需”的具体化标准
《个人信息保护法》第十三条六类合法性基础法定义务、合同必需等情形另有依据
《个人信息保护法》第十四条同意应充分知情、自愿、明确“被迫同意”不符合自愿要件
《个人信息保护法》第十五条有权撤回同意,须提供便捷方式撤回后不得断供
《个人信息保护法》第十六条不得因不同意或撤回而拒绝提供服务本条
《个人信息保护法》第十七条处理前的告知义务判断“知情”的前提
《个人信息保护法》第六十六条行政处罚违法索权的公法后果
《个人信息保护法》第六十九条过错推定的赔偿责任违法索权的私法后果
《民法典》第一千零三十五条合法、正当、必要原则;不得过度处理民事基本法层面的一致性规定

被过度索权后的索赔路径,见商家泄露消费者个人信息,能赔多少;泄露后的取证维权,见个人信息被泄露、被人肉搜索怎么办?。

十、常见误区

误区一:“写进用户协议就是合法的。” 协议的效力受必要性审查约束。格式条款不能把不必要的信息处理变成“必需”。

误区二:“不同意就退出,这是企业的经营自由。” 第十六条恰恰限制的正是这种“自由”。除非属于必需,否则不能以此拒供。

误区三:“免费产品就可以多要权限。” 是否收费不影响本条的适用。免费产品同样受必要原则约束。

误区四:“撤回同意等于解除合同,当然可以停止服务。” 撤回同意只影响基于同意的处理活动,不当然导致服务终止;除非该处理确属服务必需。

误区五:“只要弹窗写得清楚,就不算强制。” 写得清楚解决的是“知情”,解决不了“自愿”。捆绑式的一揽子同意,即使文字清晰,仍可能违反本条。

误区六:“不同意就不能用,只能忍着。” 拒绝提供非必需信息后被断供,属于可投诉、可诉的违法行为,不是用户的义务。

注意避坑

对企业来说,本条真正的合规成本不在写协议,而在做权限与功能的对应表:哪项权限服务哪个功能、有没有替代方案、拒绝后功能是否还能用。这张表做不出来,“必需”抗辩基本无从谈起。对个人来说,最有效的动作不是争论,而是只给必需、拒绝可选、撤回后录屏——把“因不同意而断供”这一事实固定下来,后面才有得谈。

一句话总结:不得以不同意处理个人信息或者撤回同意为由拒绝提供产品或者服务,除非处理该信息属于提供产品或者服务所必需;判断“必需”要看与核心功能是否不可分离、不处理是否真的无法实现、有无影响更小的替代方案;捆绑授权、功能与权限强绑定、撤回即断供均违反本条;法定义务所需、合同履行所需、功能本身客观依赖等情形可以拒绝,但“写进协议”不构成必需。违法索权可依第六十六条投诉、依第六十九条索赔。


以上内容为一般性法律知识介绍,不构成正式法律意见。具体案件请结合证据与实际情况,咨询执业律师或向有管辖权的人民法院提起诉讼。