mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-12 13:52:15 +00:00
fix(unbroker): suppress-first for PeopleConnect (deletion undoes suppression)
PeopleConnect is the exception to deletion-beats-suppression: "DELETE MY USER DATA" also deletes suppressions on file, and deletion does not stop the people-search sites from showing you (public records re-list). Suppression is the effective lever and must be maintained. - intelius.json: deletion.prefer=false; playbook/quirks/notes rewritten with the verbatim privacy-center language; delete is the data-purge-only path. - autopilot: honor deletion.prefer -> prefer_suppression when false. - methods.md / SKILL.md / README: exception called out. - tests updated + prefer-flag routing test (86 tests).
This commit is contained in:
SHL0MS
parent
50db1d6f6d
commit
aaea22f89c
6 changed files with 74 additions and 36 deletions
|
|
@ -92,9 +92,10 @@ The underlying CLI (run via `terminal`, as `python3 scripts/pdd.py <cmd>`):
|
|||
viable tier and escalates to a human task only when genuinely blocked.
|
||||
- **Cluster parents first.** Many brokers are resold shells of a few parents, so one removal can
|
||||
clear a dozen child sites. The planner orders parents ahead of standalone listings and ships
|
||||
field-verified, per-parent playbooks that prefer the **right-to-delete** lane over mere suppression
|
||||
(for example PeopleConnect's "delete my user data", or Whitepages' privacy email, which sidesteps
|
||||
the phone-callback tool entirely).
|
||||
field-verified, per-parent playbooks that usually prefer the **right-to-delete** lane over mere
|
||||
suppression (for example Whitepages' privacy email, which sidesteps the phone-callback tool), with
|
||||
per-broker exceptions where the record says otherwise (PeopleConnect: deleting your user data wipes
|
||||
your suppressions and does not stop public-records re-listing, so suppress-and-maintain instead).
|
||||
- **Multi-identifier fan-out.** A person is indexed under every name/alias, phone, email, and
|
||||
address. The planner expands all of them (filtered by what each broker supports) so listings under
|
||||
a maiden name or an old address are found, not just "primary name plus current city".
|
||||
|
|
|
|||
|
|
@ -152,9 +152,11 @@ For anything past a couple of brokers, run this as **map → reduce → act**, n
|
|||
CCPA/GDPR delete-my-PII emails (`send-email --kind ccpa_indirect`), and defer `blocked` to the
|
||||
stealth-browser pass. Opt-outs hit CAPTCHAs, email-verification loops, and session binding - work
|
||||
them **one at a time, carefully** (this is the opposite of fan-out), but do NOT stop to ask
|
||||
permission per submission in `autonomy=full`; in `assisted`, confirm each one. **Prefer deletion
|
||||
over suppression** where a broker offers both (e.g. PeopleConnect's "Right to Delete / DELETE MY
|
||||
USER DATA" actually removes data; the suppression flow only hides it).
|
||||
permission per submission in `autonomy=full`; in `assisted`, confirm each one. **Usually prefer
|
||||
deletion over suppression** where a broker offers both (Spokeo/BeenVerified) - but follow the
|
||||
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.
|
||||
|
||||
Subagent reports are self-reports: the parent re-verifies key claims (listing URLs, match basis) before
|
||||
recording `found` and before any deletion.
|
||||
|
|
@ -200,9 +202,11 @@ recording `found` and before any deletion.
|
|||
The parent re-verifies key `found` claims from subagents before trusting them.
|
||||
5. **Opt-outs (when `next` says so).** Actions come pre-ordered parents-first with `steps` from each
|
||||
broker record's own `optout.playbook` (field-verified; cluster parents like PeopleConnect,
|
||||
Whitepages, BeenVerified, Spokeo have exact, live-checked recipes). **Deletion beats
|
||||
suppression**: when an action carries `prefer_deletion`, complete the record's DELETION lane (e.g.
|
||||
PeopleConnect's "DELETE MY USER DATA"), never just the hide-my-listing flow. Per method:
|
||||
Whitepages, BeenVerified, Spokeo have exact, live-checked recipes). **Deletion usually beats
|
||||
suppression**: when an action carries `prefer_deletion`, complete the record's DELETION lane, not
|
||||
just the hide-my-listing flow. When it carries `prefer_suppression` instead (**PeopleConnect** -
|
||||
deleting removes your suppressions and does not stop re-listing), do the suppression flow and keep
|
||||
it maintained; use their Delete button only for a deliberate data-purge. Per method:
|
||||
- **web_form** → drive `optout_url` with `browser_navigate`/`browser_type`/`browser_click`, submit
|
||||
only `disclosure_fields`, screenshot the confirmation, then the action's `after` record command.
|
||||
Playbooks may end with a right-to-delete `send-email` follow-up - do it (full erasure, not just
|
||||
|
|
|
|||
|
|
@ -60,25 +60,27 @@
|
|||
],
|
||||
"deletion": {
|
||||
"via": "in_flow",
|
||||
"prefer": false,
|
||||
"url": "https://suppression.peopleconnect.us/guided-mode",
|
||||
"email": "privacy@peopleconnect.us",
|
||||
"kinds": ["ccpa", "generic"],
|
||||
"notes": "The portal's 'Right to Delete / DELETE MY USER DATA' (bottom of guided-mode) is the verified deletion path and covers the whole cluster. privacy@peopleconnect.us is the documented rights-request address (their 2025 CPRA metrics: 33,513 delete requests, median response < 1 day) - use it as the fallback if the portal breaks."
|
||||
"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."
|
||||
},
|
||||
"playbook": [
|
||||
"PeopleConnect portal (suppression.peopleconnect.us/login, privacy-center entry at /privacy-center) -- ONE flow here clears Truthfinder, Instant Checkmate, US Search, ZabaSearch, Classmates and ~15 more. DO THIS PARENT FIRST.",
|
||||
"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.",
|
||||
"Step 1 asks ONLY for an email + consent checkbox (no name/DOB, no CAPTCHA) -> sends a verification email. Least-disclosure entry: just the contact email.",
|
||||
"poll-verification will pick up the verify link. The link authenticates a SESSION bound to the browser that OPENS it: the SAME agent browser must open the link and drive /guided-mode (a different browser is bounced to /login).",
|
||||
"SUPPRESSION != DELETION -- guided-mode's default flow only HIDES the report (data retained, can re-list). Scroll to the BOTTOM of guided-mode and use 'Right to Delete / DELETE MY USER DATA' (CCPA/CPRA) -- this actually deletes across the cluster and emails its own confirmation link; poll and open that too.",
|
||||
"If the portal breaks: email privacy@peopleconnect.us (rights-request address, median response < 1 day per their published metrics), or sister addresses privacy@intelius.com / privacy@truthfinder.com / privacy@instantcheckmate.com / support@ussearch.com / privacy@classmates.com; phone 1-888-245-1655.",
|
||||
"After the deletion confirms, re-scan the covered children (they normally drop out) before submitting any duplicate child opt-out."
|
||||
"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.",
|
||||
"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. 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 2026-07-01 (policy dated 2026-06-30).",
|
||||
"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.",
|
||||
"quirks": [
|
||||
"Step 1 (suppression.peopleconnect.us/login) asks ONLY for an email + a consent checkbox, then 'Continue' -> a verification email with a link. No CAPTCHA, no name/DOB at step 1. Least-disclosure entry: just the contact email. Verified live 2026-06-30.",
|
||||
"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).",
|
||||
"SUPPRESSION != DELETION. The guided-mode/suppression flow only HIDES the background report (data retained, can re-list). At the BOTTOM of guided-mode there is a separate 'Right to Delete' section with a 'DELETE MY USER DATA' button (CCPA/CPRA) that removes the user data across the cluster - this is the stronger action and should be preferred. It also emails a confirmation link. (Confirmed via security.org Instant Checkmate guide + live flow 2026-06-30.)",
|
||||
"Their published request metrics (2025, all US users regardless of state): 33,513 deletion requests, 26,603 complied, median response < 1 day - the deletion lane is real and fast. Verified from privacy policy 2026-07-01."
|
||||
"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."
|
||||
],
|
||||
"est_processing_days": 7,
|
||||
"reappearance_risk": "medium"
|
||||
|
|
|
|||
|
|
@ -192,12 +192,14 @@ covered. `pdd.py plan <subject> --batch` **orders the `found` group parents-firs
|
|||
source of truth, field-verified, updated as live runs discover mechanics. What follows is the
|
||||
operating doctrine; the exact steps are in `references/brokers/<id>.json`.
|
||||
|
||||
**Deletion beats suppression, email lanes beat forms.** Each parent record carries a structured
|
||||
`optout.deletion` lane (`via: in_flow | email | email_followup`, plus the privacy address). The
|
||||
autopilot routes accordingly:
|
||||
**Deletion USUALLY beats suppression, email lanes beat forms -- but check the record.** Each parent
|
||||
record carries a structured `optout.deletion` lane (`via: in_flow | email | email_followup`, a
|
||||
privacy address, and `prefer`). The autopilot routes accordingly, and when `deletion.prefer` is
|
||||
false it emits `prefer_suppression` instead of `prefer_deletion`:
|
||||
|
||||
- **`in_flow`** (PeopleConnect): the deletion control lives INSIDE the web flow - complete the flow
|
||||
and use the **Right to Delete / DELETE MY USER DATA** control, never just the suppression step.
|
||||
- **`in_flow`** (PeopleConnect, `prefer: false`): the deletion control lives inside the web flow, but
|
||||
for this cluster it is the WRONG lever for search-visibility (see the exception below). Complete the
|
||||
**suppression** flow and maintain it; do not press Delete unless the goal is a data-purge.
|
||||
- **`via: email`** (Whitepages): the fully-autonomous lane - `send-email` the request (residency-picked
|
||||
kind: CCPA for US-CA, GDPR for EU/UK, generic otherwise), then `poll-verification` for their reply
|
||||
and answer identity questions with least-disclosure. This is also the **rescue lane**: any broker
|
||||
|
|
@ -206,12 +208,15 @@ autopilot routes accordingly:
|
|||
- **`email_followup`** (BeenVerified, Spokeo): the opt-out form is the fast primary (it clears the
|
||||
listing), and the playbook then sends a right-to-delete email for full erasure beyond suppression.
|
||||
|
||||
Verified parent facts (live-checked 2026-07-01; details + steps in the records):
|
||||
Verified parent facts (live-checked 2026-07-02; details + steps in the records):
|
||||
|
||||
- **Intelius/PeopleConnect** (~15+ sites in one flow): portal entry asks only email + consent →
|
||||
verify link is **session-bound to the browser that opens it** → guided-mode → **DELETE MY USER
|
||||
DATA** at the bottom (suppression alone re-lists). Fallback `privacy@peopleconnect.us` - their own
|
||||
published metrics: 33.5k deletion requests, median response < 1 day.
|
||||
- **Intelius/PeopleConnect** (~15+ sites in one flow) -- **EXCEPTION to deletion-beats-suppression.**
|
||||
Portal entry asks only email + consent → verify link is **session-bound to the browser that opens
|
||||
it** → guided-mode. Complete the **SUPPRESSION** flow and keep the account on file: suppression is
|
||||
the do-not-display list that removes you. Per their privacy-center, **'DELETE MY USER DATA' deletes
|
||||
your suppressions and does NOT stop the sites from showing you** (public records re-list), so use it
|
||||
only for a deliberate data-purge. `privacy@peopleconnect.us` is the rights-request address for that
|
||||
path; published metrics: 33.5k deletion requests, median response < 1 day.
|
||||
- **Whitepages**: `privacyrequest@whitepages.com` (or the Zendesk form) handles removal + CCPA
|
||||
deletion **without the phone-callback tool** - that phone call is only required by the automated
|
||||
tool. One removal also drops "all known connected listings". ≤15 days; check 411.com + Premium.
|
||||
|
|
|
|||
|
|
@ -185,9 +185,16 @@ def _optout_action(row: dict, playbook: dict[str, dict], subject_id: str, dossie
|
|||
f"--disclosed <field>... --channel web_form",
|
||||
}
|
||||
if deletion:
|
||||
action["prefer_deletion"] = ("this record has a right-to-delete lane -- complete the DELETION "
|
||||
"flow, not just suppression" + (f" ({deletion.get('notes')})"
|
||||
if deletion.get("notes") else ""))
|
||||
if deletion.get("prefer", True):
|
||||
action["prefer_deletion"] = ("this record has a right-to-delete lane -- complete the "
|
||||
"DELETION flow, not just suppression"
|
||||
+ (f" ({deletion.get('notes')})" if deletion.get("notes") else ""))
|
||||
else:
|
||||
# Some brokers invert the usual rule: deleting the account removes suppressions and
|
||||
# does not stop public-records re-listing (e.g. PeopleConnect). Suppress and maintain.
|
||||
action["prefer_suppression"] = (deletion.get("notes")
|
||||
or "suppression (maintained) is what removes you here; "
|
||||
"deleting undoes it and does not stop re-listing")
|
||||
if req.get("captcha"):
|
||||
action["note"] = ("CAPTCHA-gated: attempt with the configured browser backend once; if it "
|
||||
"does not clear, record blocked (do NOT retry-loop or bypass)")
|
||||
|
|
|
|||
|
|
@ -954,13 +954,32 @@ def test_cluster_parents_have_playbook_and_deletion_lane():
|
|||
assert addr in emailer.broker_addresses(b), f"{bid}: {addr} not sendable"
|
||||
|
||||
|
||||
def test_curated_intelius_playbook_prefers_deletion():
|
||||
def test_curated_intelius_suppress_first_not_delete():
|
||||
# PeopleConnect is the EXCEPTION to deletion-beats-suppression: deleting user data wipes
|
||||
# your suppressions and does not stop public-records re-listing, so suppress-and-maintain.
|
||||
b = brokers.get("intelius")
|
||||
steps = " ".join(b["optout"]["playbook"])
|
||||
assert "SUPPRESSION != DELETION" in steps # the trap, encoded in the data
|
||||
assert "DELETE MY USER DATA" in steps # the actual deletion control
|
||||
assert "privacy@peopleconnect.us" in steps # the email fallback lane
|
||||
assert b["optout"]["deletion"]["via"] == "in_flow"
|
||||
d = b["optout"]["deletion"]
|
||||
assert d["prefer"] is False and d["via"] == "in_flow"
|
||||
assert d["email"] == "privacy@peopleconnect.us" # rights-request address for the data-purge path
|
||||
steps = " ".join(b["optout"]["playbook"]).upper()
|
||||
assert "SUPPRESS" in steps # the recommended action
|
||||
assert "DELETE MY USER DATA" in steps # names the trap to avoid
|
||||
|
||||
|
||||
def test_deletion_prefer_flag_controls_autopilot_note():
|
||||
with temp_env():
|
||||
d = _consenting()
|
||||
pc = _mini_broker("pc", owns=["kid"])
|
||||
pc["optout"]["deletion"] = {"via": "in_flow", "prefer": False,
|
||||
"email": "privacy@pc.example", "notes": "delete undoes suppression"}
|
||||
q = autopilot.next_actions(d, [pc, _mini_broker("kid")], _auto_cfg(), {"pc": {"state": "found"}}, env={})
|
||||
act = next(a for a in q["actions"] if a.get("broker_id") == "pc" and a["type"] == "optout_web_form")
|
||||
assert "prefer_suppression" in act and "prefer_deletion" not in act
|
||||
dd = _mini_broker("dd")
|
||||
dd["optout"]["deletion"] = {"via": "email_followup", "email": "p@dd.example"}
|
||||
q2 = autopilot.next_actions(d, [dd], _auto_cfg(), {"dd": {"state": "found"}}, env={})
|
||||
act2 = next(a for a in q2["actions"] if a["type"] == "optout_web_form")
|
||||
assert "prefer_deletion" in act2 and "prefer_suppression" not in act2
|
||||
|
||||
|
||||
def test_curated_whitepages_email_lane_is_autonomous():
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue