摘要

  • 2026 年 10 月 27 日的一份 IETF 个人草案提出：服务条款和政策的每个版本都应留下封存记录，列明文件名、版本、固定网址与纯文本的 SHA-256 摘要；旧版文件须继续在该网址可取。
  • 草案还要求保留域名与签名密钥的历史，并让监测者独立保存带签名的 Merkle 树检查点。这样能追问“谁在何时说了什么”，不能替读者裁定那句话是否真实。

当前网页不是昨天的证人

一名客户按网页上的规则完成操作，后来服务修改了页面。争议一来，双方很容易陷入一种荒唐的举证：机构拿出今天的网页，客户拿出截屏，机器生成的摘要又指向现行条款。每份材料都可能是真实拍摄或真实生成的，却未必说明操作发生时页面写了什么。

Furkan Yanteri 于 10 月 27 日提交的个人草案没有让读者相信某个机构“很重视透明度”。它在第 4.2 节列出一张能验的清单：每版服务条款与政策都要封存；封存记录写下文件名、版本标识、该版本的网址和纯文本的 SHA-256 摘要；每份已封存的旧版都必须继续在对应网址提供。机构可以写新规则，却不能把旧版的地址当成一扇随手关掉的门。

摘要是对精确字节的承诺。拿到旧文件的人可重新计算并核对；若同一网址后来换了文本，摘要就对不上。若旧文件干脆下线，摘要虽然还在，读者却失去最关键的比对对象。因此，发布一条“我们已更新条款”的新闻远远不够。真正要保留的是旧文本本身、指向它的固定地址，以及当时已经公开的校验记录。

IETF 的文件记录将这份文本列为仍在推进的个人 Internet-Draft，状态为 I-D Exists。它是方案，不是已通过的 IETF 标准，也没有在本组官方文件中给出一宗完整的客户争议案例。讨论它的价值，应从它让哪些证据无法轻易消失开始。

谁给签名者发了话筒

草案先把声明本身做成可重复验证的对象。第 3.1 节采用 RFC 8785 的一种受限规范化 JSON：键递归排序，不留无意义空格，值限定为字符串、布尔值、空值、数组、对象及安全整数。第 3.2 节用 Ed25519 对规范化后的载荷字节签名；RFC 8032规定这一签名算法。规范化解决的是不同系统到底签了哪串字节，不能把错误陈述变成事实。

另一道关口是密钥与机构的关系。草案让企业或代理通过域名下的 _humancollab DNS TXT 记录绑定公钥。首次绑定可接受指定 HTTPS 文件；已经建立的绑定若要换钥，必须拿出 DNS 证明。旧钥不能再借给另一个域名使用；公开历史须保留每把钥及其首次签署声明的日志索引。有人接管域名、企业轮换密钥、代理继续发布声明，这些事件不能被一枚永远绿色的“已验证”徽章抹平。

域名控制者能按方案指定发言密钥。至于某条声明是否准确、某个员工能否代表企业承诺、某个代理是否得到交易授权，还要看别的记录。草案第 6 节把推论说得清楚：签名加域名绑定说明该控制者发出了声明；被独立监测的检查点收录，说明声明在那时进入公开历史；与独立资料相矛盾，才构成进一步追究说话者的理由。密码学负责把发言人和原话留在现场，事实裁断仍得有人做。

独立见证不是剪彩嘉宾

草案第 4.3 节采用与 RFC 9162 相应的 Merkle 树叶子与内部节点哈希方式。日志提供收录证明、一致性证明及签名检查点，并通过 OpenTimestamps 给公开树根加时间锚。监测者要把新检查点与自己保存的上一个检查点比较，留下本地副本。草案允许任何人运行监测者，并要求运营者在服务基础设施之外也运行一个。

关键在“自己保存”。若机构的网站、历史页面和全部检查点都落在同一个人的控制下，漂亮的日志界面只是另一块可编辑招牌。两个树大小相同、根哈希不同且签名有效的检查点，可以证明日志向不同观察者展示过互不相容的历史；但前提是有人分别把两份证据留住。见证者的价值发生在争议那天，而不是产品发布会上。

对一宗条款争议，完整的技术材料至少应接上四段：当时的纯文本旧版、含版本网址与摘要的封存记录、由外部监测者保存的检查点及收录证明、当时控制该域名的密钥历史。它们能回答原文、时间、发言主体和历史是否被改写。谁实际看到了条款、合同如何生效、代理能否代表客户行事，仍需另外取证。机构不能拿“日志证明了一切”来省掉这些问题。

网站管理员有权把今天的页面更新。这里要限制的是更诱人的权力：在更新今天的同时，悄悄替昨天改口。一旦旧版原文留在外部可验证的历史中，“请拿出当时的规则”就不再只是客户的恳求。

来源