Browser fin­ger­prin­ting: nozioni di base e opzioni di pro­te­zio­ne

Dal 2010 anche in Italia è previsto che sul pas­sa­por­to siano presenti le impronte digitali, ga­ran­ten­do in questo modo che, in com­bi­na­zio­ne con la foto bio­me­tri­ca, sia possibile associare in maniera univoca un pas­sa­por­to al suo pro­prie­ta­rio. Mentre con una normale foto sussiste teo­ri­ca­men­te il rischio che qualcuno che vi somiglia ed è entrato in possesso del vostro documento finga di essere voi, essendo l’impronta digitale unica, uno scenario simile è da escludere.

Il browser fin­ger­print (in italiano “impronta digitale del browser“) non si distingue però per questa sua unicità, ma permette comunque di ri­co­no­sce­re un utente web con un’efficacia pari a oltre l‘80 percento, e questo sebbene la ri­le­va­zio­ne di queste impronte digitali funzioni in­te­ra­men­te senza servirsi di cookie. Per questo motivo i marketer e i gestori dei siti uti­liz­za­no sempre più spesso la va­lu­ta­zio­ne delle tracce del browser per seguire gli utenti online e impiegare i risultati ai fini dell’ot­ti­miz­za­zio­ne del sito o per la pia­ni­fi­ca­zio­ne di pub­bli­ci­tà mirata.

Per poter ri­chia­ma­re i contenuti da un server avete bisogno di un client. Così ricorrete ad esempio a un client di posta elet­tro­ni­ca per re­cu­pe­ra­re i messaggi dal mail server. Invece, l’accesso a un web server avviene con i browser più co­no­sciu­ti, come Mozilla Firefox, Safari o Google Chrome. Tramite il pro­to­col­lo HTTP queste ap­pli­ca­zio­ni ri­chie­do­no i dati dai siti per farli vi­sua­liz­za­re agli utenti. La tra­smis­sio­ne dei contenuti avviene tramite i pacchetti IP, che con­ten­go­no, oltre ai dati di utilizzo, anche le in­for­ma­zio­ni sul client e che possono essere uti­liz­za­te dal server per in­di­vi­dua­re l’impronta digitale del browser.

Si di­stin­guo­no es­sen­zial­men­te due tipi di browser fin­ger­prin­ting:

• Fin­ger­prin­ting passivo: con il co­sid­det­to fin­ger­prin­ting passivo si intende la raccolta delle in­for­ma­zio­ni del browser, che vengono acquisite senza l’uso di un’ap­pli­ca­zio­ne in par­ti­co­la­re. In questo caso si tratta di in­for­ma­zio­ni che sono contenute come da standard nei dati dell’in­te­sta­zio­ne dei pacchetti IP e rag­giun­go­no così il web server. Rientrano tra queste in­for­ma­zio­ni anche l’indirizzo IP, la porta uti­liz­za­ta e il tipo di browser. Ma si an­no­ve­ra­no anche le con­fi­gu­ra­zio­ni es­sen­zia­li, come i tipi di dati de­si­de­ra­ti (HTML, XHTML, XML), i set di caratteri (ad esempio UTF-8) e le lingue (di solito la lingua del browser o del sistema operativo). Inoltre l’header HTTP fornisce in alcuni casi anche in­for­ma­zio­ni sul sistema operativo uti­liz­za­to e la pagina di pro­ve­nien­za.

• Fin­ger­prin­ting attivo: nel fin­ger­prin­ting attivo il browser richiede in modo mirato delle in­for­ma­zio­ni che non vengono fornite au­to­ma­ti­ca­men­te al momento di ri­chia­ma­re una risorsa web. Questa richiesta avviene ad esempio con ap­pli­ca­zio­ni Ja­va­Script o plug-in, che ampliano la fun­zio­na­li­tà del browser (in par­ti­co­la­re Adobe Flash e Microsoft Sil­ver­light). In questo modo si possono acquisire delle in­for­ma­zio­ni avanzate sul browser, ma anche altri dettagli esau­rien­ti sul sistema operativo, così come sullo schermo (larghezza, altezza, ri­so­lu­zio­ne) dell’utente. Altri dati for­ni­sco­no ad esempio in­for­ma­zio­ni sui tipi di font in­stal­la­ti o sul fuso orario in cui si trova l’utente.

Come già men­zio­na­to, l’impronta digitale del browser serve a iden­ti­fi­ca­re un utente per poterlo in seguito ri­co­no­sce­re nuo­va­men­te. In questo modo è possibile osservare il suo com­por­ta­men­to di na­vi­ga­zio­ne per acquisire co­no­scen­ze sulla fun­zio­na­li­tà e l’usabilità del proprio progetto web o poter far vi­sua­liz­za­re contenuti per­so­na­liz­za­ti a questo utente. Ov­via­men­te il vi­si­ta­to­re della pagina non deve ac­cor­ger­si del browser fin­ger­prin­ting, cosa che in una variante passiva non rap­pre­sen­ta nessun problema, visto che i dati devono sempre essere trasmessi per ogni richiesta e salvati lato server.

Queste in­for­ma­zio­ni trasmesse au­to­ma­ti­ca­men­te mancano spesso di efficacia. In par­ti­co­la­re l’indirizzo IP, la cui me­mo­riz­za­zio­ne risulta pro­ble­ma­ti­ca anche per motivi legali, e le porte TCP uti­liz­za­te non possono sod­di­sfa­re appieno il loro ruolo come ca­rat­te­ri­sti­ca decisiva dell’impronta digitale per due motivi:

1. As­se­gna­zio­ne di indirizzo dinamica: chi si collega a Internet, dif­fi­cil­men­te riceverà dal suo provider un indirizzo IP fisso e per­ma­nen­te. Ogni volta otterrà un IP nuovo e dinamico dal pool degli indirizzi di­spo­ni­bi­li. Un indirizzo IP concreto può quindi sempre essere assegnato a un di­spo­si­ti­vo solo per uno specifico arco di tempo. Quando esat­ta­men­te un di­spo­si­ti­vo riceve un nuovo indirizzo Internet lo sanno però solo gli utenti e il suo provider.
   
   
2. Netzwork Address Trans­la­tion (NAT): ancora più pro­ble­ma­ti­co diventa quando si utilizza la NAT (in italiano “tra­du­zio­ne degli indirizzi di rete”). Il pro­ce­di­men­to collega più di­spo­si­ti­vi su Internet con un indirizzo comune, pubblico, quindi gli utenti si dividono questo indirizzo IP. Ad esempio viene usato dai router che servono con la stessa LAN un nucleo familiare, ma anche dai provider, che con­trol­la­no in par­ti­co­la­re il settore mobile con questa tec­no­lo­gia. In questo modo può capitare che ai di­spo­si­ti­vi mobili di due diversi utenti venga assegnato lo stesso indirizzo IP.

Queste due tecniche di as­se­gna­zio­ne dell’indirizzo sono prin­ci­pal­men­te una con­se­guen­za della sempre più scarsa di­spo­ni­bi­li­tà di indirizzi IPv4. Ma visto che il suc­ces­so­re IPv6 risolverà questo problema negli anni a venire, non rimane che aspettare e vedere in che misura gli indirizzi dinamici e la NAT verranno uti­liz­za­ti in futuro. Anche le porte TCP, uti­liz­za­te da un client per la co­mu­ni­ca­zio­ne con il server, risultano essere poco adatte se uti­liz­za­te come sistema di ri­co­no­sci­men­to di un di­spo­si­ti­vo. Mentre il numero di porta di origine viene generato ca­sual­men­te per ogni richiesta, per i servizi nella rete sono sempre previsti dei numeri di porta standard pre­sta­bi­li­ti, per cui tutti i client uti­liz­za­no anche la stessa porta di de­sti­na­zio­ne. Per le richieste HTTP a un web server è ad esempio indicata la porta TCP 80.

L’header del pro­to­col­lo HTTP che, come già men­zio­na­to, viene uti­liz­za­to per la tra­smis­sio­ne dei contenuti web, non ha una di­men­sio­ne fissa, al contrario dell’header della porta TCP e dell’indirizzo IP. Oltre alla capacità di com­pren­de­re input per­so­na­liz­za­ti, vengono pre­scrit­ti diversi campi stan­dar­diz­za­ti, alcuni dei quali sono di vitale im­por­tan­za per la creazione del browser fin­ger­print. Si tratta nello specifico dei seguenti dati dell’header:

• “Referer“ (pagina di pro­ve­nien­za): se un utente giunge tramite link da una pagina A a una B, l’URL della pagina A viene trasmesso come referer al server dalla pagina B. A volte può succedere che un utente giunga alla pagina di de­sti­na­zio­ne sempre da una de­ter­mi­na­ta pagina. Allo scopo della creazione del fin­ger­print, il referer risulta quindi tanto utile quanto il parametro GET contenuto nell’URL.

• “User-Agent“ (de­scri­zio­ne del client): per ogni richiesta HTTP il relativo client fornisce so­li­ta­men­te anche una de­scri­zio­ne di sé nel campo “User-Agent”. Lì, oltre alla de­no­mi­na­zio­ne e al numero di versione, l’header HTTP offre anche spazio per un commento, che molti browser uti­liz­za­no per eseguire la piat­ta­for­ma o il sistema operativo sot­to­stan­ti.

• “Accept“ (formati di output con­sen­ti­ti): tramite il campo “Accept” il browser comunica al server quali tipi di contenuti possa elaborare e quindi quali possibili formati di output desideri. Oltre all’HTML sono richiesti so­prat­tut­to l’XHTML (Ex­ten­si­ble Hypertext Markup Language) e l’XML (Ex­ten­si­ble Markup Language). Se il campo è mancante, il client supporta tutti i tipi di contenuti.

• “Accept-Charset“ (set di caratteri ammessi): in aggiunta al formato di output il client può anche definire il set di caratteri de­si­de­ra­ti, che il server deve uti­liz­za­re per la sua risposta. In questo caso si tratta so­prat­tut­to del set UTF-8 e dello standard ISO ISO/IEC 8859-1.

• “Accept-Encoding“ (formati di com­pres­sio­ne accettati): per ot­ti­miz­za­re il tempo di ca­ri­ca­men­to di un sito web è uso comune com­pri­mer­ne i contenuti. Il browser deve di con­se­guen­za estrarre i dati compressi prima di poterli ri­pro­dur­re. Nel campo “Accept-Encoding” comunica al server con­tat­ta­to quali formati di com­pres­sio­ne supporta. La lista dei possibili pro­ce­di­men­ti, gestita da IANA, comprende anche gzip, deflate, exi e br.

• “Accept-Language“ (lingue accettate): tramite la voce HTTP “Accept-Language” i client co­mu­ni­ca­no le pre­fe­ren­ze relative alla lingua di vi­sua­liz­za­zio­ne. Quando queste sono presenti per il sito ri­chia­ma­to, il web server le fornisce. La scelta au­to­ma­ti­ca della lingua, co­sid­det­ta “forzata“, si basa sulle im­po­sta­zio­ni del browser o del sistema operativo. Le im­po­sta­zio­ni di alcuni browser offrono inoltre la pos­si­bi­li­tà di indicare ulteriori pre­fe­ren­ze di lingua.

Il fin­ger­prin­ting attivo prevede, come già intuibile dal nome, che il gestore di un progetto web richieda at­ti­va­men­te in­for­ma­zio­ni sul client. Le proprietà e i dati richiesti non risultano quindi dai dati dell’header forniti dai pacchetti del client. Visto che devono essere eseguiti a questo scopo ap­pli­ca­zio­ni sul browser, l’utente può teo­ri­ca­men­te ve­ri­fi­ca­re in qualsiasi momento se sia o meno in corso un processo di fin­ger­prin­ting, sem­pli­ce­men­te ana­liz­zan­do i pacchetti in uscita o il codice sorgente HTML o Ja­va­Script. Nella maggior parte dei casi il processo viene però tenuto nascosto ai vi­si­ta­to­ri, come succede anche nei pro­ce­di­men­ti di tracking.

Per uno scambio di dati facile e veloce tra client e server di solito si im­ple­men­ta il browser fin­ger­prin­ting attivo tramite elementi AJAX (Asyn­chro­nous JavaScript and XML). Grazie a questa tec­no­lo­gia i vi­si­ta­to­ri possono in­te­ra­gi­re con una pagina, senza che la stessa debba essere ri­ca­ri­ca­ta com­ple­ta­men­te a ogni richiesta HTTP. Per questo motivo vengono caricate in back­ground solamente le risorse richieste, mentre l’utente può con­ti­nua­re a vedere e a uti­liz­za­re tutti gli altri elementi. Le in­for­ma­zio­ni, di cui si viene a co­no­scen­za tramite i relativi script, si possono sud­di­vi­de­re in due categorie: in­for­ma­zio­ni del browser e dello schermo. Inoltre il browser fin­ger­print può essere ampliato grazie a Ja­va­Script anche di in­di­ca­zio­ni circa il fuso orario e i colori impostati del sistema.

Anche per il tracking dei colori del sistema si deve ricorrere lo­gi­ca­men­te alle im­po­sta­zio­ni del sistema operativo. Si consiglia però il supporto di CSS (Cascading Style Sheets), di modo che la funzione di Ja­va­Script get­Com­pu­ted­Sty­le(), qui ne­ces­sa­ria, possa essere re­gi­stra­ta dall’ottica scelta dall’utente per le cornici delle finestre, dei pulsanti e simili. Il lin­guag­gio di sty­le­sheet consente di creare elementi del sito, che rilevano au­to­ma­ti­ca­men­te le im­po­sta­zio­ni dei colori del sistema dei vi­si­ta­to­ri. In dettaglio si tratta di una selezione di colori per questi elementi di sistema:

• Cornice della finestra attiva (Ac­ti­ve­Bor­der)

• Testo del titolo della finestra attiva (Ac­ti­ve­Cap­tion)

• Sfondo del desktop (Back­ground)

• Testo sui pulsanti di comando (But­ton­Text)

• Bordo degli elementi 3D (Th­ree­D­Hi­ghlight)

Il web server riceve infine i relativi valori di colore, o de­no­mi­na­zio­ni dei colori del sistema, che può integrare nella creazione del fin­gre­print.

I browser sono ori­gi­na­ria­men­te stati svi­lup­pa­ti so­prat­tut­to per vi­sua­liz­za­re dei semplici documenti HTML com­pren­si­vi di singole immagini. Con il passare del tempo i requisiti dei client sono no­te­vol­men­te aumentati per via dei sempre più complessi progetti web: oltre ai formati mul­ti­me­dia­li, come file audio e video, si sono affermati ve­lo­ce­men­te anche elementi in­te­rat­ti­vi. Gli svi­lup­pa­to­ri hanno dovuto ampliare la gamma di funzioni delle ap­pli­ca­zio­ni per per­met­te­re al browser di poter ri­pro­dur­re questi diversi contenuti: questo avviene tramite plug-in. Con l’aiuto di Ja­va­script si possono ve­ri­fi­ca­re e usare i plug-in in­stal­la­ti per la de­ter­mi­na­zio­ne del browser fin­ger­print.

L’ap­pli­ca­zio­ne Ja­va­Script prova quindi in un primo passaggio a creare un nuovo oggetto ActiveX (funziona solo su Internet Explorer), che in caso di successo comunica il numero di versione e lo inoltra. Se questo processo non va a buon fine, lo script ricorre all’oggetto mimeTypes, che è già su­bor­di­na­to all’oggetto navigator in­tro­dot­to. Lo stesso è in grado di in­di­vi­dua­re tutti i formati di file sup­por­ta­ti dal browser e di ri­pro­dur­re i plug-in (navigator.plugins). Nell’ambito dello script uti­liz­za­to si riceve una risposta se ci si imbatte in Shockwave Flash o in Shockwave Flash 2.0.

Come già accennato, la prima parte dello script prova a uti­liz­za­re un oggetto ActiveX per di­mo­stra­re la presenza di Microsoft Sil­ver­light. Per questo motivo sono elencate nell’array “v“ le tre versioni correnti del plug-in (dati ag­gior­na­ti a maggio 2017). L’elenco è la base per la funzione “isVer­sion­Sup­por­ted“, che re­sti­tui­sce per la cor­ri­spon­den­te versione il valore “true“ (coincide) o il valore “false“ (non coincide), a seconda che il client ve­ri­fi­ca­to lo supporti o meno. Se gli elementi ActiveX non vengono sup­por­ta­ti, lo script analizza invece l’oggetto navigator.plugins.

L’oggetto su­bor­di­na­to a navigator “plugins“ viene ana­liz­za­to quindi con questo script dei plug-in in­stal­la­ti, com­pren­si­vi di nome (“name“), de­scri­zio­ne (“de­scrip­tion“) e nome del file (“filename“).

Allo stesso modo si possono anche ana­liz­za­re tutti i formati che il ri­spet­ti­vo client supporta per il browser fin­ger­print. Infatti al riguardo ci sono delle dif­fe­ren­ze, ad esempio su diversi di­spo­si­ti­vi, per cui i valori acquisiti possono con­tri­bui­re in molti casi alla spe­ci­fi­ca­zio­ne dell’impronta digitale. Al posto dell’oggetto “plugins” lo script deve però ricorrere al già citato oggetto “mimeTypes”:

Come già men­zio­na­to, grazie ai linguaggi CSS e Ja­va­Script si può ve­ri­fi­ca­re in modo mirato se dei font precisi sono in­stal­la­ti sul sistema operativo del client indagato. Sapere quali font sono presenti è in­te­res­san­te per vari motivi, che in parte vanno persino oltre la semplice in­di­vi­dua­zio­ne dell’impronta digitale del browser. Dare uno sguardo ai font può rivelare le seguenti nozioni:

• in­di­vi­dua­zio­ne del software uti­liz­za­to per in­stal­la­re il relativo/i relativi font, come Microsoft Office o Adobe Creative Cloud;

• in­di­vi­dua­zio­ne del software uti­liz­za­to per creare un proprio font (ad esempio la propria cal­li­gra­fia);

• con­clu­sio­ni sulle pre­fe­ren­ze e sugli interessi degli utenti del client, ad esempio per quanto riguarda i font delle sezioni, i logo e i set di caratteri specifici di un tema.

Il breve elenco mostra che queste analisi del font non con­tri­bui­sco­no solo alla spe­ci­fi­ca­zio­ne dell’impronta digitale del browser, ma può essere anche utile per la creazione di campagne pub­bli­ci­ta­rie mirate. Na­tu­ral­men­te, più i font in­stal­la­ti sono diffusi, più si potranno rag­giun­ge­re dei migliori risultati nell’analisi. Mentre con il CSS si possono sempre in­di­vi­dua­re dei singoli font, con l’ap­pli­ca­zio­ne flash (.swf) e la funzione di Ja­va­Script re­cei­ve­Fon­ts() è possibile ri­chia­ma­re ed elencare la gamma completa di font. Il codice ne­ces­sa­rio dell’oggetto flash (Ac­tion­Script) si presenta così:

L’in­te­gra­zio­ne nel documento HTML avviene con questo codice che va aggiunto nella sezione body:

I servizi web, come i social media, prevedono di solito che l’utente disponga di un account utente specifico e abbia ef­fet­tua­to con questo l’accesso alla piat­ta­for­ma. So­li­ta­men­te infatti, la maggior parte delle risorse messe a di­spo­si­zio­ne dal servizio rimane nascosta a chi non effettua il login. Questa con­di­zio­ne risulta par­ti­co­lar­men­te fa­vo­re­vo­le per la creazione del browser fin­ger­print. A questo scopo basta che sia nota una risorsa del servizio, a cui possono accedere solo gli utenti re­gi­stra­ti, e che viene inserita nell’ambito di un elemento DOM nel progetto web da ve­ri­fi­ca­re.

In questo caso il tipo di elemento ha un valore di secondo piano, perché i com­po­nen­ti decisivi, gli eventi onload() e onerror(), possono essere inseriti in in­nu­me­re­vo­li parti HTML, come <img />,<frame /> o <script />. Là vengono svin­co­la­ti, quando la risorsa collegata è stata caricata o nel caso in cui non fosse stato possibile caricarla, motivo per il quale il web server riceve una cor­ri­spon­den­te notifica. Si genera un elemento <img> esem­pli­fi­ca­ti­vo, che verifica lo stato del login su Twitter, con le seguenti righe di codice, anche se si dovrebbe fare at­ten­zio­ne al fatto che l’URL può cambiare in ogni momento:

Ora vi mostriamo quali pos­si­bi­li­tà di tracking di vasta portata offre un browser fin­ger­print ben concepito, e quanto ve­lo­ce­men­te riesca a ri­co­no­sce­re e a risalire agli utenti senza servirsi di cookie. Sono pochi quelli che sanno quanto ef­fet­ti­va­men­te unica sia l’impronta digitale lasciata dal proprio browser. Per scoprirlo ci sono diversi tool web come AmIUnique o Pa­nop­ti­click, con i quali si può testare con un clic l’unicità del browser fin­ger­print. Se quindi volete fare chiarezza e testare il vostro browser con il so­pra­ci­ta­to AmIUnique, basterà aprire il servizio tramite l’omonimo servizio web amiunique.org e cliccare sul pulsante “View my browser fin­ger­print”. Qui il vostro browser verrà ve­ri­fi­ca­to at­tra­ver­so una com­pa­ra­zio­ne con oltre 370.000 altri browser (dati ag­gior­na­ti a maggio 2017).

I valori appena pre­sen­ta­ti non sono però gli unici dati del browser fin­ger­print che questo tool va a ve­ri­fi­ca­re. Con i pulsanti “Click here” o “View more details” arrivate infatti al riepilogo generale det­ta­glia­to di tutte le in­for­ma­zio­ni che hanno con­tri­bui­to alla de­ter­mi­na­zio­ne dell’unicità. Qui trovate anche i valori spiegati nella guida, come i tipi di contenuti accettati, i metodi di com­pres­sio­ne possibili, la ri­so­lu­zio­ne dello schermo o l’ac­cet­ta­zio­ne dei cookie.

Non si può impedire com­ple­ta­men­te che l’impronta digitale del vostro browser venga in­di­vi­dua­ta, infatti nel fin­ger­prin­ting passivo l’am­mi­ni­stra­to­re del web server riceve in ogni caso au­to­ma­ti­ca­men­te i dati trasmessi nell’header HTTP. Potete però provare a mantenere il più basso possibile il valore di ri­co­no­sci­men­to del vostro client, di modo che l’impronta digitale non sia unica e quindi non uti­liz­za­bi­le per il tracking. La soluzione più semplice è usare un’esten­sio­ne del browser, che blocca au­to­ma­ti­ca­men­te i contenuti attivi come le ap­pli­ca­zio­ni Ja­va­Script, Flash o Sil­ver­light, anche se lo­gi­ca­men­te questi non potranno poi inoltrare in­for­ma­zio­ni al server. Questi plug-in tra cui ad esempio rientrano NoScript per Firefox o Scrip­tSa­fe rap­pre­sen­ta­no anche una pro­te­zio­ne ottimale contro il sempre più uti­liz­za­to canvas fin­ger­prin­ting. Questa sot­to­spe­cie di browser fin­ger­prin­ting tenta di tracciare in modo mirato il client tramite l’uso di elementi canvas. Così viene sfruttato il fatto che il rendering del testo in questi elementi varia molto a seconda del sistema operativo, del browser, della scheda grafica, dei driver e dei font. Se attivate dei plug-in di questo tipo, dovete però tenere a mente che dei precisi servizi web o almeno dei singoli contenuti non fun­zio­ne­ran­no più. Le esten­sio­ni con­sen­to­no perciò di applicare dei filtri ai contenuti o ai siti in modo mirato, per so­spen­de­re il blocco dello script, anche se è meno utile, quando si è insicuri sull’af­fi­da­bi­li­tà del pro­dut­to­re. Inoltre bisogna fare presente che l’utilizzo di un simile blocco è comunque un dato che andrà a comparire nell’impronta digitale del browser stesso. Oltre alla soluzione con il blocco dello script, non vi resta altro da fare che ri­nun­cia­re alle per­so­na­liz­za­zio­ni del sistema e del browser. Optate quindi per un browser uti­liz­za­to fre­quen­te­men­te (come ad esempio Firefox) e at­te­ne­te­vi il più possibile alle im­po­sta­zio­ni standard. Lo stesso vale ov­via­men­te anche per il sistema operativo uti­liz­za­to. Inoltre se ri­nun­cia­te a esten­sio­ni ag­giun­ti­ve per il vostro client, avete buone pos­si­bi­li­tà di evitare di generare un’impronta digitale unica e siete quindi ben equi­pag­gia­ti contro il pro­ce­di­men­to di tracking. Gli utenti di smart­pho­ne godono invece di una maggiore sicurezza, spe­cial­men­te se uti­liz­za­no modelli più datati, grazie al fatto che at­tual­men­te sugli smart­pho­ne esistono poche pos­si­bi­li­tà di per­so­na­liz­za­zio­ne.