Privacy & data handling

ShieldLabs connects pseudonymous users and visitors with the devices and IP addresses observed in each identification. Devices and IP addresses are anchors on an identification. Users are your accounts, known to ShieldLabs only by the hashed User HID you pass. The snippet collects technical attributes of the browser, device and network connection and posts them to the server, which derives the Device ID and Visitor ID and a Risk Score for each identification and delivers them to your backend. Keep the account token pseudonymous and keep personal data out of page URLs and referrers. This page describes what is and is not collected and how you stay in control of the data. Transport, key, and webhook-verification practices live on the Security page.

This page describes data handling factually. It is not legal advice and makes no regulatory compliance claim. How you disclose ShieldLabs in your own privacy policy, and on what legal basis you process this data, is your decision to make with your own counsel. For the formal document, see the Privacy Policy, the Terms of Service, and the Cookie & Tracking Policy.

What ShieldLabs collects

The snippet reads technical signals from the browser environment and the network connection. These are the raw inputs the server turns into identifiers and the Risk Score.

Category	Examples	Used for
Browser fingerprint	Hundreds of stable browser and device characteristics	Deriving the durable Device ID
Device and OS	Browser name, operating system, device type, timezone	Identification and mismatch checks
Network	IP address (read server-side from the connection), connection type, VPN/proxy/Tor indicators, network and connection indicators	Risk signal detection
Page context	The current page URL (with the `#fragment` stripped) and the referrer	Traffic source attribution
Client-side ids	A first-party `cookieID` and a `sessionID`, both minted by the snippet	Linking calls from the same browser and visit

ShieldLabs collects 300+ browser, device and network signals. The risk signals reference lists the public detections, including zero-weight informational flags, and How it works shows the flow end to end.

Minimize the data you send

The identification snippet collects technical device and network evidence, browser identifiers, the current page URL and referrer. It does not need form contents, passwords or payment details to run identification. URLs, query parameters, referrers and an incorrectly supplied User HID can contain personal data. Use a pseudonymous account token and avoid putting sensitive information into page URLs. Pseudonymous identifiers and IP addresses should still be handled as sensitive data.

User HID: you supply it, and it must be pseudonymous

The User HID is the one value that comes from you, not from the browser. It is your account id, hashed, passed into the snippet so ShieldLabs can link every device, visitor and IP address that signs in to the same account. Users, account-level risk and all four High-Risk Events are built on it.

Always pass a hashed or pseudonymous value. Never pass a raw email, username, or account id. ShieldLabs needs only to know that two identifications belong to the same account. Use a stable opaque token or a keyed backend transformation.

Generate a stable opaque token on your backend. For example:

Node.js

import { createHmac } from 'node:crypto';

const userHid = createHmac('sha256', process.env.USER_HID_SECRET)
  .update(String(authenticatedUser.id))
  .digest('hex');
// Send userHid to the browser; keep USER_HID_SECRET on the backend.

Pass that token to checkAuthenticatedUser. Keep its mapping stable across sessions. A plain hash of an easily guessed email or sequential ID does not make that input secret. The same hashing applies to forceCheckAuthenticatedUser. When you call checkAnonymous, no user id is sent at all (the User HID is sent as anonymous), as the full client API in the snippet reference lays out.

Two network addresses, kept distinct

ShieldLabs works with two different network addresses, and they are never mixed.

The connection’s public IP is read server-side from the request and used to derive location, reputation, and the risk signals that flag a masked connection.
The local IP is the address the browser itself reports, which can differ from the public IP when traffic runs through a VPN or proxy. It arrives on the webhook in the local_ip correlation field, with its country, and ShieldLabs links each local IP to the users, devices and visitors seen with it. The History API searches by public IP only. In the analytics dashboard, each user, device, visitor and public IP card lists its linked local IPs, with the identifications behind each.

Keep the local IP correlation field server-side. It exists for matching requests to each other, not for display, so do not surface it to your own users.

Client-side storage

To recognize a returning browser without a server round trip, the snippet keeps two values in the visitor’s own browser:

Value	Where it lives	Lifetime
`cookieID`	A first-party cookie and `localStorage` (`SameSite=Lax`, `Secure` on HTTPS)	2 years, lost when the visitor clears cookies or site storage
`sessionID`	`localStorage`	The current visit window

Both are random UUIDs minted on the visitor’s device. They are first-party only. The durable Device ID is derived server-side from the stable browser environment, not stored on the device, which is why it survives a cookie clear while the cookieID does not. The Identifiers page lays out how the ids relate.

When the snippet runs on your site

The SDK does not wait for a consent banner. Identification starts when your code calls checkAnonymous() (or the other exports). Gate the call yourself if applicable law or your policy requires prior consent, and see the warning on Install the JS Snippet. Details: Cookie & Tracking Policy §2.

Where your data is stored

ShieldLabs processes and stores identification data in its own infrastructure, in a single region. There is no per-customer data-residency or region selection today, so you cannot pin storage to a specific country or cloud. The Privacy Policy states a maximum retention of up to 12 months, subject to applicable settings. The current analytics dashboard exposes a 90-day live investigation window; this is not a promise that twelve months of history is available through the UI or API. Export required evidence while it is available. If you have a specific residency or retention requirement, email contact@shieldlabs.ai.

You control retention

Your data is yours to read, export, and remove.

Export

Filter identifications in the analytics dashboard and export them as CSV. Exports are free and never count toward your plan.

Read programmatically

Pull identifications for any identifier through the History API, keyed by User HID, Device ID, Visitor ID, IP, Identification ID, Session ID or Cookie ID.

Deletion is request-based: there is no self-serve delete endpoint today, so to remove stored records, or for any other data-handling question, email contact@shieldlabs.ai.

Data minimization in practice

The design choices above all point the same way: collect the technical signals needed to identify devices and visitors and score risk, and minimize personal data in the values your application supplies.

Identifiers are derived (Device ID, Visitor ID) or pseudonymous (User HID, supplied hashed by you), and should be kept separate from your direct account identifiers.
The public IP and the device’s local IP are kept distinct, and the local IP correlation field stays server-side.
The snippet captures the current page URL and referrer for attribution, not a browsing trail.
No passwords, payment data, or form contents are ever read.

Security: webhook signature verification, key management, and transport.
Users, devices, visitors and IPs: the identities ShieldLabs links and scores, and how they connect.
Identifiers: how the Identification ID, Device ID, Visitor ID and User HID are built and how durable each one is.
Risk signals: every risk signal and its weight.
Server API: read and export your stored identifications.

ShieldLabs

Core concepts

Detection

Bot detection

AI detection

Analytics dashboard

Security and privacy

Resources

Legal

Privacy & data handling

What ShieldLabs collects

Minimize the data you send

User HID: you supply it, and it must be pseudonymous

Two network addresses, kept distinct

Client-side storage

When the snippet runs on your site

Where your data is stored

You control retention

Export

Read programmatically

Data minimization in practice

​What ShieldLabs collects

​Minimize the data you send

​User HID: you supply it, and it must be pseudonymous

​Two network addresses, kept distinct

​Client-side storage

​When the snippet runs on your site

​Where your data is stored

​You control retention

Export

Read programmatically

​Data minimization in practice

​Related

What ShieldLabs collects

Minimize the data you send

User HID: you supply it, and it must be pseudonymous

Two network addresses, kept distinct

Client-side storage

When the snippet runs on your site

Where your data is stored

You control retention

Data minimization in practice

Related