Cal Privacy walks data brokers through Drop'level technical steps: hashing, lists, API and sandbox testing

Shannon Dell, product manager for Drop at the California Privacy Protection Agency, and technical staff led a deep'dive on how data brokers should implement Drop integrations and manual workflows. They framed the work as four recurring steps brokers must repeat at least every 45 days: download lists, standardize and hash records, match and process, then report statuses back to Drop.

Shannon emphasized operational readiness: ensure an active Drop account, generate an API key if integrating, confirm an HTTPS client and CSV read/write capability, and store secrets securely. "We recommend using the same file names when you upload. It makes troubleshooting and reconciliation easier," she said, and encouraged using the sandbox and provided YAML resources for engineering teams.

Artem Andrusov (head of IT) described the hashing and encoding specification in detail: standardize values, encode in UTF'8, hash each field with SHA'256, convert to base64; for composite hashes (NDZ or Name+VIN) hash fields individually, concatenate the base64 strings, then hash the concatenation to generate the final composite base64 value. He warned common pitfalls include incorrect standardization order or accidental UTF'16 conversions and urged engineers to always use UTF'8 when re'hashing composites.

Shannon and Art reviewed file semantics: downloads are ZIP archives containing one CSV per selected list type (six list types: NDZ, Email, Phone, Name+VIN, CTV ID, removed). The first download is a full historical set (requests since Jan. 1) and can be large: if all six lists are selected, the agency estimated about 1.3 million work items total and roughly 60'70 megabytes; the email list alone contains roughly 300,000 work items today. Subsequent cycles are incremental and include only new requests submitted since the last download.

On endpoints and validation, Art summarized three API operations: download (returns the ZIP or a retry message), upload (submit response CSVs), and amend (correct previously submitted statuses). Drop performs immediate file'level validation (headers, file names) and asynchronous record'level validation; outcome notifications are emailed to the account'listed contacts. The platform accepts only four status values at record level: deleted, exempted, opted out or not found.

For testing and troubleshooting, staff recommended the Drop sandbox and a hashing/standardization tool that returns expected SHA'256 base64 outputs for sample inputs. They noted some sandbox behaviors differ from production (sandbox provides direct comparison results; production only validates status codes), and advised teams to verify contact emails on their account to receive validation results.

The panel closed by urging engineering and operations teams to review the technical documentation linked in Drop and on privacy.ca.gov/databrokers, to use the sandbox to validate hashing and file flows, and to plan for the first full download and subsequent 45'day cycles.