The problem with collecting in the open

Client-side detection has an obvious weakness: the page runs on the adversary’s machine. If your collection logic is sitting in the open as readable code, a determined attacker can study exactly which signals you look at and feed your code whatever values they want. Claims to be a normal browser? Faked. The signals you measure? Quietly rewritten. The collector turns into a form the bot fills in with whatever it likes.

You can scramble the code to slow this down, but that only buys time — the page still belongs to the attacker, and anything running in the open can be watched and rewritten from the same place.

KHAN VM: move the floor

The KHAN VM raises the cost. Instead of exposing collection as readable code on the page, Noxtica runs it inside a sealed, sandboxed runtime — so the logic that decides what to measure isn’t sitting in the open for an attacker to read and rewrite.

What that buys:

The logic isn’t readable. The collection program runs inside the sandbox, not as source on the page. An attacker can’t simply read it to learn which signals it samples and how it cross-checks them.
A narrower surface to tamper with. The interesting work happens inside the sealed boundary. Someone tampering with the page is now one step removed from the logic that decides what to read.
Sealed output. The result is sealed and bound to a single request before it ever leaves the browser. A faked or replayed submission simply won’t verify on the server — the output is tied to this request, not reusable across others.

How it fits the request

The page asks for a short-lived, single-use credential, which the server issues fresh for that visit.
The KHAN VM runs, samples its signals, and produces a result sealed against that credential.
The collector submits it; the server checks that the result was genuinely produced for this request. Anything that wasn’t won’t open.

Each request gets its own protection, so even if one were compromised, it tells an attacker nothing about the next.

What it is — and isn’t

The KHAN VM relies on a browser capability that a site enables with a small security-policy setting. Where it isn’t available, Noxtica falls back gracefully to standard collection rather than failing the request — tamper-resistance is an added tier, not a hard requirement.

And it’s honest about its boundary. The KHAN VM makes spoofing the collection expensive. It does not defend against an attacker who fully controls the page, or who intercepts everything before the runtime even starts — if the adversary owns the document, no client-side sandbox saves you. That’s a server-trust and application-security problem, not a fingerprinting one.

Why a sandbox instead of “more scrambling”

Scrambling scales linearly with attacker effort — they unpick it once and they’re done. A sealed, sandboxed runtime with single-request output changes the shape of the attack: it’s no longer “read the code and lie,” it’s “reverse-engineer a sealed runtime and forge cryptographically-bound output, on every single request.” That’s a different budget. For the high-volume, low-margin automation behind most abuse, it simply isn’t worth it — which is exactly the outcome a detection layer is supposed to produce.