L’interesse sul GDPR (General Data Protection Regulation, ovvero Regolamento generale sulla protezione dei dati), la discussa regolamentazione che sarà ufficialmente in atto dal 25 maggio 2018, è sempre più vivido con l’avvicinarsi della data in cui sarà necessario adeguare, tra gli altri software, il proprio sito a questa normativa. Normativa che, peraltro, è già in vigore da qualche tempo, e che a fine maggio sarà obbligatoria per tutti.
Un testo pubblicato già nel maggio 2016 da parte della UE, che ha pensato ragionevolmente di dare due anni di tempo alle aziende, alle pubbliche amministrazioni ed a tutti gli altri per potersi adeguare. Nell’affrontare questo problema ho deciso di leggere attentamente il documento ufficiale pubblicato dalla UE: mi sembra infatti il modo più adeguato di risolvere alcuni dubbi ed ambiguità che accompagnano, da quello che leggo in giro nelle varie discussioni, la scelta sul fatidico “cosa devo fare, adesso che diventa obbligatorio il GDPR“?
Proverò a raccontarvi la mia esperienza in merito, le mie impressioni, gli errori che secondo me vanno evitati e cosଠvia.
Usa il codice
189ed7ca010140fc2065b06e3802bcd5
per ricevere 5 € dopo l'iscrizione
Premessa
Ovviamente tutto quello che dirò in questo articolo è riportato a mero scopo divulgativo, e non ha intenzione di sostituirsi al parere di un consulente legale o professionista in materia. Leggetelo per quello che è: un ingegnere informatico che prova ad evidenziare i punti più importanti del GDPR, senza presunzione e con un minimo di esperienza regressa sul campo dei siti web.
L’articolo vuole, pertanto, essere una risorsa in buonafede, non vale come consulenza di natura legale (che sarebbe già anomalo, di suo, fornire mediante il web). In genere, da quello che è dato capire, ogni singolo, azienda o pubblica amministrazione viene influenzato diversamente a livello di GDPR – inclusa l’eventualità che uno debba buttare gi๠tutto o quasi, oppure possa essere già a norma. Dipende da come ha lavorato in precedenza, ovviamente
Cos’è il GDPR?
Il GDPR formalizza una serie di importanti concetti (ad esempio stabilisce cosa debba considerarsi “dato personale”) e fornisce delle regole da seguire per il trattamento dei dati dei nostri utenti o clienti: vale indipendentemente dalla localizzazione geografica (ad esempio se avete un server in Cina ed erogate un servizio web in Europa), e va applicato a tutti quei contesti in cui siano offerti beni o servizi (free o a pagamento) e qualora il comportamento dell’utente sia in qualche modo monitorato. Si applica a dati personali trattati automaticamente in tutto o in parte, e punta a garantire una serie di diritti all’utente (tra cui – evidenzio le prime cose che ho notato come rilevanti – quello di aver fornito un opt-in esplicito o consenso dimostrabile all’iscrizione di un qualsiasi servizio, il poter disporre sempre dei propri dati, poterli cancellare, esportare, modificare ed “essere dimenticato” / diritto all’oblio, analogo a quello per cui Google anni fa è finito sotto esame).
Si tratta di una normativa piuttosto lunga e complessa che andrebbe, di fatto, incaricata di essere analizzata dal proprio studio legale, avvocato di fiducia e cosଠvia: molti piccoli siti, di fatto, non dispongono di risorse del genere, per cui saranno costretti ad assumersi dei rischi. Alla base di tutti vi è, infatti, un senso di responsabilizzazione molto marcata, che arriva ad identificare obbligatoriamente un responsabile del trattamento dei dati personali. Dati personali su cui, del resto, bisognerà capirsi con precisione, visto che sembrano fare riferimento a qualsiasi dato (in apparenza, anche un semplice nickname) che permetta l’identificazione di una persona, dei suoi gusti, convizioni, sesso e cosଠvia.
Il senso base del GDPR è duplice:
- da un lato punta ad una armonizzazione e regolamentazione delle norme relative alla privacy dei dati personali, mediante un vero e proprio regolamento (non più, quindi, direttive da seguire orientativamente) e specificatamente nel caso in cui tali dati siano archiviati da qualche parte – per consentire di accedere ad un sito, per una newsletter, per eseguire contrattistica online, e cosଠvia;
- dall’altro, la normativa riconosce con chiarezza l’importanza di una libera circolazione dei dati personali, che (viene scritto chiaramente all’inizio del testo) non può essere limitata in nessun caso, visto che esiste un’economia ed un insieme di relazioni che vengono facilitate ed incentivate da essa.
Il GDPR sta mandando in crisi molti consulenti
In quest’ottica, è chiaro che molte preoccupazioni ed isterie da parte di programmatori e consulenti del web sono, almeno nell’approccio, comprensibili solo in parte – per non dire del tutto ingiustificate: chi pensa che questa legge possa diventare un freno alle proprie attività dovrebbe, secondo me, rivedere l’approccio, e pensare ad un modo di lavorare diverso, evitando improvvisazioni e soprattutto (cosa tipicamente made in Italy, da quello che sento in questi giorni) evitare di far fare modifiche al proprio sito prendendo la normativa come se fossero specifiche di un software, o magari facendosi dettare le specifiche dal proprio avvocato. Non per altro, ma a mio umile avviso è sbagliato l’approccio: potete rivolgervi al miglior principe del foro della vostra città , ma difficilmente questi sarà in grado di darvi specifiche software precise, realizzabili ed efficaci. La legge ovviamente va rispettata, ma è opportuno che ci sia un consulente informatico o un ingegnere specializzato a “tradurle” nel vostro caso specifico, visto che (come spesso accade) ogni singolo caso finisce per fare storia a sè.
Il GDPR non è una specifica per software: va tradotto in tali termini
Il problema della corsa all’adeguamento, del resto, per quanto riguarda il settore del web e non solo, è legato ad una marcata (e per me non condivisibile) isteria di fondo, specie da parte dei colleghi non informatici (a cui verrebbe da chiedere cosa ci facciano lଠe se non debbano, per caso, assumere un informatico serio).
Lo scrivo quindi con la massima cordialità , ma con altrettanta chiarezza: cari avvocati, c’è un forte bisogno del vostro parere ovviamente ma specificate sempre (nei vostri interventi online) che siete avvocati e non informatici, per la stessa ragione per cui ho premesso a questo articolo che mi occupo di ingegneria informatica, non di diritto. Se non lo fate, rischiate di innescare meccanismi piuttosto subdoli, che porteranno i webmaster fuori strada, arrivando (beffa nella beffa) a peggiorare la situazione, invece di migliorarla. Di recente sono stato al Codemotion a Roma, ad esempio, ed ho sentito qualche persona voler affrontare il regolamento con l’idea di crittografare tutti i dati della propria applicazione, in generale: idea rischiosa (se cripti tutto e non prendi le dovute precauzioni, rischi di perdere tutto irreversibilmente), e sostanzialmente fuori bersaglio rispetto a quanto suggerito dal nuovo regolamento.
Del resto basta leggere i presupposti della legge per capire che non possiede natura restrittiva (per quanto sia decisamente prolissa nelle premesse, nelle modalità e nelle indicazioni), e ciò comporta (alla peggio) almeno di provare ad evitare le più comuni bad practices in termini di informatica. Già questo, di suo, sarebbe un gran risultato. Chiaro che poi – e faccio un inciso che più breve non si può – se il sito web è stato sviluppato dal classico cuggino, difficilmente questi sarà in grado di soddisfare i requisiti del GDPR, che magari neanche conosce, o che interpreta a modo proprio o liquida con l’idea che a lui queste cose non interessano o non riguardano i siti web.
GDPR per sviluppatori
In tal senso, cosa dovrebbe fare uno sviluppatore? Secondo il blog di Bozhidar Bozhanov (legale che ha lavorato nella UE, e che si occupa di tematiche legate alla privacy) uno sviluppatore per qualsiasi software dovrebbe garantire, alla luce della regolamentazione, quantomeno:
- il diritto per ogni cliente di essere cancellato o dimenticato dal sistema (cioè se oggi mi iscrivo ad un nuovo social network o ad un forum, devo avere la possibilità di rimuovere ogni mia traccia, se lo desidero)
- il diritto di effettuare un processing dei dati parziale (cioè la possibilità di salvare dati restricted, che solo l’utente ha il diritto di modificare)
- il diritto alla portabilità dei dati (cioè devo poter esportare in formato ragionevole i miei dati dal sistema al mio computer)
- il diritto di rettifica (cioè poter correggere dati personali che mi riguardano, in qualsiasi momento)
- il diritto di essere correttamente informato (cioè poter ottenere informazioni chiare e sintetiche, in linguaggio comprensibile)
- infine, il diritto di accesso (cioè la possibilità di accedere ai dati che custodiamo del cliente in qualsiasi momento)
Secondo l’efficace sintesi di Bozhanov, i principi cardine che interessano gli sviluppatori riguardano la data minimization (cioè non possiamo salvare più dati di quanto effettivamente non serva), l’integrità degli stessi e la confidenzialità (cioè dobbiamo adottare metodi adeguati a proteggere quei dati da occhi indiscreti, e ridurre al minimo la possibilità che siano alterabili). Ovviamente questo è solo un primo approccio, e non è detto che contenga esattamente tutto quello che vi serve: ma nel marasma di informazioni che stanno circolando, almeno in Italia, mi sembrano indicazioni più che valide. Per ulteriori informazioni fate riferimento al suo post, che elenca anche una serie di requisiti da rispettare (funzionalità da implementare, del tipo: export dei dati, checkbox di consenso, funzione “Dimenticati di me“).
Ricordatevi comunque che:
- per certi software possono esistere regole precise da rispettare (ad esempio standard ISO a cui adeguarsi)
- non è detto, in generale, che tutti i punti elencati dal GDPR siano applicabili al vostro caso;
- non è detto che il vostro sito, se realizzato a regola d’arte in passato, non necessiti eventualmente solo di qualche ritocco senza stravolgere nulla.
Non fare confusione (se possibile)!
Le differenze dell’imminente GDPR con quanto emerso ai tempi della normativa sui cookie, del resto, sono sostanziali: all’epoca si è trattato di indicazioni generiche per i vari siti, che partivano da un presupposto semplice (un legislatore che aveva intuito le potenzialità invasive dei cookie, riconoscendone contemporaneamente la necessità per il funzionamento degli stessi) che poi, all’atto pratico, ogni sito ha deciso di implementare a modo proprio.
In molti casi si sono visti risultati scadenti, addirittura in conflitto con le regole di usabilità più elementari , ed in questo caso – a mio avviso – c’è il forte rischio di fare lo stesso. Per me non ha senso neanche cosà¬: se per rispettare la legge sei costretto a ricorrere a cose ancora più complicate di quelle che dovevi combattere, semplicemente stai lavorando tanto per farlo, e senza badare minimamente alla sostanza (ricordate all’inizio: libera circolazione dei dati, non impedimenti).
Il problema di fondo – e lo scrivo per l’ennesima volta, qui – è che la normativa, per sua natura, non può dettare specifiche tecniche che devono restare, comunque, a carico di chi realizza i siti. Del resto se mai una normativa obbligasse a seguire uno standard sarebbe fuori luogo, difficile o davvero impossibile da realizzare nonchè decisamente caotico. Chiarito questo, passiamo ad analizzare nel dettaglio cosa dice questa normativa, cosa possiamo fare come best practice e da cosa diffidare o non farsi distrarre.
La fonte originale
Tra decine di articoli usciti sull’argomento, mi pare si sia persa di vista la fonte originale della legge, che potete trovare a questo indirizzo:
e scaricare in vari formati (sotto la colonna IT trovate la versione in italiano). Il GDPR si basa su 173 presupposti di base, tra cui la considerazione dell’importanza della protezione dei dati personali, il rispetto delle libertà stessa, l’armonizzazione delle regole precedente e via dicendo. In quest’ottica, è chiaro che la normativa si ispira a principi del tutto generali ed ampiamente condivisibili dai più, e rimane a mio avviso valido un aspetto fondamentale: chi già lavora professionalmente negli ambiti privacy e protezione dati non dovrebbe, almeno sulla carta, avere troppe difficoltà ad adeguarsi alle normative.
Cosa ribadita ad esempio da Digital Ocean, un servizio di hosting che sto utilizzando da qualche tempo e che sottolinea definitivamente questo aspetto (“If you already have robust compliance, security, and data privacy practices in place, your move to GDPR should be simple. “).
Secondo il testo ufficiale, anzitutto, al centro dell’attenzione vi sono infatti il trattamento dei dati personali dell’utente in vari contesti – quindi non solo in ambito digitale, allo scopo dichiarato di rafforzare i diritti in materia di protezione dei dati delle persone fisiche e di migliorare le opportunità per le imprese, agevolando la libera circolazione dei dati personali nel mercato unico digitale (ripeto, questo punto è importante: il decreto non sembra pensato come limitativo, sembra mirare più che altro a limitare le pratiche scorrette contro gli utenti finali: tipo profilarli a loro insaputa, spiarli, conservarsi i loro dati senza dargli possibilità di cancellarli, far finta di cancellarli e via dicendo). Il regolamento in questione è il 5853/12 e mira a sostituire la direttiva 95/46/CE, precedentemente utilizzata in materia.
Da un punto di vista pratico, queste modifiche andranno raccordate con una regolamentazione locale nel nostro paese, che possa integrarsi e probabilmente sostituire per intero la vecchia normativa sulla privacy (il famoso d.lgs. 196/03 che citiamo a menadito nei nostri curriculum vitae, per intenderci). Su questo, ovviamente, vedremo cosa succederà .
Una nota importante del Garante italiano
C’è da specificare che il Garante per la Privacy ha specificato che
non è vero che il Garante per la protezione dei dati si sia pronunciato sul differimento dello svolgimento delle funzioni ispettive e sanzionatorie
Del resto, sempre nello stesso comunicato, si scrive poi
nà© il provvedimento richiamato nei siti attiene a tale materia
Le comunicazioni con il tenore di “fate qualcosa altrimenti ne pagherete le conseguenze”, peraltro, sembrano discutibili quantomeno dal punto di vista comunicativo: non mi pare che le minacce siano il modo migliore per spingere le persone ad adeguarsi. Il terrorismo mediatico-psicologico, se non altro, lasciamolo da parte nelle nostre discussioni; altrimenti uno è portato a pensare male.
Vediamo, per concludere questo primo articolo, alcuni casi pratici affrontati da grosse aziende del settore web, giusto per capire cosa stiano facendo e aiutarci a regolarci nel nostro caso.
Mailchimp e GDPR
Mailchimp è un servizio che uso anch’io per gestire la newsletter e le iscrizioni degli utenti interessati ai contenuti che pubblico sul web come editore, ed è stato il primo a venirmi in mente nel chiedermi come debba avvenire, nel concreto, l’adeguamento alle leggi per la privacy.
Senza scendere in troppi dettagli, ho visto che:
- Mailchimp ha annunciato che metterà a disposizione dei tool specifici per favorire la gestione dei dati personali dell’utente;
- i form di iscrizione sono stati aggiornati per essere in linea con le disposizioni di legge in questione, in particolare (da quello che si legge) con dei form opt-in di consenso esplicito, da barrare al momento dell’iscrizione ad una newsletter (Our GDPR fields include checkboxes for opt-in consent, and editable sections that allow you to explain how and why you are using data.), con la possibilità di ricorrere ad un duplice opt-in per voler rafforzare, eventualmente, il concetto (For additional evidence of consent, you may choose to turn on double opt-in.);
- MailChimp è il responsabile finale del trattamento dei dati dei vostri iscritti, a cui questi ultimi possono rivolgersi per richiedere la cancellazione o la correzione dei dati stessi (All MailChimp users can access their MailChimp lists to correct or update information upon the request of their subscribers. Your contacts can continue to update their own data, too, by contacting us or updating their preferences in any email they receive from you.)
(fonte)
ICANN e GDPR
C’è da dire che la regolamentazione in questione non riguarda solo i siti web, ma si estende a svariati ambiti applicativi; di fatto, l’ICANN – l’organismo internazionale che gestisce i domini – ha già preparato una bozza di proposta, ad esempio, che dovrebbe e potrebbe cambiare sensibilmente le modalità di accesso ai servizi di WHOIS, assieme al tipo ed al numero di dati che sono visionabili mediante query o richieste pubbliche. Questo ovviamente è un vantaggio per gli utenti finali, che vedrebbero in qualche modo la possibilità di rendere visionabili dall’esterno i propri dati personali, limitando l’accesso agli anonimi e, in molti casi, permettendolo solo alle autorità se necessario (questo a quanto pare cambierà caso per caso a seconda dell’estensione del dominio).
Google e GDPR: il “diritto di cancellazione”
Google ha messo le mani avanti già da qualche tempo, dichiarando (cito):
Google garantisce che rispetterà fedelmente il regolamento GDPR nei servizi di Google Cloud. Ci impegniamo inoltre a sostenere i nostri clienti nelle attività di conformità al regolamento GDPR fornendo strumenti efficaci di protezione della privacy e della sicurezza, peraltro già incorporati nei nostri servizi e contratti nel corso degli anni.
ma c’era da aspettarselo, visto che maneggia una quantità impressionante di dati privati, almeno quanto ne maneggia Facebook del resto. I punti espressi da Google riguardano, per inciso, vari punti di varia importanza (protezione dei dati, crittografia, assegnamento di un responsabile al trattamento dei dati ecc.) ma quello che maggiormente credo sia importante per chi lavora sul web è legato al “diritto di cancellazione”, cioè il diritto di poter cancellare ad esempio la mia registrazione ad un sito web. Il problema dei dati degli utenti che non si cancellano più o restano per sempre, del resto, non è nuovo nell’informatica e nel web: chiunque sa che una foto intima finita su Google ci rimarrà plausibilmente per sempre, per cui il problema è come abbiamo lavorato fino ad un oggi, in un certo senso.
Ancora oggi, del resto, capita di iscriversi a siti web che poi non permettono di cancellare l’account; mi è capitato almeno una volta che mi venisse richiesta una cosa del genere per una consulenza. Ma questa cosa non si può fare, ed ho sempre risposto che al massimo si poteva scoraggiare la registrazione dell’utente, non certo impedirgli di cancellarsi. Arrivo al punto cruciale trattato da Google:
restituzione ed eliminazione dei dati (questo mi pare uno dei punti più importanti, ma posso sbagliarmi) (cito) Mediante la funzionalità dei servizi G Suite o Google Cloud Platform puoi anche eliminare i dati dei clienti in qualsiasi momento. Quando Google riceve una tua istruzione di eliminazione definitiva (come nel caso di un’email eliminata che non può più essere recuperata dal Cestino), eliminerà i dati pertinenti dei clienti da qualsiasi sistema entro un massimo di 180 giorni, a meno che non siano applicabili obblighi di conservazione. In pratica qui Google dice che fornirà dei metodi per garantire la cancellazione di dati puntuali a richiesta dell’utente, ed è interessante che promettano di farlo anche su Google Suite e Google Cloud – quindi (presumo) su Gmail, Google Drive, Google Analytics e (probabilmente) pure la Search Console.In effetti molte di queste funzionalità di cancellazione sono già presenti: banalmente è possibile ad esempio cancellare una mail,
Per ulteriori informazioni fare riferimento alla pagina ufficiale sul GDPR di Google.
GDPR ed il sito aziendale dello zio Ciccio
Cosa comporta il GDPR per chi possiede un sito, un blog o un ecommerce? In realtà non esiste una risposta univoca a questa domanda, come spesso accade nel caso di normative tecnologiche come già fu per la legge sui cookie, del resto; da quello che sono riuscito a capire ad oggi, un possibile approccio potrebbe essere quello di valutare il tipo di servizi offerti, elencarli uno per uno, scendere ad un livello di dettaglio di plugin ed elencare, anche qui, tutto quello che fa funzionare il nostro sito.
Escludendo i servizi a cui si possa accedere anonimamente (ad esempio web service non autenticati), si restringe il campo a tutti i servizi che richiedano autenticazione, per cui ad esempio (lista non esaustiva):
- newsletter del sito, o form in generale (contatti, commenti)
- gestione generale dei cookie interni ed esterni
- presenza di carrello per e-commerce
Cosa fare a questo punto? Modificare o aggiornare le funzionalità del proprio sito per adeguarla ai principi del GDPR, quindi (ad esempio) dare almeno le opportunità elencate all’inizio. La mia impressione rimane quella di sempre: molte aziende dovranno dotarsi di consulenti appositi per stabilire se le misure annesse alla privacy dei propri utenti siano sufficenti, o se invece debbano essere rinforzate, riviste o rielaborate.
Rimangono dei dubbi sostanziali non tanto sull’interpretazione del decreto (che, ricordo, non è la specifica di un software: semmai sono i progettisti di software che devono responsabilizzarsi ed adeguarsi alla legge, proponendo soluzioni del miglior livello possibile), quanto su possibili bad practices che potrebbero svilupparsi in seguito. Nel prossimo articolo che pubblicherò cercherò di affrontare più nel dettaglio questi argomenti, portando alcuni casi reale su cui sto lavorando.
Usa il codice
189ed7ca010140fc2065b06e3802bcd5
per ricevere 5 € dopo l'iscrizione
👇 Contenuti da non perdere 👇
- Domini Internet 🌍
- Gratis 🎉
- Internet 💻
- Marketing & SEO 🌪
- Reti 💻
- Scrivere 🖋
- Sicurezza & Privacy 👁
- Svago 🎈
- 💬 Il nostro canale Telegram: iscriviti
- 🟢 Quali sono le differenze tra Telegram e WhatsApp
- 🔵 Come proteggere WhatsApp con una password (GUIDA)
- 🟠 Cosa indica un HTTP Error 429