GPDR per WordPress, ecco cosa serve.

GPDR per WordPress, ecco cosa serve.

di Pubblicato: 2 maggio 2018 0 commenti

Dopo la norma sulla Cookie Law, che per altro si può dire sia stata sostanzialmente “useless” in quanto chiunque ha inserito il noiosissimo banner rendendo di fatto un “rumore di fondo” la questione per l’utenza, arriva questa estensione che prende il nome di GPDR. Ovvero regolamento generale sulla protezione dei dati, e nel mezzo di altre cose più o meno inutili presenta alcune componenti utili. La sua applicazione entrerà in vigore il 25 maggio 2018 e il non rispetto delle regole prevede sanzioni pesanti.

Va detto che la GPDR di fatto è rivolta alle imprese, quindi sostanzialmente sono queste ultime ad esserne maggiormente interessate, tuttavia la norma non prevede in modo esplicito l’esenzione per il classico blog, e quindi alcune parti di fatto possono interessare anche questa parte del web. WordPress sta lavorando da mesi alla questione e sono previste sostanziali novità che ci verranno in aiuto con la versione 4.9.6.

Nonostante l’arrivo della nuova versione bisogna fare uno screening del proprio sito web e verificare alcune situazioni come:

Permetti la registrazione degli utenti?
Utilizzi cookie e/o sistemi di profilazione anche con l’utilizzo di software conto terzi?
I plugin che utilizzi nel sito sono conformi alla GPDR?

in questo senso le aree più critiche sono:

sezione commenti,
registrazione utente se prevista,
forum e/o bacheche e/o chat,
banner,
Google Analytics e/o sistemi di metrica per visualizzazioni alternativi,
form e servizi relativi a newsletter / mail  marketing,
form contatti,
servizi dei plugin.

In sintesi la GPDR prevede:

Documentazione.

Alcune di questi articoli di fatto (e fortunatamente) si sovrappongono alla cookie law. Il primo è sicuramente quello della documentazione che solitamente è la privacy e dove devono essere esplicitamente indicati quali tipi di cookie vengono registrati e per quanto tempo vengono conservati (ricordo che questi sono memorizzati all’interno del computer dell’utente, non nel nostro server). Lo stesso dovrà valere per i dati registrati dal server o da servizi terzi quali ad esempio i servizi di monitoraggio delle visite (Google Analytics o WordPress Statistics). In questo caso si può fare riferimento ai testi già predisposti dai relativi servizi.

Alcune precisazioni riguardo Google Analytics, fate attenzione a non raccogliere i dati (gli indirizzi IP) delle utenze, in questo caso si perde un sostanziale aiuto al monitoraggio ma vi evitate non poche rogne.

Fate attenzione ai moduli di contatto, in particolare al fatto che non tengano sul server le informazioni inserite. Se ad esempio questo invia direttamente la mail non è un problema, ma se memorizza i dati sul server va chiaramente indicato nel modulo.

Form di consenso.

Bisogna assicurarsi che le form di consenso ai dati personali non siano già spuntate o precompilate per default. Qui la norma parla in modo esplicito di form, nel caso della cookie law si è andati verso un utilizzo di silenzio assenso, ovvero non è presente una form in senso classico ma una sorta di banner non bloccante. Meglio se questo oscura una parte del sito (ad esempio la parte superiore o inferiore della pagina purché sempre a vista) con il tasto accetta ben in evidenza come dimensioni e colore. Questo permette di poter fruire il sito anche senza accettare in modo forzato, purché nel breve disclaimer sia chiaramente indicato che tale comportamento sia da ritenere come accettazione della privacy. In questo modo non si penalizzano i motori di ricerca e si porta ad una iterazione con l’utente che sia il meno fastidiosa possibile. Attenzione che se avete delle checkbox di spunta nel vostro sistema di consenso, questa potrebbe essere assimilabile ad una form, e comunque non deve mai essere selezionata per default. La questione è ancora piuttosto incerta, nel senso che non è del tutto chiaro se il sistema attuale possa essere accettato dalla GPDR.

Criptazione.

Utilizzare SSL per il vostro sito, qui una spiegazione su come usare Letsencrypt, oltre che caldamente consigliato da Google stessa. Ora diventa praticamente un obbligo. La criptazione nel caso registriate informazioni utente, ad esempio un forum o i dati di una mailing list, deve essere fatta anche a livello di database. Lo scopo della norma è che in caso di falle di sicurezza del sito, i dati abbiano un ulteriore layer di sicurezza.

Processo di cancellazione dei dati.

Questa parte è un po’ aleatoria, nel senso che bisogna avere una procedura di cancellazione dei dati dell’utente. Non è specificato che lo debba fare l’utente ma che ci sia la possibilità di farlo. Per WordPress succede nel caso in cui abbiate aperto la registrazione utenti nel vostro blog. Di fatto la procedura esiste in WordPress, ma è solo nelle disponibilità dell’admin. Per chi utilizza le connessioni Oauth, cioè ad esempio nei commenti i tasti “commenta con Facebook/Google eccetera” si deve cancellare il commento oppure modificare i dati di profilazione (nome ed email) del commento stesso. Questo lo può fare l’admin ma anche l’utente stesso.

Processo di esportazione dei dati.

Qui arrivano potenzialmente le rogne, è necessario poter offrire un sistema di esportazione dei propri dati, ad esempio in formato CSV. Ricordo che il discorso vale per coloro che di fatto hanno profilazione utente, come ad esempio la registrazione utente o la sottoscrizioni di servizi quali le mail newsletter. Con la versione 4.9.6 di WordPress dovrebbe essere presente un tool di esportazione dei dati direttamente nel core del codice.

Procedura di comunicazione della violazione dei dati.

In caso il sito venga compromesso, si deve avvisare entro 72 ore tutta l’utenza. Questa è una delle norme che trovo un pò border-line, poiché per avvisarla devi trattenere i dati con tutto quello che ne consegue come abbiamo visto dai punti precedenti, insomma un po’ il cane che si morde la coda. Ad ogni modo è bene dimostrare di avere un sistema di backup e un servizio di hosting o server provider che aderisca alla GPDR. Se gestite un server, in aggiunta, tenete aggiornato il sistema operativo e controllate che il firewall sia in funzione e correttamente configurato.

Plugin di WordPress.

Se il core si sta adeguando al sistema GPDR il discorso plugin può essere un problema. Infatti non tutti sono aggiornati con regolarità, e talvolta capita di installarne uno per uno specifico scopo, mentre lo stesso presenta altre feature che potrebbero violare la GPDR stessa. Quindi è necessario analizzare il proprio parco plugin e verificare uno ad uno le varie funzionalità (ad esempio contatto/utilizzo di servizi esterni) e i cookie che potrebbero installare.

Conclusioni.

Come fu per la Cookie law mi pare che lo sforzo a cui viene sottoposto il web sia quanto meno criticabile. E’ chiaro che queste norme sono fatte per arginare una certa leggerezza dei social. Trovo che la questione come al solito sia una occasione mancata. Ad esempio non si è messo becco sulla procedura di registrazione in quanto tale. Negli ultimi anni molti servizi web, anche noti, permettono la registrazione utilizzando un indirizzo di posta elettronica, senza verificare che chi effettua la procedura sia veramente il proprietario della casella. Bene che si imponga un sistema di cancellazione, ma qui serve un approccio che veda una responsabilizzazione di chi crea i siti web e chi li utilizza.

Vuoi dire o aggiungere qualcosa?

sezione commenti aperta al pubblico

Non ci sono ancora commenti!

Puoi essere il primo a commentare.

Rispondi

This site uses Akismet to reduce spam. Learn how your comment data is processed.