Perchè non si creano prodotti o servizi privacy-friendly?

La nostra esperienza nel settore ci ha insegnato che, purtroppo, la protezione dei dati personali è un tema che viene raramente incluso nelle fasi di design di un prodotto, ma lo stesso può valere per uno specifico servizio o trattamento di dati personali come la progettazione di una nuova campagna di marketing.

E così accade che qualcuno, e purtroppo sono spesso i legali a farlo, ad un certo punto pone dei veti o delle direttive che stravolgono le strategie iniziali, ritardando il deployment o il lancio del progetto.

Perchè accade tutto questo?
Perchè, in questi casi non vengono creati prodotti o servizi privacy-friendly, che uniscono legittime esigenze di business alla protezione dei dati degli utenti e/o clienti?

Crediamo che siano due i motivi principali.

Un primo errore è quello di non chiarire le vere finalità del progetto da una prospettiva privacy. Prendiamo, a titolo di esempio, un loyalty program.

Se lo scopo del programma è quello di premiare i clienti abituali con sconti o premi, allora sarebbe facile impostarlo tutelando la privacy.

Vi sarà certamente capitato di entrare in una pizzeria e di ricevere, dopo il primo acquisto, una card che verrà perforata ad ogni successivo acquisto fino a quando si potrà finalmente riscattare una pizza in omaggio.

Nessun dato personale. Nessun problema di privacy. E allora, vi chiederete, perchè non si procede sempre in questo modo?

La ragione, appunto, sta nelle vere finalità dei “programmi di fedeltà” che in realtà sono ben diverse da quelle che il nome stesso vorrebbe suggerire.

Lo scopo non dichiarato è infatti quello di aiutare l’azienda a raccogliere dati e metriche migliori per affinare messaggi di marketing verso clienti specifici. Insomma, lo scopo è quello di monitorare i clienti, aggregare dati personali, migliorare le proprie strategie di vendita e così aumentare il profitto grazie anche a marketing targetizzato. Gli sconti o i premi sono semplicemente un incentivo per i clienti ad accedere -più o meno consapevolmente- a questo tipo di monitoraggio.

Il che non è illegittimo, di per sè. A patto che venga messa a fuoco la vera finalità del progetto per apportare le necessarie misure a protezione degli utenti. In questo caso per esempio, comprendere la finalità del progetto ci aiuterà a trovare la base giuridica corretta dei nostri trattamenti, ad essere pienamente trasparenti nei confronti dei nostri clienti sulle vere intenzioni del programma di fedeltà e, quindi, ad individuare con più precisione i rischi privacy specifici e le relative misure di mitigazione.

Quali sono questi rischi? Beh, l’analisi sulle abitudini di acquisto dei nostri clienti porta con sè evidenti rischi di monitoraggio, di aggregazione e quindi, anche di profilazione.

Una conoscenza di questi rischi, parte necessariamente da una conoscenza e onesta dichiarazione delle finalità del progetto. Ora, però, siamo in grado di capire quali misure serviranno per mitigare i rischi che abbiamo individuato: il profilo di un cliente potrebbe essere identificato con uno pseudonimo, il database potrebbe essere protetto da tecniche crittografiche, l’accesso potrebbe essere autorizzato solo con autenticazioni forti e via dicendo.

Proprio il riferimento alle tecniche crittografiche ci conduce ora al secondo motivo.

C’è anche un altro elemento che talvolta impedisce di creare prodotti o sistemi privacy-friendly: una scarsa o non conoscenza delle PETs (Privacy Enhancing Technologies), sofisticate tecniche crittografiche che si basano su metodologie probabilistiche per ridurre i rischi privacy.

Purtroppo, si tende a privilegiare le esigenze del titolare alla protezione degli interessati, anche perché spesso non si conoscono questi strumenti che in realtà ci aiuterebbero a raggiungere entrambi gli scopi.

Un esempio è la differential privacy.

Per capire di cosa si tratta è bene non partire dalla sua definizione, piuttosto complessa, bensì dallo specifico rischio privacy che è in grado di mitigare.

La differential privacy è un presidio ai c.d. linking attack, sempre più frequenti, quando più dati provenienti da più dataset sono correlati al fine di identificare una persona. Già nel 1997 una ricercatrice del Massachussets, Latanya Sweeney, aveva scoperto che con soli 3 dati (genere, codice postale e data di nascita), provenienti da dataset diversi poteva essere identificato l’87 % dei cittadini americani.

Questo tipo di inferenza, di correlazione tra i dati, può essere raggiunto anche quando il punto di partenza è un dataset anonimizzato, nel quale sono stati rimossi i dati personali.
È c’è un fatto storico eclatante a ricordarcelo: nel 2006 Netflix, all’epoca ill più grande servizio di noleggio di DVD online al mondo, annunciò una competizione con in palio 1 milione di dollari, per la creazione di un nuovo sistema di raccomandazione che potesse analizzare e comprendere il comportamento di un utente proponendoli contenuti pertinenti alle sue preferenze.

Come parte della competizione, Netflix rilascio una dataset anonimizzato contenente 100 milioni di recensioni di 500 mila utenti quale risorsa per permettere ai team di realizzare i modelli algoritmici di raccomandazione. I nomi dei film e gli username degli utenti erano stati sostituiti da numeri interi, eliminando quindi informazioni private sugli individui che avessero recensito i film.

Eppure, di lì a poco due ricercatori dell’Università del Texas furono in grado di de-anonimizzare sia lo username che i nomi dei film usando delle sofisticate tecniche statistiche. In sostanza, hanno prima eseguito uno scraping dei dati presenti sulla nota piattaforma IMDB (internet Movie Database) estraendo un enorme numero di recensioni dei film. Poi, attraverso una serie di analisi statistiche furono in grado di trovare quali utenti avessero fatto una recensione su entrambe le piattaforme: netflix e IMDB. Questa operazione permise loro di de-anonimizzare una grande quantità di dati.

Utilizzando l’Internet Movie Database come fonte di conoscenze di base (source of background knowledge), associarono alcune informazioni presenti sul database di Netflix a utenti noti, fino a desumere le loro preferenze politiche, sbirciando fra i documentari o le biopic che avevano noleggiato.

Morale: l’anonimizzazione dei dati si è dimostrata insufficiente a garantire davvero la privacy dei soggetti di un dataset.

Quindi se volessimo condividere un set di dati anonimizzato ad un ente terzo, probabilmente dovremmo valutare il rischio di una possibile identificazione dei soggetti interessati.

Ed ecco, allora, che arriva in soccorso la differential privacy, al fine di raggiungere del rumore randomico ai nostri dati. Per capire come funziona, è utile richiamare l’esempio della moneta: poniamo che “testa” corrisponda alla risposta “sì” e croce al “no”: in alcuni casi, però, e in modo assolutamente casuale “croce” corrisponderà invece ad “un nuovo lancio della monetina”. Questo è l’elemento randomico, utilissimo perchè:

• da una parte non abbiamo reso anonimo il database e questo significa mantenere importanti proprietà statistiche nel suo complesso;
• dall’altra potremo comunque salvaguardare la privacy degli utenti del data set.

Attenzione però a quanto rumore (noise) aggiungere! E a quanto deve essere ampio e rappresentantivo il database di informazioni.
Sono due aspetti fondamentali perché dovremo sì aggiungere rumore, ma non così tanto da rendere inutile il data set sotto il profilo statistico. E, ovviamente, più è ampio il database, più rumore potremmo aggiungere senza pregiudicare -o pregiudicando in minima parte- il valore statistico del database.

Di nuovo, sarà importante avere in testa le finalità del progetto per capire quali dati statistici ci servono e quali “sacrificare” per aumentare il livello di privacy degli utenti medianto l’utilizzo della differential privacy. Quindi anche le PET le potremo scegliere e implementare nel modo corretto solo se conosciamo le finalità alle basi del nostro prodotto o servizio.

Ancora una volta questo scenario ci insegna come la privacy sia un continuo bilanciamento -anche in ambiti piuttosto tecnici- tra diverse esigenze contrapposte. È un campo che richiede tanta competenza tecnica, sensibilità giuridica e, quindi, interdisciplinarietà. Ma soprattutto il tema della privacy, collegandosì alle finalità di un progetto, deve necessariamente essere posto in cima all’agenda.