Consistency Scoring: Benny the Doorman docs

Overview

Consistency scoring asks one question: do the signals collected from this browser tell a coherent story? A genuine browser environment produces signals that agree with each other — the GPU renderer agrees with the platform, the fonts agree with the OS, the audio and canvas outputs are deterministic across repeat calls. An anti-detect or spoofed environment tends to leave at least one of those agreements broken.

The result is a ConsistencyResult attached to FingerprintResult.consistency and DeviceIdResult.consistency. It exposes a normalised score, a list of fired flag names, and a bucketed spoofLikelihood of 'low' | 'medium' | 'high' for backend decision-making.

Consistency scoring is independent of automation and incognito scoring. A high spoofLikelihood indicates anti-detect activity. A high automationLikelihood indicates a driver-controlled browser. A high incognitoLikelihood is informational context, not a fraud signal.

// ConsistencyResult shape (src/types.ts)
interface ConsistencyResult {
  score: number;             // 0.0 to 1.0
  flags: string[];           // names of fired checks
  spoofLikelihood: 'low' | 'medium' | 'high';
}

// Defensive fallback: a broken check is treated as passing.
// If anything in the consistency pipeline throws, the result is:
return { score: 1.0, flags: [], spoofLikelihood: 'low' };

Exact check count, score formula, and per-check internals are deliberately not published. Treat spoofLikelihood as the stable interface; the underlying check list evolves between releases.

What is checked, at a glance

The check set covers cross-signal contradictions across several independent surfaces: GPU vs claimed OS, fonts vs claimed OS, screen geometry vs claimed device class, browser-engine reveals vs claimed engine, per-call determinism of canvas and audio, and signature checks for known anti-fingerprinting modes such as Brave Shields and Firefox resistFingerprinting.

The check set is intentionally redundant across vectors. A spoofer who patches one engine-reveal surface still trips an independent one. Specific check names, the exact thresholds that map flag counts to likelihood buckets, and the wiring between checks are not part of the public contract.

Brave-aware false-positive suppression

Brave is a legitimate browser state that produces signal patterns that overlap with anti-detect activity (Shields applies deterministic per-eTLD+1 modifications to canvas, audio, and WebGL). When Brave is confirmed, the consistency pipeline keeps the Brave marker visible in flags but re-evaluates the spoofLikelihood bucket so a normal Brave user does not read as a spoofer.

Equivalent suppression handles a small number of additional known browsers whose stock behaviour overlaps with noise-injection patterns from anti-fingerprinting extensions. Real spoofing evidence on those browsers still surfaces through the other checks in the set.

Things worth knowing

If the consistency pipeline throws an uncaught error, it returns { score: 1.0, flags: [], spoofLikelihood: 'low' }. A broken check is treated as passing so that an internal bug cannot break the fingerprint result.
The set of fired flags is exposed as opaque string names; consumers should treat them as labels for telemetry and forward them to their backend rather than branching on individual names. The set evolves between releases.
The likelihood bucket is the stable interface. Backend rules should key off spoofLikelihood, not flag-count arithmetic.
Brave and other legitimate-browser suppression runs after the raw checks. The raw markers stay visible in flags for diagnostic purposes; only the likelihood bucket is adjusted.

Last reviewed 2026-06-04