The consistency suite

Purpose: define exactly how we prove a fingerprint config — and a built core — is coherent and undetectable enough to ship. This is the release gate referenced by CHROMIUM_BUILD_AND_UPDATE §5 and core/tests/consistency/. Detection comes from inconsistency between signals, not single values, so the suite tests coherence, not just presence.

1. What we test (three layers)

1. Coherence assertions (ours, deterministic): internal contradictions → hard fail.
2. External probes (third-party detectors): run headless against the core, score the result.
3. Artifact checks: no JS-shim tampering artifacts (the thing that betrays cheap antidetects).

2. Coherence assertions (fail, don’t warn)

3. Anti-artifact checks (no shim signature)

These are why engine-level patching beats JS injection (Camoufox principle). A built patched core should pass A1–A4 by construction; a JS/CDP provider will not — that’s its documented ceiling.

4. External probes (scored)

Run headless (Playwright/CDP) against the core, capture + score:

• CreepJS — trust score + lie detection (flags inconsistencies/overrides).
• pixelscan — consistency + automation flags.
• fingerprint.com / BotD-style — bot likelihood.
• browserleaks (WebRTC, canvas, fonts, WebGL) — per-signal leakage. Each probe → normalized sub-score; record raw output as an artifact for diffing across versions.

5. Scorecard & gate

suite result = {
  coherence:   all C1..C9 PASS  (any fail → BLOCK)
  artifacts:   all A1..A4 PASS  (any fail → BLOCK)
  probes:      weighted score ≥ THRESHOLD  (else BLOCK)
  trust_score: provenance × validator × core_capability
}

• Any coherence/artifact failure blocks release regardless of probe score.
• Probe THRESHOLD is a tunable (OPEN question) — start strict, calibrate against a known-good core.
• Output is machine-readable; CI keeps last-known-good core pinned until a new build passes.

Deep-capability set (baseline anchor). A provider declares which deep / projection checks it actually spoofs as a set of check ids (deep_checks, e.g. [] for stock, ["C8"] for the 0010 build) — replacing the old single deep_fingerprint bool. Baseline-characterization then expects each deep check in the set to PASS and every other deep check to FAIL (the documented ceiling — that signal isn’t patched yet). Because identity patches land incrementally (0010 navigator-basics → C8; WebGL/fonts → C2/C3 later), the set lets a partially-patched core be characterized correctly instead of all-or-nothing (ISSUE-019). A deep check that passes outside the set (a host coincidence) or fails inside it (a regression) is a DEVIATION.

⚠ C2 scope caveat (WebGL capability-profile residual, ISSUE-020). C2 today reads only the two WEBGL_debug_renderer_info strings (UNMASKED_VENDOR/RENDERER); patch 0020 spoofs exactly those. So C2-green does NOT mean “WebGL is coherent” — the numeric getParameter limits, getSupportedExtensions list/order, getShaderPrecisionFormat matrix, getContextAttributes, the WebGL2-only params, the WebGPU GPUAdapter, and the readPixels/pixel-hash all stay the host ANGLE backend (real D3D11 on the dev host) and can contradict the spoofed GPU string. C2b now MEASURES this — a Probe-layer check records the caps profile (MAX_TEXTURE_SIZE + MAX_*_UNIFORM_VECTORS + MAX_RENDERBUFFER_SIZE + a sorted-extension digest + highp-float precision) in every scorecard, so the residual is VISIBLE next to the spoofed string instead of hidden. C2b PASSES on a plausible profile and FAILS only on an UNAVAILABLE / GROSSLY-BROKEN context (empty extensions or MAX_TEXTURE_SIZE < 4096); it does NOT detect a SwiftShader software fallback — real SwiftShader reports plausible caps (16384 + a full extension set) and c2b runs post-spoof, so that software-renderer tell needs a caps-based discriminator (a later patch). Gate interaction: the Probe layer never blocks the Verdict, but C2b is non-deep so a C2b FAIL is a characterize deviation (a broken context is surfaced, not silently green). C2b does NOT judge caps-vs-config-GPU (needs a per-GPU reference dataset); a params/extensions patch (≈0024 — 0021/0022/0023 are canvas/audio/fonts) closes the caps half.

6. Per-provider expectations

Measured baselines of the built core, by pin. M149 (149.0.7827.201, 2026-06-27 → 2026-09-04): pristine = Matches at the stock ceiling (empty deep_checks), patched = Matches with deep_checks = [C8, C6, C1, C2, C4, C3, C9]. M152 (152.0.7977.75, B74, 2026-09-04/05): the pristine build (out/M152, chrome.dll 2026-09-04 14:24:54) read through the stock declaration is Matches at the ceiling — all seven projection checks fail as stock does, every shallow check passes, Chrome/152.0.7977.75 — and its JA4 (t13i1516h2_002f,…,cca9_0005,…,44cd,ca34,fe0d,ff01_0904,0905,0906,0403,0804,0401,0503,0805,0501,0806,0601), Akamai (1:65536;2:0;4:6291456;6:262144|15663105|m,a,s,p) and QUIC-JA3 are byte-identical to the installed stock 152.0.7977.75 measured by the same instrument (JA3 differs only by Chrome’s per-connection extension shuffle). The patched build (chrome.dll 2026-09-05 02:24:38, the series of 21 on the 152 base) is Matches, 7 deep, Pass, all 32 checks with the same pass/deep as on M149, C15 in the card, and the same JA4/Akamai as the pristine one — the network inversion (ADR-0027) holds on 152 by construction. The 149→152 move is priced in SERIES_REBASE_COST.md (internal: docs/30-core/SERIES_REBASE_COST.md) §7. The M152 stock ceiling differs from M149’s in two shallow facts worth knowing: the ClientHello now carries ML-DSA signature algorithms (0904,0905,0906) and the Trust Anchor IDs extension (ca34) in code, not by field trial (B65 had measured ca34 as a stock-only difference on 149).

7. How it runs

• Local: VFLIN_BUILT_CHROME=<...>/chrome.exe cargo run -p vflin-consistency --bin run-consistency -- <version> → scorecard. The version argument is the CLAIM to score against; without it the version comes from the persisted config, not from the binary, so an env-selected core can be scored against someone else’s declaration (B83 printed 149.0.7827.201 while running the M152 build).
• CI: gate on every core build (and on fingerprint-catalog changes) before publish.
• Pre-launch (runtime): a fast subset (C1–C5) validates a profile’s identity before profile.start; failures flag the launch low-trust (FINGERPRINT_CONFIG_CONTRACT §6), never silently shipped.

8. Quiet mode — the headed probes without the windows (B68)

run-consistency never shows a window: the scoring suite is headless by design (§7). What appears on the operator’s desktop by the hundred are the headed launches — the integration tests’ harness (probe_fonts*, screen_metrics, headers_ua_ch, engine_baseline, …) and the headed self-characterization (capture_suite(…, headless = false)). All nine of those launch sites go through one helper, vflin_consistency::quiet::launch_headed, and that is where quiet mode lives.

Switch: on by default on Windows since B70 (2026-09-03); VFLIN_SUITE_QUIET=0 turns it off, =1 is still accepted; non-Windows: always off (focus guard is Windows-only, the occlusion feature is Chrome’s Windows tracker, and an off-screen window on X11/Wayland was never measured — CI on ubuntu launches as before). It became the default because B69 measured that without it the harness loses: both faces of ISSUE-148 are page-visibility conditions a hidden or occluded harness window triggers, and quiet mode keeps the page visible by construction — 160/160 on B67’s sample against 158/160 and 159/160. The product launch path (launch.rs) never sees any of this: the operator’s own profiles open on screen exactly as before.

What it does, each part forced by a measurement (worklog/core.md §B68):

What it must not change, and does not: window size (outerWidth/outerHeight = the claimed available area, ISSUE-062 — the provider sizes it, quiet mode only positions it), visibilityState, rAF cadence, and every check. Measured on the built M149 core: 20 of 20 quiet runs of the C6 instrument byte-identical to the normal baseline on every screen/avail/outer/inner row; the whole headed Signals object differs between modes by nothing beyond its own noise floor (observed_ja3); run-consistency 31 of 31 checks identical, 7 deep, Pass in both modes.

What it cannot fully hide, stated as measured: a flash on ~41 % of launches (one to three frames: the window is created at 0,0 by the provider and moved at first sight — creating it off-screen instead changes innerWidth by 16 px and is refused), and focus refusals in bursts (5 of 20 runs keep the foreground for up to 1.5 s on a few launches). In sampler terms: a harness window visible in ~5 % of samples (normal mode ~32 %).

Every quiet launch prints one [quiet] … line naming what happened (moved before/after shown, push-backs, focus taken/returned or never taken), so a series can be audited from its log. A failure to launch still answers under B67’s names (launch-port-timeout, cdp-connect-refused, …) — quiet mode adds no new failure kind.

9. The stock leg over a DevTools port (A119, W30)

Stock Chrome turns the automation tell on for an EPHEMERAL DevTools port — --remote-debugging-port=0 is the shape ChromeDriver launches with, and Chromium keys AutomationControlled on it (our core stops that with 0035; stock keeps it). Measured A119 on the installed stock 153.0.8010.53, --headless=new, a fresh profile per leg, read with Runtime.evaluate and no Runtime.enable:

(A dedicated worker reads undefined in all three — workers carry no webdriver.)

The rule. A stock CONTROL leg read by anything that looks at automation — a detector page, the suite’s A5 — is never launched on port=0 alone — nor on the pipe alone, which raises it too (B98). It takes a named port, the provider’s counter-flag (headless only: headed, the flag hangs Chromium’s kBadFlags bar and shortens the viewport), or a plain launch with an injected reporter (W30’s method). A reading that did not is labelled “via port=0: webdriver true” and is not a stock baseline for automation tells. A probe that measures something webdriver does not move (fonts, voices, the audio sum) is not affected.

Where the legs stand. The Rust suite (run-consistency, quic_probe) reads stock over port=0 WITH the counter-flag — chromium_command gives it to every core that does not keep the tell off itself, on the port as on the pipe, and launch.rs’s test now holds the port leg to it — so A5 reads false, as the product does (the product launches over the pipe with the same flag). core/scripts/detector-visit.mjs since B98 (ISSUE-303) launches every leg on a free port it names (--transport named, the default), with no counter-flag — headed, the flag would hang the bad-flags bar and shorten the viewport; --transport pipe|port0 remain only to reproduce an old reading. Our core keeps the tell off on every transport (0035).

Open questions

Probe sources stability/ToS, exact THRESHOLD, headless harness (Playwright vs raw CDP), how to run probes against a not-yet-published core, trust-score formula → OPEN_QUESTIONS.md.