redditodicittadinanza.gov.it ed i font (di Google)

Mi immetto nella polemica nata dalla analisi di Matteo Flora del sito www.redditodicittadinanza.gov.it per “gettare ulteriore benzina sul fuoco”.

Semplificando, Matteo dice che adottando, per la pagina web del sito in oggetto, un font di Google, si consegnano ad esso “i dati di navigazione degli utenti sul sito”.

Premessa per i non tecnici: cosa sono questi fonts di Google? Si tratta di una collezione di font (la rappresentazione dei caratteri sullo schermo) che Google rende disponibili “gratuitamente” a tutti coloro che li vogliono adottare per migliorare l’aspetto del proprio sito.
Moltissimi Framework e C.M.S. li hanno adottati di default (anche WordPress), con il risultato che molti siti li stanno usando. Questo comporta che, quando un utente si collega ad uno di questi siti, il suo browser procede a scaricare il font necessario dai server dedicati di Google (salvo che il font sia già presente nella cache del browser ed altro, ma non vorrei scendere troppo nei dettagli tecnici).
Come sappiamo, ogni qualvolta si realizza una connessione tcp-ip tra un browser ed un server, nel server si raccolgono vari dati tecnici, tra i quali l’indirizzo IP del client, che come ci dicono i vari Garanti, Corte di Giustizia UE, ecc. costituisce un dato personale; Google, per tali dati, si definisce data controller (impostazione che non condivido, ma qui si aprirebbe un lungo e complesso discorso).
L’adozione dei fonts Google su molteplici siti web determina una specie di “rete di sensori globale” dalla quale Google potrebbe acquisire informazioni; non che ne abbia particolarmente bisogno, dato che quasi tutti utilizzano il servizio “gratuito” Google Analytics, per non parlare di Ads, AdSense & C.

L’informativa privacy del sito redditodicittadinanza.gov.it riporta ad una pagina sul sito del Ministero del Lavoro e delle Politiche Sociali; non ha le caratteristiche richieste dal GDPR e non si riesce neanche a capire chi sia il DPO.

Aggiungo un elemento, a mio avviso trascurato ma determinante: perchè un sito del Governo Italiano deve stare in un server di una azienda americana, presso un datacenter americano, al di fuori dello spazio UE e delle tutele del GDPR?

P.S. io dico il font e non la font; il perchè lo trovate anche qui.

P.S.2 il codice WordPress di questo sito è stato da me modificato, da tempo, per caricare i webfont dal server locale (e non dai server di Google); questo rende il rendering delle pagine leggermente più lento, ma – per me – assolutamente necessario.

Aggiornamento: il Presidente del Garante per la protezione dei dati personali, in una memoria pubblicata nel pomeriggio, interviene con alcune osservazioni sul ddl di conversione in legge del decreto-legge 28 gennaio 2019, n. 4 (reddito di cittadinanza).
Al punto 5:
Un’ultima osservazione va riferita  all’architettura del sito web del Governo, dedicato al reddito di cittadinanza. 
Si segnala, al riguardo, che il sito rivela, già nel suo attuale stato di sviluppo, alcune carenze, in particolare, nell’informativa sul trattamento dei dati e nelle modalità tecniche della sua implementazione (che, ad oggi, comportano un’indebita e non trasparente trasmissione a terzi dei dati di navigazione, quali indirizzi IP e orario di connessione, da parte dei visitatori del medesimo sito). 


GDPR e fattura elettronica

Come saprete, l’Autorità di Controllo italiana si è espressa sulla imminente estensione dell’obbligo di fatturazione elettronica alle operazioni “business to business” e “business to consumer” , emanando un provvedimento nel quale ha evidenziato diverse importanti criticità.

Nel confermare tutte quante le preoccupazioni espresse dal Garante per la Protezione dei Dati Personali, vorrei evidenziare tre punti in particolare.

Il trattamento di tutti i dati relativi ad una fattura, comprese le descrizioni di ogni riga, oltre che violare i principi di privacy by default e di minimizzazione, determinano il rischio che soggetti terzi non autorizzati possano avere accesso a tali informazioni; tale condizione è particolarmente rilevante qualora la transazione economica riguardi interessi coperti da segreti aziendali, industriali o comunque si debba mantenere la riservatezza su tali importi o sconti applicati.

Come secondo punto, occorre considerare gli aspetti derivanti dalla funzione degli “intermediari e dagli altri soggetti operanti nell’ambito della fatturazione elettronica”;  si realizzeranno dei trattamenti “big-data”, soggetti non solo ai rischi indicati dal Garante ma anche a procedure di “data mining”, tramite le quali estrarre rilevanti e preziosissime informazioni sottese.

Come terzo aspetto, e consentitemi una notazione tecnologica; ai giorni nostri, l’adozione del protocollo ftp (nato nel 1971) per trasferire elevate quantità di dati, anche personali e potenzialmente di “levatura particolare”, equivale ad inviare dati personali usando piccioni viaggiatori. Ciò conferma che, spesso, chi determina non ha esatta contezza degli aspetti tecnici e delle conseguenze delle proprie decisioni.

Mi auguro che, in extremis, qualcuno si prenda la briga quantomeno di cercare soluzioni, procedurali e tecniche.

Aggiornamento del 21 dicembre: al tavolo tecnico svoltosi nei giorni scorsi tra Agenzia delle Entrate e Garante Privacy, ha fatto seguito un provvedimento del Garante.

Invito tutti i soggetti “coinvolti” nella fatturazione elettronica a leggere con attenzione il provvedimento, in particolare gli operatori sanitari, gli intermediari e gli altri soggetti delegati nell’ambito della fatturazione elettronica.

Sono state accettate le contestazioni della Autorità di Controllo italiana relative alla sproporzione della memorizzazione di tutti i dati delle fatture (le descrizioni di riga, ma anche i dati correlati, quali quelli dei vettori) e quelle relative alla assoluta insicurezza del protocollo ftp, che adesso verrà sostituito con sftp (logica conseguenza).

L’ Autorità ha autorizzato la fatturazione elettronica, alle condizioni indicate nel provvedimento, chiedendo alla Agenzia delle Entrate, entro il 15 aprile 2019, di rifare la DPIA (adesso carente in alcune parti) e di valutare l’adozione di algoritmi di cifratura dei files XML trasmessi al SDI.

GDPR e 231

Abbiamo già detto che la protezione dei dati personali non è più (non lo è mai stato) produrre scartoffie che nessuno legge, conosce o applica; si tratta di implementare un modello di gestione.

Alcuni lo chiamano Sistema Gestione Privacy (S.G.S.), altri lo definiscono Modello Organizzativo Privacy (M.O.P.).

Per quanto mi riguarda, ritengo che la definizione “privacy” da tempo non sia più adeguata, ma occorra adottare la più rispondente “dataprotection“.

Putroppo per i non anglofoni, anche in questo caso il linguaggio inglese si adatta meglio a descrivere, con due sole parole, il concetto: DataProtection Model (l’acronimo potrebbe essere D.P.M.).

Quindi tutte le aziende che vorranno essere costantemente “compliant” al GDPR, dovranno adottare, ed esercire, un DataProtection Model, con i relativi “innesti” ai processi esistenti e la creazione di quelli necessari.

Dato che molte aziende hanno già adottato altri modelli organizzativi e/o sistemi di gestione (es. Gestione Qualità, Gestione Ambientale, Responsabilità Amministrativa delle Aziende, ecc.), ci sono diverse attività che si sovrappongono.

Il D.Lgs. 231/01 e Regolamento 679/2016 condividono il concetto di “valutazione del rischio”; in effetti essi risultano avere vari “punti di contatto”, tra i quali:

  • reati informatici;
  • trattamento illecito di dati;
  • software illegale;
  • whistleblowing;
  • in alcuni ambiti, sicurezza informatica.

Il D.Lgs. 231 è attualmente obbligatorio solo per le società quotate; in Senato è all’esame un decreto legge che ne estenderebbe l’obbligo alle società di capitali che abbiano avuto, in uno degli ultimi tre esercizi, un attivo patrimoniale non inferiore a 4.400.000 euro oppure ricavi non inferiori ad 8.800.000 euro.

Insieme ad altri colleghi esperti, abbiamo valutato l’opportunità di creare un modello integrato GDPR – D.Lgs. 196/03+101/18 – D.Lgs. 231/01; stiamo quindi lavorando su questo nuovo modello, che presto potrà essere adottato ed implementato dalle aziende italiane.

Modello di valutazione del rischio da Data Breach

Come sappiamo, qualora occorra un Data Breach, il nuovo Regolamento UE 679/2016 prescrive, a carico del Titolare del Trattamento (ma anche del Responsabile esterno qualora la violazione avvenga presso di esso) degli obblighi stringenti, relativi alla comunicazione alla autorità di controllo e talvolta ai soggetti interessati dalla violazione.

Non sempre la comunicazione al Garante (e quindi di conseguenza la comunicazione agli interessati) è obbligatoria; si deve fare a meno che sia improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche”.

Occorre quindi stabilire il livello di rischio che la violazione dei dati personali induce (può indurre) a carico delle persone che sono state oggetto della violazione; una violazione dei dati personali può determinarsi da una molteplicità di eventi avversi, dalla perdita di un dispositivo mobile, dal furto di un asset IT, dalla penetrazione di una rete o di un servizio IT, dalla perdita di confidenzialità dei dati, da un incendio o allagamento che ha interessato un archivio o datacenter, sino al server o PC colpito da malware.

Data la molteplicità degli eventi avversi e le loro caratteristiche “mutevoli” a seconda del contesto, è molto complesso definire in modo appropriato e dimostrabile il reale livello di rischio. A tale scopo, ho predisposto un modello analitico di valutazione del rischio determinatosi a seguito di una violazione di dati personali.

Lo adotto sempre in ogni tipologia di data-breach, quando sono chiamato a valutare il singolo evento avverso.

Ricordo che ogni azienda deve aver gia predisposto le corrette procedure di gestione del data-breach, e (specialmente nelle organizzazioni più strutturate) definito una unità di crisi.

72 ore senza sapere cosa fare trascorrono molto velocemente.


GDPR ed il “vestito su misura”

Tra gli addetti ai lavori, ha preso campo il concetto di “vestito su misura”  oppure “abito sartoriale”, riferito ai processi di adeguamento di ogni diversa organizzazione.

Trascurando poche realtà, ogni organizzazione ha caratteristiche che necessitano di soluzioni “ad hoc” per l’adeguamento al GDPR; anche il corso di formazione deve essere specifico, centrato sui loro trattamenti e sui relativi processi e flussi di dati, nonchè sui rischi incombenti e sulle buone prassi operative da adottare.

Stamani ho visto gli “artefatti” generati da un software che consentirebbe (a dire del produttore) di adeguarsi ai requisiti del GDPR;
ebbene, dei documenti che ho visionato:

  • registro dei trattamenti;
  • informative ai clienti;
  • informative ai fornitori;
  • informative ai dipendenti;
  • lettere di nomina responsabile esterno;
  • lettere di incarico agli incaricati – soggetti designati dal titolare;

nessuno di questi aveva le necessarie caratteristiche richieste dal Regolamento, con la “chiccache il registro dei trattamenti mancava di campi obbligatori mentre aveva campi assolutamente inutili (se non controproducenti).

Quindi, in ambiti di media complessità (che purtroppo riscontro anche in micro imprese “pesantemente” informatizzate), diffidate non solo delle soluzioni “pret-a-porter”, ma anche dei pacchetti di consulenza offerti dalle associazioni di categoria ad un prezzo stracciato.

Spesso chi vi predispone i documenti non ha ben chiaro cosa vi stia scritto; oggi anche una inidonea informativa è sanzionata con importi astronomici.

E del fatto che oggi, in vigenza del GDPR, la dataprotection non si realizzi stampando qualche documento, avevo mai scritto?

Tipologie di trattamenti soggetti a DPIA

L’Autorità di Controllo italiana (Garante per la Protezione dei Dati Personali) ha predisposto un elenco (ovviamente non esaustivo) delle tipologie di trattamenti soggetti al requisito di una valutazione d’impatto sulla protezione dei dati ai sensi dell’art. 35, comma 4, del Regolamento.

  1. Trattamenti valutativi o di scoring su larga scala, nonché trattamenti che comportano la profilazione degli interessati nonché lo svolgimento di attività predittive effettuate anche on-line o attraverso app, relativi ad “aspetti riguardanti il rendimento professionale, la situazione economica, la salute, le preferenze o gli interessi personali, l’affidabilità o il comportamento, l’ubicazione o gli spostamenti dell’interessato”
  2. Trattamenti automatizzati finalizzati ad assumere decisioni che producono “effetti giuridici” oppure che incidono “in modo analogo significativamente” sull’interessato, comprese le decisioni che impediscono di esercitare un diritto o di avvalersi di un bene o di un servizio o di continuare ad esser parte di un contratto in essere (ad es. screening dei clienti di una banca attraverso l’utilizzo di dati registrati in una centrale rischi).
  3. Trattamenti che prevedono un utilizzo sistematico di dati per l’osservazione, il monitoraggio o il controllo degli interessati, compresa la raccolta di dati attraverso reti, effettuati anche on-line o attraverso app, nonché il trattamento di identificativi univoci in grado di identificare gli utenti di servizi della società dell’informazione inclusi servizi web, tv interattiva, ecc. rispetto alle abitudini d’uso e ai dati di visione per periodi prolungati. Rientrano in tale previsione anche i trattamenti di metadati ad es. in ambito telecomunicazioni, banche, ecc. effettuati non soltanto per profilazione, ma più in generale per ragioni organizzative, di previsioni di budget, di upgrade tecnologico, miglioramento reti, offerta di servizi antifrode, antispam, sicurezza etc.
  4. Trattamenti su larga scala di dati aventi carattere estremamente personale (v. WP 248, rev. 01): si fa riferimento, fra gli altri, ai dati connessi alla vita familiare o privata (quali i dati relativi alle comunicazioni elettroniche dei quali occorre tutelare la riservatezza), o che incidono sull’esercizio di un diritto fondamentale (quali i dati sull’ubicazione, la cui raccolta mette in gioco la libertà di circolazione) oppure la cui violazione comporta un grave impatto sulla vita quotidiana dell’interessato (quali i dati finanziari che potrebbero essere utilizzati per commettere frodi in materia di pagamenti).
  5. Trattamenti effettuati nell’ambito del rapporto di lavoro mediante sistemi tecnologici (anche con riguardo ai sistemi di videosorveglianza e di geolocalizzazione) dai quali derivi la possibilità di effettuare un controllo a distanza dell’attività dei dipendenti (si veda quanto stabilito dal WP 248, rev. 01, in relazione ai criteri nn. 3, 7 e 8).
  6. Trattamenti non occasionali di dati relativi a soggetti vulnerabili (minori, disabili, anziani, infermi di mente, pazienti, richiedenti asilo).
  7. Trattamenti effettuati attraverso l’uso di tecnologie innovative, anche con particolari misure di carattere organizzativo (es. IoT; sistemi di intelligenza artificiale; utilizzo di assistenti vocali on-line attraverso lo scanning vocale e testuale; monitoraggi effettuati da dispositivi wearable; tracciamenti di prossimità come ad es. il wi-fi tracking) ogniqualvolta ricorra anche almeno un altro dei criteri individuati nel WP 248, rev. 01.
  8. Trattamenti che comportano lo scambio tra diversi titolari di dati su larga scala con modalità telematiche.
  9. Trattamenti di dati personali effettuati mediante interconnessione, combinazione o raffronto di informazioni, compresi i trattamenti che prevedono l’incrocio dei dati di consumo di beni digitali con dati di pagamento (es. mobile payment).
  10. Trattamenti di categorie particolari di dati ai sensi dell’art. 9 oppure di dati relativi a condanne penali e a reati di cui all’art. 10 interconnessi con altri dati personali raccolti per finalità diverse.
  11. Trattamenti sistematici di dati biometrici, tenendo conto, in particolare, del volume dei dati, della durata, ovvero della persistenza, dell’attività di trattamento
  12. Trattamenti sistematici di dati genetici, tenendo conto, in particolare, del volume dei dati, della durata, ovvero della persistenza, dell’attività di trattamento.

Sono ovviamente sempre valide le precedenti indicazioni fornite dalla Autority su quando occorra effettuare una DPIA.