隐私与可用安全设计规范

面向设计师与工程师：这份规范管的不是产品有没有写隐私政策，而是用户能不能理解自己的数据被拿去做什么、能不能真的拒绝、能不能拿回来、能不能在丢了手机之后还进得去自己的账户，以及坐在旁边的那个人会看到多少。

隐私与可用安全产品做的是同一件事的两半：把系统对用户数据与账户所做的事情，翻译成用户能够理解的表述；再把用户的决定，翻译回系统里真实生效的约束。这个领域最常见的设计错误不是没做，而是做了一层看起来像控制权的东西——弹窗出现了、按钮点了、开关关了，但用途仍然不可解析，拒绝路径比接受路径多三步，关掉的推荐仍由另一路信号重建，删除只删掉了那一行记录而画像还在，找回账户的流程走不通于是用户被引导去打客服电话口头报出生日。这些都不是合规文本写得不够长，而是这个产品对用户作出的承诺没有兑现。

本规范由七条原则和 38 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（S3-2 就是第三条原则下的第二条规则）。

这个领域有两句话值得写在最前面，因为它们决定了后面所有条款的形状。第一句：同意的有效性由取得方式决定，不由是否点了按钮决定。一次点击是发生过的事实，不是自愿、具体、知情的证明；预勾选、默认开启、把拒绝藏进第三层菜单、把接受做成亮色而把拒绝做成灰字，取得的都不是同意（S2）。第二句：恢复流程的可用性缺陷等于安全缺陷。用户走不通的找回路径不会让用户消失，只会把他们推向更弱的路径——客服口头核验、亲友代操作、把口令写在便签上；因此恢复流程的放弃率是一项安全指标，不是一项体验指标（S5-3）。

范围声明本规范约束产品在数据用途、授权、账户与安全提示上对用户作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构。它不是合规检查表，不是安全架构文档，也不是组件库。本规范明确不做三件事：不作法律合规判定——GDPR、CCPA、PIPL 及各地法规在本规范中只作为引用来源与范围排除出现，符合本规范不等于符合任何法域的要求；不规定密码学实现——算法选择、密钥管理、协议设计与存储加密不在本规范范围内；不做威胁建模与渗透测试——攻击面枚举、红队演练与漏洞评级由安全专业流程承担。采用本规范不能替代下列专项评估：数据保护影响评估、安全评审与渗透测试、未成年人保护、无障碍符合性评估，以及各法域对特定行业的专项要求。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单与论据说明见附录 A、B，完整来源见 reference.md，可配置项见《隐私与可用安全 Design Token》。

---

1. 七条原则¶

七条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

同一个场景可以触及多条原则——用户在共用的平板上第一次打开一个记账应用，弹出通讯录权限请求，同意后应用把联系人上传用于"社交推荐"，随后应用在锁屏上推送了一条含好友姓名的通知——这一步同时面对用途是否可解析（S1-1）、这次同意是怎么取得的（S2-1）、权限请求是否发生在用途现场（S3-1）、通讯录里那些人本身没有同意（S6-2）、以及锁屏受众不明（S6-1）。这不是分类错误：五条规则约束的是五个不同规范对象上的义务，一个是用途声明，一个是取得过程，一个是权限时机，一个是第三方数据边界，一个是呈现受众。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：S2 与 S3——S2 管这一次同意是怎么取得的（自愿性、对称性、默认值、视觉权重），S3 管权限本身的时机、粒度、可见性与撤回后果。把"拒绝"按钮做成灰色小字，直接规范对象是取得方式，归 S2；"为什么在启动时就问定位"的直接规范对象是权限请求的时机，归 S3；"关掉定位之后仍用 Wi-Fi 列表推算位置"的直接规范对象是撤回的实际效果，归 S3-4。S5 与 S6——S5 管账户持有人自己的持有、证明与找回，S6 管不是账户持有人的那些人。亲密关系中的监控两边都沾：恢复流程本身允许哪些凭据、通知发到哪里，归 S5；共用账号与家庭组下他人能看到什么、被监控者是否知情，归 S6。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。一份"已声明用途清单"既是采集范围的判据（S1-2），也是权限请求文案的来源（S3-1），还是删除范围的推导起点（S4-3）；一套"受众解析"状态既决定通知预览的详略（S6-1），也决定共用设备上的状态隔离（S6-3）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：撤回同意之后系统不再据其处理数据，这是产品行为；用什么方式让这个撤回状态传到每一个下游消费方，是工程方案——两者必须对得上，但不是同一份交付物。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对用户的承诺会在可预见的情境下失效——这是标「必须」的唯一依据。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（S1-6、S2-6、S3-2、S3-5、S4-5、S5-5、S7-4 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把产品做成同意书朗读机。这个领域被做坏的方式在两端都很密集：一端是把用户的数据当成默认可取的原料，另一端是每打开一个页面先弹三层授权说明、每次点击都要求二次确认、把每一项设置都做成用户必须先读懂才能用产品的前置考试。把选择权交给用户不等于把工作量转嫁给用户——当系统自己有依据作出保守判断时，让用户来选反而是一种失职（S7-1）。安全性也一样：把恢复流程做得没人走得通，不是更安全，是把风险转移到了客服通道和便签纸上。

2.4 规则速查：38 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（S1-6、S2-6、S3-2、S3-5、S4-5、S5-5、S7-4），判定以正文为准（见 2.2）。

S1 用途可理解

S2 同意由取得方式成立

S3 权限有时机、有粒度、有痕迹

S4 撤回、导出与删除各自成立

S5 账户与恢复路径

S6 在场的其他人

S7 安全判断不外包

3. 规则详解¶

本章按七条原则展开全部 38 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 S1 用途可理解¶

这条原则管的是系统对用户数据所声明的用途本身：它说得够不够具体、覆盖了哪些数据、指向哪些接收方、变更时怎么办。用途是这个领域的第一性对象——同意要针对用途才成立（S2），权限要说得出用途才有理由（S3），删除要照着用途反推范围（S4）。用途写成一句无法被证伪的话，后面所有机制都会跟着失去判据。

S1-1用途可解析到具体处理必须¶

一句话："改善服务"不是用途；说得出做什么、用哪些数据、谁拿去用，才是。

适用任何收集、生成或接收用户个人数据的产品。

规则每一项用途必须可解析到具体的处理行为、涉及的数据类别、实际的消费方与保留期限四者（保留方式记录在 priv.purpose.retention.ttl）。保留期限是用途声明的一部分，不是可以留待以后再定的实现细节：说不出这类数据留多久、到期怎么处理，等同于该用途尚未声明完整；不留存的处理必须明确“即用即弃”及缓冲释放时点。期限须有起算事件、到期动作或可判定的结束事件；结束条件长期未到须有复核安排，不得用“必要期间”隐藏无限保留。"改善服务""提升用户体验""业务运营需要""安全与合规目的"这类无法被证伪的表述，不构成已声明的用途；"在必要期限内保留"同样不构成已声明的保留期限；把多项互不相关的处理合并进一条概括表述，等同于未声明。即时处理、长期个性化、人工质量审阅和训练通用模型须按实际目的分别判断，禁止用一次“生成答案”的许可覆盖所有后续用途。用途说明必须在用户作出实质投入之前可得，禁止仅存在于条款文本或需要用户比对历史条款才能发现。

边界条件本条不要求把内部实现细节、算法结构或供应商合同条款对外披露；要求的是用途的颗粒度足以让用户判断"这件事我要不要"。也不要求每个界面都重复完整说明——一处可查、随功能可达即可（呈现位置见 S1-6）。

设计应用用"这项数据被用来做什么、结果影响什么"这一对问题检验每条用途；若两个问题的答案在不同功能间不同，就应拆成两条用途，而不是并成一句。用途文案与权限请求文案、设置项文案取自同一处来源，避免三处说法不一致。

验证示例

• 用户侧：让未参与撰写的人读完用途说明后，回答"我的位置数据会被谁拿到、拿去干什么"，答不出即未满足。
• 实现侧：核对每条已声明用途是否能映射到具体的处理任务与下游消费方清单；存在无法映射的条目即为不合格。

反例做不到——隐私政策里写"我们可能将您的信息用于改善我们的产品和服务"；做过头——把每一次数据库写入都列成一条独立用途，产出一份两百条的清单，用户同样判断不了。

依据与参考GDPR 第 5 条目的限制原则与第 4 条第 11 项对"具体、知情"的要求（见 reference.md R11）；FTC 关于"用户被要求同意时往往未被清晰告知实际做法"的观察（R15）。

S1-2采集以已声明用途为界必须¶

一句话：每一项采集都指得出它是为哪个用途采的，指不出就不采。

适用具有数据采集能力的产品。

规则每一项被采集的数据必须指得出它服务于哪一条已声明用途；指不出对应用途的采集必须停止。可选功能所需的数据，在该功能未被用户启用时禁止采集。已声明用途终止或功能下线后，对应的采集必须随之停止，并按 S4-3 处理已有数据。采集范围的扩大与用途的扩大是两件事，任一项扩大都不自动带来另一项。

同意、访问与处置证据也属于数据处理：必须限定记录字段、可读取角色、保留期限及到期动作；禁止为证明已经删除而复制完整原始内容，禁止将认证秘密写入日志。会话录制、诊断上报和第三方分析组件必须纳入同一检查范围（priv.purpose.audit.policy；R28）。

指得出用途只是下限，不是全部：对每一条已声明用途，产品应当在能同等完成该用途的方案中，选择字段更少、精度更低、留存更短或可在本地完成的那一个；选择了更宽的方案时，记录必要性、替代保护与验证依据；对该应当项的偏离按 2.2 留痕，不把“更窄方案不可行”作为唯一可接受理由（记录在 priv.purpose.minimization.record）。一条很宽的用途声明加上一张与之对应的采集映射，可以通过前一段的检验，但通不过这一段——「有对应用途」不等于「这个精度是必要的」。

边界条件本条不禁止为安全防护、故障诊断与法定义务采集数据——但这些同样是用途，同样要按 S1-1 声明，不因其"技术性"而免于声明。

设计应用把采集项到用途的映射做成一张可被审计的表，而不是散落在各模块的埋点定义里；新增埋点时要求填写它对应的已声明用途，填不出就走用途新增流程（S1-5）。

验证示例

• 实现侧：抽取当前实际上报的字段清单，逐项回溯到已声明用途；出现"历史上加的，现在没人用"的字段即为不合格。
• 用户侧：关闭某个可选功能后，检查该功能专属的数据是否仍在上报。

反例做不到——注册时就要通讯录和精确位置，而这两项要到某个可选的社交功能启用后才用得上；做过头——为了严格对应，把同一份日志按用途复制成五份分别存储，反而扩大了数据面。

S1-3派生数据同受用途约束必须¶

一句话：算出来的和推出来的，和收上来的一样受管。

适用对用户数据进行推断、聚合、画像、特征提取或向量化的产品。

规则由用户数据派生出的推断结果、画像标签、排序权重、嵌入向量与聚合特征，必须与其来源数据受同一条用途声明约束，或另行按 S1-1 声明为独立用途；禁止以"这不是用户提供的数据"为由，把派生物排除在用途、撤回与删除的管辖之外。派生物的可流转范围不得宽于其来源数据。

边界条件本条不禁止产生派生数据，也不要求向用户展示每一项派生物的技术形态；要求的是派生物在用途、共享范围与删除范围上与来源保持一致或另有声明。

设计应用在数据字典里给每个派生字段标注来源字段与继承的用途，使删除与撤回可以沿这条链执行；不要把"特征存储"当成一个不受管辖的中间层。

验证示例

• 实现侧：删除某类来源数据后，检查据其训练或生成的用户级特征、标签与推荐权重是否同步失效。
• 用户侧：用户撤回某项用途后，观察依赖该用途派生标签的功能是否停止使用这些标签。

反例做不到——用户删除了浏览记录，但据其生成的兴趣标签留在画像里继续投放；做过头——把所有模型参数都视为个人派生数据，因为一位用户的删除请求而要求重训全量模型，最终无法执行任何删除。

S1-4数据去向指名到可解析的主体必须¶

一句话："合作伙伴"不是去向，名单才是。

适用将用户数据传输给本产品之外主体的产品，包括嵌入的第三方 SDK。

规则数据的接收方必须可解析到具体主体或足以判断风险的主体类别加可查询清单；"合作伙伴""关联公司""第三方服务商""为提供服务所必需的供应商"单独出现时不构成可解析的去向。清单必须可查、标注更新时点，并覆盖嵌入在产品内的第三方组件所发起的传输。接收方的新增按 S1-5 处理。

边界条件本条不要求公开商业合同条款、结算方式或技术接口细节；也不要求为每一次网络请求列出目的地。要求的是用户能据以判断"我的数据会离开这家公司到哪里去"。

设计应用把第三方 SDK 的数据行为纳入同一份清单，而不是只登记自研服务的调用；SDK 变动带来的传输变化按变更处理。

验证示例

• 实现侧：抓取一次典型会话的对外请求，逐个目的地回溯到清单条目；出现未列出的目的地即为不合格。
• 用户侧：用户能在不联系客服的情况下查到当前的接收方清单。

反例做不到——隐私政策写"我们可能与合作伙伴共享信息以提供更好的服务"，而实际接入了十一家广告与分析服务；做过头——把 CDN 节点、日志代理等不承载个人数据的基础设施逐个列出，把清单撑到用户读不完。

依据与参考Apple 要求应用披露第三方 SDK 的数据收集行为并以隐私清单提高准确性（R16）；FTC 记录了以模糊表述掩盖实际共享范围的做法（R15）。

S1-5用途变更不得静默扩张必须¶

一句话：新用途要重新取得依据，旧数据不自动跟着走。

适用已上线并已声明用途，随后新增、扩大或改变数据用途的产品。

规则新增用途或扩大既有用途的范围时，必须重新确定该用途的处理依据——以同意为依据的按 S2 重新取得同意，以其他依据的按该依据自身的成立条件重新确认并记录（记录在 priv.consent.basis 的 basis.ref）；并在生效前告知。不得把「原依据不再成立」本身当作改换依据的理由：同意缺失、失效或被撤回时，停止以该同意为依据的处理，而不是改称另一种依据（见 S4-1 与 Token 的能力依赖表）。按旧用途收集的数据默认不进入新用途，要进入须单独说明并单独取得依据。变更告知必须说明改了什么、从什么时候生效、对已有数据有什么影响，禁止以"条款已更新，继续使用即视为接受"作为取得方式（见 S2-1）。

边界条件本条不约束用途的收缩——停止一项用途、缩小接收方范围不需要重新取得依据，但仍应告知。修复缺陷、变更供应商而不改变用途与数据类别的，可以仍属同一用途，但接收方与处理边界须重新核对；同一用途不豁免接收方告知或适用依据评估。

设计应用把"这次改动是否改变了用途、数据类别或接收方"作为上线检查项，而不是只在法务评审时才判断；变更告知与产品更新说明合并时，不要把它埋在功能列表的第七条。

验证示例

• 实现侧：调取最近三次涉及数据处理的变更记录，检查是否分别作出了用途判定并留痕。
• 用户侧：变更生效后，检查旧数据是否已进入新用途而用户未被单独告知。

反例做不到——把原本用于订单履约的收货地址，在一次功能调整后用于线下门店的广告定向，仅在更新日志里写"优化了推荐"；做过头——每次界面文案微调都触发一次全量重新授权，把用户训练成一路点"同意"。

S1-6用户可查当前生效的用途与去向应当¶

一句话：让人看得到"现在正被用来做什么"，而不是去比对历史条款。

适用具有多项数据用途或多个接收方的产品。

规则产品应当提供一处可查的"当前生效的用途与去向"，呈现现在这个账户上实际启用的用途、对应的数据类别与接收方，并标注最近更新时点。禁止把这一信息的唯一形态做成需要用户自行比对历史条款才能得出的差异。该入口与撤回、导出与删除入口（S4-1）应当彼此可达。

边界条件本条不要求实时展示每一次数据访问；也不要求为此新建独立页面——嵌入既有的账户与设置区域即可。产品若只有单一用途且无对外传输，记录"不适用"即可。

设计应用以"这个账户当前的状态"而不是"我们可能会做的事"来组织这一页；把每条用途旁的开关直接指向 S4-1 的撤回操作，避免用户看得见却改不了。

验证示例

• 用户侧：让用户在三分钟内说出"我关掉了哪些、还开着哪些"。
• 实现侧：核对该页展示的用途集合与实际生效的处理配置是否来自同一数据源。

反例做不到——只有一份三十页的隐私政策和一份"更新摘要"，用户要靠对照才知道多了什么；做过头——做成一个逐条列出后台任务的技术仪表盘，用户看到的是队列名而不是用途。

3.2 S2 同意由取得方式成立¶

这条原则只管一件事：取得同意与授权的那一次交互过程。它不管数据被拿去做什么（那是 S1），也不管授权之后权限怎么用（那是 S3）。它管的是——问的时候有没有留出真的可以说不的余地。默认值、路径长度、按钮的颜色与位置、被拒绝之后还问几次，全都是取得方式的一部分；判定同意是否成立，看的是这些，不是日志里那条点击记录。

S2-1同意的有效性由取得方式决定必须¶

一句话：点了不等于同意了；预勾选和"继续使用即视为同意"都不成立。

适用以用户同意作为处理依据的场景，含权限授权、数据共享授权、营销授权与个性化授权。

规则同意必须由用户的明确肯定动作表达，且该动作针对可解析的具体用途（见 S1-1）。下列取得方式禁止被记为同意：预先勾选的选项、默认开启的开关、沉默或不作为、"继续使用即视为同意"、把多个不相关用途捆绑为一个开关、以及在用户无法阅读或无法退出的情境下取得的点击。一次点击是一个已发生的事实，不是自愿、具体、知情的证明；举证责任在产品一侧，取得方式必须可复现、可审计。

边界条件本条不要求所有处理都以同意为依据——合同履行、法定义务与其他合法依据下的处理不适用本条，但产品必须能说明它依据的是什么，且不得为一项本不需要同意的处理伪造一次同意来"更保险"。本条不作法域判定（见范围声明）。

设计应用把"用途"作为同意的单位，而不是把"弹窗"作为同意的单位；同一次弹窗里的多个用途分别记录取得结果。保存同意记录时一并保存当时展示的文案快照与界面形态，否则事后无法证明取得方式。

验证示例

• 用户侧：在不点击任何"同意"的情况下走完首次进入流程，检查依赖该同意的处理是否已经开始；其他处理须有事先独立成立的依据。
• 实现侧：调取同意记录，检查是否含用途标识、时间、文案快照与取得方式；只有布尔值即为不合格。

反例做不到——注册页底部一行小字"点击注册即表示您已阅读并同意《隐私政策》与《个性化推荐规则》"，其中包含向第三方共享；做过头——把每一个用途都做成必须逐条阅读并输入确认词的流程，用户在第四条之后开始机械点击，取得的同样不是知情的同意。

依据与参考GDPR 第 4 条第 11 项对同意的定义（自愿、具体、知情、明确的肯定动作）与第 7 条对取得条件的要求（R11、R12）；EDPB 关于欺骗性设计模式的分类将此类取得方式归入"跳过"与"置于黑暗中"（R14）；FTC 记录了"看似提供选择、实则选择是虚假的"这一模式（R15）。W3C 隐私原则（W3C Statement）进一步指出，同意机制常被用来回避「哪些处理是恰当的」这一判断，从而把隐私上的劳动转嫁给使用系统的人（R22）——这是本规范把义务放在用途声明（S1）而不是同意流程上的理由之一。

S2-2接受与拒绝路径对称必须¶

一句话：拒绝不能比接受更远、更难找、更不显眼。

适用向用户提供接受与拒绝二选一（或多选）的授权界面。

规则拒绝路径的步数与入口深度不得多于接受路径，可发现性不得低于接受路径——三者的"更好"方向不同，不能用同一个比较词。记录两条路径的差值与理由，只用于解释测量上的差异，不豁免本条对拒绝可达性的必须级要求。禁止只提供"全部接受"与"管理设置"的组合而没有同层级的"全部拒绝"；禁止把拒绝放在需要滚动、需要展开、需要跳转的位置而把接受放在首屏。若接受可以一键完成，拒绝也必须可以一键完成。

边界条件本条要求的是路径对称，不要求两个选项在语义上等价——产品可以说明拒绝之后会失去什么，只要该说明真实且不构成 S2-4 禁止的条件化。也不要求两个按钮完全相同的视觉样式（视觉权重见 S2-6），要求的是可达性对称。

设计应用用"完成拒绝需要几次点击、几次滚动、几次跳转"与接受路径做逐项对照，把差值记录下来；差值不为零就要给出理由。

验证示例

• 用户侧：计时对比一位新用户完成"全部接受"与"全部拒绝"分别需要多久。
• 实现侧：核对拒绝入口在移动端小屏、低分辨率与放大字号下是否仍在首屏可达。

反例做不到——Cookie 横幅上"接受全部"是一个按钮，"拒绝全部"要先点"管理偏好"、再逐项关闭十二个开关、再点"保存"；做过头——为了对称把"接受"也做成需要逐项开启，导致想要该功能的用户完成不了配置。

依据与参考EDPB 将此类设计归为“阻碍”（obstructing）类欺骗性设计模式（R14）；FTC 记录了“故意隐藏隐私选择、使其难以访问”的模式（R15）；Nouwens 等对同意管理界面的现场实验报告，拒绝入口和选项粒度会影响用户选择（R10，历史单场景研究，不作为通用效应量）。

S2-3默认值取最保守的一档必须¶

一句话：没选之前，按不采集、不共享、不个性化算。

适用存在默认取值的隐私与授权设置。

规则用户尚未作出选择时，系统必须按最保守的一档运行：不采集非必要数据、不对外共享、不个性化、不公开可见。未知情况按最保守解析——未知受众按可被他人看见（S6-1），未知年龄不扩大可选处理且不为消除未知而额外采集身份证明；法域未知时先收窄可选处理，必要处理的依据无法确认则暂停该路径并交责任人判定，不自行拼接所谓“更严”的规则。禁止以"用户可以随时关闭"为由把默认值设为开启。默认值的变更等同于配置变更，按 S1-5 告知。

边界条件本条不要求把产品的核心功能默认关闭——完成用户已选择的任务所必需的处理不属于本条约束的"非必要"范围。判定必要性的依据须被记录并可复核，不由功能方自行宣布。

设计应用把"默认值清单"作为一份独立可审的配置，而不是散落在各功能的初始化代码里；每次改动默认值都需要说明依据。

验证示例

• 实现侧：以全新账户、未作任何设置的状态运行一段典型会话，记录实际发生的采集与共享。
• 用户侧：检查用户从未打开过的设置项处于什么状态。

反例做不到——新账户默认开启"向好友展示我的动态"与"用于个性化广告"；做过头——把语言、时区、深色模式这类与隐私无关的偏好也默认为空，用户第一次进入面对一张空白配置表。

S2-4禁止以功能可用性换同意必须¶

一句话：不同意就不给用，这不是选择。

适用请求非必要处理授权的产品。

规则与所请求功能无关的处理，禁止作为使用该功能或该服务的条件。用户拒绝后，核心功能不得降级、不得插入额外等待、不得反复以受限状态提示。禁止以奖励、积分、解锁内容或抽奖诱导用户同意非必要处理。若某项处理确为提供功能所必需，必须能说明这项必需性，并按 S1-1 声明。

边界条件本条不要求产品提供无法实现的功能——地图导航确实需要位置，相机确实需要摄像头；这类功能内在必需的处理不属于本条禁止的"换取"。区别在于：拒绝之后失去的是这项功能本身，还是与之无关的其他能力。付费替代免费个性化广告的商业模式是否成立，属于法域判定，不在本规范范围内。

设计应用对每一项"拒绝后不可用"的功能，写出一句"因为这项功能需要用它来做 X"，写不出就说明它不是必需。

验证示例

• 用户侧：拒绝全部可选授权后，走一遍产品的核心任务路径，记录哪些步骤被阻断。
• 实现侧：核对被阻断的步骤是否确实依赖被拒绝的处理。

反例做不到——拒绝"个性化广告"后，App 的历史订单查询变为需要每次重新登录；做过头——为了避免任何"换取"嫌疑，把确实需要位置的导航功能也做成无位置可用，结果给出一条错误的路线。

依据与参考Apple 明确要求应用在用户拒绝跟踪请求后不得限制功能、不得以激励换取同意（R16）；GDPR 第 7 条第 4 项要求评估服务是否被以非必要处理为条件（R12）。

S2-5拒绝之后不反复索取必须¶

一句话：问过了就是问过了，换个入口再问一遍也是同一次。

适用授权可被用户拒绝的产品。

规则同一项授权在被拒绝后的重复请求必须有频次上限与新的理由；换一个入口、换一段文案、换一个时机重新发起的，计入同一项授权的重复次数。禁止在用户每次进入相关功能时重复弹出，也禁止把重复请求伪装成功能提示、红点或必读公告。用户明确表示"不再询问"后，系统禁止再主动发起该请求，只保留用户自己可找到的设置入口。

边界条件本条不禁止在用户主动尝试使用需要该授权的功能时再次请求——那是用户发起的，不计入重复索取。也不禁止在授权的实际用途发生实质变化时重新请求，但须按 S1-5 说明变化。

设计应用把重复请求的计数与上限做成机制层的约束，而不是各功能模块各自判断；上限与窗口由产品定义并记录依据，不在本规范给出数值。

验证示例

• 用户侧：拒绝某项授权后，连续使用产品两周，记录该请求出现的次数与场景。
• 实现侧：核对不同入口发起的同一授权请求是否共用同一计数器。

反例做不到——每次打开应用都弹一次通知授权，第三次开始把"稍后"按钮做成灰色小字；做过头——用户拒绝一次之后系统永久不再提供任何入口，用户后来想开启却找不到地方（这违反 S4-1 的可分别执行要求）。

依据与参考Android 权限指南明确"不要在用户拒绝后持续骚扰用户重新考虑"，并说明重复拒绝可能使系统停止再次展示权限对话框；适用条件须按目标平台核对（R17）；FTC 记录了"反复提示用户选择他们希望避免的设置"这一模式（R15）。

S2-6不以视觉与语言权重制造倾向应当¶

一句话：两个选项要看起来是两个选项。

适用呈现隐私与授权选择的界面。

规则选项的视觉权重与语言权重应当与其后果相称，不应当为使用户倾向于某一侧而设计。禁止下列做法：把倾向的一侧做成实心高对比按钮而把另一侧做成低对比文字链、给拒绝一侧使用制造愧疚或恐惧的文案（"不，我不在乎我的安全"）、使用双重否定或含糊措辞使选项语义难以辨认、利用其他任务的完成压力索取与该步骤无关的可选授权（例如在订单提交前插入一次广告个性化选择）、以及以倒计时或稀缺提示施加时间压力。

边界条件完成用户主动选择的那一步所必需的权限请求，可以出现在该步骤上——用户点了"拍照提交"随即弹出相机权限，正是 S3-1 要求的用途现场；本条禁止的是与该步骤无关的可选授权借这一时机出现。无论哪种情形，拒绝与退出的路径都必须保留。本条不要求两侧样式完全相同——按平台惯例把主要动作做成主按钮是可接受的，前提是"主要动作"的判定不以产品的数据收益为依据。也不禁止说明拒绝的实际后果，只要该说明真实（见 S2-4）。

设计应用把两侧的对比度、面积、位置与文案倾向列成一张对照表，交给未参与设计的人判断"这个界面希望我选哪个"；答案一致且与产品利益一致时，说明存在倾向。

验证示例

• 用户侧：向未参与设计者展示界面截图，让其指出"设计者希望用户点哪个"。
• 实现侧：核对两侧按钮的对比度、可点区域面积与焦点顺序。

反例做不到——"开启智能推荐，获得更懂你的内容"配亮色大按钮，旁边是灰色小字"以后再说"；做过头——把两个选项做成完全相同的灰色文字并随机排列位置，用户既看不出后果也找不到自己要的那个。

依据与参考EDPB 将此类做法归入“搅动”（stirring）类，涵盖情感操纵与视觉遮蔽（R14）；FTC 记录了“突出导致更多信息收集的选项，同时弱化限制此类行为的选项”（R15）；Utz 等在大规模现场实验中观察到通知位置与选项呈现方式对用户选择有可观影响（R09，样本限于单一站点，不据此固定任何版式）。

3.3 S3 权限有时机、有粒度、有痕迹¶

这条原则管的是系统对设备能力与账户资源的访问权限：什么时候要、能要到多细的一档、用的时候看不看得见、撤回之后会发生什么。它与 S2 的分工是明确的——S2 管那一次询问的取得方式是否留出了说不的余地，S3 管权限这个对象本身。一个产品可以把弹窗做得毫无诱导（满足 S2），却在启动第一屏就一次性索要六项权限、且关掉之后仍从别的信号把同样的东西算回来（违反 S3）。权限的最小单位不是"给或不给"，而是给多久、给多细、给谁看得见。

S3-1请求发生在用途现场必须¶

一句话：用到的时候再要，并说清这次要拿去做什么。

适用请求设备能力权限或账户资源访问权限的产品。

规则权限请求必须发生在该权限即将被实际使用的场景中，并说明这一次要用它做什么、结果影响什么。禁止在首次启动、注册流程或欢迎页集中索要与当前步骤无关的权限。请求文案必须与 S1-1 声明的用途取自同一来源，不得出现请求时说一套、隐私政策里写另一套。一次请求只对应一项用途；把多项用途合并到一次系统权限对话框中的，须在发起前另行说明各项用途（同意的取得仍按 S2-1 判定）。

边界条件本条不禁止在功能入口处提前说明"接下来会需要什么权限"——预告与请求是两件事，预告不触发系统对话框即不受本条时机约束。产品在安装或首次配置时确有必需的权限（如即时通信产品的通知权限），可在对应功能首次可用时请求，不必等到第一条消息到达。

设计应用为每一项权限写一句"用户此刻正在做什么，所以现在问"；写不出这句话，说明请求时机不对，而不是说明文案要再润色一遍。系统对话框的文案空间通常有限，把理由放在自有界面的前置说明里，让系统对话框只承担授权本身。

验证示例

• 用户侧：以全新安装状态走完前三分钟，记录出现了几个权限对话框、分别在用户做什么的时候出现。
• 实现侧：核对每个权限请求点是否位于对应功能的调用路径上；存在与调用路径无关的请求点即为不合格。

反例做不到——一个记账应用在启动画面依次弹出通讯录、位置、通知、相册四个系统对话框，用户还没看到任何功能；做过头——把说明做成必须逐屏阅读的五页教学，用户在真正需要拍照记账时被拦在教学流程里。

依据与参考Android 权限文档写明“在用户开始使用需要该权限的功能时，在情境中请求权限”，并建议尽可能推迟到用例流程的后段再请求（R17）。Apple 的文档允许在系统跟踪授权对话框之前先给出说明界面，但已有资料未将其作为“在情境中请求”规定为要求（R16）——本条的时机要求是本规范的设计主张，不是对某一平台条文的转述。

S3-2提供比"永久允许"更小的一档应当¶

一句话：只给这一次、只在用的时候给、给个模糊的位置，都应该是可选项。

适用请求可分级授权的权限（位置、麦克风、相机、相册、通讯录、健康数据等）。

规则当平台或产品有条件提供更小粒度的授权档位时，应当把它作为用户可选的一档，而不是只提供"永久允许"与"拒绝"。可用的更小档位包括但不限于：仅本次、仅在使用期间、近似而非精确、部分选取而非全部访问。禁止把更小的一档在界面上呈现为"受限模式""功能不完整"等负面表述以促使用户选择更大的一档（这同时受 S2-6 约束）。产品自身能力足以在更小档位下工作时，禁止以"实现复杂"为由只提供最大档位。

边界条件平台不提供分级能力时，本条不要求产品自行模拟一个无法在机制层强制的假分档——那会给出比实际更强的保护承诺。此时应记录该限制。本条不要求默认选中最小档位以外的行为约束，默认值另见 S2-3。

设计应用以"这项功能在最小档位下还能不能完成核心任务"为设计起点，而不是先按最大档位实现再考虑降级；后者会让最小档位永远处于"体验不佳"的状态，从而在事实上劝退用户。

验证示例

• 用户侧：选择最小档位后完成一次典型任务，记录被阻断或明显退化的步骤。
• 实现侧：核对代码中对权限结果的处理是否覆盖了全部平台档位，而不是只区分"有"与"没有"。

反例做不到——一个天气应用只接受"始终允许精确位置"，选择近似位置就提示"无法提供服务"；做过头——把每一次读取都做成一次单独授权，用户在一次相册整理中被要求确认四十次。

依据与参考Android 自 11（API 30）起，在位置、麦克风与摄像头的权限对话框中提供“仅此一次”（Only this time）选项（R17）。其他平台的等效档位本次未逐项核验，不据此声称各平台档位一致。

S3-3正在被使用时可见必须¶

一句话：麦克风开着这件事，用户要看得见。

适用在前台或后台访问麦克风、摄像头、位置、屏幕内容或其他敏感传感器的产品。

规则敏感能力处于活跃访问状态时，用户必须能获知这一事实。可见性由平台指示器承担时，产品禁止遮挡、伪装或以覆盖层规避该指示器；平台未提供指示器时，产品必须在自身界面内提供等效的活跃状态呈现。后台访问必须比前台访问有更明确的可见性与可查记录。访问结束后，状态呈现必须随之结束——持续显示一个不对应实际访问的指示，与不显示同样是错的。

边界条件本条不要求实时展示每一次数据读取的技术细节，也不要求为不涉及敏感传感器的常规网络请求提供指示。产品在平台强制指示器之外另加自有指示时，不得因此声称提供了比平台更强的保证。

设计应用把"活跃访问"作为一个显式的产品状态，而不是散落在各处的传感器句柄；有了这个状态，指示、日志与撤回（S3-4）才能读同一个源。

验证示例

• 用户侧：在通话、录音、后台定位三种场景下分别检查用户能否在不进入设置的情况下判断"现在正在采集"。
• 实现侧：核对活跃状态的开启与关闭是否与实际的传感器会话生命周期一致，是否存在关闭后仍在采集的窗口。

反例做不到——一个应用在后台持续采集位置，用户只能在系统的耗电统计里事后发现；做过头——在录音期间用一个覆盖半屏的红色警示层遮住用户正在填写的内容，使正常任务无法完成。

S3-4拒绝与撤回后行为真的改变必须¶

一句话：关掉就是不用了，不能换条路把同样的东西算回来。

适用提供权限拒绝或撤回能力的产品。

规则本条约束设备能力访问。用户拒绝或撤回权限后，系统必须停止受影响的新增访问；处理在途采集时，必须阻断尚未完成的访问并说明已经取得的数据范围。禁止通过其他传感器、指纹或网络线索暗中恢复被拒绝的能力或精度。撤回必须在实际访问检查点生效，不得仅改变界面开关；受理撤回请求与各执行点实际停止是两件事，分别报告。外部处理方尚未确认停止时，必须保留尚未完成的范围，不得由产品侧开关反推所有副本或已签发的访问凭据均已失效。撤回设备权限本身不删除历史数据，也不自动撤回独立的数据处理同意；若界面承诺“停止定位推荐”，则还须执行 S4-1 的用途停用。系统必须让用户辨认此次动作的对象、生效时点与尚未生效的范围。

边界条件用户主动选择替代路径时，可按已声明用途使用其输入：关闭定位后手选城市查看天气是合法路径；后台借 IP 恢复精准跟踪是旁路。已有历史数据仅在原处理依据仍成立、用途与期限未超出时继续使用；不能用“历史副本”延续用户已经停用的用途。

设计应用每次访问在权威授权状态上校验；缓存、后台任务与第三方组件接受撤回传播，失联时不继续受影响的新访问。界面同时呈现“已停止定位访问”和“历史记录仍保留，可另行删除”。

验证示例

• 用户侧：关闭定位，辨认哪些功能停止、哪些历史内容仍保留；手选城市后仍能查看天气。
• 实现侧：在采集中撤权，至少覆盖当前连接、离线队列、已签发的访问资格和第三方处理路径，检查传感器访问、后台队列和替代信号；只核查受影响的范围，不把有独立依据的历史数据一律判为违规。

反例做不到——关闭精确定位后改用网络指纹持续计算精准位置；做过头——关闭定位就删除所有已保存地点，并拒绝用户主动输入城市。

依据与参考Android 的权限指南要求在使用时检查权限并为拒绝提供可用退路（R17）。停止访问、用途停用和历史删除的语义分离，是本规范为避免虚假控制作出的设计要求。

S3-5长期未使用的授权自动收窄应当¶

一句话：长期闲置的授权应当收窄，期限按实际用途确定。

适用持有长期有效授权的产品。

规则在一段由产品定义并记录依据的时间内未被实际使用的授权，应当自动收窄或撤销，并在下次使用时重新请求。平台已提供自动重置能力时，产品禁止以规避机制（如后台任务定期触发一次无实际用途的访问）来维持授权。授权被收窄或撤销后重新请求的，按 S3-1 的时机要求执行，不计入 S2-5 的重复索取次数。收窄行为应当对用户可见，不使用户以为功能出了故障。

边界条件本条不适用于产品核心功能持续依赖的权限——一个持续记录运动轨迹的应用不应因用户三个月未打开界面而丢失后台定位授权，但这类例外须被列出并说明依据。也不要求产品在平台已实施自动重置时重复实现一套自己的收窄逻辑。

设计应用把"最近一次实际使用"记录到每一项授权上，而不是只记录"是否已授权"；没有这个时间戳，本条无法执行也无法验证。

验证示例

• 实现侧：调取各项授权的最近使用时间分布，检查是否存在长期为空但仍处于已授权状态的项。
• 用户侧：长期不使用某功能后重新进入，检查系统是否重新说明用途而不是直接沉默使用。

反例做不到——用户三年前授权过一次通讯录，此后再未使用该功能，授权一直有效；做过头——把用户每周使用一次的功能也按"不常用"回收授权，用户每次使用都要重新授权一遍。

依据与参考Android 应用休眠会在满足平台条件时重置权限，且存在设备前提和豁免（R25）；产品须核实其目标环境。平台回收可以承担该机制，不要求重复计时，也不由此推出统一闲置天数。

3.4 S4 撤回、导出与删除各自成立¶

这条原则管的是用户对已经交出的数据行使的处置。三件事必须分开：撤回是让系统停止继续按某个用途处理，导出是让用户拿走一份自己能用的副本，删除是让数据连同据其产生的东西一起消失。把它们做成同一个按钮，用户就会在只想停止推荐时丢掉全部历史，或者在想彻底清除时只关掉了一个开关。这个领域最常见的失败不是没提供入口，而是入口提供了、执行不彻底、状态说不清——用户点了删除，看到一句"已提交申请"，此后再无音信。

S4-1撤回与删除是两件事必须¶

一句话：停止继续用，和把已有的抹掉，要能分别做、分别说清楚。

适用保存用户数据或依据用户授权进行处理的产品。

规则每一次控制必须明确它作用在哪一类对象上——设备能力访问、特定用途的处理，还是指定范围的数据。产品必须对适用的对象分别提供控制并说明各自后果：

• 撤回能力访问：立即停止相应的新增访问（S3-4）；不自动删除历史数据。
• 停用用途：停止该用途的后续处理，并禁止用历史副本或替代信号继续该已停用用途；不自动删除已有数据。
• 删除数据：使指定范围的数据及其用户级派生物退出使用；不自动永久停用其他独立用途——被删数据所支撑的那项用途是否继续，以及新增数据是否继续收集，必须在该次操作中向用户说明清楚。

禁止把其中任一项冒充另一项，或强迫用户同时执行无关操作；可以提供明确说明后果的组合动作，并保留单独控制。用户撤回后，已有数据的存续状态必须可查；若已无独立有效的留存依据或期限已到，必须安排处置，不得以用户尚未另点删除为由无限保留。三者可以共用同一个设置页面与同一套状态基础设施——本条要求的是动作、作用实例与后果分立，不是要求固定数量的按钮；入口应当彼此可达，且与 S1-6 的用途查看页相连。

边界条件本条不要求为每一项数据分别提供三条路径——按用途或按数据类别分组是可接受的粒度；也不要求把它们放在三个不同的页面。产品若不保存任何数据（处理即用即弃），记录"删除不适用"并说明依据即可。

设计应用在同一页面上把两个动作并列呈现，各配一句后果说明："停止用于个性化推荐（已有的浏览记录保留）"与"删除浏览记录（推荐将不再使用这些记录）"；让用户看到差别，而不是让他们猜。

验证示例

• 用户侧：让用户完成"我不想再被推荐了，但记录先留着"这一意图，记录他们实际点到了什么。
• 实现侧：分别执行撤权、停用用途与删除，核查新增访问、指定用途的消费、删除范围和剩余记录；删除不得暗中永久关闭无关用途。

反例做不到——设置里只有一个"清除并关闭个性化"的按钮，用户想暂停推荐就必须一并丢掉三年的收藏；做过头——把每一类数据的撤回与删除拆成十六个开关，用户在其中找不到"全部停止"。

依据与参考EDPB 在同意语境中区分停止相关处理和独立依据的其他用途留存，并要求事先确定依据（R29）。三类控制及其界面反馈为本规范的设计要求。

S4-2撤回的难度不高于给出必须¶

一句话：当初两步给的，现在不能要七步才能收回。

适用以用户同意或授权作为处理依据的产品。

规则撤回同意或授权的步数、入口深度与所需渠道不得高于给出时。当初可以在应用内一键给出的，撤回禁止要求发送邮件、拨打电话、提交工单或前往线下网点。撤回入口必须可被用户在不借助搜索引擎的情况下找到。撤回过程中禁止插入挽留步骤、二次三次确认或"确定要失去这些好处吗"式的说服；确有必要的一次确认仍计入路径总成本，不能使撤回比给出更难。

边界条件本条要求的是路径难度不高于给出，不禁止在撤回后如实说明会失去什么功能——说明与挽留的区别在于是否阻断继续操作。对确有不可逆后果的删除类操作，一次明确的后果说明与确认不计入本条禁止的挽留（删除的确认另见 S4-6）。

设计应用把"给出路径的步数"与"撤回路径的步数"写进同一张评审表，作为发布检查项；差值不为零就必须给出理由。

验证示例

• 用户侧：对同一项授权分别计时"开启"与"关闭"所需的时间与点击数。
• 实现侧：核对撤回是否可在与授权相同的界面层级完成，是否存在仅有客服渠道的项。

反例做不到——注册时勾一下就同意了营销推送，退订要登录网页版、进入四层菜单、再输入一次账户密码；做过头——把每次停用营销都做成需要重新认证和输入确认词的高风险删除流程。

依据与参考GDPR 第 7 条第 3 项要求撤回同意应与给出同样容易（R12）；EDPB 将增设障碍的做法归为"阻碍"类欺骗性设计（R14）。

S4-3删除及于派生物必须¶

一句话：画像、权重、索引、缓存一起消失，才叫删除。

适用执行用户数据删除的产品。

规则删除必须及于据被删数据产生的派生物：用户级画像标签、个性化权重、检索索引、推荐候选集、缓存副本与备份中的可定位记录。删除完成后，系统禁止由日志、生成内容、嵌入向量或其他残留重建等价的用户级结果。删除范围内确有技术上不可即时清除的部分（如轮转周期内的冷备份），必须说明其存在、生效时点与在此期间的隔离措施，禁止以"备份中还有"为由把删除的实际效果无限期推后。对第三方接收方发出的删除请求按 S1-4 的清单执行，并说明其限度。备份恢复后必须在重新向业务开放前重放删除与撤回记录；不能因恢复备份而复活已处置内容。第三方只确认收到请求时，不能宣称其已完成删除。

边界条件本条不要求为一次用户删除请求重训全量模型——聚合到不可再识别到个人的统计量与模型参数不属于本条要求的用户级派生物，但产品必须能说明它凭什么判定某项派生物已不可再识别到个人，并记录该判定的依据。法定义务要求留存的记录不在删除范围内，但须按 S1-1 声明为独立用途，且不得继续用于原用途。

设计应用在数据字典里给每个派生字段标注来源与继承关系（见 S1-3），删除沿这条链执行；把"哪些系统持有该用户的可定位数据"做成一份可被审计的清单，而不是靠各团队回忆。

验证示例

• 实现侧：删除一个测试账户后核查检索、推荐、缓存、备份恢复与第三方回执；按已声明的留存例外单列剩余项，检查其未被用于原用途。
• 用户侧：删除浏览记录后查看范围、派生物与例外回执；推荐相似与否只作体验线索，不作为删除证据。

反例做不到——用户删除了全部聊天记录，但用于个性化的兴趣向量与检索索引原样保留，推荐照旧；做过头——把匿名化的整体统计也一并回滚，导致产品无法说明自己的基础用量。

依据与参考GDPR 第 17 条规定了删除权及其例外（R13）。

S4-4导出可用而不只是可得必须¶

一句话：导出来要看得懂、用得上，不是一个打不开的压缩包。

适用提供数据导出或可携带能力的产品。

规则导出结果必须是用户或其选择的接收方能够实际使用的形态：结构化、常用格式、字段有可理解的名称或随附说明。导出必须覆盖用户主动提供的内容与其在使用中产生的记录；不予导出的部分（如推断结果、内部评分）须被明确列出并说明理由，禁止以静默省略的方式缩小范围。导出的取得路径与等待时间须在发起前告知，完成后必须有可下载或可转移的实际产物。交付必须核对接收者的访问资格，提供受控领取路径、明确的下载有效期与服务端导出副本清理方式；禁止默认使用公开永久链接或把敏感附件发往未经核实的地址。下载资格变化后须拒绝后续领取。用户已自行下载的副本不应被承诺可远程收回。禁止以导出替代删除，也禁止把导出设为删除的前置条件。

边界条件本条不要求产品实现与任意竞品的直接互通，也不要求导出内部标识、算法中间态或其他用户的数据。导出中包含他人信息时（如聊天记录中的对方发言），产品应当说明该限度，处理方式另见 S6-2。

设计应用用"把这份导出交给另一个产品或另一个人，他们能拿它做什么"来检验格式选择；如果答案是"只能人工逐行阅读一份没有表头的 CSV"，那就还没满足。

验证示例

• 用户侧：请一位未参与开发的人打开导出文件，回答"这里面有哪几类内容、最近一条是什么时候的"。
• 实现侧：对照已声明的数据类别清单核查导出覆盖范围，逐项标注已导出、未导出及理由。

反例做不到——"下载我的数据"给出一个内含数百个随机命名 JSON 文件、无索引无说明的压缩包；做过头——为追求完整性把全部原始日志一并导出，产生数十 GB 内容，用户既下载不下来也读不懂。

依据与参考GDPR 第 20 条要求以结构化、通用且机器可读的格式提供数据（R13）。

S4-5个人数据可查看、可更正、可异议应当¶

一句话：看到自己的资料写错了，得有地方改；改不了的推断，得有地方提出异议。

适用保存用户个人资料、账户信息，或对用户形成推断与画像的产品。

规则用户应当能查看产品保存的、关于其本人的具体个人数据，而不只是查看用途清单——S1-6 的用途可查解决的是"这些数据被拿去做什么"，本条解决的是"这些数据本身是什么"，两者不互相替代。对可直接改写的记录（账户资料、联系方式、用户自填内容），应当提供更正入口；更正后，依赖该数据的推断与画像必须重新核验，禁止只改显示文本而让下游继续使用旧值。

对不可直接改写的推断结论（风控评分、兴趣画像、风险标签），应当提供三条可行路径中的至少一条：提出异议并获得处理结果、要求核查该结论所依据的来源、停止将该结论用于指定用途。产品不得以"算法不可解释"为由同时关闭这三条路径。

边界条件本条不要求所有记录可由用户直接编辑——交易流水、日志、他人提供的内容显然不可由本人改写，这些记录适用异议与来源核查路径。本条不要求公开风控算法或模型参数，要求的是结论可被质疑、来源可被核查、用途可被停止。本条不作各法域个人信息权利的合规判定（见范围声明）。

设计应用把"用户看到一条关于自己的错误信息"当成一条正常路径来设计，而不是客服工单的兜底分支。更正入口与异议入口分开：前者面向"这个值填错了"，后者面向"这个判断我不认同"。

验证示例

• 用户侧：让用户找到并更正一条错误的账户资料；再让其对一条不认同的推断标签提出异议，记录路径长度与得到结果的时间。
• 实现侧：更正一条资料后，检查依赖它的推荐、风控与个性化是否重新核验，而不是只更新了展示层。

反例做不到——用户发现画像里"有车"标签错误，产品只提供"联系客服"，客服答复无法修改；做过头——把全部内部特征向量原样开放给用户逐项编辑，用户改出一个不可用的状态，也给了对抗风控的入口。

依据与参考W3C Privacy Principles §2.5 讨论访问与更正，§2.2 讨论最小化；这是 W3C Statement 的原则参考，不替代各法域的权利清单。

S4-6处置有回执与期限必须¶

一句话：进行到哪一步、最后是什么结果、剩下什么没做完，是三个分开的问题。

适用提供撤回、更正、异议、导出、删除或账户注销的产品。

规则每一次处置请求必须有可查且来自执行机制的状态，至少分开记录以下维度：

• 阶段（phase）：已受理／执行中／已结束；已提交不等于已生效。
• 结果（outcome）：待核验／全部完成／部分完成／失败。结果可以在执行中更新；失败只在执行已结束且已核验没有任何目标完成时使用；全部完成只在阶段已结束且证据覆盖请求范围时使用。
• 范围：请求对象、已核验完成范围、未完成或未知范围、事先声明的留存例外；取消与终止原因另记。
• 证据与时点：权威来源、观察时间、最近进展及预计期限。旧快照不能覆盖较新的处置事实。

处置必须绑定正确的主体、对象和请求，核验方式与操作风险相称。已有会话或受控退订令牌足以完成低风险撤回时，不应额外索取证件或强制联系客服。

请求范围不可为迎合结果而事后缩小。下游回执丢失须标记待核验，先核对真实状态；提交或重试成功不证明处置完成，重复发起不得重复执行已完成的动作。备份隔离与物理清除分别呈现；有未核验范围时不得显示“全部删除”。

预计完成期限、超期后的联系或核对路径必须在发起时告知。出现期限未知或延误时，必须如实显示并指定处理责任，不得拒收既有请求或编造日期。部分完成时说明剩余范围与下一步；用户看到推荐变化不能代替删除证据。不可逆操作可作一次明确确认；存在可撤销窗口时说明其长度、截止时点及已执行部分不可撤销的边界，禁止借窗口连续挽留。

边界条件本条不要求为即时生效的处置（如关闭仅由本地机制控制的采集）另建回执体系——由权威状态确认的即时可见变化本身就是回执，不需要为它建一张工单。本条也不要求公开处置的内部工单编号或处理链路。

设计应用把处置状态与产品内其他长任务共用同一套状态模型，避免用户在这里遇到一套只在此处出现的表述。

验证示例

• 用户侧：发起一次账户删除，在第二天、第七天分别查看状态，记录用户能否判断"到哪一步了"。
• 实现侧：构造部分失败、全部失败、回执丢失、重复提交与迟到回执；核对界面状态、范围与证据是否一致，未知时先核对再决定是否重试。

反例做不到——点击删除后显示"您的请求已提交，我们将在合理期限内处理"，此后没有任何后续；做过头——把删除流程做成需要用户逐个确认十七个子系统的向导，用户在第五步放弃。

3.5 S5 账户与恢复路径¶

这条原则管的是用户对账户与身份的持有、证明与找回。这里有一个反直觉的核心：恢复流程的可用性缺陷等于安全缺陷。把找回做得极难，不会让账户更安全，只会让走不通的用户转向更弱的路径——客服口头核验、亲友代操作、把口令写在便签上、用同一个弱密码换一个能记住的邮箱。因此恢复流程的放弃率是一项安全指标。这条原则同时承载本规范的一条固定底线：秘密只在经界定的可信路径内流动；辅助填充可以减轻负担，普通助手与日志不得得到可复用秘密。

S5-1敏感输入只走可信路径必须¶

一句话：秘密只在可信的认证、支付或核验路径里流动，普通助手与日志碰不到。

适用涉及登录、支付或身份证件信息录入的产品，含具备代操作能力的 Agent 类产品。

规则产品必须为认证、支付与身份核验划定可信输入路径，记录参与组件、接收的值、必要留存、用户退出或接管入口（priv.account.credential.entry）。按实际能力分类敏感值，不按名称分类：

• 认证或交易秘密：口令、验证码、私钥、访问令牌，以及持有后可直接发起支付的令牌，只能由承担相应职责的可信组件处理。采用平台生物认证时，应当只接收所需的认证结果，禁止因接入认证而额外索取与任务无关的原始生物特征。
• 身份属性：银行账号、证件号等仍属敏感个人数据；核验与业务填表分别限定接收方和用途，不因为不属于口令就允许流入普通对话。
• 展示或受限引用：末四位等展示标识不等于支付授权；只有无法单凭持有使用、且受服务端范围控制的引用，才可按已声明用途在相应业务界面使用。

普通助手、模型上下文、对话记录、分析上报、会话录制与调试日志，禁止接收认证或交易秘密及未经必要性限定的敏感身份明文。禁止要求用户把秘密发送到普通聊天中或由助手转述。可信验证方、用户选定的凭据管理器、平台认证与支付组件可在必要职责内处理；自动填充不因此违规。禁止以“更方便”为由默认开通用户未选择的凭证代管。无法提供可信路径时，停止该敏感步骤并交还用户，不降级为普通文本收集。

边界条件业务表单按声明用途接收必要的身份属性不等于代管凭证。展示标识、支付授权和保存支付方式是不同动作，不能因展示了末四位就默认获得扣款许可。本条不指定加密、令牌化或认证协议。

设计应用把"这条路径上，秘密会经过哪些组件、其中哪些是经界定的可信组件、哪些会留下可复用的明文"作为设计评审的固定问题；有不该经过的环节，就改路径，而不是加一层脱敏展示。认证验证方、凭据管理器与支付组件要逐个写下来：它们各自拿到什么、保留多久、用户怎么接管。

验证示例

• 实现侧：核查日志、崩溃报告、会话录制与分析上报中是否可能出现凭证类字段。
• 用户侧：让 Agent 类产品执行一次需要登录的任务，检查它是向用户请求凭证，还是把控制权交回用户完成认证。

反例做不到——助手在对话中提示"把您的卡号发给我，我来帮您填"；做过头——为了避免任何代填，连用户自己的密码管理器自动填充也一并阻断，用户被迫手打二十位随机密码，最终改用弱密码。

依据与参考NIST 对验证方要求允许密码管理器与自动填充，对粘贴使用建议强度（R20）；可信路径不等于只能手工输入。日志中的敏感值边界参考 OWASP Logging（R28）。

S5-2恢复路径按攻击面设计必须¶

一句话：找回的门不能比正门更好推；熟人猜得到的答案不算凭据。

适用提供账户恢复、密码重置或身份重新验证的产品。

规则恢复路径的验证强度必须与正常登录路径相称，禁止存在未经评估的弱恢复后门；强度比较依据账户后果、攻击成功条件与补偿措施，不以步骤数或耗时比较。禁止把可被熟人知晓或可从公开信息推得的事实作为唯一凭据——出生日期、母亲姓氏、毕业学校、宠物名字、常用地址属于此类。恢复路径必须考虑近距离攻击者：与用户共处一室、共用设备或掌握用户设备的人，其可获得的信息与信道须被计入攻击面。恢复过程中禁止向发起方展示未经验证即可见的账户信息（如完整的绑定手机号、完整邮箱、历史地址），只在有资格看到时展示足够辨认的最小片段。未验证的找回请求不得通过文案、状态码或明显耗时差异暴露账户是否存在；恢复消息与尝试须防止批量滥发，限制命中后提供合法的下一步，不得仅因陌生人发起请求就锁死受害者账户。发出的恢复链接或验证码必须限定用途、设置有效期并在使用后失效。

边界条件本条不要求所有产品采用同一强度的恢复机制——强度与账户所承载的后果相称即可，一个本地笔记应用与一个支付账户不必等同。本条不规定具体的认证因子组合与密码学实现（见范围声明）。

设计应用把"谁可能想接管这个账户"具体写出来——陌生攻击者、前伴侣、同住室友、家庭成员——再逐条检查恢复路径对每一类是否有效；只针对陌生远程攻击者设计的恢复流程，对亲密关系中的接管几乎没有阻力。

验证示例

• 实现侧：以"掌握用户全部公开社交资料且能短暂接触其设备"为假设，尝试走通恢复流程。
• 用户侧：检查恢复流程中是否有任何一步向未验证的发起方泄露了账户的绑定信息。

反例做不到——忘记密码只需回答"您的第一所小学"，答案在用户的公开主页上写着；做过头——把恢复设计成必须同时提供三种因子且任一缺失即永久锁定，导致换过手机号的用户彻底失去账户（这违反 S5-3）。

依据与参考安全问题可能同时易猜、难记（R05，历史研究）。OWASP 的找回密码指南提供一致响应、限制滥发、一次性恢复凭据等机制参考（R27）；本规范把可预见的熟人攻击也纳入评估（R06、R07）。

S5-3恢复流程的可用性缺陷等于安全缺陷必须¶

一句话：走不通的找回路径会把用户推去走更危险的那条。

适用提供账户恢复的产品。

规则恢复流程的完成率与放弃率必须被测量，并作为安全指标纳入复核，不得只作为体验指标。用户在恢复流程中被卡住时，必须有明确的下一步或明确的失败说明，禁止让用户停在一个既不能继续也不告知原因的界面。恢复路径禁止把最终裁决完全推给无既定核验标准的人工渠道——人工渠道存在时，其核验依据必须被定义并可审计，否则它会成为整个账户体系中最弱的一环。产品应当为可预见的常见失效情形（更换手机号、丢失第二因子、邮箱不可用）预先设计路径，而不是留给个案处理。

边界条件本条不要求任何账户都必须存在可完成的恢复路径——对以用户本地密钥为唯一凭据的产品，"不可恢复"是一个可以成立的设计选择，但它必须在用户建立账户时被明确告知，且不得在事后以人工方式部分打破。

设计应用把恢复流程的漏斗与登录漏斗放在同一张图上看；恢复漏斗的大幅流失应结合合法用户、攻击流量和主动退出分层诊断，而不是"用户不够仔细"。

验证示例

• 实现侧：调取近一个统计周期的恢复流程各步完成率与最终放弃率，检查是否有责任人复核。
• 用户侧：模拟"更换了手机号且忘记密码"的用户走完全流程，记录是否得到可执行的结果。

反例做不到——第二因子丢失后唯一出路是"联系客服"，客服的核验方式是让用户口头报出出生日期与最近一笔消费金额；做过头——为提高完成率把恢复门槛降到只需邮箱验证码，等于把邮箱变成所有账户的万能钥匙（这违反 S5-2）。

依据与参考可用性与安全性并非此消彼长，把用户挡在流程外会产生新的失效路径，这一取向可追溯至 Whitten 与 Tygar 对安全软件可用性的定义（R01）。NIST SP 800-63A-4 建议凭据服务方鼓励用户绑定至少两种独立的认证方式，以减少对账户恢复的需要（R21）——这是把可预见的失效前移处理，而不是在失效发生后再设计流程。

S5-4账户与认证事件独立告知必须¶

一句话：有人给你的账户加了一把钥匙，你得从另一条路知道。

适用具有账户体系的产品。

规则下列事件发生时，必须通过不依赖被变更项本身的独立信道告知账户持有人：新设备登录、认证因子的新增与移除、密码或恢复邮箱与手机号的变更、账户恢复的发起与完成、以及授予他人访问权的操作。告知内容必须包含发生了什么、何时、以及"这不是我"时的下一步。禁止把变更通知只发送到刚被变更的那个地址或号码。告知禁止被产品的通知偏好设置整体关闭——用户可以调整其呈现方式，但不得使这类事件完全无声。

边界条件本条不要求为每一次常规登录都发送通知——判据是该事件是否改变了账户的可访问性。信道独立不等于信道安全：有理由怀疑旧号码、共享邮箱或通知镜像由他人控制时，须评估可能暴露的后果，使用经核实的替代信道或已认证安全中心，并记录选择与送达限制；不得机械地把全部细节发回可能受控的旧地址，也不得把安全告知整体关闭。没有可用独立信道时，明确限制并限制高风险账户变更，提供经定义的补救路径。产品可以合并短时间内的同类事件，但不得因合并而丢失其中任一项的具体内容。

设计应用把"账户安全事件"与"产品通知"分成两类，前者不进入营销与推荐的频次预算，也不受免打扰策略压制到不可见。

验证示例

• 实现侧：逐项触发上述事件，检查告知是否发出、发往何处，特别检查修改联系方式时告知是否到达安全且独立的已验证信道，而非机械发送到旧号码。
• 用户侧：在关闭全部通知偏好的账户上重复上述测试。

反例做不到——攻击者更换绑定邮箱后，变更确认信只发到了新邮箱；做过头——把每一次同设备的常规登录都推送一条安全提醒，用户在两周后关掉了全部安全通知（这同时触及 S7-2）。

S5-5不把认证负担转成记忆负担应当¶

一句话：别再强制改密、强加组合规则、禁止粘贴。

适用使用口令、验证码或交互式验证的认证流程。

规则产品不应当强制用户定期更换口令、不应当强加特定字符组合规则、不应当设置过短的口令长度上限。禁止阻止粘贴、禁止禁用密码管理器的自动填充、禁止以截断方式静默改变用户输入的口令。有证据表明口令已泄露时，应当要求更换——这是有依据的触发，与定期强制更换不是一回事。口令强度提示应当基于实际可猜测性而非字符类别计数。认证与恢复应当提供减少记忆、转录或解题负担的辅助机制或可达替代路径；支持键盘和辅助技术完成，拒绝某一认证方式后说明剩余选择。验证码有效期与重发后哪些码有效应当明确，重发不能使用户反复陷入不知该用哪条消息的循环（R24）。

边界条件本条不反对设置口令最小长度，也不反对禁用已知的高频泄露口令。特定行业或法域强制要求定期更换的，按其要求执行并记录该偏离的来源（本条为【应当】，偏离需留痕）。

设计应用把"用户为满足这条规则会做什么"作为规则设计的判据——强制每 90 天更换的实际结果通常是在原口令末尾递增一个数字，并把它写在便签上。

验证示例

• 用户侧：在注册与登录页尝试粘贴一段 40 位随机口令，检查是否被拒绝或被静默截断。
• 实现侧：核对口令策略中的每一项限制能对应到一个具体的威胁，对应不上的即为纯粹的记忆负担。

反例做不到——要求口令长度 8 至 16 位、必须含大小写与特殊字符、每 90 天更换且不得与前五次重复；做过头——完全取消任何长度与泄露口令检查，用户把口令设为 "123456" 也照单全收。

依据与参考NIST 对其适用对象禁止无依据的周期改密与字符组合要求，要求允许密码管理器和自动填充，对粘贴为建议（R20）。本规范对周期改密、组合要求采用【应当】，对阻止粘贴、禁用自动填充和静默截断采用【禁止】，以本条正文为准，不将来源强度整体照搬。

S5-6设备丢失有可执行的处置必须¶

一句话：手机丢了，能从另一台设备把它踢下线。

适用账户可在多台设备上保持登录状态的产品。

规则用户必须能从另一台设备查看当前已登录的会话与设备，并单独终止其中任意一个。终止请求必须先在产品可控制的服务端授权检查点撤回该设备的后续访问资格与刷新资格，禁止只在列表上移除条目而令牌仍然有效。端侧退出、缓存清除与离线验证凭据的失效，分别呈现各自的生效时点与限制。仅有端侧动作处于待执行时，不得把在线资源的访问资格一并保留——设备离线不构成继续接受其旧凭据访问在线资源的理由。被终止设备重新连接时，必须先核对撤权状态，不得复活旧会话。会话列表须包含足以让用户辨认设备的信息（设备类型、最近活动时间、大致位置或网络），同时不得包含足以被用于定位当前持有人的精确信息。

边界条件本条不要求产品提供远程擦除设备数据的能力——那是平台级能力，普通应用不因本条获得该权限。本条不要求所有离线凭据在瞬间失效——要求的是把检查点与剩余窗口写出来：产品须声明后续访问在哪个检查点被拒绝、离线期间仍可使用的本地能力范围、以及该窗口最长多久。被终止设备处于离线状态时，端侧清除转为待执行是可接受的，但用户必须能看到哪一部分已生效、哪一部分尚未生效。

设计应用把"服务端撤权已生效"与"该设备本地数据尚未清除"做成两行状态，而不是一个"待执行"。把"终止会话"与"修改口令"分开呈现并说明各自的效果——很多用户以为改密码就等于把别人踢了下去，而这取决于产品是否让令牌随之失效；这一点必须写明，不能让用户猜。

验证示例

• 用户侧：在设备 A 上终止设备 B 的会话，在设备 B 上继续操作，记录多久之后失去访问。
• 实现侧：检查终止后被撤销的是否包含刷新令牌与长期凭据，而不只是当前访问令牌。

反例做不到——设置里有"登录设备"列表但没有任何终止操作，用户唯一的办法是修改密码，而修改密码并不使旧会话失效；做过头——在会话列表中显示每台设备的精确位置与街道地址，使得同住的人可据此确认另一方的行踪（这违反 S6-4 的用意）。

依据与参考OWASP 会话管理指南要求服务端会话失效（R26）。端侧清除、离线范围与真实反馈是本规范进一步规定的体验边界。

3.6 S6 在场的其他人¶

这条原则管的是不是本次账户持有人、但被这次交互影响的人。这些人没有点过任何同意按钮：站在用户身后看得见屏幕的人、被录进一段音频的同事、共用一台平板的家庭成员、被家长或伴侣通过"关心"功能持续定位的人、通讯录里被上传了号码的联系人。同意是账户持有人给的，影响却落在他们身上——这是隐私设计中最容易被整套流程跳过的一环，因为产品的每一个交互对象都是账户持有人，而受影响的人在系统里没有位置。S5 与 S6 的分界在于：账户持有人自己的持有、证明与找回归 S5；不是账户持有人的那些人归 S6。

S6-1同屏的人不是授权受众必须¶

一句话：受众不明时，按会被别人看见来处理。

适用在锁屏、通知、投屏、外放语音、共享界面或公共场所可能呈现内容的产品。

规则呈现私密内容前必须解析当前受众；受众不明时按可能被他人看见处理，隐去具体内容并提供进入私密视图的路径。锁屏通知、语音外放与投屏状态下，默认不展开消息正文、验证码、健康与财务数据、身份信息以及可推知敏感处境的内容。禁止以"用户自己会注意"为由默认展开。用户可以主动放宽这一默认，但放宽必须是显式设置，不得由产品依据设备类型或使用频率自行推定。

边界条件发送方、事件类型、头像、标题和缩略图也可能暴露敏感处境，必须和正文一起判断；“有一条新消息”仅在其本身不会泄密时呈现。产品无法获得任何受众线索时，按最保守的一档执行即为满足本条，不要求产品实现受众识别能力。

设计应用把"私密度"作为内容的一项属性，与"受众"这项上下文相乘决定呈现详略；不要在每个通知构造点各写一遍判断逻辑。

验证示例

• 用户侧：在锁屏、车载投屏与外放语音三种状态下分别触发一条含验证码的消息，记录呈现了多少。
• 实现侧：核对私密度标注是否覆盖全部通知类型，是否存在默认公开的遗漏项。

反例做不到——锁屏上完整展示"您的银行验证码是 481920"与"体检报告已出：血糖偏高"；做过头——在用户已主动选择公开显示无敏感内容的日程后，仍把所有通知都做成"您有一条新通知"，用户必须逐条解锁查看才知道是不是垃圾消息，最终关闭全部通知。

S6-2被录入的第三方有独立边界必须¶

一句话：用户同意不能替录音里的另一个人同意。

适用采集或处理含非用户第三方信息的产品：录音录像、通讯录上传、聊天记录分析、照片中的人脸、会议转写等。

规则账户持有人的同意不构成对内容中第三方的处理依据。含第三方信息的数据，其用途必须限于完成用户当次任务所必需的范围；禁止将其用于扩展产品自身的社交图谱、身份库、广告定向或跨用户的推荐。通讯录、通话记录与相册中的他人信息，禁止在用户未使用相关功能时上传（见 S1-2），也禁止在用户删除后作为"他人的数据"继续保留。录制与转写类功能在技术与场景允许时，应当向在场其他人提供可感知的进行中提示。

边界条件本条不禁止用户自己保存与使用含他人信息的内容——用户拍下的合影仍是用户的照片。判据在于产品是否把这些第三方信息转为自身可跨用户复用的资产。本条不作各法域对录音告知义务的判定（见范围声明）。

设计应用对每一项含第三方信息的数据，写出"如果那个人来问，我们能说清他的信息被拿去做了什么"；答不出就说明用途已经超出了用户当次任务。

验证示例

• 实现侧：检查通讯录上传后的数据是否参与了跨账户的关系推断或"你可能认识的人"计算。
• 用户侧：用户删除账户后，检查其上传的他人号码是否仍在系统中可被匹配。

反例做不到——一个工具类应用上传全部通讯录，据此为每个号码建立档案，包括那些从未安装过该应用的人；做过头——为避免任何第三方数据处理，连用户自己给联系人打的备注也拒绝本地保存，使功能无法使用。

依据与参考Nissenbaum 的情境完整性（2004 年文本）提出信息流受两类情境规范约束——恰当性规范与流通规范，任一被破坏即构成对情境完整性的侵犯；该文并明确反驳“人一旦进入公共场合便无规范可言”的看法（R08）。这为“用户同意不改变第三方所处情境”提供了分析框架，但它是分析框架而非可直接套用的判定规则；常被一并引用的五参数模型出自其后续著作，不在该文中。

S6-3共用设备与共用账号不共享私密状态必须¶

一句话：一台设备上的两个人，不该继承对方的历史和推断。

适用可能被多人使用的设备或账号：家庭平板、共用电脑、智能音箱、车机、家庭共享账户。

规则设备或账号被多人使用时，产品必须提供私密状态不跨使用者继承的机制：分离的历史记录、推荐依据、搜索建议、自动填充与个性化配置。无法区分使用者时，按 S2-3 取最保守的一档，不呈现基于历史的个人化内容。禁止把已存在的多人使用事实当作共享许可——一台设备上出现两个人的使用痕迹，不构成任何一方同意向另一方展示自己的记录。切换使用者或退出的路径必须可达，且退出后不得残留可据以还原上一位使用者行为的界面状态。

边界条件本条不要求所有产品实现完整的多用户体系——提供可用的“访客”或“暂不记录”模式，使退出后不向下一位使用者暴露私密状态，可满足本条；若仍有已声明的安全日志或服务器留存，必须说明，禁止把它宣称为全链路“不留痕”。共同账户下由用户主动共享的内容（共享相册、共同清单）不属于本条约束的私密状态。

设计应用把"上一位使用者留下了什么可见痕迹"作为共用场景的验收清单：搜索框历史、输入法候选、自动填充、通知栏、最近打开、推荐首页——逐项检查，而不是只清空一个"浏览历史"。

验证示例

• 用户侧：在同一台设备上以两位使用者身份先后使用，记录第二位能看到第一位的哪些痕迹。
• 实现侧：退出访客模式后，检查本地缓存、推荐候选与输入建议是否仍含上一次会话的内容。

反例做不到——家庭平板上的视频应用把一位家庭成员的观看记录直接作为全家的推荐依据，并在首页展示"继续观看"；做过头——把家庭共享相册也按私密状态隔离，导致家人看不到自己已被邀请加入的共享内容。

S6-4具备监控能力的功能必须让被监控者知道必须¶

一句话：能看见别人在哪的功能，不能有隐藏模式。

适用提供位置共享、活动可见性、使用时长报告、内容审阅或设备管理等可被用于持续观察他人的产品，含家庭安全、儿童守护与企业设备管理类功能。

规则具备持续观察他人能力的功能，必须在被观察者的设备或账户上有持续可感知的呈现；禁止提供隐藏图标、隐藏运行、伪装成其他应用或使被观察者无法查知观察正在进行的模式。被观察者必须能查到谁在观察、观察什么、从什么时候开始。观察范围的扩大必须重新告知。被观察者不具备完全自主权的情形（未成年人、企业设备），仍必须让其知道观察的存在与范围——知情与是否有权关闭是两件事，不得因为后者不成立就取消前者。

边界条件本条不禁止家长控制与企业设备管理这类功能本身，也不要求赋予被观察者关闭它的权限。本条不作各法域对监控合法性的判定（见范围声明）。产品在被观察者侧没有账号或应用时（如仅在路由器侧实施），必须另行提供一条被观察者实际可获得的等效告知机制并验证其覆盖——例如接入时的强制告知页、该网络下的可见标识、或在该空间内可查的公示；只告诉设置者不构成满足本条，因为设置者恰恰是被观察者需要知情所针对的一方。做不到这一点的，停止开放该监控能力，而不是把告知对象换成设置者。告知设置者其呈现限度是附加要求，不是替代路径。

设计应用在设计这类功能时把"如果被观察的是设计者自己，他希望知道什么"写下来；再检查产品是否提供了这些。亲密关系中的滥用往往使用的正是产品的正常功能，而不是被入侵——因此可见性必须由产品保证，不能依赖被观察者自己去发现。

验证示例

• 用户侧：以被观察者身份检查其设备与账户，记录能否在不借助外部工具的情况下发现观察的存在与范围。
• 实现侧：核查是否存在任何可使图标、通知或状态项被隐藏的配置组合。

反例做不到——一款"家庭安全"应用提供"隐身模式"，安装后在被安装设备上不显示图标、不发通知，持续上报位置；做过头——把每一次位置读取都在被观察者设备上弹出全屏提示，使功能无法在其设计场景（走失儿童）中发挥作用。

依据与参考对亲密伴侣暴力场景的研究显示，攻击者常常是已经通过认证、以标准界面操作的一方，既有系统的威胁模型未覆盖这类对手（R06）；被用于监控的多数是以儿童安全或防盗为名的双用途应用，而非公开出售的间谍软件（R07）。行业联盟对此类软件的界定，以“在被监控者未同意、且无明确而持续的提示的情况下远程监视其设备活动”为核心，并指出仅有物理接触、解锁设备或用账号密码登录不构成被监控者的同意（R19）。

S6-5账户持有人不等于数据主体必须¶

一句话：付钱的人、买设备的人、管账号的人，不自动获得读的权利。

适用存在账户所有者与实际使用者不一致的产品：家庭组、企业账户、代管账户、以他人名义开通的服务、被赠与或被配置的设备。

规则账户的所有权、付费关系或设备的购买关系，不自动构成读取实际使用者个人数据的依据。管理者可获得的信息范围必须被明确定义、对被管理者可见，并限于其管理职责所必需；禁止默认向管理者开放对话内容、浏览记录、位置轨迹、健康数据与私人通信。管理者对被管理者账户的处置（移出、重置、导出、删除）必须对被管理者告知，紧急情况下的例外须被列出并说明依据。被管理者退出管理关系时，其个人数据的去向必须明确，禁止默认将其转交给管理者。

边界条件本条不否认管理关系中确有的正当需要——企业对工作数据的访问、家长对未成年人的必要保护。判据是被访问的数据是否落在已声明的管理职责范围内，以及被管理者是否知情（见 S6-4）。本条不作劳动法与未成年人监护相关的法律判定（见范围声明）。

设计应用在设计管理者视图时，逐项标注"这一项管理者能看到吗、为什么、被管理者知道吗"；把这份标注做成可被被管理者查看的说明，而不是只存在于管理后台的功能列表里。

验证示例

• 用户侧：以被管理者身份查询"我的管理员能看到我的什么"，记录能否得到具体答案。
• 实现侧：核对管理者接口返回的字段集是否与已声明的管理职责范围一致。

反例做不到——家庭组的组织者可以查看每位成员的完整应用使用记录与位置历史，而成员从未被告知；做过头——企业管理员无法查看任何设备合规状态，导致丢失设备时无法确认其是否已加密（这与 S5-6 的处置能力冲突）。

3.7 S7 安全判断不外包¶

这条原则管的是系统向用户发出的安全警告，以及要求用户作出的安全判断。它的出发点是一个已被反复记录的现象：重复警告可能造成习惯化，其影响取决于风险类型、时机与呈现。因此本原则的第一条不是"把警告写清楚"，而是先把不该成为警告的东西删掉——系统自己判得出的风险应当被拦截或被默认处理，而不是转成一道用户没有依据回答的选择题。剩下的每一条警告都要用得起用户的注意力：说得出后果、说得出下一步，绕过要留下痕迹且不是永久的。把安全决定推给用户，看上去是尊重选择权，实际上是把系统解决不了的问题写成用户的责任。

S7-1能挡住的不做成警告必须¶

一句话：系统自己判得出的风险，不该变成用户的选择题。

适用向用户呈现安全、隐私或风险提示的产品。

规则当系统已有足够依据判定某项行为存在明确风险时，必须直接拦截或按保守方式处理，禁止把该判断转为需要用户回答的选择题。仅在系统确实无法判定、且用户掌握系统不掌握的信息时，才向用户呈现选择。呈现选择时必须说明系统已知与未知的部分。禁止以"用户已被告知"作为把责任转移给用户的手段——告知是否有效，由用户能否据此作出判断决定，不由是否显示过决定。

保守处理必须区分两种后果：阻断新的威胁，与移除已经存在的监控。两者均须评估可见后果；后者尤其可能被安装者察觉——Coalition Against Stalkerware 的处置指引指出移除可被安装者发现，因而需要由设备持有人自己选择是否移除（该指引不是法律标准）。因此：默认动作限于阻断新增威胁；移除既有监控、重置共享凭据、向历史联系方式发出安全通知这类可能被对方察觉的动作，必须先评估其可见后果，并把选择权与安全联系路径交给当事人。不得以「保护受害者安全」为由向被监控者隐瞒监控的存在——S6-4 的知情义务不因本条而减损；本条限制的是产品替当事人作出可能暴露其求助的动作。

边界条件本条不要求把所有不确定情形都做成静默拦截——误拦的代价同样真实，尤其在拦截会阻断用户合法工作的场景。判据是用户是否掌握作出这个判断所需的信息：用户知道自己刚刚点了哪个链接（用户有信息），但不知道某个证书链的中间环节是否被替换（用户没有信息）。

设计应用对每一条现有警告问一句"用户拿什么来回答这个问题"；答案是"猜"或"点了才知道"的，就应该改为拦截或改为提供用户真正需要的那条信息。

验证示例

• 实现侧：清点产品中全部安全类提示，逐条标注系统的判定依据与用户被要求提供的判断；两者相同的即为应被拦截的项。
• 用户侧：向未参与设计的人展示一条警告，让其说明"你会依据什么决定继续还是返回"。

反例做不到——检测到明确的凭证钓鱼页面后弹出"该网站可能存在风险，是否继续？"，并提供一个同等显眼的"继续"；做过头——把所有自签名证书一律静默拦截且不提供任何例外路径，使内网运维工具全部无法访问。

依据与参考安全可用性研究强调让用户理解并完成必要的安全任务（R01）；浏览器警告研究显示效果因设计与情境而异（R02、R03）。这些来源不证明“多一条警告必然更差”，也不提供跨产品阈值。对既有监控的处置风险参考行业联盟指引（R19）。

S7-2警告的数量按有效性预算必须¶

一句话：重复提示先查原因，预算耗尽也不能放过关键风险。

适用会向用户发出中断式安全提示的产品。

规则安全警告必须被作为有限资源管理：产品必须定义在什么条件下才发出中断式警告，并对其发生频次设定上限。禁止仅以提高视觉强度（更大、更红、更多感叹号）替代原因诊断。警告被忽视时，先核查四件事——重复与去重（是不是同一风险反复出现）、时机（是不是出现在用户无法处理的时刻）、可理解性（用户能否据此判断）、风险构成是否变化（是新出现的风险类别，还是同一类别的量变）；在此基础上可以采用有验证依据的呈现修复，包括经测量证明能减缓习惯化的呈现变化。重复出现的同类警告必须被合并或转为一次性设置。频次上限到顶不得取消对关键风险的处置：达到上限时的合法处理是合并、去重，或按 S7-1 转为直接拦截，而不是让该风险不再被处置。警告的实际有效性应当被测量并纳入复核；测量须按明确的风险类别与用户组分层，并同时观察误拦截、错误放行与任务完成情况，不以单一的"行为改变率"替代安全结果。测量方法与阈值由产品定义并记录依据，本规范不给出数值。

边界条件本条不要求减少非中断式的状态呈现（如 S3-3 的活跃指示）——那不消耗同一份注意力预算。法域或平台强制要求出现的提示不计入本条的频次上限，但仍应被计入用户实际承受的中断总量并加以说明。

设计应用把"这一年里我们向用户发了多少条中断式安全提示"作为一个可被报告的数字。这个数字上升而行为改变率下降时，数量是首先要查的嫌疑，但不是已经查明的原因——同期风险构成、受众、文案可读性与拦截策略的变化都可能造成同样的曲线，先把这些分层拆开再下结论。

验证示例

• 实现侧：统计一个典型用户在一个月内遇到的中断式安全提示数量与类型分布。
• 用户侧：观察用户在连续遇到同类警告第三次之后的实际操作用时。

反例做不到——每次连接公共 Wi-Fi、每次打开外部链接、每次授予任一权限都弹一次全屏安全提示，用户在第二周形成了不看内容直接点"继续"的习惯；做过头——为控制数量把真正的高危拦截也合并进一条每周汇总，用户在事发时得不到任何提示。

依据与参考R02 的出版方摘要支持警告效果存在显著差异；R04 的摘要讨论习惯化及呈现变化。本规范要求诊断原因并验证修改效果，不从摘要推导具体频次或效果保证。

S7-3警告说得出后果与下一步必须¶

一句话：挡了什么、影响什么、接下来能怎么办。

适用向用户呈现安全或隐私警告的产品。

规则每一条留下来的警告必须说明三件事：发生了什么、如果继续会有什么后果、现在可以做什么。禁止只给出错误代码、技术术语或"操作已被阻止"而无任何可执行的下一步。后果必须以用户能理解的具体损失表述，不使用"可能存在安全风险"这类无法据以判断的表述。警告中提供的下一步必须真的可执行——指向一处并未提供的设置项、一个需要管理员权限而用户没有的操作，等同于没有下一步。警告的措辞不得夸大以促使用户选择产品偏好的一侧（见 S2-6）。

边界条件本条不要求向用户披露完整的技术诊断信息——那既无助于判断，也可能被攻击者利用。要求的是足以支持这一次决定的信息，技术细节可以放在可展开的次级位置。

设计应用用"发生了什么／会怎样／怎么办"三段式写每一条警告，写不满三段的，说明这条警告还不该发出（回到 S7-1）。

验证示例

• 用户侧：让未参与设计的人读完警告后回答"如果我点继续，最坏会怎样"。
• 实现侧：逐条检查警告中提供的操作入口是否在当前用户的权限下可达。

反例做不到——"NET::ERR_CERT_AUTHORITY_INVALID"外加一个"高级"折叠项；做过头——用三段文字详细解释证书链验证原理，用户读完仍不知道该点哪个按钮。

依据与参考Felt 等对浏览器 SSL 警告的重新设计研究报告，遵从率显著提高的同时用户对威胁的理解并未随之改善，且单独改写文案的效果很小（R03）。据此，本条的三要素是必要条件而非充分条件：写清后果与下一步不保证用户理解，但缺了它用户连可执行的动作都没有——这一推论是本规范的设计判断。

S7-4绕过路径有摩擦、有记录、可复原应当¶

一句话：绕过要是一个明确动作，而且不是永久的。

适用允许用户绕过安全拦截或降低安全设置的产品。

规则绕过安全拦截或降低安全档位的操作应当满足三项：需要一个明确的、与常规操作不同的动作（不得由误触或连续点击同一位置完成）；留下用户可查的记录（做了什么、什么时候、影响范围）；默认有期限并可一键复原。禁止把绕过设置为默认永久生效且无任何提示，也禁止在用户绕过后停止对同类风险的后续检测。绕过的作用范围应当被限定到具体对象，不扩展为全局关闭。

边界条件本条不要求把绕过做得难以完成——摩擦的目的是使其成为一次有意识的选择，不是阻止有正当理由的用户。企业或开发场景中确需长期例外的，应当以显式的例外清单表达，而不是以关闭整项保护表达。

设计应用把"用户绕过了什么"做成一份可查的清单，并在其中显示每一项的到期时间；没有这份清单，产品与用户都不知道当前实际处于什么安全状态。

验证示例

• 用户侧：绕过一次拦截后，检查用户能否在事后找到"我曾经允许过什么"。
• 实现侧：检查绕过是否被限定到具体对象，是否存在到期或复原机制。

反例做不到——点击"继续访问"后该站点被永久加入信任列表，用户此后不再收到任何提示，也无处查看这份列表；做过头——每次访问同一个已知内网地址都要求重新完成一次多步绕过流程，用户最终整体关闭了该项保护。

4. 术语和定义¶

本章只定义本规范内使用且容易产生歧义的词。

附录 A：故障注入验证清单与分类检验¶

本清单用于检验条款是否真的生效，不新增义务。逐项继承正文适用条件、例外及应当项的偏离规则；“不适用”须有理由，“未测”不等于通过。下面的时点与时长是用例情境，不是通用阈值。

A.1 用途与采集

A.2 同意的取得方式

A.3 权限的时机与撤回

A.4 处置的执行与回执

A.5 账户与恢复

A.6 旁观者与第三方

A.7 警告与安全判断

A.8 分类检验

用于检验第 1 章的切分是否成立：取 10 至 15 条具体要求（可来自本规范条款，也可来自真实评审意见），让至少三名未参与撰写的评审者独立判断其归属原则。归属分歧集中在某两条原则之间，说明这两条原则的规范对象没有切开——此时应当调整原则，而不是增设中间层或映射说明。已知需要重点检验的两处见第 1 章的明示（S2 与 S3、S5 与 S6）。本检验的评审人数与分歧判据是本规范建议的内部检查法，不是经文献验证的标准方法。

A.9 补充边界用例与判定记录

每项结论记录：适用规则及子句、产品能力与环境、初始事实、用户动作、机制证据、界面反馈、预期与实际差异、负责人。结果使用“通过／不通过／不适用（理由）／未测”；应当项的偏离另附理由、替代措施与验证。文档结构检查、实现检查与用户任务验证分开记录，不能互相替代；不得把本清单已写出当作产品已通过。

附录 B：论据边界与来源类型¶

B.1 约束词的判据

标「必须」的唯一依据是：缺了它，某条对用户的承诺会在可预见的情境下失效。下列三类论据提供不同支持，不是三种独立的强制性来源；失败记录或实现参考本身不足以决定标「必须」——

标「应当」的七条（S1-6、S2-6、S3-2、S3-5、S4-5、S5-5、S7-4）的应当项允许经论证偏离：偏离可能有正当理由，但要留痕并接受同样的验证。其中 S2-6、S3-2、S3-5、S5-5、S7-4、S4-5 与 S1-6 各含至少一条禁止级子句，那些子句不因规则标题为【应当】而降格（见 2.2）。

B.2 本规范证据最薄的三处

明确列出，不用条款语气掩盖：

1. S7-2 没有可移植的警告数量阈值。"多少条警告算多"没有跨产品的公认判据。已有研究记录了警告被忽视的现象与改进设计后遵从率的变化，但那些数值来自特定浏览器与特定警告类型，不能作为任意产品的上限。本规范因此只要求"上限被显式定义；有效性应当测量，偏离须有替代验证；责任明确"，不给数值。这是本规范中最可能被形式化应付的一条。
2. S4-3 的"不可重建"缺少可操作的判定方法。判断一项聚合结果或模型参数是否仍可定位到个人，在工程上没有简单答案；本规范给出的是要求（产品必须能说明其判定依据并记录），不是判定方法。相关的技术路线（如从模型中移除特定训练数据的影响）本次未取得可支持产品级承诺的核验结论。
3. S6-3 的"私密状态"边界依赖产品判断。哪些状态算私密、哪些属于共同账户下的正常共享，在家庭、办公与公共设备三类场景中不重合。本规范给出的是检查清单的构造方式（逐项列举可见痕迹），不是一份通用的私密状态字段表。跨文化的家庭数据共享预期差异也未在本次检索中取得可直接引用的结论。

B.3 本规范未做的事

不作法律合规判定（GDPR、CCPA、PIPL 等在本规范中只作为来源与范围排除出现），不规定密码学实现与协议选择，不做威胁建模与攻击面枚举，不给认证因子的推荐组合，不给数据分类分级的通用标准，不给未成年人年龄门槛。这些是法务、安全专业流程与产品的决定；本规范只规定这些决定必须被作出、必须可被检验，以及哪些取值不被允许。

B.4 来源

完整的来源对照与核验范围见 reference.md。规范中的条款不因为某个产品这样做过就成立；平台做法是"这类机制在真实产品中可行"的证据，不是"应当这样要求"的依据。法规条文证明某项要求在某法域存在，不证明本规范的表述与该法域的适用判定一致。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。