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
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.