CAPTCHA: make OSINT domain servers opportunistically use captcha.solve #172

Open
opened 2026-08-29 10:28:06 +00:00 by nsaspy · 0 comments
Owner

Goal

Adopt the approved CAPTCHA Domain Server across OSINT domain servers and actors that can encounter web challenges.

The integration is optional at runtime. A caller should use captcha.solve when the domain server is registered, healthy, authorized, and supports the exact challenge. The CAPTCHA service must not become a hard startup dependency.

Init-file policy

Whether a caller automatically invokes captcha.solve is controlled by the normal StarIntel init/config file through the CAPTCHA domain-server configuration.

Callers must honor at least:

  • global CAPTCHA domain enabled/disabled state
  • automatic solving enabled/disabled state
  • challenge-family allow/deny policy
  • provider/external-service policy
  • configured deadline and attempt ceilings
  • operator fallback policy

Callers must not embed provider preferences or private-solver knowledge. They delegate policy resolution to CaptchaDomainServer.

Initial caller families

Apply the pattern where relevant to:

  • Identity Domain Server account/profile enumeration
  • browser-backed public-profile collection
  • web search / scraping capabilities
  • Infrastructure Domain Server web-facing discovery
  • document/source acquisition flows
  • future OSINT domain servers with authorized browser/network collection

Do not add a provider-specific dependency to these callers.

Required caller behavior

  • detect or receive a typed challenge observation
  • preserve source request/session state
  • discover captcha.solve through the capability/domain-server registry
  • honor init-file auto-solve and challenge-family policy
  • check health and exact capability compatibility
  • submit only bounded challenge data plus opaque refs
  • await within the caller deadline
  • apply the result in the required source context
  • separately verify downstream acceptance
  • resume the original actor/workflow
  • preserve provenance across detection -> solve attempt -> application -> acceptance -> resumed collection

Domain server unavailable or disabled

If the CAPTCHA Domain Server is disabled by init, missing, unhealthy, unauthorized, or has no matching solver:

  • do not crash actor startup
  • do not busy-loop
  • do not blindly retry
  • do not convert the challenged page into notFound
  • return a typed blockedByChallenge, unsupportedChallenge, or partial result as appropriate
  • let the surrounding StarLang plan decide whether to continue, defer, or surface the block

StarLang requirements

Prefer expressing this as reusable StarLang continuation/orchestration semantics rather than duplicating Common Lisp control flow in every actor.

Required primitives include:

  • optional capability dependencies
  • init/config schema access
  • capability discovery
  • typed blocked/partial outcomes
  • deadline-aware request/reply
  • resumable continuation
  • cross-domain invocation
  • opaque session/artifact/result refs
  • provenance linkage

If StarLang lacks one, open/implement the StarLang gap before introducing an ad-hoc Python controller.

Private solver boundary

Callers know only the public captcha.solve contract. They must not know whether the selected implementation is NoneCap, NopeCHA, 2Captcha, another public adapter, or the private in-house solver.

The private in-house solver remains non-OSS.

Design authority: roam/design/star-server/STAR-CAPTCHA-002-domain-server-repository-boundary.org.

## Goal Adopt the approved CAPTCHA Domain Server across OSINT domain servers and actors that can encounter web challenges. The integration is **optional at runtime**. A caller should use `captcha.solve` when the domain server is registered, healthy, authorized, and supports the exact challenge. The CAPTCHA service must not become a hard startup dependency. ## Init-file policy Whether a caller automatically invokes `captcha.solve` is controlled by the normal StarIntel init/config file through the CAPTCHA domain-server configuration. Callers must honor at least: - global CAPTCHA domain enabled/disabled state - automatic solving enabled/disabled state - challenge-family allow/deny policy - provider/external-service policy - configured deadline and attempt ceilings - operator fallback policy Callers must not embed provider preferences or private-solver knowledge. They delegate policy resolution to `CaptchaDomainServer`. ## Initial caller families Apply the pattern where relevant to: - Identity Domain Server account/profile enumeration - browser-backed public-profile collection - web search / scraping capabilities - Infrastructure Domain Server web-facing discovery - document/source acquisition flows - future OSINT domain servers with authorized browser/network collection Do not add a provider-specific dependency to these callers. ## Required caller behavior - [ ] detect or receive a typed challenge observation - [ ] preserve source request/session state - [ ] discover `captcha.solve` through the capability/domain-server registry - [ ] honor init-file auto-solve and challenge-family policy - [ ] check health and exact capability compatibility - [ ] submit only bounded challenge data plus opaque refs - [ ] await within the caller deadline - [ ] apply the result in the required source context - [ ] separately verify downstream acceptance - [ ] resume the original actor/workflow - [ ] preserve provenance across detection -> solve attempt -> application -> acceptance -> resumed collection ## Domain server unavailable or disabled If the CAPTCHA Domain Server is disabled by init, missing, unhealthy, unauthorized, or has no matching solver: - do not crash actor startup - do not busy-loop - do not blindly retry - do not convert the challenged page into `notFound` - return a typed `blockedByChallenge`, `unsupportedChallenge`, or `partial` result as appropriate - let the surrounding StarLang plan decide whether to continue, defer, or surface the block ## StarLang requirements Prefer expressing this as reusable StarLang continuation/orchestration semantics rather than duplicating Common Lisp control flow in every actor. Required primitives include: - optional capability dependencies - init/config schema access - capability discovery - typed blocked/partial outcomes - deadline-aware request/reply - resumable continuation - cross-domain invocation - opaque session/artifact/result refs - provenance linkage If StarLang lacks one, open/implement the StarLang gap before introducing an ad-hoc Python controller. ## Private solver boundary Callers know only the public `captcha.solve` contract. They must not know whether the selected implementation is NoneCap, NopeCHA, 2Captcha, another public adapter, or the private in-house solver. The private in-house solver remains non-OSS. Design authority: `roam/design/star-server/STAR-CAPTCHA-002-domain-server-repository-boundary.org`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/starintel-auto-research#172
No description provided.