摘要

  • RFC 9614 把隐私分区定义为将识别主体的“谁”与描述活动或数据的“什么”分开；真正的分析单位是共享访问权的数据、元数据和实体所构成的“上下文”。
  • 加密、双代理或多跳都不是隐私收据。共同所有权、稳定标识符、应用载荷、联合日志、时间、尺寸和故障降级路线都可能把上下文重新合并。
  • 可审计的部署必须展示上下文图、控制权、可见标识符、保留期限、允许的连接、旁路行为，并用真实流量测量关联成功率。

“分开存放”很容易被误写成“无法重组”。前一句描述位置，后一句描述能力。身份信息在一台机器，活动信息在另一台机器，并不能回答谁有权查询两台机器、两边日志保留多久、是否使用同一个分析账户，也不能回答一条罕见尺寸的请求是否会在两个时间序列中形成明显配对。

RFC 9614 是 2024 年 7 月发布的 IAB 流信息类文档。它用隐私分区描述一种架构纪律：把能够识别用户的信息——“谁”——与用户的活动或数据——“什么”——分离。文档所说的上下文，不只是服务器或连接，而是共享访问权的一组数据、元数据和实体。

核心目标可以写得很窄：除客户端之外，不应有同一实体同时参与既暴露身份又暴露活动的上下文。这里的“实体”比设备更重要。如果两个协议角色由同一个控制主体运营，或者两边的数据进入同一分析系统，物理和逻辑分离都可能仍然有价值，却不能自动证明不可关联。

这也是 RFC 9614 最有用的地方。它没有把“隐私”当作一个总开关，而是把问题拆成观察权：谁看到了哪些事实，在哪些条件下能与别的事实合并。任何承诺都应明确针对哪个观察者、保护哪一种关系、保留哪些例外。

上下文不是机柜数量

一台服务器可以同时参与多个上下文：它既处理加密连接，也写入运营日志，还把指标送往反欺诈平台。十台服务器也可能只构成一个有效上下文，因为同一管理员能查询全部记录。反过来，同一家机构可以通过密钥隔离、不同权限、短期保留和可审计审批，把内部边界做得比两个名义独立供应商更强。

因此，代理数量不是可靠指标。增加一跳也许能让目标端看不到源地址，让接入网看不到明文，或者扩大匿名集合；同时，它会增加一个运营者、一个故障点、一份日志和一个可能被迫披露的地点。分区更多，不等于隐私单调上升。

RFC 6973 提供了互联网协议隐私威胁和数据最小化的通用框架。RFC 9614 则把注意力放到关系上。孤立的地址、搜索词或时间戳可能显得有限；把它们连接起来后，才形成对某个人的描述。评审不能只逐字段问“这是不是个人信息”，还要问“它能与什么连接”。

一张完整的上下文图要跨越网络、传输、应用和管理层。源地址、DNS、加密终点、连接标识符、账户令牌、账单、设备指纹、客服工单、反滥用信号和监控日志都应出现。只画正常数据路径，会遗漏最容易重新汇聚身份的运营路径。

加密改变观察者，不会让观察消失

TLS 能阻止非终点读取内容，但终止 TLS 的一方可以看到明文，通常也能看到对端连接。如果它同时负责身份验证和业务处理，“谁”与“什么”已经在该上下文会合。加密正确工作，并不意味着目标分区已经实现。

VPN 的效果也需要用威胁模型表达。接入提供商可能不再直接看到最终目的地，但 VPN 运营者能看到客户端侧和出口侧。观察权被转移给另一个主体。这可能是合理改进，却不是“没人能看见”。

分离连接同样会被稳定标识符击穿。两条连接如果携带同一账户令牌、独特设备指纹或罕见行为序列，就很容易合并。RFC 8981 通过临时 IPv6 地址减少稳定地址带来的关联，但上层长期令牌仍可覆盖这项收益。某一层轮换，不能消除另一层的恒定身份。

RFC 9000 描述 QUIC，RFC 9180 描述混合公钥加密 HPKE。它们为传输和封装提供重要边界，却不会决定两端是否由同一家公司控制、日志保存多久，也不会阻止应用主动把邮箱或位置写进加密载荷。密码学界定谁不能直接读取；部署决定谁站在边界两侧。

OHTTP 把问题变得可测试

RFC 9458 定义 Oblivious HTTP。客户端为网关加密请求，再通过中继发送。中继看到客户端连接，却不能读取封装内容；网关打开请求，却接收的是中继连接而不是客户端直连。RFC 9230 把相关思路用于 Oblivious DNS over HTTPS。

这种分区是实质性的。普通目标端不再默认同时拥有来源和请求，批量关联的成本因此上升。但保护有条件：中继和网关如果共享逐交易日志，能够把两半重新组合；载荷内若包含邮箱、位置或账户号，网关会从另一条路径恢复身份；流量稀疏时，时间和尺寸本身就可能成为连接键。

准确的承诺应当有限：中继不收到明文请求，网关不收到客户端直连；某个定义明确的观察者必须获得额外信息或与另一上下文合作，才能恢复关系。这样的语言比“用户匿名”更克制，也更便于验收。

测试不能只验证消息格式。应生成已知的种子交易，改变尺寸、节奏和并发量，然后分别站在中继、网关、共同运营者和外部网络观察者的视角尝试配对。测试还要覆盖缓存未命中、队列、重试、低流量和降级，因为最脆弱的状态往往不是实验室稳态。

Privacy Pass 的角色分离不等于控制分离

RFC 9576 用来源站、证明者和发行者等角色说明 Privacy Pass 架构。隐私性质取决于角色如何部署、每个角色看到哪些标识符，以及观察是否可按时间关联。角色名称不同，不代表控制主体一定不同。

同一集团可能经营两个角色，或者让它们共用云账户、安全平台、客服系统与事件响应团队。一条罕见证明紧接着一条罕见兑换，即使没有稳定标识符，也可能形成高置信配对。产品声明必须写出部署模型，不能只写协议名称。

所有权、子处理商、管理员权限和紧急访问都决定上下文能否连接。禁止串通的合同需要最小保留、访问记录与审计；纸面禁止不能替代技术边界。独立主体也会增加延迟、故障与强制点，目标应是达到测量阈值的最小可检查组合。

时间和尺寸本身就是信息

日志里没有名字，不代表日志无法识别人。一条罕见大小的消息在中继出现，数毫秒后在网关出现，足以形成候选配对。连续多条消息的节奏会进一步增强指纹。低流量时段、独特地区和错误序列会缩小匿名集合。

填充可以削弱尺寸差异；批处理、延迟和掩护流量可以模糊时间。代价是带宽、能耗、响应速度和运维复杂度。人为流量如果具有固定模式，也会产生新的指纹。RFC 9614 没有给出万能参数，因为服务目标和威胁能力各不相同。

这不是拒绝隐私改进的理由，而是界定承诺的理由。一个系统可以有效防止接入网络读取内容，却无法抵御能同时观察两端的全球对手；可以降低日常批量关联，却无法阻止针对性长期分析。只要边界说清楚，这些都是有价值的产品性质。

监测必须展示分布和尾部。平均匿名集合很大，不能保护重试用户、长报文用户或区域故障中的少数人。应报告关联的准确率、召回率、候选集合和保留窗口，并在异常流量下重复。对手会选择最容易识别的样本，而不是平均样本。

降级路径是隐蔽的合并点

多中介架构增加延迟和故障依赖，于是运营者通常设计直连模式、单跳降级、诊断头或反滥用例外。它们可以保护可用性和安全，却会改变上下文：原本只看到一半的角色，可能临时获得另一半。

故障时开放旁路，会保持服务但暴露更多身份；故障时关闭，会保住分区但拒绝服务。没有适用于所有产品的答案。正确做法是提前决定、明确触发条件并记录变更，而不是让故障脚本暗中重写隐私承诺。

每次降级都应生成收据：触发原因、开始结束时间、影响人数、新增可见字段、是否通知用户，以及例外数据之后是否与正常日志合并。年度架构图通常只描述最平静的路径；事件记录必须描述风险最高的路径。

反滥用尤其容易重新引入全局身份。限速、欺诈与拒绝服务防护喜欢稳定地址或令牌。一个隐藏的通用标识符也许能让控制变简单，却会取消分区。上下文限定令牌、聚合、短期保留或接受更多误报都有成本，领导层应显式承担这些成本。

RFC 9297 与 RFC 9484 提供多层 HTTP 路径背景；格式不能证明故障时的实际路径或残留元数据。

隐私收据应当长什么样

第一层是版本化上下文清单。逐一记录数据、元数据、访问实体、控制运营者、子处理商、标识符、指纹、保留期、允许连接与删除方式。标出加密在哪里终止，并画出正常、重试、诊断、反滥用和故障旁路。

第二层是分离强度：密码学上不可完成、合同禁止与日常不做并非同义，三者不能混称“无法关联”。

第三层是对抗性测量。授权团队用时间、尺寸、顺序、地区和罕见事件尝试关联种子交易；在不同流量和故障状态下报告结果。测试窗口要覆盖真实保留期，否则对手拥有的数据比测试者更多。

第四层是变化管理。收购、供应商整合、新分析工具、延长保留、紧急访问和反滥用事故都可能在不改协议的情况下合并上下文。它们应被视为隐私边界变更，而不是普通运维工单。

来源