# 漏洞是承重墙

**Deck:** 六天前，加利福尼亚州开始把一份名单交到该州每一家注册数据经纪商（data broker，收集并转卖个人信息的公司）手里，名单上的人正是要求把自己从这些公司的数据库里抹掉的人。名单上的标识符做过哈希处理，而且没有加盐；一台笔记本电脑约四十三秒就能把其中一个还原成电话号码。制定实施细则期间，密码学家向主管机构提出过补救方案。它以书面形式拒绝了——因为那套方案会让经纪商无法永久屏蔽你。

**By:** URnetwork 编辑部
**Dateline:** 旧金山 — 2026年8月7日
**Category:** 新闻／分析

---

## 一份“要求消失的人”的名册

名单上的人都要求消失——跟踪骚扰与家庭暴力的受害者、法官、生殖健康门诊的患者，以及任何有理由抹掉自己踪迹的人。今年1月起，他们依据加州《删除法案》（Delete Act，一部让居民在一个入口处就要求全州所有数据经纪商删除自己信息的法律）陆续提交申请。六天前，这套机制的另一半启动了：自 **2026年8月1日** 起，加州《民法典》§1798.99.86(c)(1) 要求每一家注册经纪商 *"access the accessible deletion mechanism … at least once every 45 days."*（“访问该无障碍删除机制……至少每45天一次”）。于是这份名册开始向外扩散，进入数百家经纪商的系统——正是这些人当初躲着的那个行业——而第一个强制周期在 **9月15日** 前后结束。

标识符做过哈希处理，这听上去像是一层保护。可在一个笔记本 CPU 核心上，名单里的一个加州电话号码约 **四十三秒** 就重新变回电话号码。造出这台机器的加州隐私保护局（California Privacy Protection Agency，简称 CPPA，负责执行该州隐私法的州级监管机构）确实向经纪商打过招呼——7月10日的一篇博客文章写道：*"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."*（“自8月1日起，数据经纪商必须下载做过哈希处理的删除请求，并与自己记录中的个人信息进行比对。”）而它没有做的，是就这份暴露风险说过任何一句话。其新闻室页面在8月7日复查时，最新一条仍是8月4日一篇关于佛蒙特州的帖子；8月1日的机制启动，换来的是一份写给经纪商的操作指南，而名单上的那些人，一份通知也没有收到。

## 哈希几秒钟就能剥掉

这份名单包含六类标识符，而规章（11 CCR，《加州法规汇编》第11编，即主管机构依法制定的实施细则）里指名写出的只有一类：**MAID**（mobile advertising ID，手机广告标识符）。另外五类是 DROP（加州这套删除请求平台，也就是上文那个“无障碍删除机制”）技术规范里的标签——**NDZ**（名、姓、出生日期、邮政编码 ZIP）、**Email**（邮箱）、**Phone**（电话）、**NameVIN**，以及 **CTVID**，即联网电视标识符。在做哈希之前，规则先把输入“压平”——转成小写、去掉标点、把重音符号折叠掉，所以细则自己举的例子会把 *"Björn O'Connor-López"* 变成 *"bjornoconnorlopez."* 日期变成八位数字，电话只留最后十位，还有一条兜底条款要求经纪商 *"implement any other standardization that the data broker knows will increase the likelihood of a match."*（“实施数据经纪商已知能提高匹配可能性的任何其他标准化处理”）。每一步都在丢弃熵（entropy，即取值的不可预测程度），而在一个哈希值和算出它的原值之间，唯一挡着的东西就是熵。

我们把该州自己的技术规范里那两个示例重算了一遍。每一个字段摘要、两个组合摘要都逐位相同：就是对 UTF-8 输入做普通的 SHA-256，再以 Base64 输出——没有盐，没有密钥，没有任何公开记录里尚未包含的东西。对一个低熵取值做无密钥哈希不是伪装，而是一道笔记本电脑靠把所有答案试一遍就能解开的谜题；而 SHA-256 在一个 CPU 核心上每秒能给出约 **710万次猜测** 的答案，连显卡都不用。

| 名单上的内容 | 可能取值有多少 | 在一个笔记本核心上耗时 |
|---|---|---|
| 一个加州电话号码 | 304,000,000（3.04亿） | **约43秒** |
| 任意美国或加拿大号码 | 6,400,000,000（64亿） | 约15分钟 |
| 姓名、出生日期加邮政编码，比对加州选民名册 | 约22,000,000（约2,200万） | **约3秒** |
| 一个较短的联网电视标识符 | 2.8 × 10¹²（约2.8万亿） | 约4.6天 |
| 一个手机广告标识符 | 2¹²⁸ | 不可行 |

电话号码那份名单谈不上假名化（pseudonymous，即用代号顶替真实身份），它就是明文，只多了一道手续。姓名—出生日期—邮编那份连猜都不用猜：你把要找的那一个人哈希一遍，问一句答案在不在名单上——这就是一个只回答“在／不在”的查询谕示（oracle），而哈希值又变回了姓名。就连确实破解不了的广告标识符也不需要破解；它是一把连接键（join key，用来把两边数据里的同一个人对上号的字段），广告技术公司拿它在自家设备库里跑一遍，就知道其中哪些设备属于正在设法抹掉自己的人。

最先想到的那个办法——给哈希加盐（salt，哈希前给输入拼上一段额外的随机字符串，让相同的值算出不同结果）——在这里行不通。加盐之所以能保护存起来的密码，是因为负责核对的一方本来就握着用户刚敲进去的那个秘密。DROP 的形状恰好相反：由经纪商拿*自己的*记录（加州从未见过这些记录）去比对州里的名单，因此双方必须各自独立算出同一个摘要——而一个要分发给全国每一家注册经纪商的盐，根本不是秘密。

## 加州拿到过补救方案，并以书面形式拒绝

下面这部分至今无人报道。在制定实施细则的过程中，密码学家就告诉过主管机构会出现这种局面。在《最终理由说明》（Final Statement of Reasons，美国行政制规程序中监管机构逐条回应公众意见的正式文件）附录A里，意见提交人提出了 **私有集合求交**（private set intersection，一种让双方只知道彼此的交集、别的什么都学不到的协议），或者在 **可信执行环境**（trusted execution environment，处理器里一块隔离的运算区，外部无法窥看其中的数据）内完成匹配。他们对代价并不隐瞒，承认这会阻止“数据经纪商在未来继续屏蔽标识符”（原文：*"data brokers from suppressing identifiers in the future,"*），但主张这笔交换是值得的。

主管机构拒绝了，而它给出的理由就是整个故事：

> "The Agency notes the alternatives to hashing suggested by commenter, but the Agency has determined that
> hashing is a widely used, secure, and accessible method of protecting data, and that **any method that
> prevents the ongoing suppression of identifiers by data brokers fails to adequately implement the law**."

中文大意：“本机构注意到意见提交人提出的哈希替代方案，但本机构认定，哈希是一种被广泛使用、安全且易于采用的数据保护方法；并且，**任何会阻止数据经纪商持续屏蔽标识符的方法，都没能充分落实本法**。”

把后半句慢慢读一遍。《删除法案》并不是要求经纪商把你忘掉一次，它要求经纪商从此持续地屏蔽你（suppress，即此后不再使用、不再出售你的信息）。而要永久屏蔽你，经纪商手里就得留着某种耐久的、意思是“你”的东西——哈希值恰恰就是这种东西：一个耐久、可反复重算出来的凭据。密码学家提出的每一种方案，其运作方式都是*不*给经纪商留下这样一个凭据，这正是主管机构把它们排除掉的原因。这个隐私漏洞不是设计没能堵上的缺陷，而是这套设计本来就要交付的机制。

而 §7620(c) 把这个闭环合上了：*"By submitting a deletion request, a consumer consents to disclosure of their personal information to a data broker for purposes of processing their deletion request."*（“消费者提交删除请求，即同意为处理其删除请求之目的，将其个人信息披露给数据经纪商。”）这条目的限制是实实在在的，也是这套设计能给出的最好答复——这份同意并不是没有边界的。但它管的是经纪商拿到披露之后可以*做*什么，而不是这份披露本身*是*什么。请求加州让你被忘掉，仍然意味着把你放进一份经纪商会下载的名单里。

## 主管机构的理由比批评者愿意承认的更站得住

这些都不说明主管机构办事草率。它否决了直接加密的做法，因为那会让经纪商手里握着解密密钥——那显然更糟。它把匹配规则收紧到 **100% 完全一致**，这是防止删错人的一道实打实的保险。名单是 **分段发放** 的，只处理邮箱的经纪商永远拿不到姓名加出生日期那一份；第一次之后的下载是 **增量** 的；取得访问权还要以实名账户缴纳 **每年6,000美元** 的注册费。把明文的姓名和号码发给数百家公司，比上面任何一条都更糟。

而最难的那一点根本不是主管机构的错。§1798.99.86(b)(3)——这是立法机关写下的命令，不是主管机构写的——要求建立一套机制：它既要让经纪商能判断你是否提交过请求，又“不得允许披露任何额外的个人信息……除本编另有规定的以外”（原文：*"shall not allow the disclosure of any additional personal information … unless otherwise specified in this title."*）。把结尾那个例外条款放在一边，剩下的就是一道私有集合求交的题目，被交给一个州级机构，而拨给它的钱只够做成一个 CSV 文件下载。

不过这些辩护经不起太仔细的推敲。第一次下载就是全量语料、而且每家经纪商都留着副本，此后的增量发放便无从补救；分段发放要靠经纪商如实申报自己持有哪些标识符；而 §7616 的那些保护是法律上的、不是技术上的——没有任何东西能阻止经纪商拿这份名单去*算*任何它想算的东西，规则只禁止*使用*算出来的结果。

## 一个条款就能在第一个周期结束前把它堵上

有一根现成的杠杆，而且拉动它不需要动用立法机关。§7601(c) 允许删除名单自行指定所用的哈希算法；主管机构在一份意见答复里认可了 SHA-256，却没有把它写进规则本身。它可以改为指定 Argon2id（一种刻意设计得又慢又吃内存的密码哈希函数），走一遍制规程序即可，那个四十三秒的攻击一夜之间就变得不可行——同一份名单，换一个函数，不需要任何法案。

这底下压着两条如实交代的局限。我们报道的是规章和技术规范，不是运行中的系统：规章允许使用任何算法，而面向经纪商的线上 API 在登录之后，所以今天实际部署的 DROP 究竟输出什么，我们无法确认。还有那个被反复引用的“300,000+”，是主管机构自己在6月2日给出的数字——统计的是人数、不是请求数，此后没有更新过。我们能够确认的是这套设计，而这套设计正是要害。

## 一台为了永远记住你而造的机器

把其他一切剥掉，剩下一个矛盾。一套必须永远认得出你、才能继续保护你的系统，就必须留着某种意思是“你”的东西——而任何意思是“你”的东西，都能被还原回你本人。唯一的出路是根本不让这台机器识别得出你。这不是一个技术细节，而是一个关于由谁来承担这份工作的决定——由经纪商来，还是由那些试图从经纪商眼前消失的人来。加州是在制定实施细则时作出这个决定的，可行的替代方案就摆在它面前，而它选了经纪商。

---

## 参考资料

- **Cal. Civ. Code § 1798.99.86**（《加州民法典》第1798.99.86条）— `leginfo.legislature.ca.gov` — (b)(3)，即成员归属查询（membership oracle）式的命令；(c)(1)，*"Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism … at least once every 45 days."*（“自2026年8月1日起，数据经纪商应访问该无障碍删除机制……至少每45天一次。”）法律条文：§1798.99.80 及以下各条（SB 362，即加州参议院第362号法案）；授权依据 §1798.99.87。2026年8月7日检索。
- **11 CCR §§7601–7622**，"Data Broker Registration and Accessible Deletion Mechanism"（《数据经纪商注册与无障碍删除机制》），2026年1月1日生效 — `cppa.ca.gov/regulations/pdf/data_broker_drop_reg.pdf`，共16页。§7601(c)（算法随名单一同指定）；§7612(c)（增量下载）；§7613(a)(1)(A)（标准化处理，含 *Björn O'Connor-López → bjornoconnorlopez* 这个例子）及 (a)(1)(A)(vi)；§7613(a)(2)(A)（先对每个字段做哈希，再把各摘要"without adding spaces or other characters"（不添加空格或其他字符）连接起来，然后再哈希一次）；§7616（使用限制）；§7620(b)–(c)（MAID；同意披露）。**更正，8月10日**：以下三处均由译者拿引文核对原始文件时提出。(1) 正文把六类标识符全都归到了 §7613 名下；实际上规章里指名写出的只有 `MAID`，另外五类是技术规范的标签——正如下面“DROP 技术规范”那一条原本就已记下的。(2) §7620(c) 的引文原先在 "to a data broker" 处止住，漏掉了 "for purposes of processing their deletion request."（“为处理其删除请求之目的”）。这条目的限制恰恰是对建立在该引文之上的那种解读最有力的回答，因此现在把它完整引出并作出回应，而不是把它切掉。(3) §1798.99.86(b)(3) 原先被引作 "no additional personal information"（“不披露任何额外的个人信息”），并称这是一字一句的原话；法条实际写的是 "shall not allow the disclosure of any additional personal information … unless otherwise specified in this title"（“不得允许披露任何额外的个人信息……除本编另有规定的以外”），其中留有一个例外，现在已一并呈现。更正(3)也已一并应用于配套的 hot takes，即其中关于法律条文那一段以及文首的导语。
- **《最终理由说明》附录A**，共53页 — `cppa.ca.gov/regulations/pdf/drop_fsor_45day.pdf`。第117–122号意见提出私有集合求交与可信执行环境，以及上文全文引用的该机构答复；第196号意见，及 §7613(a)(1)(B) 处关于 SHA-256 的往复；第73–75号意见（加密方案被否，理由是经纪商会握有密钥）；对第216号意见的答复（分段名单）；FTC（美国联邦贸易委员会）的意见，以及该机构"will also monitor the DROP"（也将持续监测 DROP）的回复。另见 `cppa.ca.gov/regulations/pdf/drop_fosr.pdf` 与 `cppa.ca.gov/regulations/drop.html`。
- **DROP 技术规范** — `privacy.ca.gov/drop-for-data-brokers/technical-specifications/working-with-data/`，v1.2.0，页面标注"Last updated July 2026"（最后更新于2026年7月），2026年8月7日检索。其中的哈希规则（"SHA-256 using UTF-8 input encoding"，即“使用 UTF-8 输入编码的 SHA-256”；"Output as Base64"，即“以 Base64 输出”）、六类名单，以及本报道重算过的那两个示例。
- **复现与基准测试，本报道，2026年8月7日。** 用 `hashlib.sha256` 与 Base64 重算了规范中的示例：7个字段摘要中7个相符，2个组合摘要中2个相符。吞吐率在本地用 `openssl speed sha256` 测得（16字节分组下 113,894.45 kB/s，约合单核每秒710万次哈希），另有一个 Python `hashlib` 循环（3,413,611 h/s）。搜索空间按规章自身规定的格式计算：电话号码，完整 NANP（北美编号计划）为 6.4 × 10⁹，加州区号为 3.04 × 10⁸；CTVID 按8字符的最小长度取 36⁸；MAID 为32位十六进制数字。对规章与《最终理由说明》全文执行 `grep -ci 'salt\|pepper'` 的结果为 0。
- **CalPrivacy 新闻室**（该机构对外网站的新闻页）— `privacy.ca.gov/about-us/newsroom/`，2026年8月7日重新抓取，8月10日再抓一次：最新一篇为2026年8月4日（佛蒙特州加入监管机构联盟），上一篇为7月21日（"California Privacy Protection Agency Launches First Sectoral Audit, Targets Gig Economy Platforms"；该篇于8月10日通过服务器端渲染的 `privacy.ca.gov/sitemap.xml` 得到确认，因为新闻室索引页本身是由 JavaScript 渲染的）；**新闻室里没有任何一篇提到8月1日生效的经纪商义务**。**更正，8月10日：** 本文最初写的是该机构"has said nothing about the switch-on."（“对这次启动一言未发”）。它其实说过——只是发在它的*博客*上，而不是新闻室：`privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/`，2026年7月10日，其中告诉经纪商"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."（“自8月1日起，数据经纪商必须下载做过哈希处理的删除请求，并与自己记录中的个人信息进行比对。”）正文现在写的是真正成立的那个说法，而它更窄、也更糟：该机构向经纪商做了交底，却从未向名单上的人发出警示。“300,000+”这个数字出自2026年6月2日的新闻稿"Privacy Momentum Builds: 300,000+ Californians Sign Up for DROP as Registered Data Brokers Hit a Record High"，该稿已完整取得（HTTP 200）；稿中还记录了581家已注册的数据经纪商。
- **未能确立、作为缺口如实列出的部分：** 正在运行的 DROP 部署实际输出哪种算法（数据经纪商 API 文档位于 `databroker.drop.privacy.ca.gov`，需登录才能查看；存在沙盒环境，但其文档无法访问）；CPPA 是否公布过删除*请求*的数量；以及任何比6月2日更新的数字。