Browser fingerprinting

What this check does

Scans the loaded scripts and runtime behavior for known fingerprinting techniques:

• Commercial SDKs — FingerprintJS Pro (fpjs.io, api.fpjs.io, metrics.<your-domain> CNAMEs), ThreatMetrix, IPQS, SEON.
• Canvas API abuse — calls to canvas.toDataURL() or getImageData() on hidden, off-screen, or OffscreenCanvas elements right after rendering a fixed string.
• WebGL probes — reading WEBGL_debug_renderer_info (GPU vendor/renderer strings) without a visible 3D context.
• AudioContext fingerprinting — instantiating an OfflineAudioContext, running an oscillator, and hashing the buffer.
• Font enumeration — measuring widths of test strings across hundreds of font-families to detect what’s installed.

MetricSpot maintains an allow-list for common analytics SDKs (GA4, Plausible, Fathom) that touch some of these APIs benignly, so the check fires only when the pattern matches active fingerprinting.

Why it matters

Regulators have closed the “it’s not a cookie so consent doesn’t apply” loophole. The EDPB’s 2023 guidelines on Art. 5(3) ePrivacy treat any client-side technique that reads or writes information from a user’s device — fingerprinting included — as requiring the same prior, informed, opt-in consent as cookies. The CNIL, ICO, and DPC have echoed this.

That means a fingerprinting script firing before the visitor accepts your cookie consent banner is the same compliance violation as setting a _ga cookie before consent — and enforcement is active. The CNIL fined Criteo €40M in 2023 partly on this basis.

Beyond the legal angle: fingerprinting identifies users across sessions and across the network. If a third-party SDK leaks the fingerprint, you’ve helped build a shadow profile of every visitor.

How to fix it

This is a detection rule, not a config flag. The fix is to audit what’s running and gate it behind consent.

1. Inventory. Open DevTools → Network → filter by Initiator and look for the scripts MetricSpot flagged. Trace each back to a tag manager rule or an <script> in your template. If you don’t know why it’s there, it shouldn’t be there.

2. Decide if you need it. Fraud detection on a checkout page may justify FingerprintJS Pro. A marketing landing page almost never does. The EDPB carve-out for “strictly necessary” is narrow — security and fraud prevention can qualify, analytics enrichment does not.

3. Gate it behind consent. If you keep the script, load it only after the user opts in. With a CMP (OneTrust, Cookiebot, Iubenda, Klaro):

<!-- Don't load directly -->
<script src="https://fpjs.io/web/v3/<key>/loader.js"></script>

<!-- Gate via CMP - example: Klaro -->
<script type="text/plain" data-name="fingerprintjs"
        src="https://fpjs.io/web/v3/<key>/loader.js"></script>

Then in your klaro-config.js:

services: [{
  name: "fingerprintjs",
  purposes: ["security"],
  required: false,
  default: false,
}]

4. Server-side detection. If a vendor offers a server-side SDK (FingerprintJS Pro’s serverApi), prefer that on authenticated routes — it stays inside your first-party trust boundary and is easier to audit.

5. Document it. Update your privacy policy to name the vendor, the purpose (“payment fraud prevention”), the data collected, and the retention period. Generic boilerplate is not enough.

Pair this with the third-party trackers check — both rules examine the same script inventory from different angles.

Frequently asked questions

Is “cookieless tracking” legal in the EU?

No, not without consent. The marketing pitch that cookieless = consent-free is wrong under the current EDPB interpretation. The trigger for consent is reading or writing from the device, regardless of mechanism.

What about server-side analytics like Plausible or Fathom?

Those are fine. They derive a daily-rotating hash from the IP + user-agent on the server, never store it, and don’t probe client-side APIs. MetricSpot’s allow-list excludes them.

My fraud team needs FingerprintJS on the checkout. Can I keep it?

Likely yes, scoped narrowly: load it only on /checkout and /login, document the security purpose in your privacy policy, and rely on the EDPB’s “strictly necessary for a service explicitly requested by the user” exception. Get sign-off from counsel — the boundary is jurisdiction-specific.