Summary

  • 能力、地域、信任、可用时间等筛选条件，会在实际选择发生以前暴露机构的行动意图；即使查询正文已加密，重复收窄、结果数量与时间关系仍可能把意图重新拼出。
  • draft-iannone-dawn-privacy-considerations-00 已指出监视、存储数据泄漏、关联与识别风险，但它仍是一份未完成的个人 Internet-Draft：多项威胁、DNS 隐私比较、“隐私与可审计性”、RFC 6973 问卷和安全考虑仍标为 TBD。
  • Daniel Kade 提出“选择披露预算”，约束查询粒度、最低候选集合、可关联时间窗、参与方隔离、启动过程、结果受众与留存上限。这是编辑建议，不是 DAWN 或 IETF 规范。

查询条件就是一份被压缩的内部政策

发现机制常被画成一条很干净的箭头：客户端先找到可用实体，再由其他模块进行选择、授权和编排。软件架构上，这些确实可以是不同层；信息流上，它们却不一定彼此隔离。

DAWN 讨论的可发现对象包括智能体、工作负载和其他命名实体。可查询属性可能覆盖功能、能力、协议版本、运营组织、地理位置、司法管辖地与信任指标。结构化能力卡让软件无需预先建立关系，便可跨管理域找到合作对象。这种互操作价值越高，查询就越可能携带请求者真正关心的内部规则。

“寻找翻译服务”不会透露太多。若再加上语言组合、医疗数据限制、特定证明方式、欧洲托管、某种模型与即时可用性，结果便可能指向一个具体项目。单次查询之外，调整顺序更有信息量：保留司法管辖要求却放宽价格，说明前者不可谈判；在系统故障后立刻查找某类恢复能力，说明机构可能正在处理什么事故。

DAWN 要求草案明确把选择机制和选择政策排除在范围之外。这种边界对一份不指定具体协议的需求文档而言很合理，却不能让选择政策从观察者眼中消失。目录若看见请求了哪些属性、约束按何种顺序放宽、每次返回多少候选以及何时查询，就可能在不知道最终选择的情况下复原政策。

因此，隐私对象不只是查询字符串，而是五列信息的连接：谁在问、想要什么、哪些候选匹配、返回了哪些属性、这一连串动作发生在何时。只保护其中一列，并不等于保护发现过程。

一份诚实展示缺口的草案

截至研究时点，draft-iannone-dawn-privacy-considerations-00 是 2026 年 5 月 22 日发布的活跃个人 Internet-Draft。Datatracker 显示它没有 RFC 流、负责的 Area Director 或 telechat，并明确提示个人草案不代表 IETF 背书。文章不能把它写成共识、已采纳要求或部署规范。

第 00 版公开保留了大量空白。入侵、错误归因、二次使用、披露与排除仍为 TBD；DNS 隐私相似性和“Privacy vs Auditability”章节仍为 TBD；RFC 6973 问卷尚待回答；DAWN 专用缓解类别留待未来版本；安全考虑同样未完成。这些不是可以由评论者自行补齐的细节，而是判断文档成熟度的证据。

已经写出的部分仍很重要。草案称，发现基础设施可能成为监视点：观察者能够看到哪些智能体查询哪些能力，进而了解组织兴趣、工作负载模式与运营行为。查询日志和交互历史可能暴露流程与企业活动。反复查询、智能体标识与能力搜索可以互相关联；组织名称、基础设施所有权、运营者身份，甚至罕见的能力组合，都可能识别实体。

草案把私有信息检索（PIR）列为可能有用的技术组件，同时要求继续研究其规模适应性。这个表述很克制：PIR 不是 DAWN 已选协议，也不是生产可行性的证明。即使服务器不知道用户取了哪条记录，查询词是否过细、返回集合是否足以识别、时间序列是否可关联、获取目录或密钥时是否先暴露身份，仍需分别回答。

加密只覆盖一段连接关系

成熟的 IETF 隐私文档可以作为坐标，而不是现成答案。RFC 6973 将监视、存储数据、关联、识别、二次使用、披露与排除分别分析；RFC 7258 指出，无论观察者自称出于何种善意，对内容或外部特征进行大规模关联监控都构成攻击。两者都反对用“传输已加密”结束隐私讨论。

RFC 9156 的 QNAME 最小化提供了粒度范例。递归解析器不会把完整域名发送给路径上的每个权威服务器，而只披露当前步骤所需的名称部分。映射到智能体发现，客户端应先问较宽的能力类别，只有在确有必要并且受众合适时，才逐步释放细粒度约束。

RFC 9230 的 Oblivious DoH 把知识分给两个角色：代理知道客户端连接，却看不到明文 DNS 问题；目标知道问题，却不知道客户端地址。RFC 9458 将这种隔离推广到 HTTP，同时提醒消息大小、时间、密钥标识、连接行为与差别处理都可能缩小匿名集合。隐私来自角色分离与不串通假设，而不只是密文。

RFC 9540 把视线移到更早阶段。客户端必须先发现 oblivious 服务并取得网关密钥。直接获取密钥会暴露 IP；为单一客户端准备的路径、重定向或密钥配置可以重新建立关联。受保护请求尚未开始，隐私已经可能在启动过程中丢失。

RFC 9576 通过 Privacy Pass 区分签发、证明与兑换场景。RFC 9614 将类似思想概括为隐私分区：让任何一个参与方都不能同时掌握“是谁”与“做什么”，同时警告分区并非万能。这些机制不能直接替 DAWN 做设计，却能迫使设计者逐项说明哪些连接被切断，哪些仍然存在。

候选集合也是隐私边界

答案可能比问题更暴露。一次查询只返回一个智能体，目录已经提前指出了可能的交易对象；返回两个候选，后续网络观察或许便能消除歧义。返回上百项也不必然安全：若绝大多数由同一运营者控制，或者罕见条件能识别请求者，数字本身没有保护作用。

DAWN 要求草案提出，实体应控制哪些信息公开、哪些受限；发现机制不应要求披露超过判断交互是否合适所需的信息。问题在于，“所需”必须落成失败行为。当筛选只剩一个候选时，是扩大结果、延迟回答、隐藏属性、加入批处理，还是拒绝查询？

最低候选数并非通用隐私分数。三个独立运营者可能比十个同属一个平台的智能体提供更强分散性。它的价值在于迫使系统承认：过窄结果不是中性的成功。如果没有公开规则，索引运营者会在后台决定应披露多少请求者意图和实体信息，而用户只看到一个格式正确的响应。

用披露预算治理，而不是保存一切

部署前应制定选择披露预算。它不是集中式查询审计日志，更不应保存任务全文。它是一份说明每个角色允许知道什么、例外何时失效的运行政策。

预算至少应列出可用属性类别及最大粒度；候选集合或匿名集合下限；低于下限时的动作；连续查询可关联的最长窗口；批处理、延迟、填充或轮换规则；以及谁能看到请求者身份、明文意图、候选成员和返回属性。角色可能串通的假设必须显式呈现，不能藏在架构图背后。

预算还要覆盖查询以前的路径：如何发现目录、relay、网关与密钥；哪些字段面向公众、受限群体或特定请求者；原始查询与聚合数据的留存上限；谁能批准紧急收窄或重新识别；例外的到期与复核条件；以及错误或过期属性影响结果后的更正渠道。

问责不必复制监视。运营者可以公布结果规模区间、拒绝率、属性类别使用量、例外次数与按期删除情况，而不公开搜索词或候选身份。独立测试可以发送合成查询，比较各角色实际所见。本地短期计数器可以证明下限曾被执行。正确的证据证明限制生效，而不是为证明限制而重建全部秘密。

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. DAWN 隐私考虑，第 00 版
  5. Datatracker 文档状态
  6. Datatracker 版本历史
  7. DAWN 问题陈述，第 02 版
  8. DAWN 要求，第 01 版
  9. DAWN 术语，第 01 版
  10. RFC 6973 — Internet 协议隐私考虑
  11. RFC 7258 — 大规模监控是一种攻击
  12. RFC 9156 — DNS 查询名最小化
  13. RFC 9230 — Oblivious DNS over HTTPS
  14. RFC 9458 — Oblivious HTTP
  15. RFC 9540 — Oblivious 服务发现
  16. RFC 9576 — Privacy Pass 架构
  17. RFC 9614 — 作为隐私架构的分区