Skip to main content

​
Privacy & data handling

ShieldLabs identifies visitors as entities, not named individuals. The snippet collects technical attributes of the browser, device, and network connection and posts them to the server, which derives the identifiers (VisitorID, DeviceID) and a Risk Score and delivers those to your backend. It never asks for, sees, or stores who the person actually is. This page describes what is and is not collected and how you stay in control of the data. For transport, key, and webhook-verification practices, see Security.
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.

​
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.
CategoryExamplesUsed for
Browser fingerprintCanvas, WebGL, audio, fonts, screen, navigator (user agent, platform, languages, vendor)Deriving the durable DeviceID
Device and OSBrowser name, operating system, device type, timezoneIdentification and mismatch checks
NetworkIP address (read server-side from the connection), connection type, VPN/proxy/Tor/datacenter indicators, WebRTC real-IP discoveryAnonymity detection and signals
Page contextThe current page URL (with the #fragment stripped) and the referrerTraffic source attribution
Client-side idsA first-party cookieID and a sessionID, both minted by the snippetLinking calls from the same browser and visit
The full inventory is roughly 100+ browser, device, and network signals. See Signals for the scoring reference and How it works for the end-to-end flow.

​
What ShieldLabs does NOT collect

ShieldLabs has no field for, and never asks for, any of the following:
  • Names, emails, or phone numbers.
  • Passwords. No site-user credentials are read or stored.
  • Payment data. No card numbers, no bank details.
  • Form field contents. The snippet does not read what a visitor types.
  • Full browsing history. Only the current page URL and the referrer are captured, for traffic attribution.
A ShieldLabs identity answers “is this the same browser/device as before, and how anonymous is this connection?” It does not answer “who is this person?” Visitors are entities described by a VisitorID and a DeviceID, not named accounts.

​
UserHID: you supply it, and it must be pseudonymous

UserHID is the one field that comes from you, not from the browser. It is your own account id, passed into the snippet so ShieldLabs can correlate a logged-in user’s activity across visits and devices.
Always pass a hashed or pseudonymous value. Never pass a raw email, username, or account id. ShieldLabs does not need to know who your user is, only that two requests belong to the same internal account. A one-way hash gives you that link without ever sending us a real identifier.
// Hash your internal user id before passing it in.
const enc = new TextEncoder().encode(currentUser.id);
const digest = await crypto.subtle.digest("SHA-256", enc);
const hashedId = [...new Uint8Array(digest)]
  .map((b) => b.toString(16).padStart(2, "0"))
  .join("");

const mod = await import(
  "https://cdn.shieldlabs.ai/snippet.js?publicKey=YOUR_PUBLIC_KEY"
);
mod.checkAuthenticatedUser(hashedId);
The same hashing applies to forceCheckAuthenticatedUser. When you call checkAnonymous, no user id is sent at all (the UserHID defaults to anonymous). See the snippet reference for the full client API.

​
WebRtcHIP is a hash, not a raw IP

During identification the snippet runs a WebRTC real-IP check to spot a masked connection (see Anonymity detection). The result that reaches you is WebRtcHIP, a hash of the discovered IP, kept only for correlation. It is not the raw real IP, and it cannot be reversed to deanonymize the visitor.
  • WebRtcHIP lets you tell whether two requests came through the same hidden network without exposing the underlying address.
  • It appears in the History API snapshot and on the dashboard. The raw WebRTC IP is not sent in the webhook body.
  • The connection’s public IP is captured server-side from the request and used to derive location and reputation signals.

​
Client-side storage

To recognize a returning browser without a server round trip, the snippet keeps two values in the visitor’s own browser:
ValueWhere it livesLifetime
cookieIDA first-party cookie and localStorage (SameSite=Lax, Secure on HTTPS)2 years, lost when the visitor clears cookies or site storage
sessionIDsessionStorageThe current visit (a 10-minute window)
Both are random UUIDs minted on the visitor’s device. They are first-party only. The durable DeviceID 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. See Identifiers for how the ids relate.

​
You control retention

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

Export

Filter the Data table on the dashboard and export the matching records as CSV or JSON. Exports are free and do not consume requests.

Read programmatically

Pull snapshots for any identifier through the History API, keyed by IP, UserHID, VisitorID, RequestID, or DeviceID.
To request deletion of stored records, or for any other data-handling question, contact privacy@shieldlabs.ai.

​
Data minimization in practice

The design choices above all point the same way: collect the technical signals needed to identify a browser and score anonymity, and nothing that identifies a person.
  • Identifiers are derived (DeviceID, VisitorID) or pseudonymous (UserHID, supplied hashed by you), never tied to a name or email by ShieldLabs.
  • The real WebRTC IP reaches you only as a hash (WebRtcHIP).
  • 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.
  • Identifiers: how RequestID, DeviceID, VisitorID, and UserHID are built and how durable each one is.
  • Signals: the full signal and scoring reference.
  • Management API: export and query your stored snapshots.