Fingerprinting del browser

Cosa verifica questo controllo

Analizza gli script caricati e il comportamento a runtime per individuare tecniche note di fingerprinting:

• SDK commerciali — FingerprintJS Pro (fpjs.io, api.fpjs.io, CNAME metrics.<tuo-dominio>), ThreatMetrix, IPQS, SEON.
• Abuso di Canvas API — chiamate a canvas.toDataURL() o getImageData() su elementi nascosti, fuori schermo o OffscreenCanvas subito dopo aver disegnato una stringa fissa.
• Sonde WebGL — lettura di WEBGL_debug_renderer_info (vendor/renderer della GPU) senza un contesto 3D visibile.
• Fingerprinting via AudioContext — istanziare un OfflineAudioContext, far girare un oscillatore e calcolare l’hash del buffer.
• Enumerazione font — misurare la larghezza di stringhe di test su centinaia di famiglie di font per dedurre quali sono installate.

MetricSpot mantiene una allow-list per gli SDK di analytics più comuni (GA4, Plausible, Fathom) che toccano alcune di queste API in modo benigno, così il controllo scatta solo quando il pattern corrisponde a fingerprinting attivo.

Perché è importante

Le autorità hanno chiuso la scappatoia del “non è un cookie quindi il consenso non si applica”. Le linee guida EDPB 2023 sull’art. 5(3) ePrivacy trattano qualunque tecnica lato client che legge o scrive informazioni dal dispositivo dell’utente — fingerprinting incluso — come soggetta allo stesso consenso preventivo, informato e opt-in dei cookie. CNIL, ICO e DPC hanno confermato.

Significa che uno script di fingerprinting eseguito prima che il visitatore accetti il tuo banner di consenso ai cookie è la stessa violazione di compliance dell’impostare un cookie _ga prima del consenso — e l’applicazione è attiva. La CNIL ha multato Criteo per 40 milioni di euro nel 2023 anche su questa base.

Oltre all’aspetto legale: il fingerprinting identifica gli utenti tra sessioni e tra siti. Se uno SDK di terze parti rivela il fingerprint, hai contribuito a costruire un profilo ombra di ogni visitatore.

Come sistemarlo

Questa è una regola di rilevamento, non un flag di configurazione. La soluzione è verificare cosa gira e metterlo dietro il consenso.

1. Inventario. Apri DevTools → Network → filtra per Initiator e cerca gli script segnalati da MetricSpot. Risali ognuno a una regola del tag manager o a uno <script> nel tuo template. Se non sai perché c’è, non dovrebbe esserci.

2. Decidi se ti serve. La rilevazione delle frodi su una pagina di checkout può giustificare FingerprintJS Pro. Una landing di marketing quasi mai. La deroga EDPB per il “strettamente necessario” è ristretta — sicurezza e prevenzione frodi possono rientrarci, l’arricchimento analitico no.

3. Mettilo dietro il consenso. Se mantieni lo script, caricalo solo dopo l’opt-in. Con una CMP (OneTrust, Cookiebot, Iubenda, Klaro):

<!-- Non caricare direttamente -->
<script src="https://fpjs.io/web/v3/<key>/loader.js"></script>

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

Poi nel tuo klaro-config.js:

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

4. Rilevazione server-side. Se un vendor offre un SDK server-side (come serverApi di FingerprintJS Pro), preferiscilo sulle rotte autenticate — resta dentro il tuo perimetro di fiducia first-party ed è più facile da auditare.

5. Documentalo. Aggiorna la tua privacy policy indicando vendor, finalità (“prevenzione frodi di pagamento”), dati raccolti e periodo di conservazione. La formula generica non basta.

Abbina questo controllo a tracker di terze parti — entrambe le regole esaminano lo stesso inventario di script da angolazioni diverse.

Domande frequenti

Il “tracking senza cookie” è legale nell’UE?

No, non senza consenso. La narrativa di marketing per cui senza cookie = senza consenso è sbagliata secondo l’attuale interpretazione EDPB. Il trigger per il consenso è leggere o scrivere sul dispositivo, indipendentemente dal meccanismo.

E le analytics server-side come Plausible o Fathom?

Vanno bene. Derivano un hash a rotazione giornaliera da IP + user-agent sul server, non lo conservano e non sondano API lato client. La allow-list di MetricSpot le esclude.

Il mio team antifrode ha bisogno di FingerprintJS al checkout. Posso tenerlo?

Probabilmente sì, in ambito ristretto: caricalo solo su /checkout e /login, documenta la finalità di sicurezza nella privacy policy e appoggiati all’eccezione EDPB “strettamente necessario per un servizio esplicitamente richiesto dall’utente”. Fatti dare l’OK dal legale — il confine dipende dalla giurisdizione.