Skip to content

Anti-Detect Browser Detection (ADA-3)

Overview

ADA-3 replaces the NSTBrowser-based ADA v2 challenge. Miners submit browser-side JavaScript detectors that identify which commercial anti-detect browser is driving a session, while staying silent on genuine human traffic.

Unlike AB Sniffer, the targets are not Python automation frameworks. Each target is a paid desktop application that launches a managed profile and is driven over its own loopback API, so detection must key on artifacts the product itself leaves in the page environment rather than on a WebDriver or CDP automation flag.

A submission contains six JavaScript files: one detector for each of the five target browsers and one independent headless detector. The challenge also runs human verification sessions to ensure normal browser users are never classified as an anti-detect browser or as headless.

Target Browsers

  • ads_power — AdsPower
  • dolphin_anty — Dolphin Anty
  • gologin — GoLogin
  • multilogin — Multilogin
  • octo — Octo Browser

NSTBrowser, the sole target of ADA v2, is not part of the ADA-3 roster. Its prior integration is kept for reference only and is never scheduled.

Submission Contract

Use the templates in the examples/miner_commit/src/commit/ directory. The submission must contain exactly:

File Required browser function
ads_power.js window.detect_ads_power
dolphin_anty.js window.detect_dolphin_anty
gologin.js window.detect_gologin
headless.js window.detect_headless
multilogin.js window.detect_multilogin
octo.js window.detect_octo

Each function must return, or resolve to, a value interpreted as a boolean. Do not rename the files or the exported functions. Each file must contain no more than 500 lines and pass the repository ESLint configuration (examples/miner_commit/eslint.config.mjs).

Browser fingerprinting is prohibited. Detection must rely on product-specific artifacts left in the page environment by the anti-detect browser — patched APIs, injected objects, profile or automation glue, protocol behavior, serialization, execution timing, or stack traces. Do not construct persistent browser identities or aggregate canvas, audio, font, WebGL, hardware, or device fingerprints.

Headless And Human

Headless describes a browser execution mode without a normal visible browser window. headless.js classifies the execution mode independently from the browser detectors, and must use non-user-agent evidence — inspecting or comparing only the user-agent string is not sufficient.

Human is not a sixth detector or a separate submission file. A run is treated as human when all five browser detectors return false and the headless detector also returns false.

Expected classifications:

Session Browser result Headless result Human result
Headed AdsPower ads_power only false false
Headless AdsPower ads_power only true false
Normal headed browser all false false true

A collision occurs when more than one browser detector returns true for the same run. Collisions receive heavily reduced credit and can create human false positives, so they must be removed before submission.

Scoring

Human and headless classification are hard gates.

  • Every human task must be classified as human: all five browser detectors and the headless detector must return false. Any false positive gives a final score of 0.0.
  • Every headless task must be detected by headless.js. Any missed headless detection gives a final score of 0.0.

Only submissions that pass both gates receive a browser-detection score. Browser accuracy is a weighted average across the configured targets; all five currently carry equal weight. A colliding detection is credited at 10% of a clean detection. If browser detection scores 0.0, the final score is 0.0.

Technical Constraints

  • Language: JavaScript (ES6+), one self-contained file per target
  • File limit: 500 lines per file, ESLint-clean
  • Architecture: Docker, amd64
  • State: Stateless execution, no persistence between runs
  • Prohibited: browser fingerprinting; testing-only storage or result-extraction logic

Development Workflow

  1. Start from the six supplied commit templates; retain their file names and window exports.
  2. Use the repository validator before each scoring attempt. It checks the submission contract and lint requirements before the more expensive challenge run.
  3. Follow the testing manual to start the local challenge, submit the detector payload, and inspect results. Complete every requested human-verification run: a human false positive is a hard scoring failure.
  4. Use the output to isolate missed targets, collisions, headless failures, and human failures. Re-test after every change.
  5. Build a submission image only after the score is satisfactory. The image must target linux/amd64; follow the standard miner commit workflow to publish it.

The local helper is useful for development, but miners should use the challenge scoring workflow for the authoritative result. Do not add an nstbrowser.js detector: NSTBrowser is not scheduled in ADA-3.

Plagiarism Policy

  • All submissions are compared against other miners' detectors.
  • 100% similarity = zero score.
  • Similarity score above 0.6 will result in rejection of the submission.

Resources & Guides