Fraud and abuse often come down to one question: is this the same device we saw before, or a device that is trying hard to look like someone else? WhiskerJS measures the browser and device and hands you the result. It never says “fraud” or “not fraud”. These pages show, problem by problem, which parts of that result are worth looking at and what your own server has to do with them.
The parts of a result you will use
Every use case below draws on the same four parts of one collect() result:
| Part | What it gives you | Read more |
|---|---|---|
visitorId |
one 128-bit hash over the 37 stable components: an exact-match key for a browser setup | Identifiers |
structuredId |
seven short hashes, one per signal group, so you can see which part of a device changed | Comparing two results |
integrityFlags |
names of checks that saw signs of automation or changed browser functions | Integrity checks |
binding |
your server’s nonce and timestamp, bound to the result with a digest, so an old result cannot be replayed | Anti-replay binding |
The 46 components are there too, each with a status and, when not ok, a reason code. They let you explain a decision later and compare devices signal by signal. See Signals.
The problems
What is the same in every case
- Signals, not verdicts. WhiskerJS has no scoring code. A rule or model on your server weighs the result together with account history, request headers, the IP address and velocity.
- A browser setup, not a person. Two identical devices with identical settings can share a visitorId, and one person with two browsers has two. Treat an id as evidence about a device, never as proof of who is behind it.
- Anything from the client can be faked. The integrity checks catch careless tools and the binding stops replay, but a determined attacker can send a hand-made result. Never let the result alone grant access or money. See What never to trust from the client.
- Versions matter. Compare ids only within the same
signalsVersionandidVersion. Store both with every id. - Privacy still applies. Device signals can be personal data. Read Privacy and compliance before you deploy.
No accuracy figures yet
None of these pages gives detection rates, false-positive rates or uniqueness figures for WhiskerJS, because none has been measured. A head-to-head measurement against other libraries has not run yet. The only observations so far are an early, small sample at signalsVersion 1 (four device and browser pairs, each kept one id across a few runs), which is not a benchmark. Measure on your own traffic before you rely on any rule.
Questions and answers
Does WhiskerJS stop fraud on its own?
No. WhiskerJS is a collector: it returns signals, two identifiers and integrity flags. Your server combines them with what it already knows (accounts, history, request data) and makes the decision.
Which use case should I start with?
Start where a device signal adds something you do not already have, usually at login or sign-up. Store the result per event first, look at your own traffic, then add rules.
Are there accuracy figures for these use cases?
Not yet. No head-to-head measurement of WhiskerJS has run, so these pages describe what each part of the result means, not how well it performs.