How the scan works
The scan collects evidence from your browser and from the network connection, then looks for contradictions. A real device tells one consistent story. Bots, anti-detect browsers, emulators and proxies usually get some details wrong.
Verdicts
| Verdict | Meaning |
|---|---|
| REAL | The evidence is consistent. Risk score below 0.30. |
| SUSPICIOUS | Meaningful anomalies. Risk score 0.30–0.70. Worth a closer look, but not proof of fraud. |
| FAKE · HIGH RISK | Strong evidence: risk score 0.70 or more, or a decisive signal such as an automation flag or a headless browser. |
| UNKNOWN | Fewer than half of the browser probes could run, so no reliable judgement is possible. |
Scoring
Every check reports a status, the evidence it saw, a weight (how much the finding matters) and a confidence (how sure we are). Checks feed one or more risk families: bot, device risk, proxy, VPN, Tor, datacenter, location spoofing, multi-accounting and IP reputation. Within a family the findings combine as a noisy-OR:
family = 1 − Π (1 − weight × confidence)
The families then combine the same way, each with its own importance, into the overall risk score. One weak mismatch therefore stays low. Several independent mismatches add up quickly. A few signals that are practically never seen on real users are decisive: navigator.webdriver, automation-framework globals, a HeadlessChrome User-Agent, or a crawler User-Agent.
What is checked
| Area | Signals |
|---|---|
| Automation | WebDriver flag in the page, iframe and worker; Selenium/ChromeDriver, Puppeteer, Playwright, PhantomJS and Cypress artifacts; headless User-Agent and Client Hints; an attached DevTools Protocol client; injected evaluation scripts; headless traits (zero window size, empty plugins and languages, the permission quirk). |
| Behaviour | Mouse, click, keyboard, touch, scroll and clipboard counts; untrusted (script-dispatched) events; mouse-stroke straightness and speed variance; typing rhythm and key-hold time; clicks without pointer movement. The report updates as you interact. |
| Browser consistency | User-Agent header vs JavaScript; Client Hints vs User-Agent; actual JavaScript engine (V8 / SpiderMonkey / JavaScriptCore) vs the claimed browser; navigator.platform vs claimed OS; Accept-Language vs navigator.languages; the headers a real browser always sends. |
| Cross-context consistency | The same properties read inside a Web Worker and a fresh iframe; native-function integrity (does the getter reject a foreign receiver, is it still native code); properties planted on navigator/screen; internal timezone consistency. |
| Device | Canvas, WebGL and audio fingerprints rendered twice plus known-value tests (exposes noise injection); software or VM GPUs; GPU vs OS (for example an Apple GPU on "Windows"); WebGPU vs WebGL; installed fonts vs OS; speech voices vs OS; CPU and memory plausibility; screen geometry; touch support vs mobile claim; timer precision; clock skew. |
| IP & network | IP intelligence (ISP, ASN, connection type, location); Tor exit list; official AWS, Google Cloud, Oracle, DigitalOcean, Linode and Cloudflare ranges; VPN, proxy and hosting flags from two providers; hosting and VPN network names; reverse DNS; proxy headers; abuse feeds and newly registered networks; registry vs location; WebRTC true-IP leak; device timezone and languages vs IP location; network latency vs distance; optional GPS vs IP. |
| Session history | Returning device; the same device under many visitor IDs (storage resets); one visitor ID across many fingerprints; IP rotation and countries per device; many devices per IP; impossible travel between sessions; how risky earlier scans from the same /24 were. |
Identifiers
- Device ID — a hash of stable hardware and rendering properties (canvas, WebGL, audio, fonts, screen, timezone, CPU). It ignores the browser version and survives cleared cookies and private windows.
- Browser ID — the device ID plus browser-specific details such as the User-Agent and plugins.
- Visitor ID — a random ID stored in a first-party cookie and localStorage.
Limitations — read this
- No TLS/JA4 or TCP/IP fingerprinting. Those need control of the TLS terminator or raw packet capture, which standard PHP hosting does not provide. Commercial services use them to catch HTTP clients that imitate browsers.
- Residential and mobile proxies route traffic through real home or phone connections. They are hard to identify from the IP alone; timezone, language, WebRTC and latency checks are the main defence.
- IP geolocation is approximate and sometimes wrong, especially for mobile carriers.
- Privacy tools look like spoofing. Brave, Tor Browser, Firefox resistFingerprinting and anti-tracking extensions randomize or block fingerprints. Where we can recognise them (Brave, coarse timers), the penalty is reduced, but such users may still score Suspicious.
- Open DevTools triggers the CDP check, the same as automation would.
- Session history only covers scans on this site in the last 30 days.
- Heuristics can be wrong. A verdict is evidence to weigh, not an accusation.