Ho già scritto in via generale in merito all’implementazione italiana della normativa europea sui cookie, nota come EU Cookielaw, nel mio blog iltecnico.info. Voglio però affrontare in questa sede l’argomento da un punto di vista un po’ più tecnico.

Una regolamentazione che mira ad intervenire in un settore complesso e dinamico come internet non può prescindere dallo stato dell’arte della tecnologia per raggiungere gli scopi che si prefigge. Scopi che, peraltro, andrebbero perseguiti con un sano pragmatismo di cui fatico a vedere le tracce negli eventi di questi giorni.

Ma partiamo da un punto di partenza. Cosa è un cookie?
Tecnicamente è un meccanismo per memorizzare localmente nel browser piccole quantità di informazione. La sua prima definizione ufficiale è stata fatta nella Request for comments RFC2109 (RFC sono i documenti tecnici che regolamentano internet) del febbraio 1997 con il titolo Meccanismo per la gestione degli stati del protocollo HTTP. Lo scopo era quello di creare un sistema che consentisse al web, nato originariamente con finalità puramente passive di consultazione, di muoversi verso l’interattività verso gli utenti. Il cookie era uno strumento fondamentale per questa evoluzione.
L’idea di un meccanismo di memorizzazione locale nacque nell’implementazione di uno dei primi sistemi di commercio elettronico. Per tenere traccia degli oggetti da acquistare, il cosiddetto carrello, ogni volta che aggiungiamo una voce viene creato un cookie contenente la scelta dell’utente. Al termine, al passaggio per la cassa, è possibile rileggere questi cookie ed elaborare l’acquisto.
I cookie, quindi, sono alla base uno strumento tecnico, finalizzati a gestire una persistenza, temporanea e locale, di dati tutt’altro che personali.

Come recita il vecchio detto, però, l’occasione fa l’uomo ladro. Nonostante nella loro definizione fossero stati previsti dei meccanismi per limitarne l’abuso – ad esempio, un cookie può essere letto solo da chi l’ha emesso e non da terzi – i biscottini sono stati sempre più frequentemente con finalità ben diverse da quelle originali. E quello più remunerativo è l’uso di profilazione: un cookie persistente viene utilizzato per identificare un particolare terminale e, indirettamente, un utente. E’ ben noto come la profilazione sia una tecnica largamente utilizzata in ambito commerciale.
Come però dice lo stesso Garante nel suo provvedimento, «non vi sono delle caratteristiche tecniche che li differenziano gli uni dagli altri sulla base delle finalità perseguite da chi li utilizza». Aggiungo che non c’è alcuna necessità di avere cookie specifici, complessi o multipli, per fare profilazione. Basta un solo cookie contenente un valore arbitrario, purchè univoco per chi lo emette, per assolvere egregiamente a tale funzione. Anzi, tecnicamente è addirittura possibile utilizzare tecniche steganografiche per nascondere questo codice: ad esempio, è possibile senza problemi mascherarlo all’interno della data di validità di un cookie vuoto, che così apparirebbe del tutto innocuo ed inutile.

Ma cosa prevede la normativa italiana? Può essere utile a comprendere cosa impone con l’infografica apparsa qualche giorno fa sul sito istituzionale del Garante.

Le casistiche sono stranamente sei, nonostante il provvedimento preveda solo tre tipologie: i cookie tecnici, di profilazione e di terze parti.

Dal punto di vista del principio, la logica del Garante non fa una grinza. I cookie di profilazione sono quelli che sono usati per creare profili dell’utente. Per questi è richiesta una prassi burocratica per la comunicazione al Garante, nonchè la richiesta di consenso, revocabile, da parte dei singoli utenti. I cookie tecnici sono quelli non utilizzati a scopo di profilazione. Sono cioé quelli finalizzati a gestire la navigazione, lo scopo originale degli estensori della RFC2109. In questo caso c’è sostanzialmente solo da inserire una informativa che comunichi all’utente il fatto che il sito fa uso di cookie.

La confusione nasce sui cookie di terze parti. Questi non sono rilasciati dal sito che si visita in un dato momento, ma da servizi accessori (sociali o multimediali, ad esempio) esterni ad esso. Se visitate una pagina contenente un video di youtube vi ritroverete sistematicamente con un set di cookie firmati .youtube.com anche senza visualizzare nemmeno un fotogramma.
Questi cookie terzi sono totalmente al di fuori del controllo del sito che visitate, che peraltro non è nemmeno in grado di leggerli. Proprio per questo il Garante ha deciso che, vista l’indeterminazione, ogni sito che li ospita, cioè al giorno d’oggi virtualmente tutti, non solo debba esporre il fatidico banner, ma debba anche bloccarli sino all’acquisizione del consenso.
In questo modo, però, oltre a complicare inutilmente la vita a tantissime piccole realtà, si ottiene un effetto Cassandra: massive richieste di autorizzazione faranno passare inosservate quelle che realmente richiederebbero attenzione.

Confusione che si fa ancora più grande in tema cookie analytics. Sono in generale dei cookie utilizzati ai fini statistici di analisi del traffico di un sito Web (Web Analitics), da non confondere con il quasi omonimo servizio di Google.
Le statistiche anonime sono un elemento fondamentale della gestione di un sito, ma sono anche uno strumento che può essere utilizzato ai fini commerciali e di profilazione. Anche qui, la differenza non è tecnica, ma di finalità di uso. La normativa precisa, a tal fine, che se un sito utilizza cookie analytics che sono sotto il controllo diretto dal gestore del sito, sono da considerarsi tecnici (comma 1, punto a).

La stragrande maggioranza dei piccoli siti web, però, fa uso del servizio gratuito di Google Analytics. Nei giorni a cavallo dell’entrata in vigore della normativa si è cominciata a spargere la voce che i cookie di questo servizio, anche se di terze parti, potevano essere assimilati ai cookie tecnici, se depurati dall’indicazione dell’IP del visitatore. Anche se nella normativa non c’è nulla che suffraghi questa interpretazione, in una successiva precisazione il Garante ha chiarito la posizione, dicendo che sono effettivamente da considerare tecnici qualora «a) siano adottati strumenti che riducono il potere identificativo dei cookie (ad esempio tramite il mascheramento di porzioni significative dell’IP); b) la terza parte si impegna a non incrociare  le informazioni contenute nei cookies con altre di cui già dispone.»

Il punto a) è però del tutto privo di alcun senso tecnico. Come abbiamo visto prima, il potere identificativo di un cookie è intrinseco: è sufficiente un semplice e banale codice, arbitrario purchè univoco. Mascherare l’IP è puerile, perchè ogni server web deve avere questa informazione per potere espletare la sua funzione, che è ricavabile autonomamente server-side senza necessità di scrivere o leggere qualcosa da o verso il terminale dell’utente. Questa pagina di esempio non fa profilazione, non memorizza nulla, non usa cookie di alcun tipo, non ha codice client-side, ma è comunque in grado di visualizzare alcune informazioni relative all’utente.

Perchè mascherare l’IP lato browser rende il cookie analytics tecnico, se la stessa informazione è già disponibile lato server e quindi può essere letta senza alcuna limitazione?

Quello di funzionale che rimane è la parte b), ovvero l‘impegno della terza parte a non profilare. Ma, mi chiedo, che senso ha prevedere questo approccio semplificato al problema per i soli cookie analytics e non in toto per i cookie di terze parti?

E, cosa più importante, perchè questo accanimento sui i cookie, quando questi non sono per nulla l’unico o il principale sistema utilizzato nel mondo del web per fare profilazione?
Al giorno d’oggi esistono sistemi tecnologicamente più sofisticati, e quindi potenzialmente più pericolosi per la nostra privacy, per ottenere lo stesso risultato.

L’ultima incarnazione del linguaggio del web, Html5, ad esempio prevede quattro diversi sistemi per memorizzare informazioni sul terminale dell’utente: local storage, indexedDb, file Api, application cache. A differenza dei cookie non sono limitati a piccoli frammenti di testo, ma consentono di conservare localmente dati di tipologia e di dimensioni arbitrarie. In più normalmente i browser non includono nativamente strumenti per gestire i dati memorizzati, così come frequentemente la cancellazione della cache di navigazione non elimina i dati in essi contenuti: è necessario ricorrere a plugin specifici. Questo li rende potenzialmente molto più pericolosi per la privacy dei vecchi cookie.

Un altro sistema di memorizzazione è costituito dai Local Shared Object  (LSO) di Adobe Flash. Anche questi consentono la memorizzazione di oggetti diversi dai frammenti di testo, anche se in questo caso la loro dimensione non è illimitata.  Ma questa è un limite che, ovviamente, non costituisce un problema dal punto di vista della profilazione. Anche gli LSO non sono gestibili direttamente all’interno dei browser. Il plugin installa però una apposita voce nel pannello di controllo del sistema operativo, da cui è possibile gestirne il comportamento ed eliminare gli oggetti indesiderati.

Anche l’equivalente Microsoft di Flash, Silverlight, ha a disposizione un sistema analogo, denominato Isolated Storage. La memorizzazione in questo caso è fatta a livello di utente e non di browser. Questo fa sì che i valori memorizzati in quest’area siano accessibili indipendentemente da quale sia il browser con cui siano stati memorizzati, anche questo fatto negativo per la nostra privacy. Silverlight non ha un pannello di controllo e la rimozione può essere complessa per un utente non preparato, visto che fisicamente sono memorizzati in un albero di directory protetto di ogni utente.

Un altra possibilità di identificazione è data dagli oggetti della cache, la memoria tampone utilizzata per conservare temporaneamente gli elementi scaricati dal web. E’ possibile utilizzare questa caratteristica per fare scaricare al browser uno script personalizzato, che può rimamenere in questa area potenzialmente a tempo indeterminato.  Questo script può poi essere utilizzato nelle pagine web per identificare il navigatore. L’unica protezione da questa metodologia è la cancellazione periodica della cache, visto che la disabilitazione inciderebbe molto negativamente sulla velocità di navigazione. Questa tipologia di profilazione, peraltro, temo non rientri in quelle previste dall’articolo 122 del codice delle comunicazioni, perchè non effettua esplicitamente una ‘memorizzazione’ di dati all’interno del terminale dell’utente, ma sfrutta una caratteristica intrinseca del sistema, che è una sorta di vulnerabilità.

Una ulteriore possibilità è data dal meccanismo di gestione della cache. Come ho detto precedentemente, la cache è una memoria tampone che evita di scaricare più volte un oggetto da internet se questo non è stato modificato. Per sapere se l’oggetto è aggiornato o no vi sono due tecniche, una basata sulla data di aggiornamento, ed un’altra legata ad un valore chiamato E-tag. Il comportamento di questo meccanismo è del tutto analogo a quello di un cookie. Il risultato è che è possibile sfruttare l’E-tag di un qualsiali elemento di una pagina, come ad esempio una icona, per ottenere un valore arbitrario alla stessa stregua di un cookie. Anche in questo caso valgono le considerazioni fatte per gli oggetti della cache.

Ancora più interessante è la possibilità di sfruttare i certificati digitali utilizzati nelle connessioni HTTPS. La sicurezza della connessione delle connessioni https è infatti basata su dei documenti elettronici, i certificati, che sono utilizzati per crittografare il traffico in transito. La loro univocità può essere indirettamente utilizzata come una impronta elettronica in grado di identificare univocamente il terminale del cliente, peraltro senza alcun intervento o attività da parte dell’utente.
Può essere questo il motivo che spinge alcuni grossi fornitori di servizio a spingere ad utilizzare massivamente il protocollo https, più pesante in termini di risorse e prestazioni, in luogo del normale http, anche quando una sicurezza maggiore è del tutto superflua?

Così come del tutto prive di invasività lato client sono le tecniche di device fingerprints, che hanno lo scopo di costruire un profilo del terminale dell’utente analizzando alcune delle caratteristiche che sono liberamente accessibili lato web, e senza alterare minimamente l’ambiente dell’utente. Un esempio ce lo da la EFF, Electronic Frontier Foundation, un gruppo statunitense da sempre attivo nel campo dei diritti dei cittadini, su un sito accessibile all’URL Panopticlick. Le tecniche utilizzabili, in quest’area, sono potenzialmente numerosissime, e spesso utilizzano vulnerabilità o debolezze di progetto, come testimoniato in questo documento dell’Università della California, San Diego relativo all’uso identificativo dei canvas di html5.

L’elenco potrebbe continuare, ma credo che questa rapida carrellata su alcuni dei sistemi di profilazione che possono essere (e probabilmente sono) professionalmente usati in ambito web per raccogliere dati sui frequentatori dei siti faccia comprendere che sotto il profilo tecnico il provvedimento del garante non scalfisce nemmeno il problema, creando invece confusione ed incertezze inutili e dannose.

Nel mondo concreto ci sono tantissimi oggetti che sono potenzialmente pericolosissimi, ma che sono comunemente utilizzati per scopi banali ed ordinari. Un coltello comunemente utilizzato per tagliare le cipolle può diventare un’arma mortale, ciò nonostante nella vita di tutti i giorni l’uso di tali armi potenziali è regolamentato principalmente dal buon senso.

L’approccio di stabilire delle norme tecniche, che personalmente ritengo fumose, per regolamentare una materia così complessa e di rapida evoluzione è per me totalmente sbagliato. Sarebbe stato più semplice e lineare una norma che pragmaticamente richiedesse a chiunque raccolga dati dell’utente a scopo di profilazione commerciale di sottostare alle norme previste, senza scendere in dettagli tecnici, di estendere tale obbligo anche ai terzi che utilizzino i loro servizi, lasciando il resto del mondo (web) in pace.

Mi pare una soluzione facile da comprendere e semplice da implementare, senza peraltro presentare differenze rilevanti dal punto di vista tecnico di verifica di attuazione con quella attuale.

Ma forse è chiedere troppo dalla burocrazia.