Seguici su Telegram, ne vale la pena ❤️ ➡ @trovalost
Vai al contenuto

GDPR: una guida passo-passo per trattare i dati personali sul proprio sito

Cosa dovrebbero prevedere i programmatori ed i webmaster dei siti e delle app all’interno delle loro creazioni, in base all’imminente GDPR? Vista la confusione che si registra sull’argomento, qui ho cercato di stilare una lista di requisiti, basata in parte su quella proposta dal CEO di LogSentinel e in base a quello che sono riuscito a capire dalla normativa io stesso.

Nota: si specifica che quella che segue, ancora una volta, non è un parere legale e non è la soluzione definitiva a tutti i problemi: la questione, peraltro, sembra essere molto soggettiva e variabile a seconda dei contesti. In pratica, ogni sito finisce per fare storia a sè. Per cui, attenendomi a quelli che sono i regolamenti del GDPR per come sono riuscito ad intenderli, cercherò di estrarne i punti salienti nella speranza che possa essere utile ai tanti che ancora non sanno bene cosa fare.


Cerchi un hosting economico per il tuo sito o blog? Tophost ti aspetta (clicca qui)

Introduzione

Parliamo di GDPR per siti web, concentrandoci su quali debbano essere le modalità  del trattamento, cioè sulla filosofia di fondo che dovrebbe guidare progettisti e sviluppatori ammesso che trattino, con un sito o una web app, dati personali di clienti o visitatori occasionali. Quando si approccia al problema la confusione tende a regnare sovrana, ed è stato lo stesso sentimento che mi ha accompagnato prima di decidermi a dedicare qualche giorno allo studio della materia. Cosa che ho appena finito di fare, e che sto proponendo in una serie di articoli a tema (che trovate facilmente raggruppati a questa pagina).

Come offrire le funzionalità  nel sito

In genere le funzionalità  vanno offerte in modo automatico, cioè vanno programmate o integrate via plugin: maggiore autonomia diamo agli utenti sui loro dati personali, meglio è. Se non fosse possibile mettere a disposizione le funzionalità  automatiche per gli utenti (anche solo per un fatto di tempistiche), in genere l’alternativa sembra essere dare supporto manuale ed essere facili da contattare per richiedere eventuali modifiche manuali (ovvero mettere a disposizione un proprio contatto, un responsabile del trattamento dei dati, per consentire le modifiche e la cancellazione dei dati personali): l’importante poi è dare seguito alle richieste entro massimo 30 giorni, da quello che si legge.

Le indicazioni che si possono trarre in prima istanza dall’analisi della situazione esistente saranno, tipicamente, di quattro tipi:

  1. requisiti già  soddisfatti, per aver sempre seguito le pratiche consigliate in fatto di sicurezza informatica e riservatezza dei dati personali;
  2. requisiti da soddisfare al più presto, perchè non c’è stato modo o tempo di farlo prima: carenze di vario genere secondo la falsariga di quanto scritto in seguito;
  3. risoluzione di carenze tecnologiche (CMS non aggiornati, hosting poco sicuri, ecc.);
  4. risoluzione di carenze progettuali (sito progettato per salvare le password senza crittografia, ad esempio)

Generalità  sui dati personali

Per dati personali si intende quei dati che permettano l’identificazione della persona fisica, sia singolarmente che mediante aggregazione con ulteriori informazioni: ad esempio il nome, un numero di identificazione, dati relativi all’ubicazione, un identificativo online o a uno o più elementi caratteristici della sua identità  fisica, fisiologica, genetica, psichica, economica, culturale o sociale.

In genere, poi, il trattamento di dati personali, cioè di qualsiasi tipo di informazione che riguardi una persona fisica, devono essere trattati in modo lecito, corretto e trasparente nei confronti dell’interessato. Bisogna poi definire e comprendere una “finalità ” del trattamento, cioè individuare il motivo per cui i dati vengono raccolto e mantenere fedeltà  e coerenza rispetto alle attività  che vengono svolte.

GDPR e visitatori anonimi: un dubbio amletico (o forse no)

L’articolo 11 del GDPR è stranamente molto poco citato, ma contiene dei concetti molto importanti per chi deve adeguare il proprio sito web: si afferma, infatti, che se le finalità  del trattamento non coinvolgono l’autenticazione dell’utente – e questo, per me, potrebbe coincidere con un visitatore anonimo che arriva su una pagina web del mio sito, non è necessario praticamente fare nulla (cito: Se le finalità  per cui un titolare del trattamento tratta i dati personali non richiedono o non richiedono più l’identificazione dell’interessato, il titolare del trattamento non è obbligato a conservare, acquisire o trattare ulteriori informazioni per identificare l’interessato al solo fine di rispettare il presente regolamento.).

In pratica tutti gli articoli 15, 16, 17, 18, 19 e 20 non vengono applicati, di fatto, qualora non sia coinvolto un meccanismo che consenta l’autenticazione dell’utente. Questo ovviamente non mette fine a qualsiasi discussione ma sembra dare una direttiva abbastanza inequivocabile su come adeguare il vostro sito, qualora sia un semplice blog. Ovviamente tutto sta nel capire quali funzionalità  siano attive da utenti anonimi, ad esempio commenti e form di contatto (e su questo vi invito a leggere oltre).

In generale, poi, l’identificazione univoca dell’utente avviene mediante avanzate tecniche di fingerprinting, cioè combinando ed incrociando più dati tra loro: ad esempio l’indirizzo IP con la posizione geografica, il browser usato, il PC, la data e l’ora a cui ci si è connessi. Per gli utenti anonimi che visitano il sito web, pertanto, sembra  (ma ovviamente rimane un parere professionale del tutto personale) che in linea di massima basti adeguare il sito alle consuete good practices, dare più importanza alla sicurezza ed alla protezione dei dati del sito (non solo quelli personali), evitare tecniche invasive di tracciamento degli utenti ed informare adeguatamente l’utente sull’uso dei cookie (e ne ho parlato anche qui).

Raccolta di dati personali ai fini di statistiche sui visitatori

Una seconda nota interessante è legata al fatto che il trattamento di dati personali a fini di statistiche (ad esempio raccolta di Analytics) non è considerato incompatibile con le finalità  iniziali, cioè è perfettamente ammissibile a determinate condizioni:

  1. i dati personali vanno trattati in maniera da garantire un’adeguata sicurezza e protezione, in modo che stiano alla larga da occhi indiscreti e siano un minimo tutelati da accessi illeciti, imprevisti o non autorizzati: è il requisito noto come “integrità  e riservatezza” che i proprietari dei siti riescono ad ottenere, a mio avviso, sfruttando buone soluzioni di hosting e seguendo sani principi di progettazione del sito – anche sulla base di tecniche di messa in sicurezza o hardening, uso firewall, password sicure, connessioni HTTPS e cosଠvia;
  2. la famosa limitazione della conservazione specifica che non possiamo custodire in eterno dati degli utenti, ma – al tempo stesso – sembra essere concessa una deroga su periodi più lunghi se le finalità  della conservazione sono a scopo statistico (fermo restando le consuete good practices per proteggere quei dati da intrusioni e limitare i rischi di attacchi informatici);
  3. bisogna sfruttare tecniche di pseudononimizzazione per contenere l’impatto privacy, ovvero salvare ad esempio dati parzialmente offuscati – ovviamente in modo compatibile con l’uso per cui vengono sfruttati: ad esempio se decidiamo di criptare un dato, dobbiamo tenere conto che l’app dovrà  essere in grado di decriptarlo lecitamente per i propri scopi.
  4. non si devono mai salvare più dati di quelli strettamente richiesti (minimizzazione dei dati)
  5. i dati devono essere esatti (“esattezza“), ma anche rettificabili e cancellabili su richiesta degli interessati (ad esempio dovrei poter far cancellare dagli analytics di un sito la mia presenza, ammesso che abbia delle buone e lecite ragioni per richiederlo, si suppone (rif. Articolo 5).
Ti potrebbe interessare:  Microsoft rende open source parte del progetto Chakra

Esiste poi un titolare del trattamento, ovvero una figura competente in materia che garantisce che i requisiti siano soddisfatti, in ossequio al principio di responsabilizzazione (ognuno deve essere soggettivamente coinvolto), e mantenendo l’approccio migliore possibile alla questione, secondo anche lo stato dell’arte tecnologico del momento.

Quando è consentito trattare dati personali?

Parliamo ora di siti web che raccolgono dati personali, ad esempio facendo iscrivere i propri utenti o clienti al sito (un e-commerce, un blog, un qualsiasi sito di una community). Ovviamente è tutto consentito come prima, ma ci sono delle condizioni molto precise a cui è necessario adeguarsi.

Diventa lecito, infatti, trattare i dati personali se almeno una di queste condizioni è soddisfatta:

  • è stato espresso consenso al trattamento per una finalità  specifica (o più di una, volendo); ad esempio un sito che permette alle persone di chattare e scambiarsi file potrebbe richiedere lecitamente anagrafica ed email;
  • il consenso è necessario a fini di stipulazione di un contratto, pensiamo ad esempio al sito web di un’assicurazione, oppure a quella di un’affiliazione web, ad un sito di trading online e cosଠvia;
  • il consenso serve ad un determinato obbligo legale;
  • il consenso è necessario per salvaguardare gli interessi vitali della persona (ad es. app in ambito medico);
  • il consenso è necessario per l’esecuzione di un compito in ambito pubblico (ad es. PA);
  • il consenso è necessario per garantire un diritto al titolare del trattamento, a meno che (a seconda dei casi) non dovessero avere più importanza gli interessi dell’interessato, specie se minorenne (rif. Articolo 6)

In generale, il trattamento di dati personali viene regolamentato in base giuridica, e può variare sensibilmente a seconda degli ambiti. Il quadro normativo del GDPR, per quello che sono riuscito a decifrare, si basa sul presupposto fondamentale che sà¬, i dati debbano circolare in modo libero e favoriscano il mercato ed il benessere, ma al tempo stesso è obbligatorio che si seguano dei protocolli precisi e che non si vada contro gli interessi del privato cittadino.

Questo significa che non possiamo prenderci dati di un utente ad esempio a scopo di farlo accedere ad una community online, e poi sfruttare quei dati per invitarlo a cena o mandargli della pubblicità  indesiderata.

Dati personali che è vietato trattare

Il GDPR vieta – salvo specifiche condizioni – di trattare (articolo 9):

  • dati personali che rivelino l’origine razziale o etnica
  • dati personali che rivelino le opinioni politiche
  • dati personali che rivelino le convinzioni religiose o filosofiche
  • dati personali che rivelino l’appartenenza sindacale
  • dati genetici
  • dati biometrici intesi a identificare in modo univoco una persona fisica
  • dati relativi alla salute o
  • dati relativi alla vita sessuale o all’orientamento sessuale della persona (e qui, secondo me, i vari siti adult qualcosina da rivedere la avranno)

Eccezioni considerevoli sono, appunto, quando il consenso venga fornito come indicato dal GDPR, quando sia necessario ai termini di legge, quando sia fornito con adeguate garanzie, quando i dati personali siano manifestatamente pubblici da parte dell’interessato, per via di necessità  specifiche in ambito sanitario, e se lo stesso sia effettuato a fini di archiviazione nel pubblico interesse, di ricerca scientifica o storica o a fini statistici, quindi per studi statistici e (con qualche piccola riserva da valutare, secondo me) anche a fini di marketing.

I dati personali sono inoltre soggetti ad obbligo di segretezza professionale, e possono esistere ulteriori specifiche che cambiano stato per stato.

Condizioni per un consenso “a regola d’arte”

(rif. Articolo 7) Un consenso al trattamento dei dati personali deve essere anzitutto dimostrabile – nel senso che io, responsabile del trattamento, devo poter eventualmente dimostrare che quel consenso è stato davvero espresso dall’interessato: ciò può avvenire mediante dichiarazione scritta e firmata (classico contratto), con l’accortezza di utilizzare un linguaggio semplice e chiaro. In generale, la dimostrabilità  del consenso è materia complessa in ambito di informatica, anche se probabilmente (ad esempio, nel caso dell’iscrizione ad una newsletter) uno potrebbe dimostrare che sia avvenuto un accesso alle ore X del giorno Y, con l’iscrizione dall’IP Z della mail di K. In generale, già  questo requisito dovrebbe porre un grosso limite ai servizi privi di opt-in, ovvero tutti quei servizi web (dai miner di bitcoin fino alle newsletter che inviano spam senza consenso) che lavorano senza richiedere la consapevolezza e/o il consenso esplicito dell’utente finale.

Altro punto fondamentale è che il consenso debba essere revocabile, ovvero facile dare il consenso ma anche facile toglierlo (Il consenso è revocato con la stessa facilità  con cui è accordato). Su questo molti siti sono effettivamente carenti: se do’ il consenso a ricevere una mail periodica da un sito (faccio sempre questo esempio perchè mi sembra immediato), devo essere in grado di poterlo revocare o togliere al volo: un click per iscrivermi, un click per disiscrivermi. Molti siti ad esempio costringono a fare login nel sito prima di disiscriversi, anche per incentivare – secondo loro, ovviamente – la ricezione di email: ma è sempre meglio un consenso consapevole che uno generalista, per cui il GDPR è perfettamente corretto anche dal punto di vista del marketing, a mio parere.

Checkbox di consenso

Il consenso al trattamento dei dati personali, qualora sia stato ottenuto in modo poco chiaro soprattutto, dovrebbe essere nuovamente richiesto: in pratica gli utenti dell’app o del sito andranno notificati (tipicamente via email) della necessità  di accedere ad una pagina specifica, in cui dovrebbero dare un consenso esplicito al trattamento dei dati. Senza questa operazione, molte funzionalità  del sito o dell’app dovrebbero essere disabilitate (su questo lasciatemi un beneficio del dubbio: la normativa non chiarisce perfettamente questo aspetto).

Tipicamente il consenso dovrebbe essere espresso per tutte le volte in cui esista interazione nel sito con condivisione di dati personali, quindi ad esempio (tre esempi che valgono un po’ per tutti i siti):

  • form di contatto: sono costretto, per poter contattare il sito, ad indicare almeno un indirizzo email, un nome ed un cognome, per cui è richiesto che prima dell’invio debba cliccare una spunta non pre-selezionata;
  • modulo dei commenti: anche qui è richiesto un consenso informato, revocabile e dimostrabile, quindi andrebbe inserita una spunta prima di far inserire il commento stesso, sempre nel form. Su questo, per ragioni di tempo, al momento mi sono trovato costretto a disabilitare i commenti sui miei siti web per poi dedicarmi alla questione con più calma in seguito: il mio dubbio è che un form dei commenti non equivalga ad uno di contatto, perchè comunque il commento rimane pubblico e – fino a prova contraria – sono io, webmaster, ad essere già  responsabile direttamente di ciò che viene pubblicato. Non vorrei che la spunta quindi non fosse la soluzione corretta, e per questo preferirei lasciare la questione in sospeso (per adesso);
  • forum / community: sono costretto per poter partecipare ad indicare almeno un indirizzo email, un nome ed un cognome, per cui è richiesto che prima dell’invio debba cliccare una spunta non pre-selezionata.

Diventa quindi necessario inserire delle checkbox di consenso esplicito, che non siano pre-selezionate e che siano chiare nell’intento di acconsentire al trattamento dei dati personali. Il problema, anche qui, non è tanto l’implementazione quanto l’idea che c’è alla base: se il trattamento avviene per scopi statistici o scientifici (ad esempio per addestrare un dispositivo via machine learning) ci sono delle deroghe particolari per cui il permesso non è richiesto esplicitamente, diversamente esso è necessario. Il problema qui è inquadrare correttamente lo scopo dell’attività  (cosiddetto legittimo interesse): visto che il marketing è contemplato come attività  lecita (cioè secondo il GDPR potete lecitamente raccogliere dati degli utenti per fare marketing diretto), questo significa che non sarà  per forza necessario inserire checkbox ovunque. Tantomeno è opportuno pensare di risolvere tutto cospargendo l’app o il sito di checkbox senza guardare, per l’appunto, le implicazioni logiche che questo tipo di integrazione comporta.

Ti potrebbe interessare:  Come mettere offline un sito WordPress per manutenzione

Minorenni e consenso controllato

Altro punto cruciale sono gli utenti dei servizi web e dei siti che siano minorenni: secondo il GDPR, infatti, il trattamento dei dati personali è lecito dai 16 anni in su (in alcuni stati il limite potrebbe essere ridotto a 13 anni). In caso si tratti di minorenni, comunque, sembra essere formalmente necessaria l’autorizzazione di un genitore, una procedura non banale da attuale e progettare in modo sicuro.

Se infatti, ad esempio, un minorenne si iscrivesse ad un sito con la propria email, potrebbe essere necessario richiedere l’inserimento della mail del genitore che, a sua volta, permetta l’autenticazione e l’abilitazione effettiva dell’account del figlio o della figlia. Ovviamente, ciò non toglie che il metodo non sia massimamente usabile e sicuro, per cui si attendono migliori sviluppi tecnologici per questo aspetto. Whatsapp, ad esempio, sta per aumentare il limite minimo di età  per utilizzarlo da 13 a 16 anni, apparentemente per evitare complicazioni di questo tipo.

Scadenza dei dati personali

Chi raccoglie dati per scopi leciti (ad esempio un e-commerce, …) dovrebbe chiarire che quei dati sono cancellati dopo un certo periodo, in quanto la retention infinita degli stessi non è più permessa. Chiaramente qui bisogna fare molta attenzione: se un dato ancora serve all’app o al sito, non è opportuno cancellarlo – ad esempio se un ordine ancora è in corso di consegna, la cancellazione andrebbe schedulata molto dopo che è stato consegnato o confermato.

Diritto di accesso dell’interessato: export e see all my data

Un altro punto fondamentale sui dati personali dell’utente è che egli possa facilmente sapere se esiste un trattamento dei dati in corso e, in caso affermativo, ottenere l’accesso ai dati in qualsiasi momento, quindi conoscendo le finalità  del trattamento (ad es. a scopo pubblicitario o tecnico), i tipi di dati coinvolti, i destinatari delle informazioni eventualmente condivide (ad es. gli altri utenti del sito ed i suoi visitatori, se il sito è pubblico), possibilmente il periodo di conservazione dei dati, i criteri per stabilirne la scadenza (ad esempio 10 anni), la consapevolezza di poter correggere, limitare e/o cancellare quei dati in qualsiasi momento, il diritto di reclamare con un’autorità , l’origine dei dati (se necessario), la presenza di software adibiti alla profilazione dell’utente.

In particolare, l’utente deve poter esportare i propri dati in un formato elettronico comprensibile e standardizzato: ad esempio JSON, documenti XLS, file di testo e cosଠvia. Il processo di export può essere istantaneo (per pochi dati) oppure da eseguire in background e poi notificare all’utente (come fanno da tempo, ad esempio, Twitter e Facebook). In linea di massima, poi, sarebbe opportuno poter esportare i dati personali in un formato più agevole, ovvero che sia leggibile da un essere umano.

Oltre a questo, sono da soddisfare due requisiti fondamentali:

  1. la possibilità  di rettificare i dati in qualsiasi momento, da parte degli utenti del sito;
  2. la possibilità  (o il diritto, per dirla meglio) di cancellare per sempre i propri dati personali, direttiva nota da anni come diritto all’oblio;, che non è altro, poi, che il diritto di essere dimenticati – la cosa su cui, secondo me, Wikipedia dovrebbe sopperire a breve.

Il diritto all’oblio è garantito nei seguenti casi:

  • se il consenso è stato revocato, come detto sopra;
  • se i dati non sono più necessari rispetto alle finalità  iniziali;
  • se l’interessato si oppone al trattamento;
  • se i dati sono stati trattati in modo illecito;
  • se i dati personali sono stati cancellati in base ad un obbligo di legge (art. 16 e 17).

Il tutto si traduce nella possibilità  per gli utenti di poter cancellare liberamente il proprio account e tutti i contenuti associati allo stesso, eventualmente su richiesta al responsabile. Anche le funzionalità  di backup del database, di conseguenza, devono tenere conto di questa esigenze sfruttando una politica adeguata: il ripristino di una copia di backup del DB non dovrebbe ripristinare gli utenti cancellati, per cui ad esempio uno potrebbe fare refresh del DB ogni volta che un utente si cancella per allineare i dati, in sostanza. Le pagine web cancellate devono inoltre, come requisito tecnico di fondo, restituire un errore 404 in modo tale che possano facilmente essere rimosse anche dai motori di ricerca.

Ogni utente dovrebbe pertanto poter accedere liberamente al proprio profilo, inclusa la possibilità  di modificarlo o correggerlo in qualsiasi momento (anche nel caso in cui i dati siano stati inseriti mediante API di login a Facebook o Twitter).

Limitazione del trattamento (restrict data)

Un ulteriore punto base per il trattamento dei dati personali è legato alla limitazione del trattamento (art. 18), cioè al fatto che un utente possa chiedere per una certa circostanza di limitare al minimo necessario oscurare una parte dei propri dati personali, ad esempio se gli stessi non fossero strettamente indispensabili all’applicazione. Penso ad esempio a servizi come Localbitcoins, in cui gli utenti si autenticano con nome e cognome anche a garanzia della propria affidabilità  come venditori: in questi casi, per come la vedo, la limitazione del trattamento immagino che non si possa, nè si debba applicare. Diverso è il caso, ad esempio, in cui si parli delle community che obbligano di fatto gli utenti ad inserire un sacco di dati non strettamente necessari – anche perchè spesso lo fanno per profilarli e potergli inviare pubblicità  mirata in seguita.

L’articolo 19 invita sostanzialmente ad avvisare tutti gli interessati con mezzi adeguati (email ecc.) del trattamento dei dati, e questo lo stanno facendo un po’ tutti mediante le mail che stiamo ricevendo in questi giorni.

Eventualmente dovrebbe essere implementata e messa a disposizione la possibilità  di listare gli utenti del sito e flaggarli come restricted, cioè non più visibili nè sul front-end nè sul back-end.

Da non perdere 👇👇👇



Trovalost esiste da 4438 giorni (12 anni), e contiene ad oggi 4022 articoli (circa 3.217.600 parole in tutto) e 12 servizi online gratuiti. – Leggi un altro articolo a caso
Non ha ancora votato nessuno.

Ti sembra utile o interessante? Vota e fammelo sapere.

Questo sito contribuisce alla audience di sè stesso.
Il nostro network informativo: Lipercubo.it - Pagare.online - Trovalost.it.