skills(unbroker): blind opt-out default, email fallback, PeopleConnect delete-wipes-suppression

optional-skills/security/unbroker/SKILL.md

@@ -168,6 +168,23 @@ For anything past a couple of brokers, run this as **map → reduce → act**, n
   record's `deletion.prefer`: **PeopleConnect is the exception** (`prefer: false`), where deleting
   your user data removes your suppressions and does not stop public-records re-listing, so you
   suppress-and-maintain instead.
+- **Blind opt-out is the DEFAULT, not a fallback.** Submit an opt-out/deletion on **every site with an
+  accessible removal channel, even when a listing was not first confirmed** - it discloses only the
+  subject's own identifiers to the broker's own official channel, so it does not violate
+  least-disclosure. Two corollaries: (1) a guided flow that matches email+DOB+name and says "no results"
+  is a **stronger `not_found`** than any scrape - the opt-out flow doubles as the search; (2) when a form
+  is automation-hostile (hard CAPTCHA, Cloudflare/DataDome, slide-to-verify slider), **default to the
+  broker's cited rights-request email** (name+state+contact-email only) rather than recording `blocked`.
+  CAPTCHA policy: never defeat behavioral/token/slider challenges; OK to read a static distorted-text or
+  plain-arithmetic CAPTCHA on the subject's own opt-out, but stop if the site rejects the whole
+  submission after a correct answer (it is fingerprinting the automation). Third-party/indirect records
+  are the exception - still confirm those before acting. Per-site game plans + the meta-search no-op
+  skip-list are in `references/site-playbooks.md`; the full policy is in `references/methods.md`.
+- **PeopleConnect delete-wipes-suppression (permanent rule).** A PeopleConnect *deletion* wipes the
+  suppression and the subject re-lists across the whole affiliate cluster. If a "Your deletion request
+  for PeopleConnect.us is Complete" email ever appears, the suppression is gone -> **re-run suppression
+  and re-verify** the Control step reads "suppressed". Never leave this cluster on a completed deletion
+  (see `references/brokers/intelius.json`).
 
 Subagent reports are self-reports: the parent re-verifies key claims (listing URLs, match basis) before
 recording `found` and before any deletion.

optional-skills/security/unbroker/references/brokers/addresses.json

@@ -0,0 +1,52 @@
+{
+  "id": "addresses",
+  "name": "Addresses.com",
+  "category": "people_search",
+  "priority": "standard",
+  "jurisdictions": [
+    "US"
+  ],
+  "covered_by": "intelius",
+  "search": {
+    "method": "url_pattern",
+    "url": "https://www.addresses.com/",
+    "fetch": "web_extract",
+    "match_signal": "result",
+    "by": [
+      "name"
+    ],
+    "url_patterns": {
+      "name": "https://www.addresses.com/people/{First}+{Last}"
+    },
+    "url_format_quirks": [
+      "Name people page: /people/{First}+{Last} (a literal '+' joins first and last). Surfaced a real subject listing during the OSINT cross-check.",
+      "It is a PeopleConnect/Intelius FRONT-END: every 'report' link resolves to tracking.intelius.com. The data is the Intelius cluster's."
+    ]
+  },
+  "optout": {
+    "tier": "T1",
+    "method": "web_form",
+    "url": "https://suppression.peopleconnect.us/login",
+    "requires": {
+      "profile_url": false,
+      "email_verification": true,
+      "captcha": false,
+      "gov_id": false,
+      "account": false,
+      "phone_callback": false,
+      "payment": false
+    },
+    "inputs": [
+      "contact_email"
+    ],
+    "notes": "COVERED BY THE INTELIUS/PEOPLECONNECT CLUSTER -- do NOT file a separate opt-out. addresses.com is a front-end (report links -> tracking.intelius.com), and 'addresses' is listed in intelius.owns, so one PeopleConnect suppression (see intelius.json) removes it too. Recorded here only so the scan cross-check has the URL pattern and knows it maps to the parent. After the intelius suppression confirms, re-scan this URL to verify it dropped.",
+    "quirks": [
+      "Front-end only; holds no independent removal channel. The PeopleConnect Suppression Center is the lever."
+    ],
+    "est_processing_days": 7,
+    "reappearance_risk": "medium"
+  },
+  "last_verified": "2026-07-03",
+  "source": "field_verified",
+  "confidence": "documented"
+}

optional-skills/security/unbroker/references/brokers/intelius.json

@@ -67,7 +67,7 @@
       "url": "https://suppression.peopleconnect.us/guided-mode",
       "email": "privacy@peopleconnect.us",
       "kinds": ["ccpa", "generic"],
-      "notes": "INVERTED for PeopleConnect: do NOT use 'Right to Delete / DELETE MY USER DATA' if the goal is staying out of search results. Per their privacy-center, deleting your user data ALSO deletes any suppressions you have, and deletion does NOT stop the people-search sites from showing you (public-records-sourced data re-lists). Suppression is the do-not-display list, so it is the effective lever and must be maintained. Use deletion ONLY if the goal is purging the account data they hold, accepting that you will re-list and must re-suppress. privacy@peopleconnect.us is the rights-request address for that data-purge path."
+      "notes": "INVERTED for PeopleConnect: do NOT use 'Right to Delete / DELETE MY USER DATA' if the goal is staying out of search results. Per their privacy-center, deleting your user data ALSO deletes any suppressions you have, and deletion does NOT stop the people-search sites from showing you (public-records-sourced data re-lists). Suppression is the do-not-display list, so it is the effective lever and must be maintained. Use deletion ONLY if the goal is purging the account data they hold, accepting that you will re-list and must re-suppress. privacy@peopleconnect.us is the rights-request address for that data-purge path. FIELD-CONFIRMED 2026-07-03: a completed deletion emailed 'removed your identifying information from your suppression settings and you will need to re-enter that information' -- the suppression was wiped and the subject re-listed cluster-wide. If a 'deletion request is Complete' email appears, treat the suppression as gone: re-run suppression and re-verify the Control step reads 'suppressed'."
     },
     "playbook": [
       "PeopleConnect portal (suppression.peopleconnect.us/login, privacy-center entry at /privacy-center) -- ONE flow here covers Truthfinder, Instant Checkmate, US Search, ZabaSearch, Classmates and ~15 more. DO THIS PARENT FIRST.",
@@ -77,6 +77,8 @@
       "SUPPRESS, do NOT delete (this cluster is the exception to 'deletion beats suppression'). In guided-mode, complete the SUPPRESSION flow -- it puts you on the do-not-display list, which is what actually removes you from Intelius/TruthFinder/etc. Their privacy-center states: deleting your user data 'must delete any and all suppressions associated with your user', and 'Deleting your user information will NOT prevent other users from searching for your information through the people search websites. To suppress your information ... you must maintain your user information on file with the Suppression Center.'",
       "Therefore do NOT press 'Right to Delete / DELETE MY USER DATA' if the goal is search-visibility removal: it wipes your suppression and the public-records listing re-appears. Use the delete button ONLY if the operator's explicit goal is purging held account data (accept re-listing + re-suppression).",
       "Keep the account/suppression on file; do not delete it later. If the portal breaks: sister addresses privacy@intelius.com / privacy@truthfinder.com / privacy@instantcheckmate.com / support@ussearch.com / privacy@classmates.com; phone 1-888-245-1655.",
+      "VERIFY SUPPRESSED (mandatory): after completing suppression -- and ALWAYS before marking this cluster confirmed_removed -- re-open guided-mode and confirm the Control step reads 'configured as suppressed across our people search websites'. The session persists across visits and pre-fills DOB / names / the matched record, so re-affirming is fast.",
+      "DELETE-WIPED-SUPPRESSION MONITOR (field-confirmed 2026-07-03): if a 'Your deletion request for PeopleConnect.us is Complete' email (from privacy@verifications.peopleconnect.us) ever appears, the suppression is GONE -- its own wording says the deletion 'removed your identifying information from your suppression settings and you will need to re-enter that information', and it does NOT stop the affiliate people-search sites from re-listing. This is the delete-vs-suppress inversion happening live. Immediately re-run the SUPPRESSION flow and re-verify the Control step. Never leave this cluster on a completed deletion.",
       "After suppression confirms, re-scan the covered children (they normally drop out) before submitting any duplicate child opt-out."
     ],
     "notes": "PeopleConnect portal covers the cluster via SUPPRESSION (maintained), not deletion (see the deletion lane note: delete removes suppressions and does not stop public-records re-listing). Authorized-agent requests: signed written authorization (full name, address, phone, the email the consumer uses) or POA; for Right-to-Delete they verify agent authority with the consumer by email. Verified from the live privacy policy + suppression privacy-center 2026-07-02.",
@@ -85,7 +87,9 @@
       "The verification link authenticates a SESSION and lands on /guided-mode. That session is bound to the browser that OPENED it; a different browser hitting /guided-mode is redirected back to /login. So for hands-off automation the SAME agent browser must open the verify link (Mode B: read inbox -> agent browser navigates the link -> drive guided-mode). Link is a JWT (aud PeopleConnect-email-login -> -registration) carrying a deviceId, ~15-min TTL, Cloudflare-gated. Do NOT hard-navigate to /guided-mode after auth (drops the in-memory session -> /login); if lost, re-request a fresh verify email and follow it straight through.",
       "DOB GATE: guided-mode hard-requires date of birth (immutable once saved, no skip) to match records, so requires.dob=true. DOB is not collected at intake by default (sensitive, unneeded for scanning). If absent, the planner pre-warns (needs_operator_input) that this broker needs a human touchpoint; collect it with `intake --dob` up front to run hands-off. The matching step discloses DOB + legal name + alias beyond the contact email -- corroborate the record by address/email/phone, never name+DOB alone.",
       "INVERTED delete/suppress: SUPPRESSION is the do-not-display list and is what removes you from the people-search sites; it requires keeping your identifiers on file. 'DELETE MY USER DATA' deletes those suppressions and does NOT stop the sites showing you (public records re-list). Verbatim from the privacy-center: deleting user data 'must delete any and all suppressions associated with your user'; and 'Deleting your user information will NOT prevent other users from searching for your information ... To suppress your information ... you must maintain your user information on file with the Suppression Center.' So prefer suppression; use delete only for a deliberate data-purge. Verified live 2026-07-02.",
-      "Their published request metrics (2025): 33,513 deletion requests, median response < 1 day -- deletion is fast, but per above it is the wrong lever for search-visibility on this cluster."
+      "Their published request metrics (2025): 33,513 deletion requests, median response < 1 day -- deletion is fast, but per above it is the wrong lever for search-visibility on this cluster.",
+      "DOB field in guided-mode is an HTML <input type=date> -- enter it as ISO YYYY-MM-DD (not MM/DD/YYYY). The guided-mode session persists across visits and pre-fills the DOB / names / matched record, so re-verifying suppression later is quick.",
+      "addresses.com is a PeopleConnect/Intelius front-end (all report links -> tracking.intelius.com) and is in this record's `owns`, so the cluster suppression already covers it -- do NOT file a separate addresses.com opt-out."
     ],
     "est_processing_days": 7,
     "reappearance_risk": "medium"

optional-skills/security/unbroker/references/brokers/socialcatfish.json

@@ -0,0 +1,52 @@
+{
+  "id": "socialcatfish",
+  "name": "Social Catfish",
+  "category": "people_search",
+  "priority": "standard",
+  "jurisdictions": [
+    "US"
+  ],
+  "search": {
+    "method": "url_pattern",
+    "url": "https://socialcatfish.com/",
+    "fetch": "browser",
+    "match_signal": "result",
+    "by": [
+      "name",
+      "email",
+      "phone",
+      "image"
+    ],
+    "url_format_quirks": [
+      "Reverse-lookup site (name / email / phone / image / username). Subject exposure is usually an INDIRECT one (an email/phone data point), not a full profile -- verify what is actually shown before choosing a lane."
+    ]
+  },
+  "optout": {
+    "tier": "T2",
+    "method": "web_form",
+    "url": "https://socialcatfish.com/opt-out/",
+    "requires": {
+      "profile_url": false,
+      "email_verification": true,
+      "captcha": true,
+      "gov_id": false,
+      "account": false,
+      "phone_callback": false,
+      "payment": false
+    },
+    "inputs": [
+      "full_name",
+      "contact_email"
+    ],
+    "notes": "Automation-HOSTILE opt-out form: in the field the form filled correctly but the submission was automation-defeated, so it lands as a 2-click human task rather than a hands-off submit. Decision order per the blocked-form rule (methods.md): try the in-browser form on the operator's residential browser first; if it will not go through, fall back to the rights-request EMAIL address cited on the Social Catfish privacy policy / opt-out page (confirm the current address before sending -- do NOT use an address sourced from a third-party blog), disclosing name + contact email only. If neither is possible, queue a human_task with the exact end-state.",
+    "quirks": [
+      "Form defeats automation even when fields are filled correctly -> treat as a 2-click human task or use the cited rights-email fallback.",
+      "Confirm the cited rights-request email on the live privacy policy before using it; it is the fallback lane, not the primary."
+    ],
+    "est_processing_days": 7,
+    "reappearance_risk": "medium"
+  },
+  "last_verified": "2026-07-03",
+  "source": "field_verified",
+  "confidence": "documented"
+}

optional-skills/security/unbroker/references/methods.md

@@ -1,19 +1,63 @@
 # Opt-out method playbooks
 
-How the agent executes each broker `optout.method` using native Hermes tools. Always obey the
-**verify-before-disclose** rule: confirm a real listing exists, then submit only the fields the broker
-requires (`pdd.py plan` lists them per broker).
+How the agent executes each broker `optout.method` using native Hermes tools. Obey **least-disclosure**:
+submit only the subject's OWN identifiers, and only the fields a broker's official channel requires
+(`pdd.py plan` lists them per broker). Never disclose more than that, and confirm a listing is really
+the subject's before acting on any THIRD-PARTY / indirect record (see "Distinguish the subject" and
+"Indirect exposure"). See the posture section below for when a confirmed listing is NOT a prerequisite.
 
 **Autonomy:** `pdd.py next <subject>` sequences all of this - it decides which method applies, orders
 parents first, and routes human-only work to the digest. In `autonomy=full` (default), execute its
 actions without pausing per submission; the consent recorded at intake is the authorization. These
 playbooks are the HOW for each action type.
 
+## Opt-out posture: blind opt-out is the default (not a fallback)
+
+Operator-directed posture: **submit an opt-out or deletion on EVERY site that exposes an accessible
+removal channel, even when a listing was not first confirmed** - whichever of opt-out / deletion is
+optimal per site. Do not hand back a to-do list of "we could not search these."
+
+- **Why it is sound (does NOT violate least-disclosure):** a blind opt-out sends only the subject's own
+  identifiers to the broker's own official removal channel. You are giving the broker the subject's data
+  *to remove it*, not exposing new data or acting on a third party. (Third-party / indirect records are
+  the exception: those still require confirming the exposure first.)
+- **The opt-out flow doubles as the authoritative search.** Guided flows that match on email + DOB +
+  legal name and then say "no results" are a **stronger `not_found` than any scrape** - the broker ran
+  its own matcher against real identifiers. On guided-flow sites, "run the opt-out" and "search" are one
+  action (e.g. CheckPeople; see `site-playbooks.md`).
+
+### Blocked form -> default to the cited rights-email (the headline rule)
+
+When a removal **form** is automation-hostile (hard CAPTCHA, a Cloudflare wall that will not clear, a JS
+paywall funnel), **default to the broker's cited rights-request email** rather than recording `blocked`
+and deferring to a human - unless there is an easy in-browser solve. Decision order per site:
+
+1. **Easy in-browser solve?** (one-click remove; a guided flow whose CAPTCHA auto-clears on the
+   residential browser; plain email-verify) -> do it in the browser.
+2. **Form blocked but a cited rights-email exists?** -> send a deletion/opt-out email from the operator's
+   webmail (name + state + contact email only). This is now **preferred** over recording `blocked`.
+3. **No easy solve AND no cited email** -> `blocked` (or `human_task_queued` with the exact end-state).
+4. **Only lane requires gov-ID / physical mail** -> do NOT pursue autonomously (least-disclosure);
+   surface as a human decision.
+
+"Cited" = published by the broker itself (privacy policy / opt-out page / a working deletion alias). Do
+**not** email addresses sourced only from third-party blogs or Reddit. Per-site lanes and gotchas are
+pre-recorded in `references/site-playbooks.md` so future runs execute rather than re-derive.
+
+### Triage an external OSINT list before scanning
+
+When cross-checking any external "people OSINT" catalog, separate **first-party brokers** (removal
+targets) from **meta-search / link-out aggregators** (no first-party data -> no-ops, do not file
+opt-outs), **cluster front-ends** (covered by a parent, e.g. addresses.com -> Intelius), and
+**non-broker tools / APIs / wrong-jurisdiction** (skip). The skip-lists live in `site-playbooks.md`.
+
 ## Scan ladder (all methods)
 
-Confirm exposure before acting, cheapest first. Run **every** `search_vectors` entry from `pdd.py
-plan` (each name x location, phone, email, and address the broker's `search.by` supports) - different
-vectors surface different listings for the same person; dedupe found URLs.
+Build the exposure map cheapest first (on a site with an accessible removal channel you may still
+blind-opt-out even if the scan is inconclusive - see the posture section above). Run **every**
+`search_vectors` entry from `pdd.py plan` (each name x location, phone, email, and address the broker's
+`search.by` supports) - different vectors surface different listings for the same person; dedupe found
+URLs.
 
 1. `web_extract` on the broker `search.url` (fast HTML -> markdown). Look for `search.match_signal`.
    Build per-vector URLs from `search.url_patterns` and heed `search.url_format_quirks` (see below).
@@ -204,6 +248,19 @@ stealth/operator-browser pass (`methods.md` → scan ladder 3b - the operator's
 browser is the reliable unblock). Without a cloud browser configured, soft-CAPTCHA brokers drop to
 T2 and become human tasks. **Never use a third-party CAPTCHA-defeating service.**
 
+### CAPTCHA policy, clarified (on a consenting first-party opt-out)
+
+- **Do NOT defeat** behavioral / token challenges: a Cloudflare Turnstile that will not auto-clear,
+  **DataDome**, and **"slide-to-verify" gesture-entropy sliders** (the InfoPay lane). These are hard
+  stops -> take the email lane (rule above) or record `blocked`.
+- **Acceptable to solve** on the subject's own first-party opt-out: a **static distorted-text image
+  CAPTCHA** (read it with the vision tool) or a **plain arithmetic CAPTCHA** ("8 + 13 = ?"). That is OCR
+  / arithmetic on a consenting removal, not evasion of a bot-detection system.
+- **But** if the site then rejects the whole submission ("Captcha verification failed / feature not
+  available") after a correct answer, it is fingerprinting the automation itself, not grading the answer
+  -> **stop, do not loop** (e.g. PrivateRecords' distorted-text-THEN-arithmetic double gate). If no cited
+  rights-email exists, that is a genuine `blocked`.
+
 ## Browser backends: scan vs execute
 
 Two different jobs need two different browsers. Getting this wrong is the single biggest cause of a