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

GDPR per siti web nel dettaglio: seconda parte

In precedenza abbiamo visto le linee generali del GDPR , il modo in cui l’ICANN ha affrontato il GDPR ed un particolare caso studio (Wikipedia); in questo secondo articolo, quindi, cercherò di andare ancora più a fondo nella tematica, in base alla mia analisi ed alle mie letture in merito.

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.

Cos’è il GDPR?

In breve, il GDPR (General Data Protection Regulation, Regolamento generale sulla protezione dei dati) è la regolamentazione europea che sarà  ufficialmente in atto dal 25 maggio 2018, già  è nota da anni come sostanziale requisito per tutti coloro che trattino, sia manualmente che in modo automatico, dati personali. Le principali aziende come Google, Facebook, Linkedin, Reddit, Twitter si stanno adeguando progressivamente in questi giorni, ed anche voi (se avete un sito web) dovreste seguire con attenzione la cosa, senza sottovalutarla nè prenderla all’ultimo secondo.

Nel GDPR emerge, tra le altre cose, che a farla da padrone nel regolamento sia la libera circolazione dei dati personali, ed è questo il principio cardine di tutto. In particolare la circolazione di dati tra i vari Stati Membri dell’UE: non un impedimento o una complicazione, quindi, come alcuni vorrebbero credere, bensଠun provvedimento atto a spingere le aziende a regolamentare (o semplificare per l’utente finale, come vedremo) le modalità  di accesso ai dati personali degli utenti, e garantire loro più diritti e opportunità .

Chi è interessato al GDPR

Parliamo delle aziende che trattino effettivamente dati personali degli utenti, quindi ad esempio mediante login di utenze, ma anche (nota bene) mediante accessi che rendano in qualche modo l’utente identificabile (nazionalità , cookie, indirizzi IP, …).  Ovviamente ci sono da fare delle specifiche per quello che riguarda la realtà  tecnologica – ad esempio: un indirizzo IP dinamico non è detto che consenta di identificare una persona, che peraltro potrebbe accedere da un internet point o dal cellulare di un conoscente, ad esempio. Nel dubbio, quindi, diciamo che qualsiasi sito a qualsiasi livello (sia esso amatoriale, aziendale, community, news ecc.) sembrerebbe essere interessato ad adeguarsi la normativa. Questo vale soprattutto per alcuni tipi di pagine web, tra cui quelle che richiedano l’interazione con l’utente mediante sottoposizione di dati personali come nome, nickname, indirizzo email (ed indirettamente IP, browser usato, cookie, ecc.).

Chiaro che ognuno, poi, dovrà  adeguarsi nel modo che ritiene più opportuno, e questo soprattutto perchè la normativa punta soprattutto a responsabilizzare i proprietari, non a suggerire soluzioni tecniche o implementative specifiche (su cui è dato, per la verità , un discreto margine di scelta). Da un lato questo è un vantaggio, ovviamente, per chi possieda lo stato dell’arte in fatto di tecnologie web; dall’altro sarà  un dramma per chi non programma o non sa progettare un software. Su questo è necessario essere chiari, perchè senza un minimo di consapevolezza mi sembra improbabile che possiate adeguare il vostro sito in modo sicuro (direi almeno al 95%, oltre mi sembra impossibile almeno per quanto ne sappiamo oggi).

Bufale sul GDPR

Come qualsiasi regolamentazione in ambito legale ovviamente, è anche l’interpretazione della legge a farla da padrone. E questo non significa che si debba per forza seguire un’interpretazione di terzi: anzi, è l’esatto contrario! La normativa infatti punta a responsabilizzare i singoli sul trattamento dei dati dei propri clienti, per cui è normale (a mio avviso, s’intende) che ognuno possa e debba provvedere per sè, e che le soluzioni universali (tipo adegua il tuo sito con un click) siano un azzardo per loro (che si prendono una responsabilità  colossale sulle spalle) e per voi (che spesso preferite affidare a terzi e/o perfetti sconosciuti la regolamentazione della privacy del vostro sito: dato l’argomento, poi, è un paradosso piuttosto grottesco).

Non è vero, poi, che si tratti di misure restrittive: anzi, il testo parla più volte di garantire e tutelare la libera circolazione dei dati e quindi di regolamentare un mercato che, effettivamente, non solo nell’ambito del web è stato preda di interpretazioni soggettive, leggende mai confermate e risoluzioni “alla carlona” di problemi anche seri. Si pensi, ad esempio, che ancora oggi molti sono convinti che l’hosting all’estero – per citare una leggenda molto abusata – sia una soluzione per poter aggirare il fisco e non essere soggetti a leggi europee o italiane: cosa che, quantomeno dal punto di vista della privacy, il GDPR in arrivo nega, visto che non si fa alcuna differenza di nazionalità  o di residenza e tutti dovranno adeguarsi (chi con modifiche minime, chi con nessuna, altri rivoluzionando i propri asset).

Un altro diffuso stereotipo, ad esempio, vuole che chi ha scritto questa legge non conosca la tecnologia, cosa che mi sembra falsa o strumentale o – alla meglio – fuorviante. Vediamo, a questo punto, quelli che sono i punti salienti che ho evidenziato in questa mia nuova analisi (spero di riuscire a proporne almeno un’altra, su questo stile, a beneficio di tutti gli interessati).

Le indicazioni da seguire si potrebbero suddividere in tre classi:

  • in certi casi corrispondono con good practices ben note a chi fa siti, relativamente facili da soddisfare;
  • in altri casi sono semplici linee guida da rispettare “come spirito”;
  • in casi ulteriori sono requisiti da aggiungere al proprio sito: del tipo, la possibilità  di esportare i dati personali o di fare opt-out.

Alcuni punti base del GDPR

Di seguito ho evidenziato i punti salienti dal punto di vista di chi fa e/o gestisce siti web. Spero di non aver dimenticato nulla.

  • si scrive che ogni persona ha diritto alla protezione dei dati di carattere personale che lo riguardano, a prescindere dalla nazionalità  e dalla residenza di chi eroga il servizio e di chi ne usufruisce. Qualsiasi trattamenti dei dati dovrebbe essere conforme al GDPR, indipendentemente dal fatto che esso avvenga o meno nell’UE (punto 22). Esempio: se avete una offshore con sede extra EU e server in Mongolia, conta che tipo di servizio offrite, a chi offrite il servizio, non da dove lo erogate, per cui dovrete adeguarvi anche voi al GDPR) (punto 2)
  • al tempo stesso si scrive che il diritto alla protezione dei dati personali non è una prerogativa assoluta o intoccabile, ma dipende dal contesto sociale, in base al principio di proporzionalità , per favorire e garantire il rispetto della vita privata e familiare, del domicilio, delle comunicazioni, la protezione della libertà  di pensiero e personale, di espressione e di informazione e (si noti bene) anche nel rispetto della libertà  d’impresa (punto 4).
  • un particolare accento viene posto sulla sicurezza informatica dei dati personali: ad esempio quando si fa riferimento ad un desiderabile “elevato livello di protezione dei dati personali“, ed al diritto alla protezione degli stessi (punto 6, ad esempio)
  • Il GDPR – si scrive – sembra partire dai punti meno efficaci della direttiva 95/46/CE che non avrebbe impedito abusi e frammentazione della legge, nè eliminato dubbi ed incertezze sul trattamento dei dati personali. Si scrive pertanto che tali eventi possono costituire un vero e proprio freno all’esercizio delle attività  economiche, ed è per questo che vanno prevenute e corrette per tempo (punto 9).
  • Gli Stati Membri possono integrare il regolamento con normative specifiche che varino, stato per stato (punto 10)
  • Sono ammesse alcune deroghe o eccezioni: ad esempio per le aziende con meno di 250 dipendenti (micro, piccole e medie imprese), che dovranno adeguarsi seguendo misure evidentemente differenti (punto 13)
  • Il regolamento serve a tutelare i dati personali delle persone fisiche (cioè persone vere e proprie) e non di quelle giuridiche (un complesso organizzato di persone e/o beni)  (punto 14)
  • La protezione dei dati dovrebbe essere neutrale sotto il profilo tecnologico e non dipendere dalla particolare tecnica utilizzata (punto 15)
  • Il regolamento GDPR non riguarda il trattamento di dati personali di una persona fisica in ambito di attività  a carattere personale o domestico (punto 18)
  • Il GDPR riguarda sia servizi free che a pagamento (punto 23)
  • Il punto 24 evidenzia l’importanza di ricorrere e rispettare il GDPR nel caso in cui esista “monitoraggio del comportamento” degli utenti, cioè andando a verificare se le persone siano tracciate su internet, mediante profilazione della persona fisica finalizzata in particolare a stabilirne gusti, preferenze, comportamenti e posizioni personali.
  • Pseudononimizzazione: qui è necessario fare chiarezza. La procedura in questione (nota in inglese come pseudonymization) non è altro che una tecnica di de-identificazione che sostituisce dati sensibili con identificativi artificiali o pseudonimi, secondo determinati criteri. I dati pseudonomizzati sono più sicuri da trattare, non espongono a rischi di privacy (o comunque li contengono) e si possono comunque usare per analisi statistiche e di altro tipo. Non è quindi necessario crittografare database alla meno peggio: questa è una tecnica per consentire l’analisi dei dati senza violare la privacy degli utenti, anche perchè viene suggerita come tecnica per rispettare gli obblighi e garantire fattivamente la riduzione sostanziale dei rischi per la privacy (punto 28)
  • Altro punto fondamentale: la normativa “sa” che aggregando i dati lasciati dagli utenti sui siti (nello specifico, ma vale anche nelle app) come cookie, indirizzi IP, tag di identificazione a radiofrequenza (RFID), informazioni date e ricevute dal server, possono pervenire alla creazione di fingerprint o impronte digitali univoche, che possono favorire l’identificazione fisica dell’utente – e che per questo devono essere limitate e regolamentate (punto 30). Ovviamente tutto sta nel capire anche la natura del rischio: la normativa è molto attenta a definire il contesto ed a bilanciare i rischi sulla base dell’ambiente in cui sono posti (quindi, per fare un esempio familiare: un conto è un sito molto popolare su un hosting da 10 euro all’anno, altro conto è lo stesso su un’architettura sicura lato server)

Come deve essere fornito il consenso al trattamento dei dati?

Si scrive nel punto 32 del GDPR che l’atto deve essere inequivocabile, ad esempio mediante una casella (checkbox) da spuntare in un sito web – a patto che la stessa sia esplicita sulla propria natura, appunto, e non sia attuabile mediante nessuna azione specifica, inattività  o preselezione. In pratica sembra applicarsi lo stesso principio per cui l’iscrizione ad una newslettere deve essere sempre consapevole ed esplicitamente accettata, e questo dovrebbe valere estensivamente per:

  • form di contatto;
  • form dei commenti;

In genere questi cambiamenti vanno inseriti nelle pagine web specificando come verranno trattati i dati personali, utilizzando un linguaggio semplice e comprensibile per l’utente (e questa dovrebbe essere una buona notizia sia per i webmaster che per gli utenti, in fondo). Ma come dovrà  essere il trattamento dei dati personali dell’utente?

Come deve essere fatto il trattamento

Il trattamento dei dati personali dell’utente (punto 39) dovrà  essere “lecito e corretto”, nello specifico: “dovrebbero essere trasparenti per le persone fisiche le modalità  con cui sono raccolti, utilizzati, consultati o altrimenti trattati dati personali che li riguardano nonchà© la misura in cui i dati personali sono o saranno trattati“.

Questo significa che non possiamo, ad esempio, usare i dati degli utenti per dargli un servizio di newsletter informative, e poi magari rivendere quei dati a terzi oppure inviargli pubblicità , cose già  ampiamente note nel settore, peraltro. Come nota ulteriore, le indicazioni devono essere “facilmente accessibili e comprensibili e che sia utilizzato un linguaggio semplice e chiaro“, che è una novità  importante ed auto-esplicativa, oltre che facile da adempiere per tutti: linguaggio semplice e chiaro sul cosa faremo coi dati personali degli utenti.

Non si possono memorizzare i dati degli utenti all’infinito!

Altro punto basilare (sempre al punto 39) è la cosiddetta retention limitata dei dati: non possiamo conservare i dati degli utenti per sempre. Onde assicurare che i dati personali non siano conservati più a lungo del necessario, il titolare del trattamento dovrebbe stabilire un termine per la cancellazione o per la verifica periodica. àˆ opportuno adottare tutte le misure ragionevoli affinchà© i dati personali inesatti siano rettificati o cancellati. I dati personali dovrebbero essere trattati in modo da garantirne un’adeguata sicurezza e riservatezza, anche per impedire l’accesso o l’utilizzo non autorizzato dei dati personali e delle attrezzature impiegate per il trattamento. Questo punto è particolarmente critico e, ad oggi, Wikipedia non sembra essersi adeguata come scrivevo stamattina (ovviamente è solo un esempio, ed è molto probabile che ci siano altri servizi online che ricadano nello stesso errore.

Finalità  del trattamento dei dati

Inoltre si scrive (punto 42) che le finalità  specifiche del trattamento dei dati personali dovrebbero essere esplicite e legittime e precisate al momento della raccolta di detti dati personali. e non solo: I dati personali dovrebbero essere adeguati, pertinenti e limitati a quanto necessario per le finalità  del loro trattamento, cioè non dovete raccogliere più dati di quelli strettamente necessari.

Questa è anche una regola di progettazione web ben fatta, una good practice che tutti dovrebbero seguire: perchè gestire più dati del necessario, in fondo? Del resto per vendere un servizio online di qualità  (ad esempio di video on demand) basta chiedere (come fa Netflix ad esempio) solo ed esclusivamente l’email – non ci servono nome, cognome, sesso, residenza, indirizzo come impropriamente tendono a fare molti, no? Mi pare che fare il contrario sia frutto di una mentalità  di marketing vagamente retrograda, poi ovviamente non voglio generalizzare e posso sbagliarmi sui casi specifici.

Ricordo solo – perchè mi pare chiaro dalla lettura e dall’analisi del documento – che è contro la normativa raccogliere dati degli utenti senza esplicitare lo scopo per cui viene fatto.

Il consenso non è mai sottinteso: deve essere dimostrabile

Altro punto critico (punto 42) della normativa in vigore ufficialmente (a brevissimo) riguarda il fatto che il titolare del trattamento dovrebbe essere in grado di dimostrare che l’interessato ha acconsentito al trattamento, ovvero che:

i fini di un consenso informato, l’interessato dovrebbe essere posto a conoscenza almeno dell’identità  del titolare del trattamento e delle finalità  del trattamento cui sono destinati i dati personali. Il consenso non dovrebbe essere considerato liberamente espresso se l’interessato non è in grado di operare una scelta autenticamente libera o è nell’impossibilità  di rifiutare o revocare il consenso senza subire pregiudizio.

In altri termini il consenso al trattamento dei dati personali, oltre a dover essere esplicito, deve anche essere dimostrabile in futuro; ovviamente qui bisognerebbe anzitutto capire gli ambiti applicativi di questo per un sito web. Se è vero che basta una semplice visita da visitatore anonimo a doverci imporre di visualizzare una finestra informativa – in cui si chieda di accettare i cookie ed il GDPR per proseguire, a questo punto – resta un dubbio sull’aver inteso correttamente la cosa: qualora uno non dia il consenso cosa succederebbe? Se ad esempio non accettasse il trattamento del propri dati per motivi personali (evidentemente leciti), come dovrebbe “comportarsi” il sito web? Si tratta di un interrogativo a cui ancora, ad oggi, non riesco a trovare una risposta netta e chiara. Chiaro che poi, a livello pratico, sono dell’idea che nessun sito chiederà  mai di dare il consenso al trattamento dei dati personali sulla semplice lettura di un blog, ma potrebbe decidere di farlo (o essere obbligato) qualora l’utente usi un form di contatto oppure, ad esempio, vada a commentare nel blog (sono esemplificazioni che sto facendo io, non sono esplicitamente presenti nel decreto, ndr).

Poi va capito come implementare la cosa: apparentemente, da un punto di vista tecnologico il consenso è dimostrabile esclusivamente con firma autenticata digitale. Mi pare pero’ una soluzione troppo drastica e sostanzialmente inadeguata – anche perchè dovresti fare firmare digitalmente il consenso a tutti i tuoi visitatori, francamente improponibile e dispendioso oltre che contrario alla libera circolazione dei dati (premessa fondamentale del GDPR, non dimentichiamo). Posso pensare di far firmare il consenso in modo sicuro anche senza scomodare firma digitale, ovviamente, anche usando HTTPS e garantendo la sicurezza del database e delle infrastrutture, ma al tempo stesso devo assumermi i rischi e le responsabilità  del caso – in modo esplicito, a differenza del passato.

Di seguito sono espressi ulteriori punti importanti da rispettare, che danno anche un senso più misurato rispetto a tanti articoli allarmistici che stanno circolando in queste ore. Il trattamento va considerato lecito se è necessario per stipulare un contratto, ad esempio, ma anche per tutelare o proteggere interessi vitali. Il legittimo interesse del trattamento dei dati personali può anche riguardare la prevenzione delle frodi e, in particolare, le finalità  di marketing diretto sono accettate (espresso ad es. nel punto 47).

Modalità  di accertamento del consenso al trattamento

Il punto 50 descrive in generale come debba essere effettuato l’accertamento, cioè come si debba procedere nel caso in cui uno, ad esempio, abbia degli utenti già  registrati nel proprio sito (ad esempio i contributor di un blog collaborativo, come mi sta capitando di dover gestire in questo periodo). Premesso che, come specificato anche nelle premesse del GDPR, il titolare del trattamento (che potrebbe coincidere col webmaster o con il proprietario del sito) dovrebbe:

  1. verificare che tutti i requisiti basilari siano soddisfatti;
  2. fatto questo, adeguare tecnologicamente ed informare in modo consapevole gli utenti, in base al tipo di rapporto che possiede con i propri utenti ed in base alle aspettative di questi ultimi per quello che riguarda un “ragionevole utilizzo”.

Chiaro che, in sostanza, il GDPR mostra una sostanziale coerenza con una forma di ragionevolezza di fondo: l’idea di base è quella di non abusare dei dati personali che i nostri utenti ci cedono, o che utilizzano per contattarci o per commentare nel sito, per scriverci, per pubblicare contenuti, per usare una community e cosଠvia. Non è semplice formalizzare meglio la cosa, per cui la mia idea è quella di progettare entro la prossima settimana un plugin per WordPress che venga incontro alla maggioranza delle esigenze del GDPR per webmaster, e che possa quantomeno personalizzarsi a dovere. La cosa essenziale per gli sviluppatori credo che sia la semplicità  e la modularità , specie se uno debba adeguare o gestire più siti web.

Il punto 50 esprime altri concetti fondamentali, a mio avviso: ribadendo che le finalità  della raccolta di dati personali debbano essere coerenti nel tempo, prevede anche che il consenso possa essere cambiato dopo un’accettazione esplicita da parte del cliente. Questo potrebbe coincidere con una alert di conferma del trattamento, da presentare una volta e poi basta (per un po’, almeno) sullo schermo del browser, ovviamente con modalità  tali da non interferire inutilmente, in seguito, con la navigazione, e fermo restando che non si capisce bene cosa debba succede nel caso in cui un utente decida di non approvare. Il diritto di opporsi deve essere chiarificato e messo a disposizione dell’utente, quindi ciò si potrebbe esplicitare sia nel non accettare che il sito tratti i suoi dati (e in quel caso, ad esempio, redirect su Google) sia nel rifiutare un trattamento precedente (ed in questo caso si tratterebbe di un opt-out, cioè della possibilità  di uscire dal sito e cancellare liberamente il proprio account).

Pensiamo a riguardo ai tantissimi, troppi siti web in cui non è praticamente più possibile disiscriversi (almeno ad oggi), tutti i siti e servizi in blacklist su AccountKiller.; certo bisognerà  capire se davvero la cosa costituisce una violazione del GDPR, ma di sicuro molti dovranno adeguare le proprie politiche dando la possibilità  all’utente di fare opt-out facilitato, di discriversi in qualsiasi momento e di poter cancellare ogni traccia dei propri dati.

Logica di cancellazione dei dati

Di conseguenza, per quanto ne sappiamo ogni sito dovrebbe prevedere esplicitamente (ammesso che preveda di potersi registrare agli utenti comuni):

  • l’opzione di cancellare il proprio account (opt-out di account);
  • l’opzione di cancellare i contenuti annessi al proprio account (opt-out di account e contenuti)

La cancellazione dovrebbe essere fisica (es. DELETE su MySQL) e non logica (es. flag di MYSQL a false).

Fonte originale

Per leggere il testo originale del decreto potete andare a questo link:

http://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC

👇 Da non perdere 👇



Questo sito esiste da 4471 giorni (12 anni), e contiene ad oggi 7744 articoli (circa 6.195.200 parole in tutto) e 15 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.