How to Self-Host unbroker for Data Broker Removal

At a glance

Consent gates the run; custody grows with the host surface. The workflow records consent before scanning, keeps deterministic run state and verification in a ledger, and treats a shared hosted app as the highest personal-data custody option.

Sources

1. 1. github.com · unbroker
2. 2. raw.githubusercontent.com · SKILL.md
3. 3. privacy.ca.gov · drop
4. 4. cppa.ca.gov · data broker registry
5. 5. github.com · Big Ass Data Broker Opt Out List

Data behind this diagram

unbroker operating stages and custody boundaries

Stage or host	Stable role	Boundary or record
Local workstation	Personal runs with local dossiers and controlled browser or email sessions	Lower hosting surface; machine availability remains required
Temporary VPS	Clean isolated run without local machine dependency	Encrypt storage, restrict access, avoid backups, and delete the workspace after reporting
Shared hosted app	Convenient multi-user hosting	Highest PII custody burden; the article says not to start here
Consent	Record authorization before scanning or removal requests	No consent means no run
Deterministic state	CLI owns dossiers, broker data, planning, ledger, drafts, reports, polling, and queue	Keep collected fields narrow and use opaque subject IDs
Agent actions	Execute scans, browser steps, email work, and scheduled rechecks	Anti-bot and identity-proof gates move to a human task
Ledger	Record removal route, fields disclosed, result, and fallback reason	Submitted is not the same as removed
Verification poll	Re-scan and classify hidden, deleted, corrected, or unresolved outcomes	Broker and source-record removal remain separate
Human digest	Present blocked tasks and schedule rechecks	Monitoring duration controls person-record retention
California DROP	One deletion request can cover more than 600 registered brokers	Covered data must be deleted within 90 days starting August 1, 2026

Scroll →

unbroker is a Hermes Agent skill for finding exposed personal information on broker and people-search sites, filing removals where possible, recording outcomes, and checking later. The useful self-host pattern is simple: keep the person record local, record consent, disclose only required fields, and treat every removal as unconfirmed until a re-scan verifies it.

Primary sources

• unbroker README on GitHub
• unbroker SKILL.md
• California DROP official page
• California Data Broker Registry
• BADBOOL broker opt-out list

What you are hosting

The upstream skill splits the work in two. A Python CLI owns deterministic state: setup, dossiers, broker data, planning, ledger, drafts, reports, verification polling, and the next action queue. The agent handles scanning, browser steps, email work, and scheduled re-checks.

That split is the reason it is interesting. You are not asking a model to invent a privacy cleanup process. You are asking it to follow a queue and write down what happened.

Local Mac or VPS

Basic run shape

Install the skill through Hermes, then start a fresh session and drive the workflow from the skill directory.

hermes skills install official/security/unbroker

In the unbroker skill directory, the upstream docs use the Python CLI as the driver:

PDD="python3 scripts/pdd.py"

The exact commands can change upstream. Check the official README and SKILL.md before a real run. The stable operating pattern is:

1. Run setup and doctor.
2. Create a subject only after consent.
3. Refresh broker data.
4. Generate the next action queue.
5. Execute scan, opt-out, email, browser, or verification tasks.
6. Record each result in the ledger.
7. Repeat until there is nothing useful to do now.
8. Present the human-task digest and schedule re-checks.

$PDD setup --auto
$PDD doctor
$PDD intake --full-name "Example Person" --email "example@example.com" --city "City" --state "CA" --consent
$PDD refresh-brokers
$PDD next <subject_id>
$PDD tasks <subject_id>
$PDD status <subject_id>

Consent and intake

The intake data is sensitive by design. It can include names, aliases, emails, phones, current location, and prior locations. Keep it narrow. If a broker cannot search by a field, do not collect it just because it feels complete.

• Record consent before any scan.
• Use a separate workspace per subject.
• Use opaque subject IDs, not names in folder paths.
• Prefer local storage and at-rest encryption where available.
• Do not store government ID unless a specific human-only task requires it.

Email and browser mode

Removal flows often need email verification. The upstream skill supports browser-mode email and programmatic SMTP/IMAP. Browser mode avoids storing a mail password, but it requires a logged-in browser session. Programmatic email is more automated, but the credential surface is larger.

DROP first for California

California DROP changes the route for California residents. The state tool lets a resident submit a single deletion request to more than 600 registered brokers. Starting August 1, 2026, data brokers must delete covered data within 90 days of a DROP request.

That means a good California run should not only crawl people-search sites. It should file or track DROP, then work people-search parent clusters, standalone opt-outs, email rights requests, blocked tasks, and re-scans.

What to measure

The value of a run is not only "submitted forms." The useful data is the removal graph.

Workflow boundaries

• The consent-gated intake records the subject's authorization before scans or removal requests.
• Hidden from free search and deleted are different verification states.
• Hard anti-bot gates move to a human fallback path.
• Person-record retention follows the run or monitoring plan.
• Broker-listing removal and source-record removal are reported as separate outcomes.

Read the unbroker overview for the consent, local-storage, and re-scan boundaries.