Expanded username testing: 35 controls across eight platforms

Updated 1 November 2026 · MyRecon editorial

We tested 35 platform-specific controls across eight platforms with the MyRecon web engine, Sherlock and Maigret on 1 November 2026. Each tool has 35 recorded outcomes, including exclusions and unresolved checks. MyRecon and Maigret each returned six source-supported matches; Sherlock returned four. No definitive false positives were observed on the scored controls. Eleven reference checks remained unresolved, and Sherlock also excluded nine controls under its current upstream policy. These limits matter when reading the results.

Publisher disclosure: MyRecon ran and publishes this study of its own engine and competing tools. The sample uses published upstream testing fixtures and generated candidates. We do not claim to own those fixture accounts. Personal social-media handles and customer search history are excluded. A fixture handle used on several platforms does not imply the accounts share an owner.

Observation window: 2026-11-01T16:39:28Z to 2026-11-01T16:41:33Z (UTC). This is a dated snapshot. Download the complete evidence ZIP, 105-row CSV, JSON observations and SHA-256 checksums.

Supported matches, false positives and unresolved checks

Supported match: a normalized positive agrees with current, account-specific reference evidence. False positive: a normalized positive contradicts explicit reference absence. False negative: a normalized negative contradicts a verified existing account. Unresolved / unscored: the reference or prediction is unknown, counted once per control. This includes upstream exclusions. Excluded entries were recorded without making a tool request. Zero observed false positives here is not a guarantee of zero errors elsewhere.

Coverage is (TP + TN + FP + FN) / all 35 controls. The false-positive denominator is FP + TN; unknown predictions on reference negatives are excluded from that denominator and retained in the evidence. No whole-catalogue accuracy or speed ranking follows from this developer/community sample.

Native claims and quarantined outcomes

Maigret reported two additional npm claims whose references returned HTTP 401. Both remain unverified. Sherlock returned native AVAILABLE on five denied npm requests; their HTTP 403 responses are normalized to unknown, preserving the native statuses. Blocks and unavailable sources are not evidence of account absence. All tool-specific outcomes appear below and in the CSV.

How the controls were selected and verified

The predeclared manifest contains 11 upstream claimed fixtures, eight upstream unclaimed fixtures and 16 generated negative candidates. They span GitHub, GitLab, Hacker News, Docker Hub, Dev.to, npm, Keybase, PyPI. Each fixture is tested only on the platform that published it as a control; this is not a cross-platform identity search. Case variants in case-insensitive namespaces are deduplicated. The 35 pairs contain 23 literal handle spellings (22 case-folded strings); repeated handles do not represent independent people.

The selection manifest records the upstream repository revision, source field, selected detection rule and rule hash for each fixture. Two deterministic 14-character alphanumeric candidates per platform are generated from the study ID, platform and index. Random-looking names are not assumed absent. Current source evidence determines their reference labels.

All reference observations were collected before tool predictions. Exact typed official API objects, explicit API absence, or a PyPI profile title naming the exact handle can establish a reference. HTML 200 alone, tool agreement, a login wall and a challenge cannot. We retain only account identifiers needed to verify the reference, response status, timestamps, response length and SHA-256, with profile contents omitted.

Stale fixtures and unresolved observations

• Stale claimed fixture: Sherlock’s Hacker News fixture blue returned JSON null from the official API. It is a verified absence in this snapshot, despite its historical claimed label. The pg fixture was confirmed separately.
• GitHub namespace: the official API identifies blue as an organization. This supports the tested public account namespace; it does not verify an individual person.
• npm: all five independent reference requests returned HTTP 401. Their account truth remains unknown, including the three negative candidates.
• PyPI: all five reference pages showed a Client Challenge. Sherlock’s negative outputs cannot be scored against those challenges. Maigret’s PyPI rule is disabled/protected and stayed unknown.
• Keybase: the published long unclaimed fixture did not satisfy the reference’s typed absence rule. Its negative predictions are unscored; the two shorter generated candidates were verified absent.
• Sherlock exclusions: the captured upstream exclusion list contains HackerNews and DEV Community. Their nine controls stay unknown. The study honors those exclusions even though the engine and bundled rules are pinned.

Every control and tool outcome

Tool versions, rules and execution settings

Python 3.12.14, Requests 2.34.2; one Windows workstation and network. References ran first, followed by MyRecon, Sherlock and Maigret in sequence, with one platform per request group and fixed pacing. Application caches were bypassed; provider caches were not controlled. Engine source files and the harness have separate SHA-256 hashes in the JSON. The MyRecon source revision describes the local web engine, not a hosted UI or Android device test.

Third-party code and bundled rules are pinned to the versions shown, without claiming they are the newest releases. Sherlock’s mutable exclusion list was fetched once and captured with its timestamp and SHA-256. No supplied credentials, proxies or block bypass were used. Upstream libraries may handle cookies returned by the sites. HTTP denials/errors (including 419), redirects that remain unresolved, unsupported checks and native failures normalize to unknown while retaining native output.

Download and reproduce the evidence

• Evidence ZIP: measured JSON, 105-row CSV, fixed manifest, reproduction scripts and upstream license notices.
• Measured JSON: references, all tool outcomes, source hashes, selected rules, exclusions, versions and timestamps.
• CSV: one row for every tool/control pair, including unknown and excluded outcomes.
• Predeclared control manifest, reproduction instructions and SHA-256 checksums.

Extract the ZIP and follow its README. Check out the recorded MyRecon revision, install the pinned third-party requirements in an isolated Python 3.12 environment, copy the included study harness, and run it with the provided manifest. A fresh run makes fresh network observations; it will not necessarily reproduce these historical outcomes. The ZIP contains retained, privacy-minimized observations and source-response hashes, rather than complete profile bodies.

python backend/tools/expanded_username_study.py --manifest controls.json --output output/new-study.json

Limitations and what this study supports

This expands the earlier single-handle case to eight selected platforms and a fixed set of platform-specific fixtures and controls. It supports the dated account-existence observations and per-tool outcomes shown here. The sample favors developer/community services, contains repeated fixtures and a GitHub organization, and includes no newly created owner-controlled positive accounts. Public fixtures are upstream test inputs; we make no claim about their ownership or consent to an identity investigation. Broader consumer social networks, authenticated profiles, the Android app and whole catalogues were not measured.

The reference and MyRecon share some official API sources, so this is a publisher-run regression study rather than an independent audit. Thirty-five controls and one network window cannot estimate population error rates. Eighteen reference negatives and six positives were decisive; eleven references remained unknown. Exclusions reduce effective scope, which is why both the common planned scope and scored denominators are published. No production detection rules were changed in response to this study. Known fixtures are not a held-out evaluation, and a matching handle does not prove identity, common ownership or registration availability.

See the earlier case study and separate daily regression snapshot, the workflow comparison, and the false-positive review guide. Corrections can be reported through the contact page; replacement observations should retain their own dates.

Primary sources

• Sherlock upstream project and its pinned site-rule links in the manifest.
• Maigret upstream project and its pinned fixture fields in the manifest.
• GitHub user endpoint, GitLab Users API, Hacker News Users API and Forem user API.
• The account-specific reference URLs and captured evidence for every platform appear in the matrix and downloadable JSON.

More from the MyRecon blog · Browse all guides