GDPR: guida pratica per gli sviluppatori

Il nuovo regolamento europeo sulla privacy sta mandando tutti nel panico. In questo articolo affronteremo gli aspetti più pratici dell’adeguamento

Ammetto che scrivere sul GDPR mi rende un tantino nervoso, perché non sono un avvocato ed una figura esperta è più che richiesta. Nonostante ciò, vorrei provare a dare del mio, concentrandomi poco sui dettagli del regolamento e prestando più attenzione alla pratica.

L’utente al centro

Innanzitutto è bene comprendere l’anima del regolamento, che a mio parere si può riassumere nel principio di privacy by design e privacy by default. Ovvero, la tutela dell’utente, dei suoi dati e delle sue libertà deve essere pensata e garantita sin dal principio e deve essere un punto cardine di tutto il processo di sviluppo.
Ogni cosa deve essere fatta all’insegna della trasparenza, affinché l’utente possa avere sempre tutto sotto controllo. Per questo motivo ogni informativa, come i termini e condizioni o la privacy policy, deve essere sempre a portata di mano. Ad esempio, una buona idea può essere quella di inserire i link delle policy nel footer, in modo che siano accessibili da qualunque pagina del sito.

Terminologia

Prima di cominciare, per essere sicuri di non tralasciare nulla, è bene ripassare un po’ di termini chiave:

  • Interessato: è la persona fisica soggetta ad un trattamento. In questo articolo viene spesso indicato come utente;
  • Titolare del trattamento (controllore dei dati): persona o organizzazione che determina le finalità di trattamento dei dati e ne è responsabile;
  • Responsabile del trattamento (processore dei dati): elabora i dati per conto del titolare del trattamento;
  • Dato personale: qualunque tipo di dato che permetta di identificare un utente. Comprende varie categorie, tra cui dati identificativi (nome, cognome, data di nascita) e dati sensibili; trovate qui una migliore panoramica;
  • Dato sensibile: dato di categoria speciale, che può rivelare informazioni di carattere genetico o biometrico, origine etnica, preferenze sessuali, religiose o politiche, stato sociale o economico, e così via.
  • Profilazione: attività di raccolta ed elaborazione dei dati, con lo scopo di suddividere gli utenti del servizio in gruppi di comportamento;

Contenuto della privacy policy

Il documento deve spiegare con un linguaggio limpido e semplice come verranno trattati i dati degli utenti. Quindi è necessario innanzitutto spiegare quali dati saranno raccolti e per quali scopi. Inoltre è bene differenziare i dati forniti direttamente dall’utente, come ad esempio quelli inseriti nel form di registrazione, da quelli raccolti in modo automatico, come l’indirizzo IP. Specificare quindi la base di raccolta, cioè se avviene tramite consenso, su contratto o per un legittimo interesse. Infine specificare per quanto tempo questi dati saranno conservati.

Qui faccio una considerazione. Questo modo di trattare i dati non è banale come sembra, perché il regolamento non ci sta chiedendo di scrivere l’informativa e accantonarla lì. Ci sta di fatto chiedendo un impegno costante nel mantenere l’informativa sempre aggiornata. Se ad esempio, al momento della registrazione, l’informativa afferma che l’indirizzo e-mail serva solamente a confermare l’account, in seguito non si potrà utilizzarlo per effettuare eventuali comunicazioni di alcun tipo.

L’informativa deve contenere i contatti del titolare del trattamento e del DPO, se esiste, evidenziando il fatto che questi sono utili per chiedere modifiche o cancellazione dei dati. Inoltre bisogna informare della possibilità di ricorrere al Garante e all’autorità giudiziaria.

Infine, si deve specificare se questi dati saranno passati a terzi, che in tal caso diventano responsabili del trattamento, come ad esempio servizi di analytics, di e-mail, di pagamento e quant’altro. Un maggiore riguardo spetta ai dati che viaggiano al di fuori dell’Unione Europea. Il trasferimento è consentito solo se c’è un adeguato livello di protezione dei dati, quindi con uno standard equivalente a quello del GDPR. Se il responsabile è negli Stati Uniti, c’è bisogno che questo aderisca al Privacy Shield, un accordo tra USA ed Europa che regolamenta questo tipo di trasferimento dei dati.

Potete verificare sul sito del Privacy Shield se le aziende americane a cui fate affidamento hanno aderito.

La privacy policy è un documento a cui bisogna prestare molta attenzione, perciò, se volete un esempio pratico, ho apprezzato molto l’impostazione chiara e lineare di Subito.it.

Consenso

Questo è un punto centrale del regolamento. Per i dati sensibili o soggetti a profilazione, il consenso deve essere libero, esplicito, specifico e inequivocabile. Vuol dire che questo deve essere chiesto attraverso una frase semplice, affermativa e chiara. L’utente non deve essere obbligato ad accettare un trattamento di profilazione e deve dare il consenso volontariamente e attraverso un’azione precisa, ad esempio spuntando una checkbox o cliccando su un pulsante.
È da escludere il consenso tacito o presunto, quindi non va bene pre-spuntare la checkbox oppure supporre che l’utente acconsenta se continua con la navigazione.

Secondo il GDPR il consenso deve essere anche specifico, cioè ogni checkbox deve far riferimento ad un trattamento ben preciso. Quindi serve una casella dedicata ai termini e condizioni, un’altra alla privacy policy, un’altra ancora alla newsletter e così via.

Cookie

Non tutti i cookie sono soggetti al consenso, ma dipende dalla tipologia e che siano di prime o terze parti. In particolare non sono soggetti a consenso:

  • cookie tecnici, strettamente necessari al funzionamento del sito (per memorizzare la lingua, una preferenza, una sessione, ecc.), sia di prime che terze parti;
  • cookie statistici gestiti direttamente dal sito (prime parti),  purché non vengano utilizzati per profilare;
  • cookie statistici di terze parti anonimi, cioè che non contengano dati personali di un utente.

Qualora il sito non installi alcun tipo di cookie, non c’è bisogno del banner informativo, altrimenti è obbligatorio e deve contenere una frase chiara e un link alla cookie policy.

Google Analytics

Un’altra preoccupazione comune è come comportarsi con Google Analytics. Sostanzialmente si può agire in due modi. Essendo uno strumento utile alla profilazione, dovremmo inserire lo script nella pagina solo quando il consenso è stato accettato. È facile immaginare come le visite registrate in Analytics scenderebbero notevolmente e questo sarebbe un grosso problema. Per essere compliant, Google ha introdotto in ga.js una funzione per anonimizzare gli indirizzi IP, il che permette di considerare i cookie di Analytics come tecnici:

ga('set', 'anonymizeIp', true)

Qualora ve lo steste chiedendo, la funzione va inserita dopo lo script di Analytics, solo se l’utente non ha acconsentito all’uso dei cookie.

Come dicevamo nella sezione riguardante la privacy policy, bisogna specificare per quanto tempo i dati saranno conservati e questo lo si può impostare su Amministratore > Proprietà > Informazioni sul monitoraggio.

Infine è bene sapere che Google potrebbe utilizzare i vostri dati di Analytics per altri servizi. Se acconsentite a questo tipo di utilizzo, è bene specificarlo nella policy. Potete dare o negare questi permessi in Amministratore > Account > Impostazioni account.

Dimostrazione del consenso

Il titolare del trattamento deve essere in grado di dimostrare che l’utente ha acconsentito al trattamento dei dati. Il regolamento non parla esplicitamente di una soluzione e in tutti i webinar o articoli in cui ci fossero degli avvocati, questi finivano sempre per consigliare l’utilizzo di una marca temporale certificata, come quella di InfoCert. Cosa vuol dire? Che dovremmo memorizzare una serie di informazioni a cui porre una sorta di firma, passando per un’autorità esterna trusted, detta Time Stamping Authority, con cui un domani potremmo dimostrare in tribunale che abbiamo raccolto quei dati in un certo istante.

Tuttavia trovo questa tecnica inapplicabile nella realtà. Infatti, anche utilizzando una marca temporale, saremmo in grado di dimostrare che quei dati sono stati registrati in una certa data ad una certa ora, ma non siamo assolutamente in grado di dimostrarne l’autenticità.

Alternative? L’ideale sarebbe avere un documento firmato digitalmente dal cliente, ma chiaramente è impraticabile. Si potrebbe pensare, nel momento in cui l’utente acconsente al trattamento, di inviargli un’email riepilogativa dei consensi espressi, tramite PEC. Così entrambe le parti avrebbero una prova utilizzabile eventualmente in un tribunale.

Qualcuno mi ha suggerito perfino una soluzione molto carina basata su IPFS, un protocollo basato su blockchain, che quindi rende inalterabili i dati registrati e sempre verificabili da entrambe le parti.

Revocabilità

Il consenso espresso prima del 25 maggio resta valido se questo è stato raccolto rispettando già i criteri esposti, altrimenti bisogna raccogliere nuovamente il consenso. Nella pratica, si può banalmente mostrare una finestra in primo piano che informa l’utente dell’adeguamento al regolamento e che chiede di riconfermare il consenso, sempre tramite checkbox.

Infine, il consenso deve essere revocabile, quindi, così com’è stato facile dare il consenso, l’utente deve poterlo ritirare. Nella pratica la cosa logica da fare è creare una sezione apposita nel sito da cui poter gestire i consensi.

Diritto all’oblio

Come già detto, l’utente deve avere il pieno controllo dei dati che lo riguardano, perciò ne può richiedere la cancellazione. In particolare, il titolare del trattamento è tenuto alla cancellazione dei dati solo se questi non sono più necessari per gli scopi rispetto ai quali sono stati raccolti o se sono trattati illecitamente o se l’interessato si oppone legittimamente al loro trattamento. Sia chiaro che la richiesta deve essere presa in esame e può essere disattesa. Prendiamo, ad esempio, i commenti di un blog a cui sono registrati diversi utenti. Uno di questi ad un certo punto disattiva il proprio account. I suoi commenti che fine fanno? Chiaramente non verranno cancellati, perché sono ancora necessari alla piattaforma e agli altri utenti.
Insomma la cancellazione non deve essere una cosa così automatica e le aziende sotto questo punto di vista sembrano essere abbastanza tutelate. Basti pensare che qualora si ricevessero molte richieste di cancellazione ingiustificate, c’è la possibilità di inserire un costo ragionevole

Principio di accountability

Il principio di accountability mette nelle mani del titolare una responsabilità molto più importante rispetto al passato. È possibile nominare dei responsabili del trattamento, che operano sempre per conto del titolare e inoltre viene introdotta la figura del DPO.
Le aziende con più di 250 dipendenti o che trattano dati particolari e che possano “presentare un rischio per i diritti e le libertà dell’interessato”, quindi anche dati sensibili, sono tenute a mantenere aggiornato un Registro dei trattamenti, preferibilmente in formato elettronico, che contenga informazioni dettagliate circa il trattamento dei dati e le misure organizzative e di sicurezza adottate.

Non scendo troppo nei dettagli del contenuto, ma potete trovare maggiori informazioni e un modello scaricabile in Excel su infogdpr.eu.

Portabilità del dato

L’utente deve essere sempre in grado di visualizzare i propri dati e di poterli scaricare in locale. Per il download è richiesto un formato portabile, come CSV, HTML, XML, JSON, con l’idea che questi dati potrebbero essere trasmessi altrove. Nella pratica si può pensare di realizzare una pagina spartitraffico che concentra in un’unica schermata tutti i link alle pagine necessari per visualizzare o per scaricare in formato JSON i vari dati. La soluzione di Facebook rispecchia esattamente questa modalità.

DPO

Si tratta di una persona fisica (o un gruppo di persone fisiche) ed ha un compito di sorveglianza e di implementazione. È obbligatorio in pochi casi, ovvero quando l’organizzazione è un’autorità o organismo pubblico, quando si effettua monitoraggio di fenomeni su larga scala o se si raccolgono dati sensibili o penali.
È una figura non certificata, cioè non esistono albi, per cui non ricopre un ruolo esclusivo e può essere interno oppure esterno all’organizzazione. Deve essere visto come uno specialista dell’azienda e messo nelle condizioni di muoversi in autonomia e poter accedere alle risorse necessarie.

Data breach

La parte che interessa di più il reparto ICT di un’azienda, probabilmente, è il data breach. Dal momento in cui si rileva una fuga di dati, bisogna valutare se questa può mettere a rischio i diritti e le libertà degli individui, per cui si potrebbe verificare un danno reputazionale, finanziario o simile. In tal caso il titolare è tenuto a notificare del breach gli utenti interessati e il Garante entro 72 ore da quando il breach viene scoperto. Al di là delle notifiche, ogni violazione e fuga di dati va documentata, comprese le circostanze, le conseguenze e i provvedimenti adottati per porvi rimedio.

Considerazioni sulla sicurezza

Il GDPR non è un regolamento scritto per i tecnici, quindi non sorprenda la mancanza di dettagli implementativi nel testo o il non coinvolgimento vero e proprio del reparto informatico. Se il regolamento fosse stato pensato in termini di sicurezza informatica vera e propria, avrebbe chiesto quanto meno di utilizzare il protocollo HTTPS nelle comunicazioni, dato che altrimenti basta un semplicissimo sniffing per leggere informazioni anche molto personali. Al contrario di quanto si vocifera spesso, non viene detto nulla circa le informazioni da loggare, delle password o dei dati da criptare. Al più il regolamento invita a prendere le misure necessarie per mettere i dati degli utenti in sicurezza, che può tradursi nel rafforzamento dell’infrastruttura aziendale, mediante l’uso di firewall, antivirus e software aggiornati, e per intervenire direttamente sui dati si può ricorrere essenzialmente a due tecniche: la cifratura e la pseudonimizzazione. Per cifratura si intende scrivere il dato in un formato non comprensibile, utilizzando una chiave su un certo algoritmo. Per pseudonimizzazione invece si intende la non riconducibilità di quel dato ad una persona fisica. L’idea di fondo è quella che in caso di fuga di dati, specialmente se sensibili, questi risultino incomprensibili o inadatti ad identificare una persona.

Conclusioni

Il GDPR ha creato un panico molto diffuso in tutti i settori e probabilmente sarò impopolare se dico che sono contento di questo regolamento. Capisco il terrore, soprattutto dei piccoli imprenditori, che di leggi e di siti, fondamentalmente, non ci capiscono niente, ma come società proiettata verso un futuro dove l’informatica è dappertutto e dove i nostri dati sono un valore, proteggersi è essenziale. Probabilmente nei prossimi tempi ci saranno pochi controlli sull’adeguamento e francamente lo spero, dato che dubito sulla conformità del 95% delle aziende, ma mi piace la linea di fondo, che secondo me vuol far prendere una piega precisa alle aziende, atta a tutelare gli utenti e i loro dati.

L'autore

Ciao, sono Antonio D'Amore, e sono un ingegnere informatico con la forte passione per il web. Sguazzo nell'ambiente startup, grazie a Tobevy, di cui sono co-founder e CTO, e adoro la divulgazione, ragion per cui ho creato questo blog