Username Checker False Positives: A Review Workflow

Key takeaways

• Understand the three outcomes
• Inspect false-positive causes
• Use controls without inventing ground truth

Understand the three outcomes

Found means a supported check observed evidence consistent with a public profile; it still needs source review. Not found means the check observed the expected negative pattern for that service. Unknown means it could not make a reliable decision, for example because of a challenge, timeout or ambiguous response. These describe a specific check at a time, not all accounts belonging to a person. Public presence also differs from whether a handle is available to register.

Inspect false-positive causes

Open the returned URL. Watch for a generic login page, search page, redirect to the platform home, suspended-account notice or a profile type different from the expected user page. Compare the page title and visible handle with the candidate. A tool may be using a status-code heuristic that does not understand these cases. Platform templates can change and invalidate a previously working detector.

Use controls without inventing ground truth

For an authorized evaluation, use a public account you control as a positive control and a second handle verified missing at the original service as a negative control. A random-looking string is not guaranteed to be unused. Record service, expected outcome, source evidence, observed result and date. Do not call an empty set of results a clean audit, and do not turn a tool's own output into its ground truth.

Worked example: application shell

Illustrative case: /user/known-handle and /user/verified-missing-handle both return status 200 and the same generic sign-in screen. A detector that checks only HTTP status labels both found. Your evidence supports unknown under that access context because neither response contains profile-specific information. If the official service displays an explicit missing-user message for the negative control, that may support not found. The distinction is the content observed, not the successful network request.

Observed case: a successful GitLab request with no matching user

The recorded October 2, 2026 regression run checked torvalds on GitLab. The official user-search API returned HTTP 200, while the recorded reference classified the exact handle as not found. The optional HTTP-200-only detector labeled it found. This is one observed false positive caused by treating request success as account evidence. The API result is about that GitLab handle at that time; it says nothing about the person associated with the same handle on GitHub. MyRecon and the reference share some API evidence, so their agreement is not an independent accuracy audit. The frozen raw run below includes source URLs, observation timestamps, versions and all 30 checks.

Download the frozen October 2 raw run and methodology (JSON)

Read benchmark evidence with its scope

MyRecon links recorded comparison evidence from the homepage. The published case is useful for inspecting result definitions and source review; a single handle is not an estimate of overall precision, recall or success rate across the catalogue. Provider failures and unsupported services should remain visible. A large platform count measures attempted scope, not confirmed accounts or reliable identity resolution.

Report a suspected detector problem

Record the platform, candidate URL, result status, time and the relevant public response. Redact your private identifiers and session information. Send a minimal report through the site contact channel. Recheck the original page before acting on the candidate; do not repeatedly hammer a blocked service. An unavailable check should remain unavailable until there is new evidence.

Reproduce the reasoning before trusting the label

Open the reference source URL in the frozen record and check the exact username field in any returned user objects. An empty array can be a successful user-search response without a matching account. Compare that observation with the detector label, then record found, not found or unknown according to the evidence. A later response may differ from the dated run. If the endpoint now blocks you, retain unknown rather than claiming the historical result was reproduced. The same reasoning applies to HTML login shells, but this API observation does not demonstrate every platform uses the same failure mode.