Browser support

ShieldLabs runs as a single JavaScript snippet, so it works wherever a modern browser does. The same code path runs on Chrome, Firefox, and Safari alike, and the same browser keeps its DeviceID across repeat visits. The product is web only. There is no native mobile SDK and no npm package today, only the snippet loaded from the CDN. Mobile web browsers are fully supported.

​

Supported browsers

The snippet recognizes every mainstream desktop and mobile browser. Identification (the DeviceID and VisitorID) runs the same way in all of them: a visitor returning in the same browser keeps the same DeviceID. The DeviceID is derived from the rendered browser environment, so a different browser engine renders those inputs differently and produces a different DeviceID for the same person. What also varies by engine is how many anonymity signals each one exposes. Other Chromium-based browsers, such as Vivaldi and Yandex Browser, are recognized and identify the same way. A browser that reports an unfamiliar user agent still gets a DeviceID. It is simply labeled as unknown rather than by name.

​

The three engines

Browsers come and go, but they share three rendering engines. ShieldLabs groups support by engine, because that is what actually determines which signals are available.

• Chromium powers Chrome, Edge, Brave, Opera, Samsung Internet, Vivaldi, and Yandex. It exposes the fullest set of Network Intelligence and anti-detect signals.
• Gecko powers Firefox. The identification mechanism is the same, though the engine renders its inputs differently. A few anonymity signals are collected through a different path and may contribute fewer entries to the Risk Score.
• WebKit powers Safari on every Apple platform. The mechanism is the same here too. Signal coverage is closer to Gecko than to Chromium.

The takeaway: the DeviceID is stable for a given browser, and signal coverage varies by engine. Because the engine renders the inputs the DeviceID is built from, the same person on two different engines (say Chrome and Safari) gets two different DeviceIDs, while the same browser on repeat visits stays constant.

​

How persistence behaves per browser

Browsers differ most in how long they keep first-party cookies and site storage. That matters because two identifiers depend on storage and one does not.

• DeviceID is derived on the server from dozens of stable browser and device characteristics. Nothing about it is stored in the browser, so no privacy setting can expire it.
• VisitorID is built from the DeviceID combined with the cookie-based CookieID. When a browser clears or shortens cookie storage, the CookieID resets and a new VisitorID is minted.

So privacy defaults reset the VisitorID but leave the durable DeviceID intact, as the full identifier model lays out.

​

Safari

Safari is privacy hardened by default. Apple caps the lifetime of script-writable storage and first-party cookies set by JavaScript, so the CookieID expires sooner than on other browsers.

• Affects the VisitorID. A returning Safari visitor whose cookie storage has expired gets a fresh CookieID, and therefore a fresh VisitorID.
• Does not affect the DeviceID. The DeviceID is derived, not stored, so the same Safari user keeps the same DeviceID across visits. This is why returning visitors are not miscounted as new.

This applies to desktop and mobile Safari, and to any browser on iOS, since they all share WebKit.

​

Brave

Brave is a Chromium browser with strict privacy protections built in. For ShieldLabs purposes it behaves like Chrome running an aggressive ad and tracker blocker.

• Brave may block the snippet host or randomize some browser attributes.
• Identification still works once the snippet host is allowed, one of the steps for keeping accuracy high below.
• Some anonymity signals may contribute fewer entries when attributes are randomized. The DeviceID remains stable.

​

Incognito and private mode

Private and incognito windows are fully supported. A private window is the same browser on the same machine, so the DeviceID is stable across normal and private sessions on that browser.

​

Keeping identification accuracy high

A few setup choices keep accuracy as high as possible, especially on privacy-hardened browsers.

• Allow the snippet host. Make sure cdn.shieldlabs.ai and the data endpoints are not blocked by an ad blocker or a Content Security Policy. A blocked snippet collects nothing. When the fingerprint is blocked or JavaScript is disabled, no characteristics reach the server, so the DeviceID comes back all-zero (00000000-0000-0000-0000-000000000000) rather than a real identity. Treat an all-zero DeviceID as “nothing collected,” not as a returning visitor.
• Keep first-party storage available. Clearing or stripping cookies does not change the DeviceID, but it does reset the VisitorID and visit counts. Leave first-party storage in place where you can.
• Pass a hashed UserHID for signed-in users. Once a visitor logs in, call the checkAuthenticatedUser export with a hashed account id. This ties anonymous activity to a known account across visits and browsers.
• Use the framework integration. The React, Vue, Angular, Preact, Svelte, and native-JS wrappers all load the same module from the CDN. They keep the import in your app code where it is easy to maintain.

​

Mobile and platforms

Mobile web is a first-class target. The snippet runs in mobile Chrome, mobile Safari, Samsung Internet, and other mobile browsers exactly as it does on desktop. There is no native mobile SDK today. ShieldLabs identifies users inside the mobile browser, not inside a native app. A WebView that runs standard browser JavaScript can load the snippet, but a fully native app screen has no browser context to collect from.

​

Next steps