Environment integrity

What this layer checks

The environment layer (15% of the total score — see The scoring engine) looks for evidence that the JavaScript runtime itself has been instrumented or run somewhere unexpected, independent of anything behavioral:

• JS engine tampering — whether Function.prototype.toString has been patched. Automation frameworks and some anti-detect tooling override this method to hide the fact that a function has been monkey-patched (for example, to make a spoofed navigator.webdriver getter's source look native). A patched toString is a hard, deterministic tampering signal — not a fuzzy confidence score — because there is no legitimate reason for a real browser's JS engine to lie about a function's own source.
• Iframe context mismatch — whether the collector's execution context matches what's expected for a same-origin, top-level page load.
• Worker context mismatch — similarly, whether a Web Worker context appeared where it shouldn't have.

Why this is deterministic, not probabilistic

Unlike behavioral signals, which need a genuine sample size to be trustworthy (see the completeness gate), js_engine_tampered is treated as a deterministic rule: it's exactly as reliable on a session's first request as its hundredth, so it passes through ML fusion at full value, never gated by completeness.

Gated on presence, not just outcome

All three checks are gated on EnvHasFPData — whether the client actually reported environment-integrity data at all. This matters for a subtle reason: a naive implementation might check "were any tamper flags raised," which would score a session where the check ran and found nothing identically to a session where the check never ran. That conflates "no problems found" with "we didn't look" — exactly the kind of absence-as-signal mistake the Golden Rule is built to prevent. EnvHasFPData distinguishes presence of the check from its outcome, so only genuine tampering evidence — not missing telemetry — ever contributes to the score.