DROP identifier hashing: the SHA-256 spec, by identifier type
To match DROP's consumer deletion lists against your own records, you standardize each identifier and hash it exactly the way CalPrivacy's Data Broker API does — a different rule for every field, and a two-step composite process for two of the six lists. Get any one of these rules wrong and matches silently fail; DROP has no way to tell you your hash was built incorrectly, only that it didn't match anything.
The two constants: SHA-256, Base64
Every DROP hash uses the same algorithm and encoding — only the input text changes by identifier type:
- Standardize the raw value first (rules below).
- Hash the standardized string with SHA-256, treating it as UTF-8 bytes.
- Encode the 32-byte digest as Base64. Output is always 44 characters, ending in
=(pattern^[A-Za-z0-9+/]{43}=$).
For example, the standardized email [email protected] hashes to KA18MT/ph6IHYjzT9zwETySDQyvSh87YuoSBpOQtkhE= — that fixed-length string, not the plaintext, is what appears in both DROP's downloaded lists and the lookup table you build from your own records.
Standardization rules, field by field
Apply these before hashing. They are stricter and more specific than they look — most hashing bugs come from skipping a step or doing them out of order.
| Identifier | Standardization rule |
|---|---|
Remove all whitespace, then lowercase. Do not strip dots, plus signs, or any other characters — [email protected] is a different identifier from [email protected], even though Gmail treats them as the same inbox. | |
| Phone | Keep digits only, then take the last 10 digits (or all of them if fewer than 10 remain). A leading country code gets dropped automatically as long as the rest of the number is 10 digits. |
| DOB | Format as YYYYMMDD with no separators — 1990-04-03 becomes 19900403. |
| ZIP | Keep alphanumeric characters only; for ZIP+4, drop the +4 segment first; lowercase; then remove leading zeros; then take the first five characters present. Order matters — a ZIP of 07030 becomes 7030 (four characters), not a re-padded five. |
| Name (first/last) | Normalize Unicode, lowercase, transliterate Greek and Cyrillic characters, fold accented Latin characters to plain ASCII where possible, then keep only letters and digits. José folds to jose. |
| MAID (mobile ad ID) | Keep hexadecimal characters only (0-9, a-f), then lowercase. Standardized value must be exactly 32 characters. |
| VIN | Keep alphanumeric characters only, then lowercase. Standardized value must be exactly 17 characters. |
| CTVID | Keep alphanumeric characters only, then lowercase. Standardized value must be 8–32 characters. |
Composite hashing: NDZ and NameVIN
Four of the six DROP lists — Email, Phone, MAID, CTVID — hash one standardized field directly. The other two are composite lists built from multiple fields hashed in two passes:
- NDZ = First name + Last name + DOB + ZIP
- NameVIN = First name + Last name + VIN
The process is: standardize and hash each field separately (so first name gets its own SHA-256/Base64 hash, last name its own, and so on), then concatenate those Base64 hash strings in the specified order, and hash the concatenated string again with SHA-256/Base64 to get the final composite hash. Building the composite from raw field values instead of from the per-field hashes — a common shortcut — produces a hash that will never match anything.
Reporting back: status codes 2, 3, 4, 5
Once you've matched your records against a downloaded list, you upload a response CSV with the exact header Id,Status, where Id is the 12-character work item ID from the download and Status is one of four numeric codes:
| Code | Meaning |
|---|---|
| 2 | Exempted — match found, and all personal information for that request is exempt from deletion. |
| 3 | Deleted — match found, non-exempt personal information deleted. |
| 4 | Opted out — multiple consumers share the matched identifier, so all were opted out of sale and sharing instead of deleted. |
| 5 | Not found — no match after completing the matching process. |
There's no separate "unprocessed" code — a work item you never report against by the 45-day deadline is simply a violation, priced at $200/day under SB 362 (see our SB 362 penalty breakdown). If you upload the wrong CSV header, DROP rejects the file outright rather than accepting partial rows, so it's worth validating the header string exactly before every upload.
Common mistakes, in order of how often they show up
- Stripping email dots/plus-addressing. The spec explicitly says not to — only whitespace removal and lowercasing are allowed.
- Hashing composite fields as one string. NDZ and NameVIN require per-field hashes concatenated first, then a second hash — not a single hash of the concatenated raw values.
- Re-padding ZIP codes after removing leading zeros. The rule removes zeros and then takes up to five characters of whatever's left — it does not guarantee five digits.
- Treating MAID/VIN/CTVID length checks as optional. If your standardized value doesn't land at exactly 32, 17, or 8–32 characters respectively, something upstream (a stray separator, a truncated field) is wrong before you even hash it.
Drop45 runs this entire spec in your browser. Upload a DROP list and your own records; standardization, SHA-256 hashing, composite construction and matching all happen client-side, so consumer data never leaves your machine. Free for up to 500 records per run.