A partire dal 25 maggio 2018, entrerà in vigore il GDPR un nuovo regolamento che integra una direttiva europea sui cookie (nota come EUCookieLaw) entrata in vigore il 30 maggio 2015.
Molti hanno temuto che sarei rimasto in disparte, notando che la libreria EUCookieLaw non veniva aggiornata da molto, troppo tempo.
Molti hanno anche segnalato bug, malfunzionamenti e complicazioni varie. C’è chi lo ha fatto attraverso il forum di WordPress, chi lo ha fatto attraverso email e chi invece ha usato l’issue tracker di GitHub.
Ad un certo punto mi sono chiseto se fosse stato più conveniente correggere gli errori di EUCookieLaw ed integrare le funzionalità per il GDPR oppure se la strada corretta sarebbe stata di riscriverlo da capo, rendendo EUCookieLaw compatibile con qualsiasi tecnologia lato server. La prima scelta sarebbe stata la più semplice da attuare, avevo già tutto e c’erano pochi errori, ma avrebbe significato continuare a coltivare il mio piccolo orticello trascurando tutti quei siti che invece non hanno WordPress, Joomla o Drupal. Avrei inoltre trascurato tutti quei siti vetrina che sono fatti in solo HTML, ritornati di moda con i vari tool visuali che ti aiutano a costruirli partendo da una base grafica comune: BootStrap.
Quindi dopo diverse nottate insonni, una grande riflessione e la volontà di rendere aperto a tutti EUCookieLaw, ho deciso di riscriverlo da zero. Un reboot che però doveva tener conto di diversi aspetti. Quindi (a settembre) mi ero preparato una sorta di decalogo sulle funzionalità, le migliorie da apportare e le criticità emerse dall’attuale versione:
- Status quo:
- La versione ad oggi disponibile di EUCookieLaw è abbastanza semplice da utilizzare
- Esiste una soluzione per WordPress
- Esiste una soluzione per Drupal
- C’è della documentazione per installarlo in Joomla
- Consente il blocco preventivo dei cookie
- Ci sono talvolta delle criticità con la gestione della cache di WordPress
- Non risulta intuitivo per tutti
- La documentazione è solo in inglese
- ci sono degli articoli in italiano
- Non gestisce il GDPR
- Un’estetica abbastanza dozzinale
- Cosa migliorare?
- Renderlo ancora più semplice
- Renderlo più accattivante, per chi lo configura e per chi lo guarda sui siti.
- Deve essere gradevole e funzionale da desktop e da mobile.
- Deve essere integrabile con i CMS con cui è già funzionante.
- Deve funzionare anche con i siti in ASP
- Deve funzionare con qualsiasi sito vetrina
- Deve essere indipendente dalla tecnologia lato server
- Nessuna dipendenza da libreria di terze parti.
- Deve consentire anche la gestione del GDPR.
- Migliorare la documentazione
- Creare numerosi esempi d’uso e tutorial anche per i non addetti ai lavori
- Deve consentire la scelta granulare dei consensi
- Deve essere possibile revocare uno o più consensi
- Deve essere facilmente configurabile
- Non deve perdere le funzionalità attuali
- Non deve avere problemi con nessun plugin e nessun’altra libreria
Quindi ho iniziato una valutazione di fattibilità accurata dove avevo bisogno di fornire una risposta dettagliata per ciascuno dei punti di cui sopra, ad alcune questioni inizialmente non avevo risposte, ma alla fine ho trovato la quadra:
Compatibilità con plugin di terze parti
Numerosi utenti hanno segnalato nel tempo problemi di compatibilità con alcuni plugin. A molte segnalazioni è stata data risposta attraverso un puntuale adattamento del plugin, rendendolo però di fatto molto più pesante e articolato di quanto servisse. In alcuni casi il problema era legato ai vari plugin di gestione della cache su WordPress. Tutto ciò si è tradotto talvolta in problemi di performance.
L’unico modo per rendere la libreria compatibile con qualsiasi plugin sarebbe stato di farlo girare tutto lato client nel browser. Questo è stato il primo passo che mi ha portato a ripensare EUCookieLaw3 come una libreria totalmente JavaScript. Quindi dopo aver identificato le eventuali incompatibilità con i vari browser ho deciso di procedere proprio su questa strada, trascurando tutte le versioni di Internet Explorer precedenti alla 10 ma avendo cura di farlo funzionare in tutti gli altri browser.
Perchè a partire da Internet Explorer 10?
Al contrario di molti, ritengo che il GDPR e la Cookie Law siano significativi per tutelare la nostra privacy su internet. È anche vero che un’interpretazione o un’applicazione errata delle leggi fa partorire mostri.
Mettiamo caso che io abiti in una zona ad alto rischio di furti in appartamento, di certo non esco di casa se ho le porte di cartone. Rischierei che qualsiasi malintenzionato possa entrare in casa e prelevare indisturbato ogni cosa. Ecco, chi naviga sul web con una versione del browser datato è paragonabile a chi esce dalla casa con le porte di cartone. Quindi non avendo di per se cura della propria privacy, perchè dovremmo farci noi paladini di una privacy che non è tutelata prima dai diretti interessati? Ovviamente la domanda è retorica! :-)
Consenso granulare e revoca
Nelle vecchie versioni di EUCookieLaw non si aveva la possibilità di scegliere quali servizi accettare e quali rifiutare. Era una scelta: o tutto o niente. La vecchia direttiva lo consentiva, non c’era negligenza, ma semplice adempimento a direttive europee. Con il GDPR le regole sono cambiate: l’utente non può accettare tutto o niente. Potrebbe decidere di accettare i cookie di Facebook ma non quelli di Twitter, potrebbe non voler dare il consenso al trattamento dei dati personali per servizi di email marketing svolti dal sito. Quindi è stata presa la decisione di suddividere i vari servizi in gruppi di approvazione, consentendo al titolare del sito la volontà di scegliere ed identificare i servizi forniti, dando le dovute indicazioni all’utente sulla finalità del trattamento e quindi lasciare a quest ultimo la scelta finale di quali servizi accettare.
L’utente però deve essere in grado di revocare il consenso precedentemente fornito per i singoli trattamenti e, finalmente con la nuova versione, tutto questo è diventato realtà!
GDPR
Secondo la confusione generale che c’è in giro, l’unica cosa su cui sembra che tutti gli esperti e meno esperti convergano è che il consenso e la revoca devono essere registrati… Non tutti però sono d’accordo. Questa è stata una sfida abbastanza ardua per me, perchè volevo garantire l’anonimato del consenso ma allo stesso tempo la riconducibilità ad un certo utente delle scelte nel tempo. Inoltre volevo svincolare coloro che non avrebbero voluto conservare tale registrazione. Le sfide complesse mi hanno sempre affascinato e ho sempre adottato il motto “Nulla è impossibile, è solo una questione di tempo“.
Per chi ritenesse opportuno conservare la registrazione elettronica del consenso, saranno pubblicati nei prossimi giorni una serie di articoli nei quali spiegherò dettagliatamente come fare per conservare lo stato delle autorizzazioni al trattamento dei dati dell’utente sul server. In generale il principio è il seguente:
Quando un utente fornisce il consenso per una certa finalità (per esempio Autorizzo alla visualizzazione del widget di Facebook), EUCookieLaw3, richiama una funzione (se esiste) esterna con tre parametri di input:
- la finalità per la quale l’utente ha fornito il consenso
- lo stato dell’autorizzazione
- la data esatta in cui è stato autorizzato il trattamento
Sarà quindi a cura di questa funzione esterna decidere cosa fare dei dati ricevuti, ignorarli o registrarli da qualche parte (cookie, server o ovunque ritenga opportuno) e nella forma ritenuta più corretta.
Quando lo stesso utente dopo qualche ora o qualche giorno decide di revocare il suo consenso ad una specifica finalità, viene invocata la medesima funzione che riceverà in input le solite 3 informazioni:
- la finalità per la quale richiede la revoca
- l’indicazione che è una revoca
- la data esatta in cui è stato revocato tale trattamento
Attraverso il plugin per WordPress, ho fatto in modo che questo sia facilmente configurabile da pannello di controllo e ci sia la possibilità di consultare tutte le autorizzazioni e le revoche occorse nel tempo.
Inoltre ciascun utente in autonomia può essere in grado di visionare i cambiamenti delle sue decisioni nel tempo.
CMS-agnostic e dependance-free
Forse è una delle sfide più grandi che possa essere proposta ad uno sviluppatore: trovare una soluzione che sia compatibile con qualsiasi ambiente server (Windows, Linux), con qualsiasi tecnologia (PHP, ASP, Python, Java, ecc.), con qualsiasi browser moderno e che non si basi su nessuna libreria esistente.
La soluzione che ho adottato è stata di delegare tutte le operazioni a JavaScript, attraverso il quale vengono intercettate tutte le modifiche che avvengono nella pagina web e, in base alle regole di configurazione fornite ad EUCookieLaw3, alcuni contenuti/servizi risulteranno non disponibili fino al consenso dell’utente, secondo le regole di blocco definite dal titolare del sito.
Facilmente configurabile
Va bene delegare tutto a JavaScript per avere una certa indipendenza dal CMS e dal server, ma la complessità maggiore a questo punto sarebbe stata delegata al titolare del sito nella configurazione di EUCookieLaw3. Ricordo ancora che ci sono state nelle vecchie versioni di EUCookieLaw molte richieste di supporto di questo tipo “Come modifico il titolo del banner?“, “Come posso mettere il tag strong al posto di h1” (c’era anche un bug).
Essendo uno e non trino (e nemmeno bino, scusate la battutaccia… :-D ) mi sono reso conto che non avrei potuto sostenere nel lungo periodo una mole elevata di richieste, decretando sin da subito il fallimento di una soluzione di questo tipo, seppure potenzialmente valida. Fino alla versione 2.7 di EUCookieLaw, per gli utilizzatori di WordPress era abbastanza semplice (ma qualcuno lo riteneva comunque complesso) configurare il banner informativo, lo era molto meno per chi doveva configurarsi il banner a mano, pur considerando che la documentazione era estremamente dettagliata. Per venire incontro a tutti gli utenti, ho deciso di sviluppare una micro WebApp liberamente utilizzabile da tutti denominata EUCookieLaw3 Configuration Builder che consente di configurare tutti gli aspetti di EUCookieLaw dal tipo di azione utilizzata per decretare il consenso dell’utente al testo che dovrà essere utilizzato nei pulsanti passando ovviamente dai gruppi di trattamento.
Funzionale da desktop e da mobile
Rifacendomi alla qualità di framework blasonati e considerando l’elevata diffusione di Bootstrap anche tra i temi per WordPress, ho deciso di adottare la nomenclatura delle classi di Bootrsap 3 per la finestra modale.
Qualcuno si sarà domandato perchè la scelta sia ricaduta sulla versione 3 e non sulla versione 4. La risposta è semplice: molti siti sono già stati sviluppati almeno un anno fa e molti di essi facevano uso di Bootstrap 3, quindi sarebbe stata una forzatura richiedere un’aggiornamento dei temi alla versione 4.
Tuttavia EUCookieLaw è in grado di funzionare anche senza Bootstrap, purchè ci sia da parte del titolare del sito la predisposizione delle necessarie classi per consentire la corretta visualizzazione del banner informativo. Per lo scopo ho creato un repository nel quale sono pubblicati i vari temi disponibili, da scaricare ed utilizzare sul proprio sito e le istruzioni per creare il proprio stile.
Migliorare la documentazione
Seppur la documentazione prodotta è veramente tanta, mi rendo conto che è sempre articolata da leggere per i non tecnici, e talvolta anche per i tecnici. Quindi ho organizzato in 3 repository distinti la libreria JavaScript, i temi ed il plugin per WordPress. Così anche chi dovesse richiedere supporto su un argomento specifico, potrà farlo nell’opportuna area.
Seguiranno comunque nei prossimi giorni numerosi articoli su come configurare EUCookieLaw3 e come gestire le varie funzionalità.
Nel frattempo ringrazio tutti gli amici, virtuali e non, che mi hanno supportato, sostenuto ed incitato durante tutte le fasi di reingegnerizzazione e sviluppo della nuova versione di EUCookieLaw3!