Quando anche chi fa recensioni di frigoriferi inizia a proporre fantasiose interpretazioni tecniche sulla Profilazione e sugli indirizzi IP che non sarebbero dati (personali) che possono profilare, capisci che forse è arrivato il momento di fare un filo di chiarezza su cose che pensavi essere banalmente assodate almeno dal 2016 se non dal 2010…
Nel post sul Reddito di Cittadinanza chiedo come mai il Ministero abbia deciso di:
- Utilizzare in modo illecito dei componenti (inutili) sul sito web?
- Ha deciso deliberatamente di omettere questo utilizzo dalla Informativa?
- Ha deciso di utilizzare una Informativa errata creata per un sito differente?
- E perché non ha applicato il Principio di Minimizzazione del Trattamento?
- E soprattutto: perché ha deciso di regalare a DUE enti terzi i dati dei cittadini che consultano il sito per il Reddito di Cittadinanza?
Molti hanno iniziato a commentare, principalmente in modalità cinofallica, su tre argomentazioni:
- Usano solo l’indirizzo IP che non è un dato personale!1!1!!
- Non trattano i dati li tengono anonimi!1!1!1!
- Ma Google e Microsoft rispettano il GDPR1!1!1!1!
Tutto questo, ovviamente, dimostrando di non aver capito rigidamente una mazza di Profilazione, di Dato Personale, di Principio di Minimizzazione e di come in generale funziona una Informativa.
Partiamo dal principio: a quanto è dato sapere e supporre, sia Google che Microsoft trattano i dati personali in loro possesso (vedi a seguito) in modo perfettamente in linea con la normativa GDPR: se un dato personale persona potenzialmente tracciante/profilante viene dato loro si impegnano a trattarlo secondo le direttive, ma il problema è un altro, molto, molto differente.
Se infatti stiamo parlando, anche solamente nel caso dell’indirizzo IP, di un dato SICURAMENTE personale, e su di questo non ci sono dubbi – non lo dico io, lo dice direttamente il sito del Garante oltre che la Corte di Giustizia – allora è chiaro che Google e/o Microsoft devono trattarlo come tale, arrivando nel caso di Google a dichiararsi Data Controller tramite un comunicato ufficiale del Team Leader del progetto Fonts come peraltro giusto che sia.
Se questo è talmente pacifico che Google stesso si definisce Data Controller ed ammette che sono Dati Personali, il sito del Ministero non può in alcun modo esimersi dal comunicarlo agli utenti tramite Informativa, dichiarando che uno o più dati personali sono dati in gestione alla Piattaforma di Google e/o Microsoft, dati personali che (fino a modifiche della Privacy Policy che possono essere unilaterali essendo Data Controller) non vengono in questo momento utilizzati per ulteriore profilazione.
Ma oltre alla mera Informativa il problema è un po’ più grave ed esteso: il Ministero ha esplicitamente omesso di prestare attenzione al principio di Minimizzazione dei Dati Personali raccolti. Infatti dal combinato disposto degli artt. 5 e 6 del GDPR, che determinano le condizioni di liceità e le finalità della raccolta dati, si ricavano i principi generali che il titolare del trattamento deve seguire nelle raccolta dei dati personali degli utenti.
In particolar modo, il Regolamento europeo sancisce la necessità che i dati personali vengano raccolti per finalità determinate, esplicite e lecite nei limiti di quanto necessario per il raggiungimento dello scopo per i quali sono stati raccolti. L’unione di questi due principi determina la nascita del c.d. principio di minimizzazione del trattamento.
E, SICURAMENTE, il dare a terzi dati personali per non dover installare localmente una Font e un filmato non rappresenta in alcun modo una minimizzazione, ma una inutile estensione del perimetro di attori a cui tali dati personali vengono spediti.
Rimangono quindi valide le considerazioni del mio post precedente:
- Utilizzare in modo illecito dei componenti (inutili) sul sito web?
- Ha deciso deliberatamente di omettere questo utilizzo dalla Informativa?
- Ha deciso di utilizzare una Informativa errata creata per un sito differente?
- E perché non ha applicato il Principio di Minimizzazione del Trattamento?
- E soprattutto: perché ha deciso di regalare a DUE enti terzi i dati dei cittadini che consultano il sito per il Reddito di Cittadinanza?
Addendum su dday.it
Visto che state prendendo in molti fischi per fiaschi rispondo anche ad un altro articolo, quello di DDay.it, con qualche precisazione tecnica, soprattutto vista la evidente confusione del giornalista che lo ha redatto.
ADDENDUM 8 Febbraio: Questo, peraltro, alla luce della nota del Garante che non solo “sbugiarda” in toto le tesi dell’articolo in questione, ma abbraccia pienamente la tesi da me espressa (quasi ricalcandola) con la frase di cui a seguito:
“Si segnala, al riguardo, che il sito rivela, già nel suo attuale stato di sviluppo, alcune carenze, in particolare, nell’informativa sul trattamento dei dati e nelle modalità tecniche della sua implementazione (che, ad oggi, comportano un’indebita e non trasparente trasmissione a terzi dei dati di navigazione, quali indirizzi IP e orario di connessione, da parte dei visitatori del medesimo sito)”.
Dalla Nota del Garante
Colgo quindi l’occasione anche per ribattere tecnicamente, da tecnico che di queste cose se ne occupa da una dozzina di anni invece che da giornalista appassionato di tecnologia, anche alle singole affermazioni contenute in quell’articolo.
Partiamo dall’inizio (enfasi e numeri aggiunti da me):
Google nella sua pagina spiega bene la questione: l’uso delle font di Google non richiede autenticazione e nessun “cookie”, ovvero nessun elemento tracciante (1), viene inviato a Google. L’unico evento che si scatena quando un utente apre una pagina che usa la font di Google è una richiesta di “get” (2), ovvero lo scaricamento di un piccolo file contenente appunto i caratteri. I server che Google usa per le font non sono gli stessi che usa per i suoi servizi, quindi non può essere creata alcuna correlazione tra chi scarica quella font e chi sta usando altri servizi (3), come la mail di Google.
Dall’articolo di DDay
In pratica ci sarebbero tre dettagli che non renderebbero un tracciante:
- Il fatto che non fa utilizzo di un cookie;
- Il fatto che fa solo una “get” ;
- Il fatto che “non può essere correlato”.
Analizziamole insieme, vi va?
1. Per fare il tracker NON ci vuole il cookie… (cit)
Partendo dalla fantasiosa interpretazione che un “tracker” debba per forza utilizzare cookies per essere tale non credo che ci voglia un gran che nel capire che si tratta semplicemente di un giornalista che poco ha a che vedere con la tecnologia e che probabilmente non ha avuto modo di analizzare l’evoluzione tecnologica dal 2013 ad oggi.
La buona parte del tracking moderno, infatti, è effettuato secondo quella che viene normalmente definita la tecnologia di Cookieless Tracking, ormai standard de facto anche per le grandi aziende internazionali e che si fonda su un Device-Id estratto non già dal cookie ma dalle richieste pervenute. Una buona spiegazione del meccanismo commerciale è data anche da CJ che proprio tramite un meccanismo di Cookieless Beacon riesce ad aggirare anche le nuove tecnologie di anti-profilazione di Apple.
Se volete qualche dettaglio in più di una implementazione più casereccia ci sono un po’ di esempi online, ma i meccanismi secondo cui non serve alcun cookie per il tracciamento sono noti già dai tempi degli ETags-based tracking mechanism e, ancora da prima, dal famoso e quasi invincibile Evercookie.
Quindi per il primo punto “non richiede autenticazione e nessun cookie, ovvero nessun elemento tracciante” possiamo dare per scontato che è totalmente errato e privo di fondamento.
2. Per fare il tracker CI vuole la GET
Legato a quanto sopra c’è anche la buffa affermazione secondo cui “l’unico evento che si scatena quando un utente apre una pagina che usa la font di Google è una richiesta di GET”.
Buffo perché una richiesta GET è esattamente il meccanismo che serve per istanziare un Cookieless Beacon, come dettagliato negli Evercookie. Oltre a questo ricordiamo che una richiesta GET da una serie di parametri con cui riconoscere ed identificare univocamente, anche senza Javascript, un browser. Parametri come i plugin installati, le lingue accettate, la versione del browser.
Sono tutti dati che prendono il nome di Fingerprint e che almeno dal 2010 sappiamo che possono tracciare con una semplice GET ed identificare il singolo utente in modo preciso e completo, come peraltro mostra la EFF con l’ormai vecchio (ma probabilmente non conosciuto da DDay) tool online di Panopticlick che mostra anche nella pratica (alla voce fingerprint) come una semplice GET come quella per richiedere le Font sia più che sufficiente per tracciare.
Se vi interessa il relativo paper è vecchiotto, del 2010, ma sempre molto molto interessante ed attuale, e potete testarlo online come ad esempio il mio browser adesso abbia queste info:
Quindi per il primo punto secondo cui non si tratta di un tracciante perché “l’unico evento che si scatena quando un utente apre una pagina che usa la font di Google è una richiesta di GET” possiamo dare per scontato che è totalmente errato e privo di fondamento.
3. Per fare il tracker non ci vuole il server….
La terza fantasiosa interpretazione che da l’articolo è che “non può essere creata alcuna correlazione tra chi scarica quella font e chi sta usando altri servizi”. Questo in virtù del fatto che “i server che Google usa per le font non sono gli stessi che usa per i suoi servizi”.
Per rendere la cosa in termini non informatici è esattamente come dire che siccome abbiamo lasciato il nostro numero di telefono alla cassiera di nome Maria, che lo ha appuntato nei suoi log, non è correlabile lo stesso numero che abbiamo dato alla cassiera di nome Anna – salvato ancora nei log – solo perché non è la stessa persona che ci ha serviti.
Fantasiosa perché la correlazione può essere effettuata da più parti di quante siamo forse in grado di fare stare qui, tra cui:
- Correlando l’indirizzo IP della richiesta con una qualunque autenticazione su qualunque altro servizio di Google dove l’utente si autentica (gmail, youtube, maps…);
- Correlando l’indirizzo IP della richiesta con una qualunque banner di retargeting erogato da Google;
- Correlando l’indirizzo IP della richiesta con una qualunque dato di Google Analytics presente in una area riservata post-autenticazione;
E, sia chiaro, Google queste cose le sa, tant’è che se fosse CERTO che non fosse un dato personale non si sarebbe preso la briga, vedi sopra, di doversi dichiarare Data Controller…
Direi quindi che anche per il terzo punto “non può essere creata alcuna correlazione tra chi scarica quella font e chi sta usando altri servizi” possiamo dare per scontato che è totalmente errato e pacificamente privo di fondamento.
Animali fantastici ed altre fantasiose affermazioni…
Visto che il rimanente articolo si poggia su questi grossolani errori di base non credo ci sia un gran che da aggiungere, ma colgo l’occasione per puntualizzare ancora un paio di cose, già che sto scrivendo:
Sono GDPR compliant? Secondo le recenti analisi il 99% dei siti non è ancora compliant 100% alle normative sulla privacy, e le fonts di Google rientrano in quei casi limite dove non si è capito bene da che parte della linea stare.
Dall’articolo di DDay.it
No, si è capito benissimo. Sono Dati Personali (tra cui l’IP), non ci sono dubbi né per il sito del Garante nè per la Corte di Giustizia Europea e nemmeno per Google che specifica di dover essere considerato Data Controller tramite un comunicato ufficiale del Team Leader del progetto Fonts.
Come peraltro giusto che sia (bravi Google e Microsoft!).
Azure Media Player, come ogni riproduttore video, potrebbe integrare un sistema di tracciamento delle visite, ma nel caso del sito italiano non c’è traccia del plugin di analytics: si comporta come un semplice riproduttore di file video anonimo. Nessuna chiamata parte quando si inizia la riproduzione.
Dall’articolo di DDay.it
Anche qui: no.
L’indirizzo IP è un dato personale.
Non serve uno script per tracciare, come spiegato sopra. Peraltro la stessa definizione di “file video anonimo” (?!?!?!) è quanto di più errato possa essere utilizzato, perché – a meno che il client non installi TOR o similari – l’indirizzo IP viene COMUNQUE spedito per effettuare la GET.
E memorizzato.
Ed è un dato personale.
Ora attendiamo la rettifica di quanto sopra e se pensate che serva altro sono a disposizione!
