Skip to content

AB Sniffer v6

Overview

AB Sniffer v6 evaluates two separate capabilities:

  1. identifying which browser automation framework opened the challenge page; and
  2. identifying whether that browser is running in headless mode.

A submission contains nine JavaScript files: one detector for each of the eight target frameworks and one independent headless detector. The challenge also runs human verification sessions to ensure that normal browser users are not classified as automation or headless.

Target Frameworks

  • seleniumbase
  • seleniumdriverless
  • pydoll
  • patchright
  • zendriver
  • nodriver
  • botasaurus
  • puppeteerextra

Submission Contract

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

File Required browser function
botasaurus.js window.detect_botasaurus
headless.js window.detect_headless_non_ua
nodriver.js window.detect_nodriver
patchright.js window.detect_patchright
puppeteerextra.js window.detect_puppeteerextra
pydoll.js window.detect_pydoll
seleniumbase.js window.detect_seleniumbase
seleniumdriverless.js window.detect_seleniumdriverless
zendriver.js window.detect_zendriver

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

Browser fingerprinting is prohibited. Detection must use page-local evidence related to automation behavior, instrumentation, patched APIs, protocol behavior, serialization, execution timing, stack traces, or framework-specific leaks. Do not construct persistent browser identities or use canvas, audio, font, WebGL, hardware, or device fingerprint aggregation.

Headless And Human

Headless describes a browser execution mode without a normal visible browser window. headless.js classifies the execution mode independently from the framework detectors. It must report true for a headless automation run and false for a headed automation run. The challenge expects non-user-agent evidence, so changing or inspecting only the user-agent string is not sufficient.

Human is not a ninth framework detector or a separate submission file. A run is treated as human when all eight framework detectors return false and the headless detector also returns false. Human verification is performed in a normal headed browser.

Expected classifications:

Session Framework result Headless result Human result
Headed automation Exactly the active framework is true false false
Headless automation Exactly the active framework is true true false
Human browser All framework detectors are false false true

A framework collision occurs when multiple framework detectors return true. Collisions receive reduced framework credit. Any framework detection or headless detection during a human task makes the final score zero.

Scoring

The current v6 scoring model is:

  • Framework classification: 90% of the final score.
  • Headless classification: 10% of the final score.
  • A correct, collision-free framework result receives full framework credit.
  • A correct framework included in a collision receives reduced credit.
  • A missed framework receives no framework credit for that run.
  • Each of the first three headless mistakes removes one third of the headless component; three or more mistakes reduce that component to zero.
  • A zero framework score produces a zero final score.
  • Any failed human verification produces a zero final score.

Runs are generated from the configured framework runners and device types. Each framework can be run in headed and headless modes, and the order may be shuffled. The exact number of runs and runner configuration are controlled by the scoring environment.

Testing Versus Production Scoring

Local testing and production scoring serve different purposes and should not be expected to produce identical results.

Local testing Production scoring
Uses automation runners created and configured by the miner Uses private RedTeam runner implementations and presets
Uses the miner's available operating systems and hardware Uses the production scoring infrastructure and configured device types
May use different browser, driver, and framework versions Uses versions installed in the production runner images
Uses miner-selected launch flags, patches, extensions, locale, timing, and network conditions Uses production launch arguments, patches, resource limits, timing, and network conditions
Helps diagnose detector behavior and false positives Determines the official score
Results are visible directly on the test page and through local scoring output Available output may be limited to the official score and permitted result details

These environment differences are expected to cause noticeable changes in observable automation signals. A detector that works against one local runner can miss or collide in production. Conversely, a production runner may expose a signal that is absent locally. Local success therefore does not guarantee the same production score.

Test multiple browser and framework versions, headed and headless modes, clean sessions, launch configurations, and supported operating systems. Prefer several independent, framework-specific signals over one environment-specific property. Always test normal human browsers because a single human false positive can invalidate the complete score.

Validation And Submission

Follow the repository's Testing_manuals.md before publishing an image. Validate both the source files and the prepared miner files with the provided validation workflow.

Build the final private image for linux/amd64, use a fully tagged repository, and do not push it until the tested score is accepted. General image publishing and commit registration are covered in Building and Publishing Your Solution.