Abuse decisions
HumanProof scores challenge starts and explains the decision.
HumanProof combines widget behavior, form context, request headers, and recent project history into one risk score. The score produces an allow, challenge, or block recommendation. In observe mode the recommendation is recorded only; in enforce mode block decisions can stop the request before the proof-of-work challenge starts.
What the widget collects
The widget starts collecting local counters when it connects to the page. It does not send those counters until a challenge starts. If the widget is inside a form, it watches that form; otherwise it falls back to the document.
| Behavior | Elapsed time, focus and blur counts, keyboard activity, pointer movement, pointer-down activity, interaction count, current visibility state, and whether the page was hidden. |
|---|---|
| Widget context | Widget variant, trigger mode, branding mode, and widget signal version. |
| Form context | Likely email value when a normal email field is present, form method, same-origin form action path, and current page path. |
Server-side scoring
The browser never decides whether traffic is risky. The HumanProof backend receives the widget payload during the challenge request, adds request and project history signals, then stores the score and reason codes with the verification event.
User agent quality, language headers, fetch context, and origin/domain checks.
Disposable email domains and safe form/page context when available.
Repeated failed attempts and repeated high-risk patterns from the same hashed IP inside a short window.
Decisions
| Decision | Meaning |
|---|---|
| Allow | The challenge start looks normal for the current preset. |
| Challenge | The attempt should continue through proof-of-work and server-side verification. |
| Block | The attempt exceeds the block threshold for the preset and can be stopped before the challenge engine is called. |
| Observe | The project is learning and recording recommendations without enforcing risk blocks. |
Observe and enforce
HumanProof records scores, reasons, and recommended decisions, but eligible requests still continue to the proof-of-work challenge. Use this before turning on blocking.
HumanProof can reject block-level challenge starts before CAP receives the request. Blocked starts are counted as protected attempts because they consumed an abuse decision.
Reason codes
Reason codes explain why a score changed. They are designed for operators, support teams, and developers reviewing abuse decisions.
| very_fast_start / fast_start | The challenge started unusually quickly for an explicit or form-triggered flow. |
|---|---|
| no_observed_interaction / no_form_interaction | The widget did not observe expected pointer, keyboard, focus, or form interaction before the challenge. |
| background_or_hidden_page | The page was hidden or backgrounded during the observed window. |
| automated_user_agent | The request user agent matches common automation or command-line tooling patterns. |
| disposable_email | The automatically detected email domain is a known disposable provider. |
| repeat_failures / repeat_high_risk_pattern | The same hashed IP recently produced failed or high-risk events for this project. |
Privacy boundary
HumanProof keeps scoring server-side and stores hashed IP and user-agent values for event history. The widget sends minimal form context automatically; it does not scrape arbitrary form fields, and same-origin form paths are stored instead of full cross-origin action URLs.