Device Intelligence

Device fingerprinting is one technique. Device intelligence is the discipline. A fingerprint is a single signature derived from the browser environment. Device intelligence layers that fingerprint together with network analysis, risk signals, and cross-layer mismatch detection to produce a full profile: a persistent DeviceID plus an explainable Risk Score and the signals behind it, all returned in one server response. In short: browser fingerprinting is a component of device intelligence, not the whole thing.

ShieldLabs is web and JavaScript only. There is no native mobile SDK, and there is no VM, emulator, root, jailbreak, or bot detection. Everything on this page describes a browser running the ShieldLabs snippet.

Fingerprinting vs. intelligence

Device fingerprinting

One technique. Reads stable browser components (canvas, WebGL, audio, fonts, screen, navigator, timezone, and more) and reduces them to a single signature.

The full discipline. Fingerprint + network analysis + risk signals + mismatch detection, returned as a persistent DeviceID plus the Risk Score and the signals that fired.

The output of device intelligence is not just an ID. It is an ID and a signal set, delivered together:

You get	What it is
DeviceID	A persistent identifier derived from the browser environment. See Identifiers.
Risk Score (0-100)	An explainable score with a `Details` array naming every signal that fired. See Risk Score.
Signals	The underlying anonymity and mismatch signals (VPN, proxy, anti-detect, OS mismatch, and more). See Signals.

You never call a separate “fingerprint” endpoint and a separate “risk” endpoint. One snippet collects the signals, the server scores them, and the result arrives by webhook (and is readable via the History API). See How it works.

How the DeviceID is derived

The DeviceID is computed server-side. The browser never computes it. The ShieldLabs snippet collects dozens of stable browser-fingerprint components and posts them to the server. Shield.Core then derives the DeviceID as a UUID5 hash of the sorted, stable components. The same browser environment always hashes to the same DeviceID.

DeviceID = UUID5( namespace, sorted stable components )

The stable components include (at the category level):

Rendering: canvas, WebGL, audio, client rectangles, font rendering
Fonts and text: available fonts, font preferences
Display: screen resolution, color depth, color gamut, HDR, pixel ratio
Navigator and locale: platform, languages, vendor, timezone, Intl, math
Capabilities and APIs: storage APIs, media capabilities, touch support, CSS support

Volatile components that change too often to be useful (for example speech-synthesis voices and storage quota) are deliberately excluded from the derivation, so the DeviceID stays stable across normal browsing.

We collect these at the category level. The docs do not publish the exact component count or the precise hashing internals. “Dozens of stable browser components” is the accurate framing.

Why the DeviceID is durable

Because the DeviceID is derived from the browser environment rather than stored in the browser, it survives the things that break cookie-based tracking:

Survives cookie clear

Clearing cookies and local storage does not change the browser environment, so the DeviceID is unchanged.

Survives incognito

A private or incognito window hashes the same stable components to the same DeviceID.

Survives IP rotation

Switching networks or rotating IPs does not touch the fingerprint, so the DeviceID holds.

Browser-bound

A different browser produces different components and therefore a different DeviceID. There is no cross-browser recognition today.

This is the opposite of the CookieID and VisitorID, which are stored client-side and regenerate when storage is cleared. The durability claim belongs to the DeviceID alone. The full mechanics, including how VisitorID = UUID5(DeviceID + CookieID) is built, live in Identifiers.

Be honest about the boundary. The DeviceID is browser-bound: the same person on a different browser counts as a different device. ShieldLabs does not recognize the same person across two different browsers today.

Catching anti-detect browsers and spoofing

A fingerprint on its own can be faked. Anti-detect browsers and fingerprint-spoofing tools exist specifically to forge a clean-looking browser signature. Device intelligence catches them by cross-layer mismatch: it compares what the browser claims against what the network and local environment show. When those layers disagree, the spoof is visible even though the fingerprint looks plausible on its own.

Cross-layer check	What disagreement reveals
OS Mismatch	The OS the browser claims does not match the OS the network fingerprint shows.
Anti-detect Browser	Local and behavioral indicators consistent with anti-detect or fingerprint-spoofing tooling.
IP Mismatch	The public IP does not match the IP derived from the real-IP (WebRTC) check.
Timezone Mismatch	The browser timezone does not match the timezone of the IP.

These signals feed the Risk Score with the same explainable Details as every other signal. ShieldLabs surfaces the mismatch and the points it contributed. The decision to allow, challenge, review, or block stays in your application code. See Acting on the Risk Score.

For the full list of anonymity and connection signals (Tor, VPN, Privacy Relay, datacenter, proxy, and the rest), see Anonymity detection. For every signal and its weight, see Signals.

What it does not do

To set accurate expectations:

No native mobile SDK

Device intelligence runs in the browser via a JavaScript snippet loaded from the CDN. There is no iOS or Android native SDK. See Install the snippet.

No VM, emulator, root, or jailbreak detection

These require native or OS-level access that a browser snippet does not have. ShieldLabs does not claim them.

No bot detection

ShieldLabs is visitor identification, anonymity detection, and abuse and fraud signals. It is not a bot-detection product. Automated or scripted activity may show up as a downstream symptom in Abuse patterns, but the product does not frame itself as bot detection.

No automatic blocking

ShieldLabs scores. Your code decides. The DeviceID and signals are inputs to your own allow, challenge, review, or block logic. There is no in-product rules engine.

Next steps

Identifiers

How DeviceID, VisitorID, CookieID, SessionID, UserHID, and RequestID are made and how durable each one is.

Anonymity detection

VPN, proxy, Tor, Private Relay, and datacenter detection, including the VPN 2-of-3 corroboration rule.

Signals

Every signal, its weight, and what it means for the Risk Score.

Risk Score

The 0-100 explainable score, the Clean / Low / Medium / High bands, and recommended actions.

​Fingerprinting vs. intelligence

Device fingerprinting