blocked-tail pass: blind opt-out default, email fallback, peopleconnect delete-wipes-suppression
from a live blocked-sites pass (no PII): - posture shift: blind opt-out is the DEFAULT, not a fallback -- submit on every site with an accessible removal channel even without first confirming a listing (own identifiers to the broker's own official channel = still least-disclosure). guided flows double as the authoritative search. - blocked-form rule: when a form is automation-hostile (hard captcha / cloudflare / datadome / slide-to-verify), default to the broker's CITED rights-email rather than recording blocked. - captcha policy clarified: never defeat behavioral/token/slider challenges; ok to read a static distorted-text or plain-arithmetic captcha on the subject's own opt-out; stop if the whole submission is rejected after a correct answer (fingerprinting the automation, not grading it). - intelius/peopleconnect: delete-wipes-suppression is field-confirmed -- a deletion-complete email means the suppression is gone and the subject re-lists cluster-wide; re-run suppression and verify the Control step reads "suppressed". guided-mode session persists; DOB is an <input type=date>. - new records: addresses.json (intelius front-end, cluster-covered) and socialcatfish.json (cited rights-email lane + automation-hostile form). - new references/site-playbooks.md: per-site game-plan matrix (8 blocked-tail sites), the meta-search no-op skip-list (idcrawl/lullar/yasni/webmii/namesdir/itools/skipease), and the infopay / peopleconnect backend clusters. OSINT-list triage taxonomy added to methods.md. - state-machine.md: fixed doc drift + documented submitted->not_found illegal (resolves as awaiting_processing), blocked->submitted via action_selected, operator_manual_check, --evidence & pitfall. tests: standalone 99, PR 97 (+1 cluster-coverage regression); ruff + windows-footguns clean.
This commit is contained in:
SHL0MS
parent
26dca5e54d
commit
5218c8a1d3
8 changed files with 272 additions and 9 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
}
|
||||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
}
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,56 @@
|
|||
# Per-site playbooks (pre-recorded game plans)
|
||||
|
||||
Field-verified game plans so the agent **executes** rather than re-discovers each run: does an
|
||||
in-browser search/opt-out work, what removal lanes exist, which is optimal, and the known gotcha or
|
||||
end-state. This is the durable memory for sites that do not have their own `references/brokers/<id>.json`
|
||||
record (the per-broker JSONs are the memory for the ones that do).
|
||||
|
||||
**Policy lives in `methods.md`** (blind-opt-out default, the blocked-form email-fallback decision order,
|
||||
and the CAPTCHA policy). This file is the site matrix + skip-lists + backend clusters. When you learn a
|
||||
site's mechanics, add or correct a row here (and promote it to a broker JSON if it becomes a recurring
|
||||
removal target).
|
||||
|
||||
## Blocked-tail pass matrix (worked 2026-07-03)
|
||||
|
||||
| Site | In-browser search? | Best lane | Field-verified gotcha / end-state |
|
||||
|---|---|---|---|
|
||||
| **PropertyRecs** | yes (real listing) | in-browser **one-click remove** | Form is a single **Full-Name** field + a **City/State** field (NOT first/last). No email verify, no CAPTCHA. Confirms "Success: Information Removed". Cleanest removal of the batch. |
|
||||
| **CheckPeople** | the flow **is** the search | in-browser **guided flow** | email -> verify link `/opt-out/dob/<token>` (from `info@checkpeople.com`) -> DOB (immutable) -> legal name -> Matching Records. "Unable to find any results that matched your name and date of birth" is a **strong `not_found`** (the broker ran its own matcher). |
|
||||
| **InfoTracer** | form gated | **email** `privacy@infotracer.com` (cited on `/optout`) | Form `members.infotracer.com/removeMyData` has a **slide-to-verify** slider (do NOT defeat). The cited email is a working Zendesk lane (ack + ticket #). **InfoPay backend.** |
|
||||
| **SpyFly** | form gated | **email** `deletemyinfo@spyfly.com` | `/help-center/remove-my-public-record` has a **Cloudflare Turnstile that will not clear**. Privacy policy lists only a form + phone, but the `deletemyinfo@` alias is a working deletion lane. |
|
||||
| **ZoomInfo** | email-gated | submit email (no-op if no profile) | "IF your email matches a profile we will send instructions." No instructions email = no profile. B2B **work-contact** DB; residential-footprint subjects generally do not match. |
|
||||
| **UnMask** | guided flow (stuck) | **human task** | PeopleConnect-family Suppression Center; step-1 "email sent" shown **twice**, but the verify email **never delivers** (checked 2h incl. spam/all-mail) -> broker-side delivery failure, needs a human retry. |
|
||||
| **PrivateRecords** | form (blocked) | **blocked** | `/api/helper/optOutLight/search` -> **double CAPTCHA** (distorted-text image THEN arithmetic) -> still rejected "Captcha verification failed" (it is fingerprinting the automation, not grading the answer). No cited rights-email (policy only has an unsubscribe link). |
|
||||
| **SearchQuarry** | none acceptable | **do NOT pursue** (human decision) | Same **InfoPay** slide-to-verify slider as InfoTracer; FAQ states removals are processed **only** by a mailed/faxed form + a copy of a gov-ID. Violates least-disclosure -> surface as a human decision, do not pursue autonomously. |
|
||||
|
||||
Also recorded `not_found` this pass via operator manual check (`operator_manual_check` evidence note):
|
||||
**ClustrMaps, PeekYou, NeighborReport** (404 / dead), **USA People Search** (no results),
|
||||
**BeenVerified** (no results; an optional preventive deletion email to the controller was left on the
|
||||
table). A dead/404 site or an operator-confirmed "no results" search is a valid `not_found`.
|
||||
|
||||
## Backend clusters (one operator's behavior predicts the others)
|
||||
|
||||
- **InfoPay backend** = **InfoTracer + SearchQuarry** (and other InfoPay-run sites): identical
|
||||
`InfoPay_Core_Components_OptOuts_*` form fields and the same **slide-to-verify** slider. If one shows
|
||||
the slider, expect it on the rest -> go straight to the email lane (where cited) or skip.
|
||||
- **PeopleConnect / Intelius front-end** = **addresses.com** (report links -> `tracking.intelius.com`).
|
||||
Covered by the cluster suppression (`addresses` is in `intelius.owns`); no separate opt-out. See
|
||||
`brokers/intelius.json` and `brokers/addresses.json`.
|
||||
|
||||
## Meta-search / link-out aggregators -- do NOT file opt-outs (no-ops)
|
||||
|
||||
These hold **no first-party data**; they interpolate the name into social-search URLs and show affiliate
|
||||
links to brokers we already handle (Spokeo / TruthFinder / BeenVerified). They clear when the underlying
|
||||
brokers do. Record `not_found` and move on; do **not** add them as broker records or file removals:
|
||||
|
||||
> **IDCrawl, Lullar, Yasni, WebMii, Namesdir, iTools, Skipease.**
|
||||
|
||||
## Triage before scanning (taxonomy)
|
||||
|
||||
When cross-checking any external "people OSINT" list (e.g. an OSINT Radar catalog), separate:
|
||||
|
||||
1. **First-party data brokers** -> removal targets (scan / blind opt-out).
|
||||
2. **Meta-search / link-out aggregators** -> no-ops (skip-list above).
|
||||
3. **Cluster front-ends** -> covered by a parent (e.g. addresses.com -> Intelius); do not double-file.
|
||||
4. **Non-broker tools / APIs / wrong-jurisdiction** -> skip: PhoneInfoga (a tool), People Data Labs
|
||||
(dev API), Truecaller (login-gated app), Canada411 / 192.com (CA / UK jurisdiction).
|
||||
|
|
@ -31,13 +31,26 @@ found -> action_selected | submitted | human_task_queued | indire
|
|||
indirect_exposure -> submitted | human_task_queued | not_found | found | blocked
|
||||
action_selected -> submitted | human_task_queued | blocked
|
||||
submitted -> verification_pending | awaiting_processing | human_task_queued | blocked
|
||||
verification_pending -> confirmed_removed | human_task_queued | blocked
|
||||
verification_pending -> awaiting_processing | confirmed_removed | human_task_queued | blocked
|
||||
awaiting_processing -> confirmed_removed | human_task_queued | blocked
|
||||
confirmed_removed -> reappeared | confirmed_removed (recheck refreshes the date)
|
||||
reappeared -> found | indirect_exposure
|
||||
human_task_queued -> found | indirect_exposure | action_selected | submitted | verification_pending
|
||||
| awaiting_processing | confirmed_removed | blocked
|
||||
blocked -> searching | found | not_found | indirect_exposure | action_selected
|
||||
| human_task_queued
|
||||
```
|
||||
|
||||
A transition to the same state is always allowed (idempotent field updates).
|
||||
|
||||
## Notes / gotchas learned in the field
|
||||
|
||||
- **`submitted -> not_found` is ILLEGAL.** A lodged request that then finds no matching profile is a
|
||||
no-op that resolves as `awaiting_processing`, never a walk back to `not_found`. (This is why a guided
|
||||
opt-out whose matcher says "no results" after you have already submitted is recorded
|
||||
`awaiting_processing`, not `not_found`.)
|
||||
- **`blocked -> submitted` is ILLEGAL directly** - go `blocked -> action_selected -> submitted`.
|
||||
- **Recording an operator's manual verdict:** attach an `operator_manual_check` evidence note. A
|
||||
dead / 404 site, or an operator-confirmed "no results" search, is a valid `not_found`.
|
||||
- **`--evidence` shell gotcha:** an `--evidence` JSON string containing a literal `&` trips the shell's
|
||||
backgrounding guard - write the word "and" instead of `&`.
|
||||
|
|
|
|||
|
|
@ -187,6 +187,18 @@ def test_clusters_expose_ownership():
|
|||
assert "peoplelooker" in cl.get("beenverified", [])
|
||||
|
||||
|
||||
def test_blocked_pass_records_and_cluster_coverage():
|
||||
# Records added from the blocked-tail pass load, resolve, and dedupe correctly.
|
||||
ids = {b["id"] for b in brokers.load_all()}
|
||||
assert {"addresses", "socialcatfish"} <= ids
|
||||
# addresses.com is a PeopleConnect/Intelius front-end -> covered by the intelius cluster (deduped).
|
||||
assert "addresses" in brokers.clusters().get("intelius", [])
|
||||
for bid in ("addresses", "socialcatfish"):
|
||||
b = brokers.get(bid)
|
||||
assert tiers.select_tier(b) in {"T0", "T1", "T2", "T3"}
|
||||
assert b["optout"]["method"]
|
||||
|
||||
|
||||
# --- tier selection -----------------------------------------------------------
|
||||
|
||||
def test_every_broker_resolves_to_valid_tier():
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue