# The Hole Is Load-Bearing **Deck:** Six days ago California began handing every registered data broker a list of the people who asked to be erased. The identifiers are hashed, unsalted, and a laptop turns one back into a phone number in about forty-three seconds. Cryptographers offered the agency a fix during rulemaking. It said no, in writing — because the fix would stop brokers suppressing you forever. **By:** URnetwork editorial **Dateline:** San Francisco — August 7, 2026 **Category:** News / Analysis --- ## A roster of the people who asked to vanish The people on the list asked to vanish — stalking and domestic-violence survivors, judges, reproductive-health patients, anyone with a reason to erase a trail. Since January they have been filing under California's Delete Act, one place to tell every data broker in the state to erase them. Six days ago the other half switched on: from **1 August 2026**, Civil Code §1798.99.86(c)(1) requires every registered broker to *"access the accessible deletion mechanism … at least once every 45 days."* The roster now moves outward into hundreds of brokers' systems — the exact industry these people were hiding from — and the first mandatory cycle closes around **15 September**. The identifiers are hashed, which sounds like protection. On a single laptop core, a California phone number on the list becomes a phone number again in about **forty-three seconds**. The agency that built the machine did tell brokers this was coming — a blog post on 10 July says that *"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."* What it has not done is say anything about the exposure. Its newsroom, re-checked on 7 August, tops out at a 4 August post about Vermont; the 1 August switch-on got a how-to for brokers and no notice at all to the people on the list. ## The hash comes off in seconds The list carries six kinds of identifier, and only one of them is named in the regulation: **MAID**, a mobile advertising ID. The other five are labels from the DROP technical specification — **NDZ** (first name, last name, date of birth, ZIP), **Email**, **Phone**, **NameVIN**, and **CTVID**, a connected-TV ID. Before anything is hashed, the rule flattens the input — lowercase, punctuation stripped, accents folded, so its own example turns *"Björn O'Connor-López"* into *"bjornoconnorlopez."* Dates become eight digits, a phone its last ten, and a catch-all clause tells the broker to *"implement any other standardization that the data broker knows will increase the likelihood of a match."* Every step throws away entropy, and entropy is the only thing standing between a hash and the value it was computed from. We recomputed the two worked examples in the state's own technical specification. Every field digest and both composite digests come out identical, bit for bit, as plain SHA-256 over UTF-8, Base64-encoded — no salt, no key, nothing the public record does not already hold. A keyless hash of a low-entropy value is not a disguise; it is a puzzle a laptop solves by trying every answer, and SHA-256 answers about **7.1 million guesses per second on one CPU core**, no graphics card involved. | What is on the list | How many possibilities | Time on one laptop core | |---|---|---| | A California phone number | 304,000,000 | **~43 seconds** | | Any US or Canadian number | 6,400,000,000 | ~15 minutes | | A name, birth date and ZIP, checked against the CA voter file | ~22,000,000 | **~3 seconds** | | A short connected-TV ID | 2.8 × 10¹² | ~4.6 days | | A mobile advertising ID | 2¹²⁸ | infeasible | The phone list is not pseudonymous. It is plaintext with one extra step. The name-birthdate-ZIP list needs no guessing at all: you hash the one person you are looking for and ask whether the answer is on it — a yes/no oracle, and the hash is a name again. Even the advertising ID, which genuinely cannot be broken, needs no breaking; it is a join key an ad-tech firm runs against its own devices to learn which of them belong to someone trying to erase themselves. The obvious first thought — just salt the hashes — cannot work here. Salting protects stored passwords because the party checking already holds the secret the user just typed. DROP is the opposite shape: the broker tests *its own* records, which California has never seen, against the state's list, so both sides must reach the same digest independently — and a salt shared with every registered broker in the country is not a secret. ## California was offered the fix, and refused it in writing Here is the part nobody has reported. During rulemaking, cryptographers told the agency this would happen. In Appendix A of the Final Statement of Reasons, commenters proposed **private set intersection** — a protocol that lets two parties learn only what they have in common and nothing else — or matching inside a **trusted execution environment**. They were honest about the cost, conceding it would stop *"data brokers from suppressing identifiers in the future,"* and argued the trade was worth it. The agency said no, and its reason is the whole story: > "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**." Read the second half slowly. The Delete Act does not ask a broker to forget you once; it requires the broker to keep suppressing you, from now on. To suppress you forever, a broker has to hold something durable that means *you* — and a hash is exactly that: a durable, re-derivable token. Every scheme the cryptographers offered works by *not* leaving the broker such a token, which is why the agency ruled them out. The privacy hole is not a defect the design failed to close. It is the mechanism the design was built to deliver. And §7620(c) closes the loop: *"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."* That purpose limitation is real, and it is the best answer this design has — the consent is not open-ended. But it governs what a broker may *do* with the disclosure, not what the disclosure *is*. Asking California to make you forgotten still means putting you on a list that brokers download. ## The agency's case is stronger than its critics allow None of this makes the agency careless. It rejected outright encryption because that would leave brokers holding decryption keys — plainly worse. It tightened the matching rule to a **100% match**, a genuine safeguard against deleting the wrong people. The lists are **segmented**, so an email-only broker never receives the name-and-birthdate list; downloads are **incremental** after the first; and access costs a **$6,000** annual registration under a named account. Shipping plaintext names and numbers to hundreds of firms would be worse than any of this. And the hardest point is not the agency's fault at all. §1798.99.86(b)(3) — a command the legislature wrote, not the agency — orders a mechanism that lets a broker determine whether you filed a request and that *"shall not allow the disclosure of any additional personal information … unless otherwise specified in this title."* Set the closing carve-out aside and what remains is a private-set-intersection problem, handed to a state agency and funded as a CSV download. The defenses hold up less well than they look, though. Incremental delivery is no help once the first download is the whole corpus and every broker keeps a copy; segmentation trusts brokers to declare their identifiers honestly; and §7616's protections are legal, not technical — nothing stops a broker from *computing* whatever it likes off the list, the rule only forbids *using* the result. ## One clause could close it before the first cycle ends There is a lever, and pulling it takes no legislature. §7601(c) lets the deletion list name its own hashing algorithm; the agency blessed SHA-256 in a comment response but declined to write it into the rule. It can specify Argon2id instead, by rulemaking, and the forty-three-second attack becomes infeasible overnight — the same list, a different function, no bill required. Two honest limits sit under this. We are reporting the regulation and the specification, not the running system: the regulation permits any algorithm and the live broker API is behind a login, so what the deployed DROP emits today we cannot confirm. And the much-repeated "300,000+" is the agency's own count from 2 June — people, not requests, not updated since. What we can confirm is the design, and the design is the point. ## A machine built to remember you forever Strip everything else away and one contradiction remains. A system that has to recognize you forever in order to keep protecting you must keep something that means you — and anything that means you can be turned back into you. The only way out is not to be identifiable to the machine at all. That is not a technical detail; it is a decision about who does the work — the brokers, or the people trying to disappear from them. California made it during rulemaking, with the working alternative in front of it, and chose the brokers. --- ## References - **Cal. Civ. Code § 1798.99.86** — `leginfo.legislature.ca.gov` — (b)(3), the membership-oracle command; (c)(1), *"Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism … at least once every 45 days."* Statute: §1798.99.80 et seq. (SB 362); authority §1798.99.87. Retrieved 7 August 2026. - **11 CCR §§7601–7622**, "Data Broker Registration and Accessible Deletion Mechanism," effective 1 January 2026 — `cppa.ca.gov/regulations/pdf/data_broker_drop_reg.pdf`, 16 pp. §7601(c) (the algorithm travels with the list); §7612(c) (incremental downloads); §7613(a)(1)(A) (standardization, including the *Björn O'Connor-López → bjornoconnorlopez* example) and (a)(1)(A)(vi); §7613(a)(2)(A) (hash each field, concatenate digests "without adding spaces or other characters," hash again); §7616 (use limits); §7620(b)–(c) (MAIDs; consent to disclosure). **Corrections, 10 August**, all three raised by translators checking the quotations against the source. (1) The body attributed all six identifier types to §7613; only `MAID` is named in the regulation, and the other five are the technical specification's labels — as the DROP technical specification bullet below already recorded. (2) §7620(c) was quoted ending at "to a data broker", dropping "for purposes of processing their deletion request." The purpose limitation is the strongest answer to the reading built on it, so it is now quoted and answered rather than cut. (3) §1798.99.86(b)(3) was given as "no additional personal information" and called "word for word"; the statute reads "shall not allow the disclosure of any additional personal information … unless otherwise specified in this title", and the carve-out is now shown. Correction (3) was applied to the hot takes as well, in the statutory-limb paragraph and the standfirst. - **Final Statement of Reasons, Appendix A**, 53 pp. — `cppa.ca.gov/regulations/pdf/drop_fsor_45day.pdf`. Comments 117–122 proposing private set intersection and a trusted execution environment, and the Agency's response quoted in full above; comment 196 and the SHA-256 exchange at §7613(a)(1)(B); comments 73–75 (encryption rejected because brokers would hold keys); response to comment 216 (segmented lists); the FTC comment and the Agency's "will also monitor the DROP" reply. Also `cppa.ca.gov/regulations/pdf/drop_fosr.pdf` and `cppa.ca.gov/regulations/drop.html`. - **DROP technical specification** — `privacy.ca.gov/drop-for-data-brokers/technical-specifications/working-with-data/`, v1.2.0, "Last updated July 2026," retrieved 7 August 2026. Hashing rules ("SHA-256 using UTF-8 input encoding", "Output as Base64"), the six list types, and the two worked examples recomputed by this desk. - **Reproduction and benchmarks, this desk, 7 August 2026.** The spec's worked examples recomputed with `hashlib.sha256` and Base64: 7 of 7 field digests and 2 of 2 composite digests match. Throughput measured locally with `openssl speed sha256` (113,894.45 kB/s at 16-byte blocks ≈ 7.1M hashes/s on one core) and a Python `hashlib` loop (3,413,611 h/s). Search spaces computed from the regulation's own formats: phone 6.4 × 10⁹ for the full NANP (800 area codes × 800 exchanges × 10,000 subscriber numbers) and 3.04 × 10⁸ for California area codes; CTVID 36⁸ at the 8-character minimum; MAID 32 hex digits. `grep -ci 'salt\|pepper'` = 0 over both the regulation and the FSOR. - **CalPrivacy newsroom** — `privacy.ca.gov/about-us/newsroom/`, re-fetched 7 August 2026 and again 10 August: latest post 4 August 2026 (Vermont joining the regulator consortium), previous 21 July ("California Privacy Protection Agency Launches First Sectoral Audit, Targets Gig Economy Platforms", confirmed 10 August from the server-rendered `privacy.ca.gov/sitemap.xml`, since the newsroom index itself is JavaScript-rendered); **no newsroom post on the 1 August broker obligation**. **Correction, 10 August:** this edition first said the agency "has said nothing about the switch-on." It had — in its *blog*, not its newsroom: `privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/`, 10 July 2026, tells brokers "starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records." The body now says what is actually true, which is narrower and worse: the agency briefed the brokers and never warned the people on the list. The "300,000+" figure comes from the 2 June 2026 release "Privacy Momentum Builds: 300,000+ Californians Sign Up for DROP as Registered Data Brokers Hit a Record High", retrieved in full (HTTP 200); it also records 581 registered data brokers. - **Not established, reported as gaps:** what algorithm the live DROP deployment emits (the data-broker API documentation at `databroker.drop.privacy.ca.gov` is login-gated; a sandbox exists but its docs were not reachable); any CPPA-published count of deletion *requests*; and any figure more recent than 2 June. ## Publication notes First edition of 7 August 2026. Selected from a 23-candidate slate built on 47 leads across eight beat sweeps, in `blog-research/2026-08-07-01/`. **This candidate was verified independently by two desks that did not share notes**, which is why it leads. One worked from the rulemaking record — 11 CCR, the Final Statement of Reasons, and the statute — and established that the regulation fixes no algorithm, that no salt appears anywhere, and that private set intersection and trusted execution environments were proposed and refused with a stated reason. The other worked from the published technical specification, reproduced its worked examples bit for bit, and benchmarked SHA-256 locally rather than citing published attack rates. Where they disagreed, the stricter reading was taken: "report the regulation, not the deployment," which is carried into the gaps above. **Rewritten 9 August 2026 against the readability standard the August 6–8 run earned (§0.6).** The earlier version led with the document and shared a section skeleton with its neighbours — `## The steelman, at full strength`, `## What we know, and what we don't` and `## What you can actually do` appeared verbatim across consecutive editions. This version leads with the people on the list and the forty-three-second attack; every heading is written for this story and none repeats a neighbouring edition. The keyless-hash finding is stated as a finding, with the digest dump, the `grep` and the `openssl` line moved to the References; the bounded nulls are folded into the body; the standing "what we know" ledger is gone. Body length **1,456 words**, measured by `blog-temp/2026-08-07-01/wordcount.py` on 11 August 2026. **This note previously claimed 1,323**, which was true of the version it was written for; later editing added 133 words and the figure was never re-run. The drafting history below is still accurate as history — down from 1,767 in the first draft and 1,485 after the rewrite. A second length pass cut whole units rather than rephrasing: the reader-advice paragraph went (its broker-already-holds-you caveat survives in the hot takes), the standalone salt section folded into one paragraph of the cracking section and lost its coda, and the lede was rebuilt to open on the people who filed rather than on the statute.