Il fingerprinting del canvas oltre le basi: perché due Chrome identici renderizzano pixel diversi

Il fingerprinting del canvas è in uso in produzione dal 2012. L'idea è semplice: chiedere al browser di renderizzare contenuto 2D, rileggere i pixel e calcolarne l'hash. Dispositivi diversi producono pixel leggermente diversi a parità di istruzioni, e quelle differenze sono abbastanza stabili da identificare un dispositivo tra le sessioni.

Fin qui, nulla di nuovo. Ciò che è meno compreso è perché la tecnica funziona — perché configurazioni software identiche su hardware identico producono comunque output di pixel diversi. La risposta sta all'intersezione tra driver della GPU, rendering dei font e aritmetica in virgola mobile.

La pipeline di rendering non è deterministica

Quando JavaScript chiama context.fillText("Cwm fjord bank glyphs vext quiz", 4, 45), Chrome non renderizza i pixel da sé. Genera istruzioni per Skia — la libreria grafica 2D — che a sua volta invia comandi di disegno a un backend accelerato dalla GPU (di solito ANGLE su Windows, Metal su macOS o il fallback software nei container).

A ogni passaggio si accumulano piccole differenze di implementazione:

• Il sottosistema font di Skia seleziona una famiglia di font. Se Arial non è installato, ricorre a un fallback — e il fallback varia in base ai font installati nel sistema.

• Il font selezionato viene renderizzato alla dimensione richiesta usando FreeType (su Linux), DirectWrite (su Windows) o Core Text (su macOS). Ogni libreria ha algoritmi di hinting diversi.

• Viene applicato il posizionamento subpixel. È qui che font identici iniziano a produrre pixel diversi — l'algoritmo arrotonda le posizioni a offset frazionari di pixel, e le regole di arrotondamento differiscono tra le piattaforme.

• Il testo rasterizzato viene composto sul canvas. Il blending avviene tramite shader della GPU sui sistemi con accelerazione hardware, e tramite codice CPU in modalità fallback.

Ognuno di questi passaggi può introdurre differenze di uno o due valori di pixel. Singolarmente invisibili. Collettivamente uniche.

Le versioni dei driver della GPU dominano il fingerprint

Due macchine Windows 11 con chip Intel UHD Graphics 620 possono produrre output del canvas diversi se i loro driver della GPU differiscono. Intel rilascia aggiornamenti dei driver più volte l'anno, e ogni aggiornamento può cambiare il filtraggio subpixel, la correzione gamma e l'anti-aliasing del testo.

Questo significa che la stabilità del fingerprint del canvas è limitata dalla frequenza di aggiornamento dei driver. Un utente che aggiorna il driver grafico — spesso silenziosamente, tramite Windows Update — vedrà cambiare il proprio fingerprint del canvas.

I sistemi di rilevamento gestiscono la cosa trattando il fingerprint del canvas come uno dei tanti segnali, non come identificatore a sé stante. Quando cambia ma gli altri segnali restano stabili (fingerprint TLS, renderer WebGL, fuso orario, font installati), il visitatore viene comunque riconosciuto.

Il rendering delle emoji è una miniera d'oro

L'elemento più identificante di un fingerprint del canvas spesso non è il testo né le forme, ma le emoji. Il rendering delle emoji dipende dal font emoji fornito con il sistema operativo — Segoe UI Emoji su Windows, Apple Color Emoji su macOS, Noto Color Emoji su Android.

Anche all'interno di uno stesso OS, il rendering delle emoji cambia tra le versioni. Il rendering dell'emoji arcobaleno in Windows 10 differisce da quello di Windows 11. La faccina sorridente di iOS 16 ha un anti-aliasing diverso da quella di iOS 17.

Gli script moderni di fingerprinting del canvas renderizzano appositamente sequenze di emoji che includono le aggiunte più recenti a Unicode. Un visitatore che dichiara di usare Safari su iPhone ma non riesce a renderizzare un'emoji introdotta in iOS 17 sta usando un iOS più vecchio — o mente sulla piattaforma.

I framework di automazione producono fingerprint riconoscibili

Chrome headless, in esecuzione in un container Docker senza GPU, usa SwiftShader per il rendering. SwiftShader produce output del canvas internamente coerenti ma distinti da qualsiasi Chrome con accelerazione hardware.

La firma è riconoscibile: anti-aliasing insolitamente pulito, valori di colore specifici nelle regioni con gradienti e bordi del testo che non corrispondono a nessun driver GPU noto. Un fingerprint del canvas che corrisponde a SwiftShader in Chrome 124 in un container Linux è quasi certamente automazione — nessun utente reale usa un browser in questo modo.

Puppeteer-extra-stealth tenta di falsificare l'output del canvas intercettando toDataURL() e restituendo dati modificati. Ma la modifica introduce spesso artefatti propri — pattern di rumore che si ripetono tra le sessioni e che, paradossalmente, rendono lo sforzo di anti-fingerprinting più rilevabile del non fare nulla.

Perché l'iniezione di rumore non funziona bene

I browser orientati alla privacy come Brave iniettano rumore nell'output del canvas per impedire il tracciamento. L'idea è aggiungere piccole variazioni casuali ai valori dei pixel, così che lo stesso dispositivo produca fingerprint diversi a ogni sessione.

In pratica, l'iniezione di rumore ha tre problemi:

1. Il rumore stesso è un fingerprint. Un visitatore il cui output del canvas cambia a ogni caricamento, ma i cui altri segnali restano identici, è riconoscibile come un browser che inietta rumore. E questo è di per sé identificante.

2. L'algoritmo del rumore è stabile. L'implementazione di Brave produce pattern di rumore specifici che non corrispondono alla varianza naturale del rendering della GPU. I sistemi di rilevamento possono distinguere gli output del canvas che sembrano alterati dal rumore da quelli che sembrano naturali.

3. I sistemi sofisticati combinano i campioni. Più rendering sulla stessa pagina, o tra sessioni diverse, possono essere mediati. Se il rumore è piccolo, la media converge sul fingerprint deterministico sottostante.

Che cosa cattura il fingerprinting del canvas

Oltre all'ovvio output visivo, il fingerprinting del canvas può estrarre diversi attributi del dispositivo come effetti collaterali:

Tempo di rendering — il tempo che il canvas impiega a renderizzare rivela la capacità della GPU. Un desktop 4K con GPU dedicata renderizza più velocemente di un laptop di fascia media.

Metriche del testo — measureText() restituisce larghezze esatte in pixel che variano in base al rendering dei font. La larghezza del testo può essere usata come fingerprint anche senza rendering.

Supporto delle operazioni di compositing — alcuni browser o configurazioni GPU supportano modalità di compositing estese. Testarne il supporto rivela i confini delle capacità.

Effetti filtro — i filtri in stile CSS applicati al canvas producono output diversi tra le GPU, in particolare i filtri blur e drop-shadow.

Dove si colloca il fingerprinting del canvas in uno stack di rilevamento

Da solo, il fingerprinting del canvas non è un identificatore robusto. I driver cambiano. Gli utenti cambiano browser. L'iniezione di rumore è comune nel pubblico attento alla privacy.

La sua vera forza è come controllo incrociato. Quando una sessione dichiara di essere un utente di ritorno sulla base di cookie o del login all'account, il fingerprint del canvas agisce da secondo segnale — la corrispondenza con il fingerprint storico conferma la dichiarazione, la discrepanza segnala furto di account o hijacking della sessione.

Per il rilevamento dei bot, il fingerprinting del canvas eccelle nell'intercettare l'automazione containerizzata. Gli utenti reali hanno GPU reali. Le GPU reali producono firme di rendering riconoscibili. Tutto ciò che renderizza come SwiftShader, o come un canvas mal falsificato, finisce nella categoria «quasi certamente bot».

La tecnica del 2012 funziona ancora nel 2026 per la stessa ragione: il rendering è deterministico per ambiente ma quasi impossibile da falsificare del tutto. Ogni tentativo di nascondersi lascia tracce del tentativo stesso.