Why KaizoCore
The threat model this was built against, and why fingerprinting alone doesn't hold up.
The problem with fingerprint-first bot detection
Most bot/fraud detection products are built around device fingerprinting: collect a bunch of stable browser signals (canvas hash, WebGL hash, screen size, fonts, TLS handshake shape) once, hash them together, and use that hash to recognize the same "device" across requests.
The problem: fingerprints are static, and static things get harvested and replayed. A commodity anti-detect browser or a fingerprint-spoofing service can hand an attacker a fingerprint that's stable, internally consistent, and looks exactly like a real device — because in some cases it is a real device's fingerprint, captured once and reused across a farm of automated sessions. Once fingerprint harvesting is cheap (and it is — this is a whole commercial category), a detection system that treats a matching fingerprint as evidence of trust is trusting exactly the thing an attacker can buy.
The KaizoCore answer: fingerprints are for correlation, not trust
This is the single invariant the whole scoring engine is built around:
A device fingerprint is used to link a session to a previously-seen bad actor. It is never used to increase trust in a session. Presence of a stable, valid-looking fingerprint earns zero points, ever.
Concretely: internal/entity/registry.go's bad-actor lookup only ever adds
risk (a fingerprint matching a known bad actor), never subtracts it. There is
no rule anywhere in the scoring engine that says "this canvas hash is stable,
therefore this session is more human." If that rule existed, it would be
exactly the thing fingerprint-harvesting tools are built to exploit.
What proves humanity, if not a fingerprint?
Two categories of evidence, both much harder to fake cheaply than a static hash:
- Continuous behavioral signal — real mouse movement has jerk, tremor, and directional entropy that scripted or replayed movement doesn't reliably reproduce under scoring. This is measured continuously (see PULSE), not once.
- Server-attested cryptographic proof of a real, recent, clean session — an ack token issued only after a session has sustained multiple clean PULSE heartbeats in a row, single-use, 30-second TTL. Replaying a captured token doesn't work; the nonce is consumed on first use.
The Golden Rule: absence of a signal is never suspicious by itself
The other invariant that shows up everywhere in the rules engine: if a
signal is missing — no mouse data because the user is on a touchscreen, no
environment fingerprint because a corporate proxy stripped it, no completed
collect() because the page loaded fast — that absence must never, by
itself, score as suspicious. Every rule that depends on optional data is
gated on that data's presence, not just its value. A rule like "no natural
idle periods" only fires once there's enough real behavioral sample to trust
the absence as meaningful, not just insufficient data.
This matters because the alternative — penalizing missing data — creates a detector that's biased against exactly the real users most likely to have thin telemetry: accessibility-tool users, slow networks, privacy-conscious browsers, and fast, confident purchasers.
Where this leaves KaizoCore vs. the field
Read How it works for the full architecture. The honest summary: KaizoCore's continuous-liveness model closes a real, disclosed gap in fingerprint-first detection (see the internal gap analysis against Castle.io's own published research on fingerprint harvesting), but it is not unbeatable — a well-resourced attacker running real, slow, attended browser sessions is still real browser traffic, and that's a different, harder problem than replaying a captured fingerprint. Every limitation KaizoCore knows about is documented, not hidden — see FAQ.