Security model
DROP Matched is designed around data minimization. The server should not need a copy of customer rows to compare them with hashed DROP work items. Keeping that comparison in the browser narrows the systems, vendors, logs, and backups that could otherwise hold the information.
Browser-local workflow
The workspace reads files selected by the operator, validates their shape, standardizes supported identifiers, computes SHA-256 digests, and compares them with the DROP list. Generated worklists, response CSVs, and receipts are assembled for local download.
The normal matching path does not require network calls for those rows. DROP Matched does not ask for CPPA credentials and does not sign in to the DROP portal on the operator’s behalf.
The production workflow’s local suppression ledger uses IndexedDB in the authorized browser profile to retain active work-item IDs and hashes, dated removal tombstones, processing status, and pending finalization journals for later screening and crash-safe completion. Monotonic event dates prevent older batches from reviving newer removals. This narrows server exposure but is not encrypted by DROP Matched independently of the device/browser storage controls; protect and back up the endpoint accordingly.
Deterministic validation
The matching engine validates official filename shapes, 12-character work-item IDs, Base64 SHA-256 hashes, list-type field constraints, response status rules, and count invariants. Unsupported or changed inputs should fail visibly instead of being silently coerced.
Removed work items are excluded from response generation. Status 4 is constrained to the published multiple-consumer linkage case. A matched item requires an operator decision; the software does not infer exemption, deletion, or opt-out status from a match alone.
Account and receipt metadata
The account layer may store identity and session information, one operator-verified broker ID and its audit reference, exact payment-processor subscription state when billing is enabled, plus non-row-level cycle evidence: independent access, response, and amendment dates; completion timestamps; aggregate status/file totals; operator attestation flags; specification version; and report or batch fingerprints. Accepted amendment receipts are append-revisioned, and hourly billing reconciliation records only aggregate freshness/count state for autonomous checking. API endpoints reject payload fields outside their narrow metadata contract.
The canonical report fingerprint binds aggregate counts and both action-completion and CPPA-acceptance attestations. It can reveal a changed receipt, but it does not independently prove the underlying action occurred or that the attestation was true.
Autonomous monitoring
Deterministic operational checks can watch the rolling next-access interval, each downloaded batch’s response deadline, application health, dependency availability, database consistency, and the published specification baseline. Healthy checks should remain quiet; exceptions should be queued for review.
A specification change is not automatically translated into new compliance behavior. It is flagged for research, testing, and release review.
Operator responsibilities
- Use a trusted, patched device and current desktop browser.
- Protect customer exports, DROP downloads, worklists, response files, and receipts at rest.
- Verify the source, access date, broker identifier, and completeness of each DROP download.
- Carry out required deletion, exemption, opt-out, and service-provider work in the relevant systems.
- Upload each response through an authorized CPPA workflow and verify acceptance before recording completion.
- Consult qualified counsel about obligations and exceptions specific to the organization.
Report a security issue
Do not include customer records, DROP files, credentials, secrets, or live exploit payloads in an initial report. Send a high-level description to privacy@dropmatched.com so a secure follow-up path can be arranged.