Garante della Privacy: Provvedimento di autorizzazione al trattamento dei dati personali effettuato attraverso il Sistema di allerta Covid-19 – App Immuni – 1° giugno 2020

GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

Nella riunione odierna, alla quale hanno preso parte il dott. Antonello Soro, presidente, la dott.ssa Augusta Iannini, vicepresidente, la dott.ssa Giovanna Bianchi Clerici e la prof.ssa Licia Califano, componenti, e il dott. Giuseppe Busia, segretario generale;

Visto il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati, di seguito “Regolamento”);

Visto il decreto legislativo 30 giugno 2003, n. 196, recante “Codice in materia di protezione dei dati personali, recante disposizioni per l’adeguamento dell’ordinamento nazionale al Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la Direttiva 95/46/CE”, così come modificato dal decreto legislativo 10 agosto 2018, n. 101 (di seguito “Codice”);

Viste le “Linee guida 04/2020 sull’utilizzo dei dati di localizzazione e degli strumenti per il tracciamento dei contatti nel contesto dell’emergenza legata al COVID-19” del Comitato europeo per la protezione dei dati del 21 aprile 2020 (doc. web n. 9322516);

Vista la documentazione in atti;

Viste le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del regolamento del Garante n. 1/2000;

Relatore il dott. Antonello Soro;

PREMESSO

Il Ministero della salute, con la nota del 28 maggio 2020, ha trasmesso al Garante, ai sensi dell’art. 36, § 5, del Regolamento e dell’art. 2-quinquiesdecies del Codice, la valutazione d’impatto sulla protezione dei dati, effettuata ai sensi dell’art. 35 del Regolamento, per essere autorizzato ad avviare il trattamento di dati personali relativo al “Sistema di allerta Covid-19”, istituito dall’art. 6 del decreto legge 30 aprile 2020, n. 28 (sul quale l’Autorità ha espresso il proprio parere con il provvedimento n. 79 del 29 aprile 2020, doc. web n. 9328050), “al solo fine di allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi e tutelarne la salute attraverso le previste misure di prevenzione nell’ambito delle misure di sanità pubblica legate all’emergenza Covid-19” mediante una piattaforma unica nazionale “per la gestione del sistema di allerta dei soggetti che hanno installato, su base volontaria, un’apposita applicazione sui dispositivi di telefonia mobile”. Il Ministero ha successivamente integrato la documentazione inviata, fornendo, in data 30 maggio 2020, il testo dell’informativa che si intende rendere agli interessati, ai sensi degli artt. 13 e 14 del Regolamento, in relazione al trattamento dei dati personali.

Nella predetta valutazione di impatto, corredata da ampia documentazione, sono state rappresentate le misure tecniche e organizzative adottate dal Ministero al fine di garantire, in particolare, un livello di sicurezza adeguato ai rischi elevati per i diritti e le libertà degli interessati.

1. La descrizione del Sistema di allerta Covid-19

Il Sistema di allerta Covid-19, che rappresenta il sistema nazionale di tracciamento digitale dei contatti (contact tracing), è finalizzato al contrasto della diffusione del Covid-19 ed è complementare alle modalità ordinarie di tracciamento dei contatti già in uso nell’ambito del Servizio sanitario nazionale (SSN). Tale Sistema, denominato Immuni, è composto da un’applicazione (di seguito “app” o “app Immuni”) per dispositivi mobili; dai sistemi e dalle componenti tecnologiche e organizzative che ne permettono il funzionamento (di seguito “backend”), nonché da un servizio di interazione con gli operatori sanitari che utilizza il Sistema Tessera Sanitaria (di seguito “Sistema TS”).

Il Ministero della salute è titolare del trattamento dei dati personali raccolti nell’ambito del predetto Sistema e si avvale di Sogei S.p.a. e del Ministero dell’economia e delle finanze, limitatamente all’utilizzo del Sistema TS, che operano in qualità di responsabili del trattamento (art. 28 del Regolamento).

L’applicazione, istallata liberamente e volontariamente dagli interessati, consente di avvisare tempestivamente gli utenti di essere entrati in contatto stretto con un soggetto risultato positivo al Covid-19, fornendo raccomandazioni sul comportamento da assumere e invitandoli a consultare il proprio medico.

Accanto a tale meccanismo, è prevista la raccolta di ulteriori dati dai dispositivi degli utenti (c.d. analytics) per fini di sanità pubblica, contribuendo, nel contempo, a migliorare il funzionamento del Sistema di allerta Covid-19.

L’app Immuni si basa sull’utilizzo della tecnologia Bluetooth Low Energy (BLE) e sul Framework di Exposure Notification realizzato da Apple e Google (di seguito “Framework A/G”), reso disponibile su dispositivi mobili con sistema iOS e Android, che include interfacce di programmazione delle applicazioni (API – Application Programming Interface) e tecnologie a livello di sistema operativo per consentire il tracciamento dei contatti, senza ricorrere alla geolocalizzazione dei dispositivi degli utenti.

Nella valutazione d’impatto il Ministero della salute ha rappresentato l’esigenza, condivisa con le Regioni, di una preliminare fase di sperimentazione del processo di contact tracing digitale in un numero limitato di Regioni o Province autonome.

1.1. Il rilevamento dell’esposizione a rischio di contagio

In sintesi, si rappresenta che il Sistema Immuni fa ricorso a un approccio c.d. “decentralizzato” di rilevamento dell’esposizione al contagio, di seguito descritto, in cui il contatto stretto con soggetti risultati positivi è notificato direttamente all’utente a seguito di una procedura svolta all’interno del dispositivo su cui è istallata l’app Immuni.

Tale procedura è possibile perché vengono memorizzati all’interno del dispositivo, in un’area crittograficamente protetta, i dati relativi alle interazioni, avvenute con tecnologia bluetooth in modalità paritaria (peer-to-peer), con i dispositivi di altri utenti dell’app Immuni rilevati in sua prossimità.

A) Installazione e configurazione dell’app

Ogni utente, dopo aver scaricato l’app Immuni dagli app store ufficiali di Apple e Google, procede alla sua installazione e configurazione, ricevendo una sintetica descrizione del suo funzionamento e di alcune caratteristiche del trattamento dei dati personali effettuato attraverso delle infografiche, accompagnate dai link all’”informativa privacy” e ai “termini di utilizzo” del servizio.

L’app Immuni, per il suo funzionamento, non richiede l’identificazione dell’interessato attraverso la registrazione o la creazione di un account individuale dei propri utenti.

In tale fase preliminare (c.d. onboarding), all’utente viene richiesto di dichiarare di avere almeno 14 anni (età minima per accedere al servizio), di indicare la provincia di domicilio (che successivamente può essere modificata), nonché di concedere i permessi necessari al funzionamento dell’app (abilitazione delle notifiche di esposizione al Covid-19; visualizzazione, per i soli dispositivi iOS, delle notifiche locali generate dall’app; attivazione del bluetooth e, per i soli dispositivi Android, anche della geolocalizzazione che, pur non essendo utilizzata dall’app Immuni, è richiesta dal sistema operativo per poter rilevare i dispositivi bluetooth nelle vicinanze).

B) Interazione tra i dispositivi mobili degli utenti

Una volta compiute queste operazioni l’app inizia a funzionare e viene generata, in modo casuale, mediante algoritmi crittografici, una chiave temporanea (composta da 128 bit) denominata TEK (Temporary Exposure Key) che varia con frequenza giornaliera. A partire da ogni TEK, ogni 10 minuti, viene generato un identificativo di prossimità del dispositivo mobile (composto da 128 bit), denominato RPI (Rolling Proximity Identifier). Da ogni TEK possono essere generati 144 RPI a essa corrispondenti, mentre in presenza del solo RPI non è possibile risalire alla TEK da cui è stato generato.

Tali RPI vengono diffusi in modalità broadcast e sono ricevuti da altri dispositivi raggiungibili mediante interfaccia bluetooth, producendo di fatto, in caso di sufficiente prossimità, uno scambio reciproco di RPI tra i dispositivi su cui è installata l’app Immuni, registrandoli automaticamente nella loro memoria locale, unitamente ad altri dati accessori (metadati quali la data, la durata e la distanza del contatto). In tal modo, sul dispositivo di ogni utente sono memorizzate la lista delle proprie TEK (aggiornata quotidianamente) e la lista degli RPI dei dispositivi degli altri utenti con cui si è entrati in contatto. Le TEK e gli RPI sono automaticamente cancellati, dai dispositivi, trascorsi 14 giorni dalla loro memorizzazione.

C) Raccolta delle TEK dal dispositivo di un utente accertato positivo al Covid-19

In caso di esito positivo di un tampone, nell’ambito dell’indagine epidemiologica effettuata dall’operatore sanitario del Dipartimento di prevenzione della Azienda sanitaria locale competente, viene chiesto al paziente se abbia installato l’app Immuni. In tal caso, l’operatore chiederà allo stesso se voglia rendere disponibili le proprie TEK al fine di allertare del rischio di contagio gli utenti con cui è entrato in contatto stretto nei giorni precedenti la diagnosi o la manifestazione dei sintomi. Qualora il paziente voglia procedere in tal senso, l’operatore sanitario richiede allo stesso di aprire l’app e di utilizzare la funzione di generazione del codice OTP (One Time Password), composto da 10 caratteri. Il paziente comunica tale codice OTP all’operatore sanitario e attende l’autorizzazione per effettuare il caricamento (c.d. upload) delle proprie TEK. L’operatore sanitario, utilizzando una specifica funzionalità resa disponibile sul Sistema TS, inserisce il codice OTP e la data di inizio dei sintomi forniti dal paziente, che vengono così trasmessi al backend di Immuni. Entro un limitato intervallo temporale (2 minuti e 30 secondi), il paziente dovrà completare la procedura di caricamento delle TEK generate sul proprio dispositivo negli ultimi 14 giorni, che sono trasmesse al backend di Immuni che, previa verifica dell’OTP, le elabora per individuare, sulla base della data di inizio dei sintomi, solo le TEK generate nei giorni in cui il paziente, sulla base della data di insorgenza dei sintomi dichiarata, deve essere considerato contagioso.

Il predetto meccanismo di autorizzazione è volto ad assicurare che siano caricate sul Sistema Immuni esclusivamente le TEK riferibili a utenti accertati positivi al Covid-19.

All’atto dell’upload delle TEK, l’app effettua anche il caricamento automatico sul backend di Immuni di alcune informazioni relative agli eventuali contatti stretti con soggetti positivi rilevati in precedenza (c.d. analytics di tipo Epidemiological Information, meglio descritti alla lett. A) del par. 1.2 del presente provvedimento), e della provincia di domicilio indicata dall’utente all’atto del primo utilizzo dell’app o successivamente modificata.

D) Pubblicazione delle TEK degli utenti risultati positivi al Covid-19

Le TEK degli utenti risultati positivi, acquisite con le modalità di cui sopra, sono pubblicate per la messa a disposizione dell’app immuni, affinché possano essere scaricate automaticamente e periodicamente dagli utenti dell’app per consentire alla stessa di rilevare la ricorrenza di un eventuale contatto mediante il confronto con gli RPI salvati all’interno di ciascun dispositivo mobile.

A tal fine, il backend di Immuni genera periodicamente, a un intervallo regolare di 30 minuti, un file, firmato digitalmente, contenente l’insieme delle TEK (c.d. TEK Chunk) dei nuovi soggetti risultati positivi. Tale file viene pubblicato e reso disponibile attraverso una Content Delivery Network (CDN), ossia un insieme di server distribuiti geograficamente che consente di garantire lo scaricamento (download) del file da parte di numerosi utenti, fornito da una società, designata, a sua volta, responsabile del trattamento da Sogei. Tali file vengono automaticamente cancellati trascorsi 14 giorni dalla sua generazione.

L’app installata sui singoli dispositivi degli utenti verifica periodicamente (ogni 4 ore circa, ma anche con frequenza maggiore qualora il dispositivo mobile sia connesso al proprio alimentatore elettrico) la presenza di aggiornamenti, memorizzando nel dispositivo gli eventuali nuovi file contenenti le TEK pubblicate.

E) Raffronto con gli RPI salvati nei dispositivi degli utenti

Una volta ricevute le TEK pubblicate dal sistema di backend, ciascun dispositivo su cui è installata l’app avvia il raffronto tra gli RPI ricavati dalle TEK scaricate e quelli, rilevati nei 14 giorni precedenti, memorizzati all’interno di ciascun dispositivo mobile, al fine di verificare la presenza di un contatto stretto con utenti accertati positivi al Covid-19 (match).

Tale raffronto viene effettuato a livello locale attraverso l’algoritmo messo a disposizione dal Framework A/G che sulla base di alcuni parametri quali la durata del contatto e la distanza tra i dispositivi su cui è installata l’app (rilevata mediante l’intensità del segnale bluetooth), calcola l’indice di rischio di contagio (Total Risk Score) per ogni eventuale contatto rilevato. Se tale indice di rischio supera una soglia predefinita, l’app mostra all’utente un messaggio di allerta sulla possibile esposizione al contagio (c.d. notifica di esposizione), per essere stato un contatto stretto di un soggetto accertato positivo al Covid-19 (“Il giorno TOT sei stato vicino a un caso COVID-19 positivo”). Il messaggio invita quindi l’utente ad adottare alcune regole di comportamento, nonché a contattare il proprio medico di medicina generale/pediatra di libera scelta, che a sua volta provvederà a contattare il Dipartimento di prevenzione della Azienda sanitaria locale territorialmente competente.

Successivamente all’operazione di raffronto con gli RPI memorizzati all’interno del dispositivo mobile, in presenza o meno di un contatto a rischio, l’app può trasmettere, in modo automatico e secondo un modello probabilistico, alcune informazioni al backend di Immuni che riguardano: la ricezione o meno di una notifica di esposizione al rischio, la data dell’eventuale ultimo contatto stretto con soggetto risultato positivo, la provincia di domicilio, nonché indicatori tecnici relativi al dispositivo dell’utente e all’utilizzo dell’app (c.d. analytics di tipo Operational Info with/without Exposure, meglio descritti alla lett. B) del par. 1.2 del presente provvedimento).

1.2. La raccolta e l’utilizzo degli analytics

Il Sistema di allerta Covid-19, oltre alle TEK degli utenti accertati positivi al Covid-19, raccoglie, attraverso l’app, le ulteriori informazioni di seguito descritte.

A) Gli analytics di tipo Epidemiological Info

Ogni qual volta un utente risultato positivo al Covid-19 decide, liberamente, al fine di “avvisare altri utenti a rischio di contagio”, di effettuare il caricamento delle proprie TEK su sistema di backend, comunicando all’operatore sanitario la data di inizio dei sintomi, l’app trasmette automaticamente anche ulteriori informazioni c.d. Epidemiological Info al backend di Immuni. In tale circostanza, di per impostazione predefinita, vengono quindi raccolti sul Sistema di allerta Covid-19 anche i dati sotto specificati per “consentire l’affinamento dell’algoritmo di calcolo del rischio derivante da un contatto e allertare solo le persone che sono effettivamente a rischio”, nonché per “finalità di tutela della salute pubblica” e “di carattere epidemiologico”:

Le Epidemiological Info raccolte comprendono:

1) provincia di domicilio;

2) Exposure Detection Summary, ossia una serie di informazioni sintetiche relative a tutti gli eventuali contatti a rischio avvenuti negli ultimi 14 giorni (rilevati attraverso il raffronto delle TEK scaricate con gli RPI memorizzati all’interno del dispositivo), che comprende:

a) numero di contatti a rischio rilevati;

b) numero di giorni trascorsi dall’ultimo contatto a rischio;

c) durata aggregata dei contatti a rischio (misurata in multipli di 5 min. fino a un massimo di 30 min.), distinta per tre intervalli di intensità del segnale bluetooth (c.d. attenuation);

d) indice di rischio più elevato tra quelli relativi ai contatti a rischio;

3) Exposure Info, ossia una serie di informazioni analitiche relative a ciascun eventuale contatto a rischio avvenuto negli ultimi 14 giorni (rilevato attraverso il raffronto delle TEK scaricate con gli RPI memorizzati all’interno del dispositivo), che comprende:

a) data in cui è avvenuto il contatto a rischio;

b) durata del contatto a rischio (misurata in multipli di 5 min fino a un massimo di 30 min);

c) intensità del segnale bluetooth durante il contatto a rischio (c.d. attenuation);

d) durata del contatto a rischio (misurata in multipli di 5 min fino a un massimo di 30 min), distinta per tre intervalli di intensità del segnale bluetooth (c.d. attenuation);

e) rischio di contagiosità associato alla TEK relativa al contatto a rischio;

f) indice di rischio relativo al contatto a rischio.

La raccolta dei predetti dati (Epidemiological Info, TEK degli ultimi 14 giorni, clock del dispositivo e data di inizio dei sintomi, è subordinata al meccanismo di autorizzazione basato su un codice OTP descritto alla lett. C del par. 1.1 del presente provvedimento).

B) Gli analytics di tipo Operational Info

L’app trasmette, in maniera automatica e secondo un modello probabilistico, al backend di Immuni le c.d. Operational Info without Exposure e, se c’è stato un contatto a rischio le c.d. Operational Info with Exposure. In ogni caso, il numero di invii di analytics di tipo Operational Info che un singolo dispositivo può effettuare è limitato su base mensile.

Le Operational Info sono raccolte per “capire statisticamente il livello di diffusione dell’app sul territorio e la correttezza del suo utilizzo”, nonché per “monitorare su base statistica l’epidemia, allocare in modo più efficiente le risorse sanitarie e massimizzare quindi la prontezza e adeguatezza del supporto fornito agli utenti che risultano a rischio”.

Allo stato attuale, la trasmissione di tali analytics riguarda unicamente i dispositivi con sistema operativo iOS. Infatti, al fine di garantire la validità delle Operational Info e di imporre un limite mensile al loro invio da parte dei dispositivi mobili, evitando nel contempo l’eventuale inquinamento dei dati raccolti dal backend, il Sistema di allerta Covid-19 fa ricorso a tecniche di device attestation che consentono di verificare l’autenticità del dispositivo dal quale provengono i dati, allo stato possibili solo per dispositivi con sistema operativo iOS (API DeviceCheck di Apple) con le modalità di seguito descritte.

Le Operational Info comprendono:

1) analytics token (il cui significato è descritto nel par. 1.3, raccolto per una finalità meramente tecnica strumentale a garantire sicurezza e maggior affidabilità dei dati trattati nell’ambito del meccanismo di device attestation dei dispositivi iOS);

2) provincia di domicilio;

3) stato di attivazione dell’interfaccia bluetooth;

4) stato del permesso all’utilizzo del Framework A/G per la notifica di esposizione;

5) stato del permesso alla visualizzazione di notifiche locali generate dall’app;

6) sistema operativo del dispositivo mobile (iOS o Android);

7) avvenuta ricezione o meno di notifiche di esposizione al rischio;

8) data in cui è eventualmente avvenuta l’ultima esposizione al rischio (contatto stretto con un soggetto risultato positivo).

C) La conservazione e l’utilizzo degli analytics da parte del Ministero

In relazione alle modalità di conservazione e al successivo trattamento di entrambe le categorie di analytics per le finalità sopra descritte, viene rappresentato che “la fornitura dei dati da parte di Sogei sarà effettuata giornalmente, in forma anonima e aggregata via PEC, agli uffici competenti del Ministero della salute.”, senza fornire ulteriori elementi (es. tecniche di anonimizzazione applicate ai dati dopo la loro raccolta, tempi di conservazione).

D) Device attestation: generazione e utilizzo dell’analytics token

Al fine di consentire al backend di Immuni di verificare l’autenticità dei dispositivi dai quali provengono gli analytics di tipo Operational Info, per i soli dispositivi con sistema operativo iOS, vengono effettuate le seguenti operazioni:

l’app Immuni richiede ad Apple (“DeviceCheck iOS API”) l’attribuzione di un identificativo temporaneo del dispositivo, denominato device token, che consentirà al backend di Immuni di verificarne l’autenticità;

successivamente, l’app Immuni genera, in modo casuale, un altro identificativo del dispositivo, denominato analytics token, salvandolo in locale e inviandolo al backend di Immuni unitamente al device token attribuito da Apple;

alla ricezione di tali dati, il backend di Immuni verifica con Apple (“DeviceCheck server API”) la validità del device token relativo al dispositivo dell’utente; in tale circostanza, il backend di Immuni si avvale anche di alcune funzionalità rese disponibili da Apple (c.d. “DeviceCheck per-device bits”) che consentono di tenere traccia di quei dispositivi mobili che, avendo assunto un comportamento anomalo nella generazione dell’analytics token, non sono autorizzati a inviare Operational Info;

in caso di riscontro positivo da parte del servizio di Apple, il backend di Immuni memorizza l’analytics token in un database, associandolo a un contatore di invii;

ogni qual volta l’app Immuni deve inviare gli analytics di tipo Operational Info, assieme a tali dati viene trasmesso l’analytics token generato in precedenza;

alla ricezione di tali analytics, il backend di Immuni controlla se l’analytics token esiste, se è stato generato e se non è già stato utilizzato per effettuare due invii; solo se tutte queste condizioni sono soddisfatte, le Operational Info vengono accettate e salvate nel backend di Immuni; in caso contrario, i dati vengono scartati.

L’analytics token cambia con cadenza mensile e viene inviato al backend di Immuni al massimo tre volte al mese (all’atto della generazione, dell’invio delle Operational Info with Exposure e dell’invio delle Operational Info without Exposure), in modo da limitare “la capacità del server di reidentificare lo stesso dispositivo a cavallo di più chiamate al server”.

Su base mensile i dispositivi su cui è istallata l’app Immuni generano, in modo casuale, un identificativo denominato analytics token necessario a verificare la validità degli analytics di tipo Operational Info inviati al Sistema di allerta Covid-10.

OSSERVA

Il trattamento di dati personali effettuato nell’ambito del Sistema di allerta risulta legittimo e proporzionato in quanto siano rispettati i diritti e le libertà degli interessati e sia accompagnato anche da adeguate misure di prevenzione e diagnosi volte ad agevolare la presa in carico delle persone contagiate da parte del Sistema sanitario nazionale e la precoce individuazione di nuovi focolai di infezione. Ciò, assicurando, in particolare la trasparenza, la correttezza e la sicurezza in ogni fase del trattamento, in relazione ai rischi elevati che presenta per i diritti e le libertà degli interessati.

1. Base giuridica del trattamento, volontarietà e finalità perseguite

Come detto, la realizzazione dell’app Immuni si colloca nel contesto normativo stabilito dall’art. 6 del d.l. n. 28/2020 con il quale è stata istituita la piattaforma unica nazionale per la gestione Sistema di allerta Covid-19.

La predetta disposizione, fra l’altro, prevede alcuni requisiti fra loro strettamente connessi quali: 1.1) la volontarietà dell’istallazione dell’app; 1.2) il perseguimento di alcune specifiche finalità; 1.3) l’utilizzo di dati pseudonimizzati.

1.1. Sulla volontarietà dell’utilizzo dell’app

Quanto alla prima, occorre sottolineare che un’applicazione fondata sulla volontarietà degli utenti implica che la volontà si manifesti in tutte parti del suo funzionamento: il download, l’istallazione, la configurazione, l’attivazione della tecnologia Bluetooth, il caricamento delle TEK sul backend di Immuni in caso di risultato positivo del tampone, la raccolta delle diverse categorie di analytics nelle fasi in cui si articola il trattamento, la consultazione del medico di fiducia dopo aver ricevuto un messaggio di allerta sul rischio di essere entrato in contatto stretto con soggetti risultati positivi, la disinstallazione dell’applicazione, ecc. (cfr. punti 24 e 31 delle “Linee guida 04/2020 sull’utilizzo dei dati di localizzazione e degli strumenti per il tracciamento dei contatti nel contesto dell’emergenza legata al COVID-19” del Comitato europeo per la protezione dei dati del 21 aprile 2020).

Corollario della volontarietà è, come previsto anche dal legislatore, che le persone che non intendono o non possono utilizzare l’applicazione, intesa nella sua interezza o solamente in una sua fase, non possono subire alcun pregiudizio, e deve, in ogni caso, essere assicurato il rispetto del principio di parità di trattamento (art. 6, comma 3, d.l. n. 28/2020).

L’utilizzo volontario dell’app deve essere chiaramente specificato agli utenti, in aderenza al principio di trasparenza ed eventuali innovazioni nelle caratteristiche del trattamento devono essere riscontrate in corrispondenti modifiche dell’informativa stessa (artt. 5, par. 1, lett. a; 12; cons. nn. 39 e 60, del Regolamento).

1.2. Sulle finalità dell’app

La normativa di riferimento stabilisce che il Sistema di allerta Covid-19 debba perseguire esclusivamente la finalità, da un lato, di “allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi” e, dall’altro, di “tutelarne la salute attraverso le previste misure di prevenzione nell’ambito delle misure di sanità pubblica legata all’emergenza Covid 19”. È, inoltre, conferito al Ministero, in qualità di titolare del trattamento dei dati personali effettuato attraverso il predetto Sistema, il compito di porre in essere gli ulteriori adempimenti necessari alla gestione del sistema di allerta per l’adozione di correlate misure di sanità pubblica e di cura, in coordinamento con i soggetti previsti dalla legge, anche per il tramite del Sistema TS e nel rispetto delle relative competenze istituzionali in materia sanitaria connessa all’emergenza epidemiologica (art. 6, comma 1, d.l. n. 28/2020).

Le predette finalità possono essere perseguite attraverso il trattamento dei dati personali raccolti dall’app che, “per impostazione predefinita, siano esclusivamente quelli necessari ad avvisare gli utenti dell’applicazione di rientrare tra i contatti stretti di altri utenti accertati positivi al COVID-19, individuati secondo criteri stabiliti dal Ministero della salute e specificati nell’ambito delle misure di cui al presente comma, nonché ad agevolare l’eventuale adozione di misure di assistenza sanitaria in favore degli stessi soggetti” (art. 6, comma 2, lett. b, ivi).

A ciò si aggiunge che il funzionamento dell’app Immuni implica anche il trattamento di “categorie particolari dati, in quanto relativi alla salute degli utenti. Questi ultimi possono essere trattati ai sensi dell’art. 9, par. 1, lett. g, del Regolamento, nel rispetto delle ulteriori garanzie previste dall’art. 2-sexies del Codice, che prevede la specificazione dei “tipi di dati che possono essere trattati, le operazioni eseguibili e il motivo di interesse pubblico rilevante, nonché le misure appropriate e specifiche per tutelare i diritti fondamentali e gli interessi dell’interessato”.

Al riguardo, tale livello di dettaglio è riportato nella valutazione di impatto in esame, con la quale – ai sensi dell’art. 6, comma 2, del d.l. n. 28/2020 – il Ministero della Salute è stato chiamato ad adottare “misure tecniche e organizzative idonee a garantire un livello di sicurezza adeguato ai rischi elevati per i diritti e le libertà degli interessati”. Tale documento contiene una descrizione generale dei dati trattati, delle operazioni eseguite, dei flussi di dati e delle specifiche finalità perseguite.

In particolare, il Sistema comporta il trattamento dei dati necessari, come previsto dal legislatore, da un lato, per il tracciamento dei contratti al fine di allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi (es: TEK, RPI, la data di inizio dei sintomi per persone positive al tampone, la avvenuta ricezione della notifica di esposizione) e, dall’altro, per fini di sanità pubblica, contribuendo, nel contempo, a migliorare il funzionamento del Sistema di allerta Covid-19 (es: analytics Operational Info ed Epidemiological Info, descritti sopra, che comprendono, tra l’altro, la provincia di domicilio, la data in cui è avvenuto l’ultimo contatto a rischio, il grado di rischio di contagio, l’aver ricevuto un messaggio di allerta, lo stato di attivazione del bluetooth, il permesso per l’utilizzo del Framework A/G che rende possibile il tracciamento dei contatti, il permesso per le notifiche, il sistema operativo del dispositivo, il clock del dispositivo, gli analytics token, i device token).

1.3. Sull’utilizzo di dati pseudonimizzati

L’art. 6 comma 2, lett. c) del d.l. n. 28/2020 stabilisce che il trattamento effettuato per allertare i contatti sia basato sul trattamento di dati di prossimità dei dispositivi pseudonimizzati.

La pseudonimizzazione, ai sensi dell’art 25 del regolamento costituisce una misura di privacy by design, volta primariamente ad assicurare l’applicazione efficace dei principi della protezione dei dati personali, integrando nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati. Si tratta dunque di un adempimento e non di una tecnica di anonimizzazione dei dati.

Lo scopo della tutela è rappresentato dalla definizione di pseudonimizzazione, introdotta dall’art 4 comma 1 del Regolamento come il risultato di un trattamento di dati personali che non ne consente l’attribuzione a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente e soggette a specifiche misure tecniche e organizzative intese a garantire che tali dati personali non siano attribuiti a una persona fisica identificata o identificabile.

Per dare compiuta applicazione al dettato normativo devono dunque essere chiaramente individuate le due componenti di un trattamento di pseudonimizzazione, il dato pseudonimizzato e l’informazione aggiuntiva, e deve inoltre essere garantita la separazione tra queste due componenti in assenza della quale sarebbe possibile l’identificazione di un interessato.

Nel contesto del contact tracing lo scopo della pseudonimizzazione, in tal modo realizzata, è di consentire la distribuzione delle chiavi TEK (vale a dire il risultato della pseudonimizzazione) ai partecipanti al sistema ma non delle chiavi di co-decodifica (vale a dire l’informazione aggiuntiva) venendo a mancare la quale sarebbe impedita in radice ai partecipanti la possibilità di risalire all’identità di qualsiasi altro partecipante.

A tal riguardo, l’applicazione di tecniche di cifratura asimmetriche a stato dell’arte (ad esempio, basate su algoritmi di hash), con una adeguata custodia delle chiavi da parte del soggetto centrale, che sarebbe l’unico in grado di consentire la re-identificazione per ragioni meramente funzionali all’operatività del sistema, si configurerebbe come una schema di pseudonimizzazione idoneo a realizzare il disaccoppiamento tra TEK e le loro chiavi di decodifica, consentendo così la corretta applicazione dell’art. 6 comma 2, lett. C) del d.l. n. 28/2020, nonchè, su tale base, la pubblicazione delle TEK dei soggetti risultati positivi.

2. Le caratteristiche dell’algoritmo di esposizione al contagio

In via preliminare si rappresenta che, nella valutazione d’impatto non sono ancora individuati puntualmente i criteri epidemiologici di rischio e i modelli probabilistici su cui si basa l’algoritmo, né i parametri di configurazione impiegati corredati dalle assunzioni effettuate, in conformità con quanto disposto dall’art. 6, comma 2, lett. B), del d.l. n. 28/2020, il quale prevede che l’individuazione del contatto stretto avvenga “secondo criteri stabiliti dal Ministero della salute e specificati nell’ambito delle misure“ tecniche e organizzative contenute nella valutazione d’impatto.

Al riguardo, si sottolinea l’importanza che sia assicurata la massima trasparenza pubblica di tali criteri, anche al fine di garantire un idoneo scrutinio da parte della comunità scientifica.

Sotto questo profilo, si rappresenta che la valutazione del rischio di esposizione al contagio effettuata dall’app è calcolata mediante un algoritmo, solo genericamente rappresentato nella valutazione di impatto, che tiene conto della durata del contatto e della distanza dei dispositivi mobili desunta dall’intensità del segnale bluetooth ricevuto dal dispositivo (c.d. attenuation). Il modello di rischio può evolvere con il tempo, in funzione delle informazioni sul virus che risulteranno disponibili.

Occorre considerare che la valutazione della distanza fra dispositivi è intrinsecamente suscettibile di errori in quanto l’intensità del segnale bluetooth dipende da fattori diversi come l’orientamento reciproco di due dispositivi o la presenza di ostacoli fra essi (compresa la presenza di corpi umani), potendo così rilevare “falsi positivi” e “falsi negativi”.

Peraltro, la mancata conoscenza del contesto in cui è avvenuto il contatto stretto con un caso accertato Covid-19 (dato certamente rilevante, invece, ai fini epidemiologici, anche in ragione dell’eventuale utilizzo di sistemi di protezione) è suscettibile di creare potenzialmente numerosi “falsi positivi”.

È importante infatti sottolineare che l’individuazione dei contatti a rischio è effettuata in modo probabilistico, al fine di allertare gli utenti di un possibile rischio di contagio; per cui deve essere chiaro che in nessun caso la ricezione di un messaggio di allerta proveniente dall’app significa automaticamente che l’utente è stato sicuramente contagiato.

Quanto detto è rilevante anche considerando la fase di sperimentazione e la successiva fase iniziale di utilizzo dell’app in tutto il territorio nazionale, anche per ottenere (e mantenere) la fiducia degli utenti circa l’esattezza e la precisione dell’app nel generare messaggi di allerta solo nei confronti degli utenti che abbiano avuto un reale rischio di aver contratto il virus. In caso contrario, infatti, nel caso in cui ove i falsi contatti stretti o non effettivamente ad alto rischio di contagio fossero numerosi, si rischierebbe invece di compromettere la fiducia degli utenti nell’affidabilità della app con conseguente interruzione del suo utilizzo.

******

Su tali basi, si raccomanda, pertanto, che:

l’algoritmo, basato su criteri epidemiologici di rischio e modelli probabilistici (specificando i parametri di configurazione impiegati e le assunzioni effettuate), sia puntualmente indicato e costantemente aggiornato nella valutazione d’impatto, in osservanza del principio di responsabilizzazione, come del resto previsto dall’art. 6, comma 2, lett. b), del d.l. n. 28/2020, rendendolo disponibile allo scrutinio da parte della comunità scientifica;

gli utenti siano adeguatamente informati in ordine alla possibilità che l’app generi notifiche di esposizione che non sempre riflettono un’effettiva condizione di rischio (stante la possibilità, ad esempio, che alcuni soggetti entrino in contatto con persone positive al Covid-19 in ragione della propria attività lavorativa, ma adottando dispositivi di protezione individuale o altri accorgimenti), e fornisca agli utenti informazioni semplici e chiare sul funzionamento dell’algoritmo (anche attraverso una c.d. infografica);

gli utenti dell’app possano temporaneamente disattivare la stessa attraverso una funzione facilmente accessibile nella schermata principale e che di tale funzione di disattivazione temporanea siano informati gli utenti in modo chiaro attraverso le infografiche visualizzate all’atto dell’installazione dell’app.

3. Analytics

Per raggiungere le finalità di “allertare le persone che siano entrate in contatto stretto con soggetti risultati positivi” e di “tutelarne la salute attraverso le previste misure di prevenzione nell’ambito delle misure di sanità pubblica legata all’emergenza Covid 19”, il Ministero della salute ha ritenuto necessario prevedere che il Sistema Immuni raccolga attraverso l’app le diverse tipologie di analytics sopra descritte. Ciò, per consentire, in primo luogo, di predisporre le adeguate misure di presa in carico, da parte del Servizio sanitario nazionale, dei soggetti risultati a rischio di contagio – individuando tempestivamente nuovi focolai di infezione e monitorando il grado di adesione all’utilizzo dell’app da parte degli utenti – e, dall’altro, di permettere, attraverso l’analisi di dati epidemiologici, un costante miglioramento della capacità dell’algoritmo di individuare i contatti stretti tra gli utenti, assicurando al contempo il complessivo funzionamento del Sistema di allerta Covid-19 attraverso una migliore calibrazione delle configurazioni dell’app.

Al riguardo, si ritiene opportuno che, come già rappresentato, venga assicurata la massima trasparenza nei confronti degli utenti, garantendo la volontarietà del conferimento delle informazioni da parte degli utenti verso il backend di Immuni. Le informazioni che il Ministero intende acquisire sono, infatti, archiviate sul dispositivo dell’utente cui deve essere garantita la massima consapevolezza delle operazioni eseguite, favorendo, in tal modo, una fiduciosa e ampia adesione al Sistema di allerta Covid-19 (cfr. punto 28 delle Linee guida n. 04/2020 cit. del Comitato europeo per la protezione dei dati).

Occorre, infatti, rappresentare che tali informazioni non possono essere considerate dati anonimi (queste sono, infatti, acquisite dal Sistema di allerta Covid-19 in forma individuale dai singoli dispositivi) e consentono, in diversi contesti, concrete possibilità di re-identificazione degli interessati, soprattutto se associate ad altre informazioni ovvero in caso di morbilità non elevata o di ambiti territoriali con bassa densità di popolazione.

Al riguardo, si evidenzia che nella valutazione d’impatto non sono adeguatamente precisate le modalità con cui il Ministero della salute intende trattare e conservare le diverse tipologie di analytics raccolti, le tecniche di anonimizzazione eventualmente adottate, i tempi di cancellazione, nonché le specifiche misure di sicurezza poste in essere anche in relazione ai prospettati flussi di dati via PEC tra Sogei e il medesimo Ministero.

Infine, con riferimento al fatto che le Operational Info vengono attualmente raccolte solo da dispostivi iOS, si rappresenta che il Ministero ha ritenuto che i dati acquisiti in tal modo siano sufficienti per ottenere elaborazioni rappresentative, essendo conosciuta la distribuzione di dispositivi iOS e Android nelle diverse province italiane, precisando, altresì, che è in fase di sviluppo un meccanismo di device attestation anche per dispositivi Android. In particolare, la necessità di coinvolgere Apple e, successivamente, Google nel predetto meccanismo deriverebbe da esigenze di natura meramente tecnica, strumentale a garantire la sicurezza e una maggiore affidabilità dei dati raccolti.

È opportuno, a tal proposito, osservare come il ricorso iniziale agli analytics prodotti dai soli dispositivi iOS introduca una possibile distorsione (bias) nel campione su cui saranno calcolati gli indicatori di efficacia nell’uso del sistema e a partire dai quali sarà eventualmente effettuata la calibrazione del funzionamento dell’app. Ciò anche in ragione delle caratteristiche socio-demografiche proprie degli utilizzatori di dispositivi iOS che possono essere significativamente diverse da quelle degli utilizzatori dei dispositivi Android.

Si rileva peraltro che la comunicazione dei dati, diversi da quelli appartenenti a categorie particolari, nei confronti di Apple può trovare legittimazione nell’art. 17-bis del d.l. 9 marzo 2020, n. 14, che disciplina il trattamento dei dati personali nel contesto emergenziale, purché gli utenti siano adeguatamente informati del ruolo svolto da Apple in tale circostanza.

******

In relazione a quanto sopra rappresentato, si ritiene necessario che gli analytics siano accuratamente protetti nel backend di Immuni, evitando ogni forma di riassociazione degli stessi a interessati identificabili e assicurando l’adozione di adeguate misure di sicurezza e tecniche di anonimizzazione, da individuarsi in ragione delle specifiche finalità in concreto perseguite, nel rispetto dei principi di privacy by design e by default (art. 25 del Regolamento).

Con riferimento al prospettato meccanismo di device attestation messo a disposizione da Apple, si invita a ponderare la possibilità di introdurre analoghi strumenti che non comportino il coinvolgimento di soggetti terzi nel trattamento. Laddove, invece, ciò, nel rispetto del principio di accountability, fosse ritenuto indispensabile, si raccomanda di rappresentare chiaramente agli utenti tale circostanza, specificando che saranno comunicati ad Apple esclusivamente i dati tecnici necessari a garantire la sicurezza e una maggior affidabilità dei dati raccolti, ferma restando la necessità di esaminare la soluzione di device attestation che verrà individuata per i dispositivi Android.

4. Trasparenza del trattamento e diritti degli interessati

4.1. Principio di trasparenza

In virtù del principio di trasparenza, il titolare deve informare l’interessato dell’esistenza del trattamento effettuato nell’ambito del Sistema di allerta Covid-19 e delle sue finalità, fornendogli le informazioni necessarie ad assicurare un trattamento corretto e trasparente, pur in considerazione le circostanze emergenziali in cui è effettuato e il contesto specifico in cui i dati personali sono trattati (artt. 5, par. 1, lett. a), 13 e 14 del Regolamento e considerando n. 60).

Le informazioni devono essere rese disponibili all’interessato prima della raccolta dei dati, anche con una modalità progressiva, fornendo in primo luogo quelle relative alle principali caratteristiche del trattamento. Al riguardo, il legislatore ha previsto che gli utenti ricevano, prima dell’attivazione dell’applicazione, informazioni chiare e trasparenti, al fine di raggiungere una piena consapevolezza, in particolare, sulle finalità e sulle operazioni di trattamento, sulle tecniche di pseudonimizzazione utilizzate per proteggere la sua identità e sui tempi di conservazione dei dati (art. 6, comma 2, lett. a), d.l. n. 28/2020). Particolare attenzione deve essere poi prestata alla volontarietà dell’uso dell’app, alla tipologia dei dati trattati e ai soggetti coinvolti nel trattamento.

Oltre a quanto già indicato nei precedenti paragrafi in relazione al rispetto del principio di trasparenza, al fine di facilitare la comprensione degli elementi informativi previsti dal Regolamento, si conviene che, come rappresentato nella valutazione d’impatto, gli stessi possano essere forniti in combinazione con icone standardizzate – leggibili da dispositivo automatico – per dare, in modo facilmente visibile, intelligibile e chiaramente leggibile, un quadro d’insieme del trattamento previsto (cfr. considerando n. 61 al Regolamento).

Il linguaggio con cui devono essere rese le informazioni previste dal Regolamento deve essere formulato con modalità tali da essere comprensibile al maggior numero possibile di persone, in quanto una parte significativa della popolazione sarà probabilmente interessata dall’app.

Si esorta inoltre anche a individuare adeguate modalità di fruizione delle predette informazioni anche da parte delle persone con disabilità.

******

Ciò premesso, oltre all’esigenza rappresentata nel paragrafo 3 relativa alla trasparenza nella raccolta e nell’elaborazione degli analytics, in relazione al modello di informativa trasmesso a questa Autorità successivamente alla ricezione della valutazione d’impatto, si raccomanda di descrivere – nella parte relativa alla “Trasmissione/flusso dei dati” – le operazioni effettuate con riferimento ai dati analytics di tipo Epidemiological Info, nonché di specificare con maggiore chiarezza che i dati personali raccolti “Per i soli utenti esposti al rischio di contagio” e “Per i soli utenti risultati positivi al SARS-CoV-2” si aggiungono a quelli acquisiti per “Tutti gli utenti dell’app” (punti 5 e 4 del modello di “Informativa resa ai sensi degli articoli 13-14 del Regolamento (UE) 2016/679 (“General Data Protection Regulation – GDPR” in atti).

Con specifico riferimento all’utilizzo dell’app anche da parti di minori ultra quattordicenni, si raccomanda di prestare particolare attenzione alle informazioni da fornire e al contenuto dei messaggi di avvenuta esposizione a rischio di contagio.

Per quanto riguarda la fase di sperimentazione del Sistema di allerta Covid-19 indicata nella valutazione di impatto (par. 3), si raccomanda di informare gli utenti, tempestivamente e con modalità efficaci, che -in tale fase- sebbene possano installare l’app, l’avviso di esposizione al rischio di contagio potrà pervenire soltanto se il contatto è avvenuto con soggetti risultati positivi al Covid-19 assistiti dalle Regioni o Province autonome deputate alla sperimentazione.

4.2. Diritti dell’interessato

Il Regolamento, nel riconoscere all’interessato specifici diritti rispetto al trattamento dei suoi dati personali, individua anche alcuni ambiti in cui l’esercizio degli stessi può essere limitato (cfr. considerando nn. 63 e 68 e artt. 15 e ss. del Regolamento).

In primo luogo, si evidenzia che, per le caratteristiche del trattamento effettuato attraverso il Sistema di allerta Covid-19 e le tecniche di pseudonimizzazione utilizzate, come indicato nella valutazione d’impatto, il titolare potrebbe non essere in grado di identificare l’interessato in funzione dell’esercizio da parte dello stesso dei diritti riconosciuti dal Regolamento. Di tale circostanza il titolare deve compiutamente informare l’interessato (art. 11, par. 2, del Regolamento).

Ciò premesso, con specifico riferimento alle valutazioni effettuate dal Ministero in merito all’esercizio dei diritti da parte degli interessati e a quanto indicato nel modello di informativa trasmesso a questa Autorità, si evidenzia che:

i diritti di accesso (art. 15 del Regolamento), rettifica (art. 16 del Regolamento), limitazione del trattamento (art. 18 del Regolamento) e portabilità dei dati (art. 20 del Regolamento) non sono esercitabili da parte dell’interessato con riferimento al trattamento dei dati personali effettuati attraverso il Sistema di allerta Covid-19 in considerazione delle caratteristiche del trattamento;

il diritto di opposizione (art. 21 del Regolamento), analogamente a quanto indicato per il diritto alla cancellazione, può essere esercitato dall’interessato. Come correttamente rappresentato nella valutazione di impatto e nell’informativa, il diritto di opposizione si concretizza nella possibilità per l’interessato di disinstallare l’app. Al riguardo, si rappresenta l’opportunità che l’interessato sia edotto della circostanza che le chiavi saranno via via cancellate, al termine del quattordicesimo giorno di vita, anche sull’infrastruttura centrale.

******

Il diritto di cancellazione è invece esercitabile direttamente tramite l’app per tutte le chiavi temporanee (TEK) e gli identificativi di prossimità (RPI) mediante una funzione appositamente messa a disposizione dal Framework A/G volta a interrompere l’utilizzo dell’app in qualsiasi momento. L’interessato dovrebbe essere reso edotto della modalità di esercizio di tale diritto indicata nella valutazione di impatto e delle relative conseguenze.

Inoltre, si rappresenta l’opportunità che la funzionalità necessaria ad adattare l’utilizzo dell’app in contesti in cui sarebbero prodotti falsi positivi, sopra descritta, possa utilmente essere impiegata per garantire l’esercizio del diritto di opposizione qualora l’utente su base temporanea, ne ravvisi l’esigenza, evitando di ricorrere alla soluzione più radicale della disinstallazione dell’app.

5. Temporaneità della misura e tempi di cancellazione dei dati

Il trattamento dei dati personali deve essere conforme ai principi di minimizzazione dei dati e di limitazione della conservazione, in base ai quali – rispettivamente – i dati personali devono essere “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati”, nonché “conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati” (art. 5, par. 1, lett. c) ed e), del Regolamento).

Al riguardo l’art. 6, comma 6, del d.l. n. 28/2020 prevede che l’utilizzo dell’app e della piattaforma, nonché ogni trattamento di dati personali effettuato tramite di essi devono essere interrotti alla data di cessazione dello stato di emergenza disposto con delibera del Consiglio dei ministri del 31 gennaio 2020, e comunque non oltre il 31 dicembre 2020. Entro tale data tutti i dati personali trattati devono essere cancellati o resi definitivamente anonimi.

È inoltre previsto che “i dati relativi ai contatti stretti siano conservati, anche nei dispositivi mobili degli utenti, per il periodo strettamente necessario al trattamento, la cui durata è stabilita dal Ministero della salute e specificata nell’ambito delle misure di cui al presente comma; i dati sono cancellati in modo automatico alla scadenza del termine” (art. 6, comma 2, lett. e), del d.l. n. 28/2020)

Nella valutazione d’impatto il Ministero ha puntualmente individuato i tempi di conservazione dei dati in relazione alle specifiche finalità, prevedendo la cancellazione delle singole tipologie dei dati personali trattati una volta esaurita la finalità per i quali sono stati raccolti e comunque non oltre il 31/12/2020.

In proposito, al fine di valutare la proporzionalità del trattamento effettuato, è rilevante, fra l’altro, che:

le TEK e gli RPI memorizzati sui dispositivi mobili degli utenti siano cancellati automaticamente dopo 14 giorni;

le TEK dei soggetti risultati positivi Covid-19 che hanno effettuato l’upload sul backend di Immuni siano analogamente cancellate dopo 14 giorni.

Restano in ogni caso ferme le osservazioni formulate in ordine ai tempi di conservazione degli analytics di cui al par. 3 e dell’indirizzo IP di cui al par. 7 al cui contenuto si rinvia integralmente.

6. Soggetti coinvolti nel trattamento

L’art. 6, commi 1 e 5, del d.l. n. 28/2020 prevede quali sono i soggetti istituzionali coinvolti nel trattamento dei dati personali.

Il titolare del trattamento è il Ministero della salute che si avvale dei soggetti indicati nelle predette disposizioni, fra cui Sogei S.p.a. e il Ministero dell’economia e delle finanze, limitatamente all’utilizzo del Sistema TS, che operano in qualità di responsabili del trattamento (art. 28 del Regolamento).

In tale quadro, nella valutazione d’impatto è inoltre indicato il coinvolgimento di fornitori di servizi di Content Delivery Network (CDN), designati sub-responsabili da parte Sogei, a seguito di specifica autorizzazione del Ministero della Salute ai sensi dell’art. 28 del Regolamento. Ciò, al fine di garantire – come riportato nella predetta valutazione d’impatto – la disponibilità e resilienza del sistema, l’esposizione delle chiavi temporanee relative agli utenti risultati positivi al tampone Covid-19.

Nella valutazione d’impatto non è invece sufficientemente chiarito il ruolo di altri soggetti ivi nominati o che potrebbero essere coinvolti nel Sistema Immuni, quali la società che ha sviluppato l’applicazione (Bending Spoons S.p.a.), o le società Apple e Google. Relativamente a queste ultime, l’utilizzo del Framework A/G attribuisce loro un mero ruolo di fornitori di tecnologia (technology provider) senza implicare di per sé alcun trattamento di dati personali.

Tale aspetto andrebbe precisato, in ossequio ai principi di trasparenza e responsabilizzazione.

7. Sicurezza del trattamento

Ai diversi pregi del modello decentralizzato su cui si basa il Sistema Immuni, si affiancano alcune vulnerabilità di cui occorre essere consapevoli anche al fine di adottare le opportune misure di mitigazione dei rischi di sicurezza del Sistema, relativi anche alla possibile re-identificazione degli utenti con riferimento sia a coloro che ricevono il messaggio di allerta che a coloro che sono risultati positivi al Covid-19.

7.1. Sicurezza del dispositivo e rischi di re-identificazione

La riservatezza dei dati relativi ai soggetti risultati positivi al Covid-19 è affidata in parte alle misure tecniche e organizzative che devono essere individuate dal titolare del trattamento ma, in parte, anche alla capacità di evitare le occasioni in cui gli RPI di un utente (identificativi di prossimità, pseudonimi di breve periodo), inviati in broadcast con tecnologia bluetooth, possano essere rilevati da terzi, anche in abbinamento ad altre informazioni identificative, per essere, successivamente, raffrontati con le TEK dei soggetti risultati positivi, pubblicate dal Sistema di allerta Covid-19.

L’utente deve essere adeguatamente avvisato della particolare cura da riservare alla sicurezza del proprio dispositivo mobile, per prevenire l’azione di malware anche in forma di app apparentemente innocue ma che potrebbero avere un comportamento malizioso al fine di acquisire informazioni utili a ricostruire le relazioni tra gli utenti o le catene di contagio, ovvero individuare i soggetti esposti al rischio di contagio o quelli risultati positivi al Covid-19.

Occorre inoltre considerare che, all’esterno del dispositivo mobile possono essere attivati degli apparati di scansione (sniffer) in grado di intercettare la trasmissione broadcast degli RPI per usi impropri o, comunque, non autorizzati, determinando conseguenze pregiudizievoli in capo agli interessati.

Accanto ai predetti scenari, si aggiungono i rischi di re-identificazione inferenziale dei soggetti risultati positivi al Covid-19, con la compromissione della riservatezza delle informazioni, sia da parte di soggetti coinvolti nel trattamento, anche attraverso la disponibilità di analytics, sia da parte di altri utenti con tentativi di ricostruire contatti senza che siano necessari sofisticati strumenti tecnologici.

Al riguardo, si rappresenta che la pubblicazione delle TEK relative ai soggetti risultati positivi al Covid-19, comportando la diffusione degli pseudonimi dei loro dispositivi, li espone a una particolare tecnica di attacco denominata “paparazzi attack”, che si realizza quando sia possibile acquisire agevolmente lo pseudonimo di un soggetto la cui identità sia nota, per esempio in prossimità del suo luogo di dimora oppure in ogni altro luogo in cui alla trasmissione via bluetooth dello pseudonimo siano associabili informazioni aggiuntive, come avviene in esercizi commerciali all’atto del pagamento con carta di credito, al passaggio attraverso varchi di imbarco controllati negli aeroporti, oppure nei luoghi di lavoro con i sistemi di rilevamento delle presenze.

Si tratta di contesti in cui potrebbero essere acquisiti gli RPI generati dal dispositivo di un utente ignaro associandovi altre informazioni identificative e consentendo la ricerca degli RPI così acquisiti tra quelli ottenibili dalla pubblicazione delle chiavi TEK dei soggetti positivi, con un effetto finale di re-identificazione associato a una caratterizzazione dello stato di salute.

In particolare, nel caso dell’app Immuni, la pubblicazione del codice del programma come open source e la pubblicità data agli algoritmi crittografici adoperati nel Framework A/G potrebbero consentire a chiunque conosca, avendole scaricate, le TEK dei soggetti risultati positivi, di ricavare da ciascuna di esse i 144 RPI da raffrontare con la base dati di RPI “etichettati”.

7.2. Le misure adottate nell’ambito del Sistema di allerta Covid-19

Con riferimento alla sicurezza complessiva del trattamento, si rappresenta che nella valutazione d’impatto sono descritte accuratamente le misure tecniche e organizzative adottate dal Ministero della salute nell’ambito del Sistema di allerta Covid-19, nonché quelle condivise dal Ministero dell’economia e delle finanze in relazione alle funzionalità appositamente introdotte nel Sistema TS, di seguito sinteticamente descritte:

le TEK, gli RPI e gli altri dati presenti sul dispositivo dell’utente sono memorizzati in aree crittograficamente protette, in modo da renderli illeggibili a soggetti non autorizzati;

il colloquio tra l’app e i servizi del backend di Immuni avviene mediante canali di comunicazione sicuri basati sul protocollo HTTPS (Hypertext Transfer Protocol Secure) e sull’utilizzo del meccanismo di certificate pinning;

la generazione di traffico dummy (dati fittizi), in modo automatico e secondo un modello probabilistico, consente di limitare, in modo efficace, la possibilità di inferire – attraverso l’analisi del traffico crittografato tra l’app e il backend di Immuni all’atto dell’upload delle TEK o della trasmissione delle Operational Info – informazioni relative a particolari categorie di utenti (soggetti risultati positivi o esposti al rischio di contagio);

i file contenenti i TEK Chunck sono firmati digitalmente, in modo da consentire all’app di verificarne l’integrità e l’autenticità;

la pubblicazione del codice sorgente dell’app e delle principali componenti del backend di Immuni che consente lo scrutinio da parte della comunità di sviluppatori;

il tracciamento degli accessi compiuti ai sistemi e alle basi dati dagli amministratori di sistema, con un congruo periodo di conservazione dei log;

l’utilizzo di apparati di sicurezza perimetrale per bloccare attacchi volti a sfruttare vulnerabilità note, associate sia al software di base che al codice sviluppato per il Sistema Immuni;

l’utilizzo di un codice OTP, con una validità temporale limitata (2 minuti e 30 secondi), per autorizzare – nel corso dell’indagine epidemiologica condotta da un operatore sanitario del Dipartimento di prevenzione della Azienda sanitaria locale competente – l’operazione di upload delle TEK di un soggetto risultato positivo;

l’adozione di procedure di autenticazione informatica degli operatori sanitari per l’accesso al servizio di autenticazione OTP, reso disponibile sul Sistema TS;

il tracciamento degli accessi e delle operazioni compiute sul Sistema TS dai predetti operatori sanitari e dagli amministratori di sistema, con un congruo periodo di conservazione dei log.

7.3. Ulteriori misure suggerite

In relazione ai rischi elevati presentati dal trattamento, individuati anche nella valutazione d’impatto, si ravvisa la opportunità di apportare ulteriori miglioramenti alla sicurezza complessiva intervenendo sui seguenti aspetti.

A) Conservazione degli indirizzi IP dei dispositivi mobili

Dall’esame della documentazione, non è chiaro se vengano conservati gli indirizzi IP dei dispositivi mobili che interagiscono con il backend, sia direttamente (all’atto dell’upload delle TEK e delle Epidemiological Info) sia mediante l’intervento della CDN (al momento per il download delle TEK e la trasmissione delle Operational Info).

In particolare, nella valutazione d’impatto si afferma che “l’indirizzo IP del dispositivo che invia i dati viene trasformato in un indirizzo fittizio attraverso tecniche di Network Address Translation (NAT) dall’infrastruttura di backend all’atto dell’upload dei dati e non viene memorizzato né nel database né nei file di log. L’indirizzo IP viene esclusivamente tracciato temporaneamente sui sistemi perimetrali di accesso degli upload”, mentre nel suo allegato n. 15 è riportato che “non è prevista la memorizzazione degli indirizzi IP dei client da parte del server di backend centrale. L’indirizzo IP viene conservato dall’infrastruttura perimetrale ai soli fini di garantirne la sicurezza informatica”.

******

Occorre quindi commisurare i tempi di conservazione nella misura strettamente necessaria al rilevamento di anomalie e di attacchi. Ciò, in quanto gli indirizzi IP sono dati personali e possono costituire quell’informazione aggiuntiva che, collegata ai dati raccolti, in determinate circostanze consente l’identificazione degli utenti.

B) Tracciamento delle operazioni compiute dagli amministratori di sistema

Dall’esame della documentazione emerge che il tracciamento degli accessi dagli amministratori di sistema è limitato alle operazioni di login e logoff, non consentendo così un efficace controllo, a posteriori, delle operazioni eseguite sui dati.

******

Occorre, pertanto, introdurre misure volte ad assicurare il tracciamento delle operazioni compiute dagli amministratori di sistema sui sistemi operativi, sulla rete e sulle basi dati.

C) Caricamento erroneo di Diagnosis Keys (TEK) non riferite a soggetti positivi a seguito di errori materiali o diagnostici

Con riferimento alla valutazione dei rischi individuati nella valutazione d’impatto, occorre considerare l’ulteriore scenario di compromissione dell’integrità dei dati derivante dall’ipotesi in cui, una volta pubblicate le TEK di un soggetto ritenuto positivo, per varie ragioni (ad esempio, casi di omonimia, scambio di referti, errori materiali), si renda necessario un intervento di rettifica dei dati inseriti al fine di ripristinarne l’accuratezza.

Andrebbero dunque individuate, nel rispetto del principio di responsabilizzazione, le misure tecniche e organizzative adeguate a tal fine.

8. Sperimentazione

Nella valutazione d’impatto il Ministero della salute ha rappresentato l’esigenza, condivisa con le Regioni, di una preliminare fase di sperimentazione del processo di contact tracing digitale in un numero limitato di Regioni o Province autonome.

Ciò al fine di verificare il corretto funzionamento dal punto di vista tecnico e dell’impatto sui servizi territoriali dell’app, in considerazione del possibile ulteriore carico di lavoro (contact tracing, individuazione, isolamento/quarantena, diagnostica, sorveglianza) derivante dalla diffusione del nuovo strumento digitale, che dovrebbe presumibilmente rivelare anche contatti non rilevabili con le modalità tradizionali di contact tracing.

Al riguardo, è stata ritenuta congrua la durata di almeno una settimana della fase di sperimentazione, da svolgersi nelle Regioni o Province autonome che saranno individuate dai decisori politici nazionali e regionali.

In tale quadro, poiché l’app non può essere rilasciata soltanto in zone limitate del Paese, per realizzare la sperimentazione, sarà inizialmente consentito l’utilizzo codice di sblocco OTP esclusivamente nelle Regioni o Province autonome scelte per la sperimentazione. Di conseguenza, in tale fase, tutti i cittadini pur potendo scaricare l’app dagli store ufficiali, saranno preventivamente avvertiti che l’avviso di esposizione al rischio di contagio potrà pervenire soltanto se il contatto è avvenuto con soggetti risultati positivi al Covid-19 assistiti dalle Regioni o Province autonome in cui è stata avviata la sperimentazione. Nella valutazione d’impatto è comunque indicato che di tale circostanza sarà fornito apposito avviso nell’app store.

In relazione alla fase iniziale di utilizzo della app, nella valutazione d’impatto è richiamato l’art. 35, par. 9, del Regolamento, ai sensi del quale il titolare del trattamento raccoglie, se del caso, le opinioni sul trattamento previsto da parte degli interessati che saranno coinvolti nel trattamento stesso, o dei loro rappresentanti, fatta salva la tutela degli interessi commerciali o pubblici o la sicurezza dei trattamenti.

Al riguardo, il Ministero ha evidenziato che è stato privilegiato “il pieno rispetto degli obblighi di trasparenza attraverso, tra le altre cose, il carattere libero e aperto del software utilizzando lo strumento della piattaforma GitHub per la condivisione e la cooperazione sulle questioni tecniche legate all’applicazione, lasciando ad un momento successivo, e segnatamente al termine della fase di sperimentazione, la raccolta di opinioni sull’uso vero e proprio dell’applicazione da parte dei diretti interessati”, che dovrebbe consentire “un primo momento di confronto con le opinioni esperte sulla parte più strettamente tecnica dell’applicazione e sulle misure di sicurezza volta a rafforzare quel vincolo di fiducia che è un elemento fondamentale per il buon esito del progetto”.

In relazione, invece alla raccolta delle opinioni degli utenti è stato deciso di “rimandare alla fase di sperimentazione la raccolta di dette opinioni”, considerando, fra l’altro, l’ampio dibattito su tutti gli organi di stampa sull’app Immuni e il particolare “contesto emergenziale in cui il trattamento si inserisce e quindi con la necessità di adottare misure di contenimento del Covid-19 nel più breve tempo possibile”.

Si auspica che le opinioni degli utenti espresse nella fase di sperimentazione, raccolte con le modalità sopra descritte, siano tenute in debita considerazione per il previsto aggiornamento della valutazione d’impatto e per il miglioramento del Sistema Immuni.

RITENUTO

In ragione dell’esigenza di avviare il Sistema di allerta Covid-19, il trattamento di dati personali effettuato nell’ambito di tale Sistema può essere considerato proporzionato, essendo state previste misure volte a garantire in misura sufficiente il rispetto dei diritti e le libertà degli interessati attenuandone i rischi derivanti dal trattamento.

Nel presente provvedimento sono contenute alcune prescrizioni volte a rafforzare le garanzie nei confronti dei soggetti i cui dati siano trattati nell’ambito del sistema di allerta Covid 19. Le misure prescritte potranno essere adottate nel corso della sperimentazione del Sistema, così da garantire che in fase attuativa ogni residua criticità sia risolta.

Si rammenta, infine, che la raccolta dei dati personali trattati attraverso tale sistema, da parte di soggetti non autorizzati, determina un trattamento di dati personali illecito (anche sotto il profilo penale, ove ne sussistano gli ulteriori requisiti di fattispecie). Analogamente, i dati raccolti attraverso il predetto sistema non possono essere trattati per finalità non previste dal richiamato art. 6 del d.l. n. 28/2020 ed in particolare per assumere decisioni nei confronti dell’interessato suscettibili di arrecargli pregiudizio.

TUTTO CIÒ PREMESSO, IL GARANTE

a) ai sensi e per gli effetti degli artt. 36, § 5, e 58, § 3, lett. c), del Regolamento e dell’art. 2-quinquiesdecies del Codice, autorizza il Ministero della salute ad avviare il trattamento relativo al Sistema di allerta Covid-19 di cui all’art. 6 del d.l. 30 aprile 2020, n. 20, nel rispetto delle seguenti prescrizioni:

1) indicare puntualmente nella valutazione d’impatto, l’algoritmo, basato su criteri epidemiologici di rischio e modelli probabilistici, aggiornandolo costantemente, specificando i parametri di configurazione impiegati e le assunzioni effettuate, rendendolo disponibile alla comunità scientifica (§2);

2) informare adeguatamente gli utenti in ordine alla possibilità che l’app generi notifiche di esposizione che non sempre riflettono un’effettiva condizione di rischio, in ragione della possibilità di contatto con persone positive al Covid-19 a causa della propria attività lavorativa, in condizioni tuttavia caratterizzate da un adeguato grado di protezione (§2);

3) consentire agli utenti dell’app di disattivarla temporaneamente attraverso una funzione facilmente accessibile nella schermata principale, informando di tale facoltà attraverso le infografiche visualizzate all’atto dell’istallazione dell’applicazione (§ 2);

4) individuare modalità adeguate a proteggere gli analytics nel backend di Immuni, evitandone ogni forma di riassociazione a soggetti identificabili, adottando altresì idonee misure di sicurezza e tecniche di anonimizzazione, da individuarsi in ragione delle specifiche finalità in concreto perseguite, nel rispetto dei principi di privacy by design e by default (§3);

5) precisare, nel modello di informativa, la descrizione delle operazioni effettuate con riferimento agli analytics di tipo Epidemiological Info e dei dati personali raccolti in relazione alle diverse categorie di interessati (§ 4.1);

6) dedicare particolare attenzione all’informativa e al messaggio di allerta tenendo conto del fatto che è previsto l’uso del Sistema anche da parte di minori ultra quattordicenni (§ 4.1);

7) fornire adeguate informazioni agli utenti in relazione alle caratteristiche della fase di sperimentazione (§ 4.1 e 8);

8) integrare la valutazione d’impatto e l’informativa in relazione alle modalità di esercizio del diritto di cancellazione e di opposizione (§ 4.2);

9) integrare, sulla base del principio di responsabilizzazione, la valutazione d’impatto con la descrizione del ruolo e delle operazioni ascrivibili ad altri soggetti lì citati o suscettibili, comunque, di coinvolgimento nel Sistema Immuni, evidenziando la sussistenza di eventuali rischi per gli interessati i cui dati siano trattati dal sistema (§ 6);

10) commisurare i tempi di conservazione degli indirizzi ip, per i fini e nei termini richiamati, nella misura strettamente necessaria al rilevamento di anomalie e di attacchi (§ 7.3);

11) introdurre misure volte ad assicurare il tracciamento delle operazioni compiute dagli amministratori di sistema sui sistemi operativi, sulla rete e sulle basi dati (§ 7.3);

12) adottare misure tecniche e organizzative per mitigare i rischi derivanti dall’upload di TEK non riferite a soggetti positivi a seguito di eventuali errori materiali o diagnostici (§ 7.3);

b) ai sensi e per gli effetti dell’art. 157 del Codice, richiede al Ministero della salute di comunicare quali iniziative siano state intraprese al fine di dare attuazione a quanto previsto nel presente provvedimento, entro il termine di 30 giorni dalla data della ricezione del presente provvedimento.

Ai sensi dell’art. 78 del Regolamento, nonché degli artt. 152 del Codice e 10 del d.lgs. 1° settembre 2011, n. 150, avverso il presente provvedimento può essere proposta opposizione all’autorità giudiziaria ordinaria con ricorso depositato al tribunale ordinario del luogo ove ha la residenza il titolare del trattamento dei dati, entro il termine di trenta giorni dalla data di comunicazione del provvedimento stesso.

Roma, 1° giugno 2020

IL PRESIDENTE
Soro

IL RELATORE
Soro

IL SEGRETARIO GENERALE
Busia

Garante della Privacy: Provvedimento correttivo di urgenza nei confronti di Aruba Posta Elettronica Certificata S.p.a

Provvedimento correttivo d’urgenza nei confronti di Aruba Posta Elettronica Certificata S.p.a. – 18 dicembre 2019

Registro dei provvedimenti
n. 228 del 18 dicembre

GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

Nella riunione odierna, in presenza del dott. Antonello Soro, presidente, della dott.ssa Augusta Iannini, vicepresidente, della dott.ssa Giovanna Bianchi Clerici e della prof.ssa Licia Califano, componenti, e del dott. Giuseppe Busia, segretario generale;

Visto il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati), di seguito “Regolamento”;

Visto il decreto legislativo 30 giugno 2003, n. 196, recante il Codice in materia di protezione dei dati personali, così come modificato dal decreto legislativo 10 agosto 2018, n. 101, di seguito “Codice”;

Visti gli atti e la documentazione acquisita nel corso dell’istruttoria avviata dall’Ufficio nei confronti di Aruba Posta Elettronica Certificata S.p.a. (di seguito “Società” o “Aruba PEC”), con sede in Ponte San Pietro (BG), via San Clemente, 53, al fine di “verificare l’osservanza delle disposizioni in materia di protezione dei dati personali, con particolare riferimento alla gestione del servizio PEC, anche a seguito dei numerosi casi di data breach notificati al Garante da diversi titolari di caselle PEC, riguardanti la perdita o la procurata indisponibilità di dati personali a seguito della ricezione di messaggi PEC contenenti allegati infetti da virus informatici […]”;

Rilevato che, nel corso dell’istruttoria, è emerso che, per la commercializzazione e attivazione del servizio PEC, la Società si avvale di una rete di Partner (circa 8.900 soggetti pubblici e privati), ai quali la stessa rende disponibile l’applicazione web denominata “Area Clienti”, raggiungibile da rete Internet all’indirizzo “XX”, attraverso cui i Partner possono attivare nuove caselle di posta elettronica certificata (di seguito “PEC”) ed effettuare altre operazioni di gestione delle stesse (es. cambio del titolare della casella, reset della password di accesso, disattivazione della casella);

Rilevato che, allo stato, la citata applicazione web, in caso di attivazione di una casella PEC tramite Partner, provvede all’invio di un messaggio di “avvenuta certificazione” sulla casella di posta elettronica ordinaria del titolare della casella PEC, all’interno del quale è riportato un link che consente allo stesso di impostare la password di accesso alla casella PEC, mentre, come emerso dalla documentazione in atti, prima del 25 settembre 2019, la stessa applicazione web prevedeva una diversa modalità di generazione e consegna delle credenziali di autenticazione per l’accesso alla casella PEC, in base alla quale:

il Partner impostava direttamente la password di accesso alla casella PEC che, successivamente, attraverso l’applicazione veniva inviata, in chiaro, sulla casella di posta elettronica ordinaria del titolare della casella PEC;

la password così impostata dal Partner, doveva essere composta da almeno 8 caratteri, senza che fossero previsti ulteriori requisiti di complessità né l’aggiornamento periodico;

al momento del primo utilizzo da parte del titolare della casella, la modifica della password attribuita dal Partner in sede di attivazione, seppur consigliata, non era obbligatoria;

Ritenuto che la predetta modalità di generazione e consegna delle credenziali di autenticazione per l’accesso alla casella PEC, adottata in precedenza dalla Società, in caso di mancata modifica della password da parte dei titolari delle caselle attivate da Partner, sia suscettibile di esporre diverse categorie di interessati (titolari della casella, mittenti/destinatari dei messaggi, nonché altri soggetti i cui dati sono presenti all’interno dei messaggi o dei relativi allegati) a gravi rischi di utilizzi impropri dei propri dati personali nonché furti d’identità;

Rilevato che, come dichiarato dalla Società nella documentazione in atti, le caselle PEC attivate tramite Partner, prima del 25 settembre 2019, per le quali non è mai stata modificata la password di accesso, alla data del 20 novembre u.s., risultavano pari a 559.151;

Rilevato, altresì, che, nel corso dell’istruttoria, è emerso che, attraverso l’applicazione web denominata “PEC Log”, raggiungibile da rete Internet all’indirizzo “XX”, i log dei messaggi PEC sono consultabili ed esportabili, oltre che dai titolari delle caselle, anche mediante un’utenza (con credenziali di autenticazione costituite dalla username “XX” e dalla relativa password) condivisa da più soggetti coinvolti a vario titolo nella gestione del servizio PEC della Società;

Rilevato che alla predetta utenza è attribuito un profilo di autorizzazione di tipo amministrativo in grado di effettuare operazioni di consultazione e di esportazione dei log relativi a tutti i messaggi inviati o ricevuti dai circa 6,5 milioni di caselle PEC gestite dalla Società nei 30 mesi precedenti;

Considerato che i log dei messaggi PEC – che la Società, ai sensi dell’art. 11, comma 2, del d.P.R. 11 febbraio 2005, n. 68, recante il Regolamento recante disposizioni per l’utilizzo della posta elettronica certificata, a norma dell’articolo 27 della legge 16 gennaio 2003, n. 3, è tenuta a conservare – devono contenere almeno le seguenti informazioni: il codice identificativo univoco assegnato al messaggio originale, la data e l’ora dell’evento, il mittente del messaggio originale, i destinatari del messaggio originale, l’oggetto del messaggio originale (che può contenere anche dati di carattere riservato, come nel caso di notifiche di atti processuali, anche penali), il tipo di evento (accettazione, ricezione, consegna, emissione ricevute, errore, ecc.), il codice identificativo dei messaggi correlati generati (ricevute, errori, ecc.), nonché il gestore mittente;

Ritenuto che la possibilità di effettuare da rete Internet operazioni di consultazione e di esportazione dei log dei messaggi inviati o ricevuti da tutte le caselle PEC gestite da Aruba PEC presenta ingiustificati profili di rischio per i diritti e le libertà degli interessati, aggravati dall’utilizzo condiviso delle credenziali di autenticazione relative alla predetta utenza, che non consente di attribuire le azioni compiute a un determinato soggetto, impedendo così di controllarne l’operato;

Rilevato che, dall’esame della documentazione in atti, è stato constatato che i log di tracciamento degli accessi e delle operazioni compiute sull’applicazione web denominata “Area Clienti” contengono, in particolare:

i parametri con cui viene invocato il web service raggiungibile all’indirizzo “XX”, comprese le credenziali di autenticazione di un’utenza tecnica (composte dalla username “XX” e da una password di 8 caratteri senza elementi di complessità, riportata in chiaro);

i parametri con cui viene invocata un’application programming interface raggiungibile all’indirizzo “XX”, comprese le credenziali di autenticazione di un’utenza tecnica (composte dalla username “XX” e dalla relativa password, riportata in chiaro);

Rilevato, peraltro, che, all’interno dei predetti log di tracciamento prodotti dall’applicazione web denominata “Area Clienti”, sono presenti anche informazioni riferite ai soggetti per cui viene richiesta l’attivazione, da parte di un Partner, di una casella PEC o di un altro servizio, quali il nome, il cognome, il codice fiscale, il numero di telefono, l’indirizzo di posta elettronica ordinaria, la denominazione della casella PEC, la username e la relativa password, ancorché sotto forma di hash con salt;

Ritenuto che la memorizzazione all’interno dei file di log di credenziali di autenticazione, per di più in chiaro, costituisce di per sé una grave violazione degli obblighi di sicurezza di cui all’art. 32 del Regolamento in quanto compromette la capacità di assicurare, su base permanente, la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, sia quando tali credenziali consentono di trattare direttamente dati personali, sia quando le stesse sono utilizzate per amministrare e gestire i sistemi informatici coinvolti nel trattamento (cfr. anche art. 5, § 1, lett. f), del Regolamento);

Ritenuto, più in generale, che riportare all’interno dei file di log informazioni non indispensabili per le finalità di controllo e sicurezza connesse al tracciamento degli accessi e delle operazioni compiute su un sistema informatico e sui dati in esso contenuti, determini una duplicazione di dati personali oggetto di trattamento nell’ambito del predetto sistema che risultano così esposti a maggiori rischi di trattamenti non autorizzati o illeciti, e, quindi, non sia conforme ai principi di minimizzazione e di riservatezza di cui all’art. 5, § 1, lett. c) e f), del Regolamento;

Considerate le rilevanti criticità sopra descritte, che comportano rischi di elevata probabilità e gravità per i diritti e le libertà degli interessati, relative a:

a) mancata modifica delle password impostate direttamente dai Partner al momento della loro attivazione delle predette 559.151 caselle PEC;

b) possibilità di effettuare, da rete Internet, operazioni di consultazione e di esportazione dei log dei messaggi inviati o ricevuti dai circa 6,5 milioni di caselle PEC gestite dalla Società, peraltro mediante un’utenza, condivisa da più soggetti, a cui è attribuito un elevato profilo di autorizzazione di tipo amministrativo;

c) memorizzazione, all’interno dei file di log prodotti dall’applicazione web denominata “Area Clienti”, di credenziali di autenticazione di utenze tecniche (username e password riportate in chiaro), e di informazioni non necessarie al perseguimento delle finalità di controllo e sicurezza connesse al tracciamento;

Ritenuto necessario intervenire urgentemente per tutelare i diritti e le libertà degli interessati, essendo pregiudicata la capacità, da parte della Società in qualità di titolare del trattamento, di garantire, come richiesto dal Regolamento, la sicurezza dei dati trattati all’interno dei propri sistemi informatici, assicurandone, su base permanente, la protezione da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o da danni, anche accidentali; ciò in violazione degli artt. 5, § 1, lett. f), e 32 del Regolamento;

Ritenuta, in particolare, la necessità di ingiungere alla Società, ai sensi dell’art. 58, § 2, lett. d), del Regolamento, in via d’urgenza, con riserva di ogni altra determinazione, anche sanzionatoria – essendo la notifica di cui all’art. 166, comma 5, del Codice, incompatibile con la natura e finalità del presente provvedimento – di adottare le seguenti misure:

A) con riferimento alla criticità di cui al punto a):

1) l’invio, entro il termine di 10 giorni dalla ricezione del presente provvedimento, a tutti i titolari delle suindicate 559.151 caselle PEC che non abbiano già provveduto a modificare la password impostata dal Partner, di una comunicazione volta a rappresentare che, in caso di mancata modifica della stessa entro un termine congruo – da individuarsi a cura della Società – verrà adottata una procedura di modifica obbligatoria della password;

2) l’adozione, entro il termine di 30 giorni dalla ricezione del presente provvedimento, di una procedura di modifica obbligatoria dalla password di accesso alle caselle PEC in caso di inerzia dei titolari delle stesse;

B) con riferimento alla criticità di cui al punto b),

1) l’inibizione, entro il termine di 10 giorni dalla ricezione del presente provvedimento, dell’accesso, da rete Internet, all’applicazione web “PEC Log” con utenze in uso ad utenti operanti presso la Società a cui è attribuito un profilo di autorizzazione elevato, che consente di effettuare operazioni di consultazione e di esportazione dei log dei messaggi inviati o ricevuti da tutte le caselle gestite da Aruba PEC;

2) l’assegnazione, entro il termine di 10 giorni dalla ricezione del presente provvedimento, a un solo soggetto autorizzato delle credenziali di autenticazione dell’utenza “XX”, previa modifica della password, assicurando, inoltre, che tutti gli utenti dell’applicazione web denominata “PEC Log” siano dotati di credenziali di autenticazione ad uso esclusivo degli stessi;

C) con riferimento alla criticità di cui al punto c),

1) la ridefinizione, entro il termine di 30 giorni dalla ricezione del presente provvedimento, delle modalità di tracciamento degli accessi e delle operazioni compiute sull’applicazione web “Area Clienti”, prevedendo che i file di log prodotti non contengano credenziali di autenticazione di utenze tecniche, né ogni altra informazione non indispensabile per le finalità di controllo e sicurezza connesse al tracciamento;

2) la ridefinizione, entro il termine di 60 giorni dalla ricezione del presente provvedimento, delle modalità di tracciamento degli accessi e delle operazioni compiute su ogni altra applicazione web che produca file di log contenenti credenziali di autenticazione di utenze tecniche o, comunque, informazioni non necessarie al perseguimento delle finalità di controllo e sicurezza connesse al tracciamento;

3) la modifica, entro i termini di adozione delle misure di cui precedenti ai punti 1) e 2), delle password utilizzate dalle utenze tecniche riportate all’interno dei file di log;

Tenuto conto che, ai sensi dell’art. 83, § 6, del Regolamento, “l’inosservanza di un ordine da parte dell’autorità di controllo ai sensi dell’articolo 58, paragrafo 2, è soggetta a sanzioni amministrative pecuniarie fino a 20 000 000 EUR, o per le imprese, fino al 4 % del fatturato mondiale totale annuo dell’esercizio precedente, se superiore”;

Ritenuto che ricorrano i presupposti di cui all’art. 17 del Regolamento n. 1/2019 concernente le procedure interne aventi rilevanza esterna, finalizzate allo svolgimento dei compiti e all’esercizio dei poteri demandati al Garante;

Vista la documentazione in atti;

Viste le osservazioni formulate dal segretario generale ai sensi dell’art. 15 del regolamento del Garante n. 1/2000;

Relatore il dott. Antonello Soro;

TUTTO CIÒ PREMESSO, IL GARANTE

1) ai sensi dell’art. 58, § 2, lett. d), del Regolamento, ingiunge ad Aruba Posta Elettronica Certificata S.p.a. di adottare le misure di cui alle lettere A), B), e C) indicate in premessa, entro i termini di volta in volta individuati;

2)  richiede ad Aruba Posta Elettronica Certificata S.p.a. di comunicare quali iniziative siano state intraprese al fine di dare attuazione a quanto ingiunto nel presente provvedimento e di fornire comunque riscontro adeguatamente documentato ai sensi dell’art. 157 del Codice entro 10 giorni dallo spirare dei termini di cui alle lettere A), B), e C) indicate in premessa; l’eventuale mancato riscontro può comportare l’applicazione della sanzione amministrativa pecuniaria prevista dall’art. 83, § 5, del Regolamento.

Ai sensi dell’art. 78 del Regolamento, nonché degli artt. 152 del Codice e 10 del d.lgs. 1° settembre 2011, n. 150, avverso il presente provvedimento può essere proposta opposizione all’autorità giudiziaria ordinaria, con ricorso depositato al tribunale ordinario del luogo ove ha la residenza il titolare del trattamento dei dati, entro il termine di trenta giorni dalla data di comunicazione del provvedimento stesso.

Roma, 18 dicembre 2019

IL PRESIDENTE
Soro

IL RELATORE
Soro

IL SEGRETARIO GENERALE
Busia

Whistleblowing non sicuro: Garante privacy sanziona un’università per 30.000 € – Diffusi i nomi di chi aveva segnalato illeciti

Il datore di lavoro, che adotta procedure tecnologiche per la segnalazione anonima di possibili comportamenti illeciti (whistleblowing), deve verificare che le misure tecnico-organizzative e i software utilizzati siano adeguati a tutelare la riservatezza di chi invia le denunce. Lo ha ribadito il Garante per la protezione dei dati personali nel sanzionare un’università per aver reso accessibili on line i dati identificativi di due persone che avevano segnalato all’ateneo possibili illeciti.

L’università aveva dichiarato che, a causa di un aggiornamento della piattaforma software utilizzata, si era verificata la sovrascrittura accidentale dei permessi di accesso ad alcune pagine web interne dell’applicativo usato per il whistleblowing, rendendo così possibile a chiunque consultare i nomi e altri dati di coloro che avevano inviato segnalazioni riservate. Tali informazioni erano di conseguenza state indicizzate da alcuni motori di ricerca fino a che l’università, dopo essere venuta a conoscenza del problema, era intervenuta per farli deindicizzare e cancellare le relative copie cache.

Nel corso dell’istruttoria è stato rilevato che la violazione dei dati personali (data breach) era riconducibile all’assenza di adeguate misure tecniche per il controllo degli accessi, che avrebbero consentito di limitare la consultazione al solo personale autorizzato. In base al Regolamento spetta in primo luogo proprio al titolare del trattamento (in questo caso l’ateneo) – tenendo conto della natura, dell’oggetto, del contesto e delle finalità del trattamento – mettere in atto misure tecniche e organizzative per garantire un livello di sicurezza adeguato al rischio. Tra queste rientra anche una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure adottate. Nel caso di specie invece l’università si è limitata a recepire le scelte progettuali del fornitore dell’applicativo che non prevedeva la cifratura dei dati personali (identità del segnalante, informazioni relative alla segnalazione, eventuale documentazione allegata), né l’adozione di un protocollo di trasmissione che garantisse una comunicazione sicura, sia in termini di riservatezza e integrità dei dati scambiati, sia di autenticità del sito web visualizzato da chi invia le segnalazioni. La gravità della violazione risulta acuita dal particolare regime di riservatezza stabilito dalle norme in materia di whistleblowing, proprio a maggior tutela degli interessati.

Il Garante, quindi, dopo aver accertato l’illecito trattamento dei dati e l’omesso adempimento degli obblighi di sicurezza imposti dal Gdpr – tenendo comunque conto che la violazione ha riguardato solo due persone e che l’Ente ha attivamente cooperato nel corso dell’istruttoria – ha inflitto all’ateneo una sanzione amministrativa di 30.000 euro.

dalla Newsletter del Garante per la Privacy del 18/02/2020

Il sindaco di Riace Antonio Trifoli pubblica una mail con i dati personali di Jasmine Cristallo

(Cliccare sull’immagine per ingrandirla)

Non so chi siano né Jasmine Cristallo (che mi risulta leader e portavoce di una parte del movimento delle cosiddette “sardine”) né Antonio Trifoli. Cioè, so benissimo che Antonio Trifoli è il sindaco di Riace, eletto nella lista civica “Riace Rinasce”, vicina alla Lega, già destituito con una sentenza del Tribunale la cui efficacia esecutiva risulta sospesa in virtù del ricorso presentato avverso la stessa sentenza.

Fatto sta che un paio di giorni or sono il sindaco Trifoli ha pubblicato su Facebook il testo di una PEC di Jasmine Cristallo indirizzata alla Questura di Reggio Calabria e all’ufficio protocollo del Comune in cui si comunicava che si sarebbe tenuto un flash mob e che la partecipazione avrebbe previsto la presenza di 150/200 persone approssimativamente. Il tutto senza cancellare l’indirizzo di residenza, l’indirizzo di posta elettronica (quest’ultimo segnalato dalla quasi totalità della stampa, anche se sulla documentazione in mio possesso che premetto a questo intervento l’e-mail PEC non compare) e il recapito telefonico, mettendo così la persona di Jasmine Cristallo all’esposizione di qualunque fanatico che abbia o che abbia voluto perseguitarla a vario titolo. Adesso tutti sanno dove abita (e saperlo, purtroppo, non dovrebbe essere un grosso problema, visto che gli archivi comunali dell’anagrafe di stato sono pubblici e pubblici sono i dati in essi contenuti), a quale indirizzo di posta elettronica risponde (e questo potrebbe essere un problema abbastanza facilmente risolvibile, basta “switchare” le impostazioni della casella in modo che riceva posta elettronica esclusivamente da account altrettanto certificati e che rimandi indietro le mail provenienti da account di posta elettronica tradizionale che sovente sono i più utilizzati per il mail bombing denigratorio). Resta (come se fosse poco), il problema del numero del cellulare e, più in generale, l’atteggiamento di chi, alla carlona, ha pubblicato su un social una mail (cercando di avvalorare la propria tesi circa il numero dei partecipanti al flash mob), senza preoccuparsi di sbianchettarne i passaggi salienti e/o i dati personali che non interessavano a nessuno. O, forse, interessavano solo ai soliti leoni da tastiera.

Il messaggio è restato in linea per pochissimo tempo (è stato quasi immediatamente cancellato), ma ormai il danno era fatto. Jasmine Cristallo ha dichiarato:

“Eccovi il signor Antonio Trifoli. Non l’ho mai incontrato di persona, ma tra poco succederà: in tribunale”

mentre Trifoli, azzardando una francamente incomprensibile scintilla di difesa ha detto:

“La mia intenzione era soltanto quella di evidenziare il numero esatto delle persone che hanno partecipato all’iniziativa e per errore ho pubblicato sul mio profilo Facebook anche l’indirizzo di Jasmine Cristallo. Stamane le ho telefonato spiegandole questo e chiedendo scusa. Non è mio costume fare certe cose, anzi sono contento quando qualcuno viene a Riace per manifestare pacificamente. Io non sono Mimmo Lucano, ma non sono né leghista né razzista come spesso mi dipingono”.

E ancora:

“Per una svista – si legge sul suo profilo – è  stata pubblicata per poco tempo, sotto i tanti commenti di una testata locale, una nota in cui vi erano alcuni dati della sig.ra Jasmine Cristallo. Porgo a lei le mie più sentite scuse e la aspetto al Comune di Riace per offrirle un mazzo di fiori e per scambiare 4 chiacchiere con lei, per farle capire che non sono così cattivo e pieno di pregiudizi, come invece sono stato descritto”.

Sarà, però intanto i soliti haters hanno cominciato a minacciare velatamente perfino la figlia dell’attivista e questo è seriamente preoccupante.

Leggerezza o atto doloso che sia, la privacy di una persona sarebbe stata pesantemente violata. E non si può non offrire tutta la propria solidarietà a Jasmine Cristallo che in questo frangente è senz’altro il soggetto più debole e compromesso.

Come disabilitare le notifiche di lettura su WhatsApp

A me WhatsApp piace. Mi è utile per comunicare brevemente con le persone, ci mando foto, raramente qualche video, ci rompo spesso le scatole al prossimo, quando sono in Toscana faccio delle videochiamate con mia figlia, insomma, mi ci trovo assai bene.

So altrettanto bene che si tratta di uno strumento tremendamente invasivo per quello che riguarda la privacy. Ma è un prezzo che sono disposto a pagare e quando lo uso non penso che è di proprietà di Zuckerberg o come si scrive. Esattamente come quando mangio la Nutella non penso al fatto che le nocciole possano essere turche, la mangio e basta, butta giù che ti fa bene!

Ma una delle cose che non potevo sopportare, fino a ieri, di WhatsApp, erano i doppi segni di spunta azzurri che mi notificavano l’avvenuta lettura del messaggio da parte del destinatario.

Voglio dire, mi scrivono un messaggio, me lo mandano, a quel punto WhatsApp segnala con un segno di spunta singolo l’avvenuta ricezione del messaggio sui suoi sistemi, e con un segno di spunta doppio (di colore grigio) che quel messaggio è stato inoltrato sul terminale del destinatario (cioè me), perché mai il mittente dovrebbe sapere anche se ho letto quel messaggio o meno? Ma saranno affari miei? Volete anche sapere se mi è piaciuto, se risponderò e quando risponderò. Perché poi la componente psicologica è quella: l’hai letto quindi adesso sei costretto a rispondere. E la gente magari lo fa anche, con una faccina, un dito alzato, un gomito piegato (particolarmente ostile quest’ultimo), il sorrisino che fa vedere che scendono le lacrime, quello che mostra la bocca spalancata (perché ce ne sono di diverse tipologie, uno solo non bastava), cuoricini a gogò, gattini, micetti, felini in fasce, disegnini vari, casine, casette, caselle, orsacchiotti, peluscini, Di Stefano ora basta.

Insomma, perché mai una persona dovrebbe sapere se io ho letto o meno un suo messaggio? E quando l’ha saputo cosa cambia? Mi dà fastidio questa cosa. E allora l’ho tolta. Non pensavo si potesse fare e invece ho trovato il modo. Ve lo trascrivo qui di seguito:

– Si apre l’applicazione.
– Si clicca sui tre puntini verticali in alto a destra.
– Poi si va su “Impostazioni”
– Da qui su Account —> Privacy.
– Sul menu “Privacy” si disattivano le “Conferme di lettura”.

Si tratta di una operazione a doppio binario. Vuol dire che, una volta compiuta, chi vi scrive non saprà se voi avete letto il messaggio, ma se voi scrivete a qualcuno, analogamente sarete voi a non poter avere la conferma di lettura da parte del destinatario. E va beh, pazienza, diamo agli altri quello che pretendiamo per noi e viviamo tutti più leggeri. Meno stress, meno impazienza. Hasta pronto.

Pa: il Garante Privacy chiede più tutele per chi segnala gli illeciti (Whistleblowing)

Adottare ulteriori misure per proteggere l’identità di chi segnala riservatamente condotte illecite e quella dei presunti autori, delineare più precisamente i fatti che possono essere segnalati con il “whistleblowing” nella Pa, definire meglio il ruolo dei soggetti coinvolti.

Queste sono alcune delle condizioni e osservazioni indicate dal Garante per la privacy nel parere sulla bozza di “Linee guida in materia di tutela degli autori di segnalazioni di reati o irregolarità di cui siano venuti a conoscenza in ragione di un rapporto di lavoro, ai sensi dell’art. 54-bis del d.lgs. 165/2001, (c.d. whistleblowing)”, predisposta dall’Anac.

Le Linee guida – rivolte ai datori di lavoro in ambito pubblico, ma contenenti anche indicazioni per l’inoltro di segnalazioni da parte di dipendenti di imprese fornitrici di beni o servizi per la Pa – specificano le misure tecniche di base che le pubbliche amministrazioni, titolari del trattamento dei dati, dovranno adottare ed eventualmente ampliare, tenendo conto degli specifici rischi del trattamento e nel rispetto dei principi di privacy-by-design e privacy-by-default.

Il testo delle linee guida era stato inizialmente posto dall’Autorità anticorruzione in consultazione pubblica e poi integrato sulla base di una positiva collaborazione con il Garante per la privacy, così da rafforzare la tutela della speciale riservatezza dell’identità del segnalante e delle informazioni che facilitano l’individuazione di fenomeni corruttivi nella Pa.Tale collaborazione aveva portato anche a delineare meglio, ad esempio, il ruolo dei fornitori di applicativi e servizi informatici utilizzati per l’acquisizione e la gestione delle segnalazioni, nonché a proporre accorgimenti specifici per evitare la tracciabilità del segnalante.

Il parere favorevole del Garante privacy è però condizionato – anche alla luce degli esiti di attività ispettive avviate nel corso del 2019 proprio nei confronti dei principali soggetti (società informatiche, pubbliche amministrazioni) che trattano dati nell’ambito del whistleblowing – all’introduzione di specifiche modifiche che possano evitare di compromettere la corretta gestione delle segnalazioni.

Al fine di incrementare l’utilizzo e la fiducia in questo strumento, il Garante ha chiesto, ad esempio, che nelle Linee guida vengano circoscritte e definite meglio le condotte segnalabili con il “whistleblowing”, così da evitare che gli uffici che gestiscono le segnalazioni rischino di trattare illecitamente i dati delle persone citate, magari perché riferibili a casi non previsti dalla normativa anticorruzione. Dovranno poi essere specificati meglio – seppure con alcune limitazioni a tutela dell’identità del segnalante – i diritti garantiti dalla normativa privacy anche all’autore del presunto illecito.

Dovrà inoltre essere limitata al “responsabile della prevenzione della corruzione e della trasparenza” la possibilità di associare la segnalazione all’identità del segnalante. Nel parere è indicato, tra l’altro, che occorre specificare meglio il ruolo svolto nel trattamento dei dati dai soggetti (sia interni all’amministrazione, sia esterni come l’Autorità giudiziaria e la Corte dei Conti) che possono conoscere le informazioni contenute nelle segnalazioni riservate.

Il Garante ha infine chiesto all’Anac di rafforzare nelle Linee guida le misure tecniche e organizzative necessarie per tutelare l’identità del segnalante, utilizzando, ad esempio, protocolli sicuri per la trasmissione dei dati, abilitando accessi selettivi ai dati contenuti nelle segnalazioni, ed evitando che la piattaforma invii al segnalante notifiche sullo stato della pratica, in quanto tali messaggi potrebbero consentire di svelarne l’identità.

Fonte: Newsletter del Garante della Privacy del 20/12/2019

Garante della Privacy: è illecito mantenere attivo l’account di posta dell’ex dipendente

Commette un illecito la società che mantiene attivo l’account di posta aziendale di un dipendente dopo l’interruzione del rapporto di lavoro e accede alle mail contenute nella sua casella di posta elettronica. La protezione della vita privata si estende anche all’ambito lavorativo.

Questi i principi ribaditi dal Garante per la privacy nel definire il reclamo di un dipendente che lamentava la violazione della disciplina sulla protezione dei dati da parte della società presso la quale aveva lavorato.

L’ex dipendente contestava, in particolare, alla società la mancata disattivazione della email aziendale e l’accesso ai messaggi ricevuti sul suo account. L’interessato era venuto a conoscenza di questi fatti per caso, nel corso di un giudizio davanti al giudice del lavoro promosso nei suoi confronti dalla sua ex azienda, avendo quest’ultima depositato agli atti una email giunta sulla sua casella di posta un anno dopo la cessazione dal servizio.

Dagli accertamenti svolti dall’Autorità è emerso che l’account di posta era rimasto attivo per oltre un anno e mezzo dopo la conclusone del rapporto di lavoro prima della sua eliminazione, avvenuta solo dopo la diffida presentata dal lavoratore. In questo periodo la società aveva avuto accesso alle comunicazioni che vi erano pervenute, alcune anche estranee all’attività lavorativa del dipendente.

Il Garante ha ritenuto illecite le modalità adottate dalla società perché non conformi ai principi sulla protezione dei dati, che impongono al datore di lavoro la tutela della riservatezza anche dell’ex lavoratore. Subito dopo la cessazione del rapporto di lavoro, un’azienda deve infatti rimuovere gli account di posta elettronica riconducibili a un dipendente, adottare sistemi automatici con indirizzi alternativi a chi contatta la casella di posta e introdurre accorgimenti tecnici per impedire la visualizzazione dei messaggi in arrivo.

L’adozione di tali misure tecnologiche – ha spiegato il Garante – consente di contemperare l’interesse del datore di lavoro di accedere alle informazioni necessarie alla gestione della propria attività con la legittima aspettativa di riservatezza sulla corrispondenza da parte di dipendenti/collaboratori oltre che di terzi. Lo scambio di email con altri dipendenti o con persone esterne all’azienda consente infatti di conoscere informazioni personali relative al lavoratore, anche solamente dalla visualizzazione dei dati esterni delle comunicazioni (data, ora oggetto, nominativi di mittenti e destinatari).

Oltre a dichiarare l’illecito trattamento, il Garante ha quindi ammonito la società a conformare i trattamenti effettuati sugli account di posta elettronica aziendale dopo la cessazione del rapporto di lavoro alle disposizioni e ai principi sulla protezione dei dati ed ha disposto l’iscrizione del provvedimento nel registro interno delle violazioni istituito presso l’Autorità. Tale iscrizione costituisce un precedente per la valutazione di eventuali future violazioni.

fonte; Newletter del Garante della Privacy del 20/12/2019

Garante della Privacy – Omicidio a Roma: i media rispettino il codice di procedura penale

In seguito alla pubblicazione di numerose immagini dei presunti autori di un omicidio, avvenuto a Roma, il Garante ritiene opportuno ricordare che – fermo restando il diritto-dovere di informare su fatti di interesse pubblico – il giornalista deve comunque attenersi a quanto stabilito dalla specifica normativa vigente in materia.

Oltre a quanto previsto dalle Regole deontologiche relative al trattamento di dati personali nell’esercizio dell’attività giornalistica, l’art. 114, del Codice di procedura penale vieta “la pubblicazione dell’immagine di persona privata della libertà personale ripresa mentre la stessa si trova sottoposta all’uso di manette ai polsi ovvero ad altro mezzo di coercizione fisica, salvo che la persona vi consenta”.

Roma, 25 ottobre 2019

Tratto da: https://www.gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9170332

Ancora su @vanitosa95: il senso di Open Online per il fake

Il 21 ottobre scorso pubblicavo sul blog un post sulla storia di @vanitosa95, troll e hater bloccato su Twitter dalle numerose segnalazioni degli utenti, che augurava cancri e tumori a iosa a piccoli e grandi personaggi della politica, soprattutto a quelli di sinistra, nonché agli utenti che si fossero, putacaso, trovati in disaccordo con Salvini.

Nel post riportavo alcune delle frasi di odio che l’utente aveva tradotto in svariati tweet, omettendo di riportare la fotografia (chiaramente fasulla e farlocca) che l’hater in questione aveva pubblicato. Scrivevo che: ” i messaggi di questa persona, di cui ho oscurato la foto (non per rispetto della sua privacy, perché non ne ho nessuno, ma per rispetto di quella della persona a cui è stata probabilmente carpita) mi hanno turbato al punto di venirne a parlare con voi “.

Guarda caso, il giorno dopo, esce, alle 14,49, un articolo di David Puente su Open On Line, intitolato “Tutti dietro a Vanitosa95, ma Open vi aveva avvertito. Altri dettagli sull’account e la foto del troll” in cui l’articolista riferisce testualmente: “Qualcuno ha pensato che fosse meglio censurare la foto per una questione di privacy e sicuramente qualcuno potrebbe sostenere che pubblicarla metterebbe a rischio la persona ritratta a causa delle solita – e inutile – «caccia all’uomo».” Non si capisce bene a chi si riferisca l’autore del pezzo quando cita questo “Qualcuno” (ma possiamo bene immaginarcelo).

Segue una lunga disamina per dimostrare che la foto messa da @vanitosa95 sul suo profilo Twitter corrisponde in realtà a quella di una persona transessuale e che le immagini di questa persona erano già apparse su un sito a carattere pornografico.

Per quanto riguarda il nostro blog, nella sua piccola essenza di risorsa di opinione, ho solo da dire che personalmente non ritengo necessario dimostrare che @vanitosa95 sia un troll o, meglio, un hater, perché si tratta di un dato ormai dimostrato per tabulas. E allora ripubblicare la foto che l’odiatore di rete del giorno (tanto verrà abilmente sostituito da qualcun altro, non temete) ha utilizzato per corredare il proprio profilo, diventa inutile e ridondante. In breve, non ho bisogno che mi si dimostri che la foto ritraeva una determinata persona per credere che chi l’ha impunemente usata sia una persona fasulla che cercava solo visibilità. In breve, “un utente intento a pubblicare contenuti provocatori”, per dirla con le stesse parole di Puente.

Qualcuno dirà che si trattava di un transessuale la cui immagine è contenuta in un sito pornografico a disposizione di chiunque voglia andare a visitarlo. Dunque un’immagine pubblica. Vero. Ma non è detto che il nome o l’immagine di questa persona debbano per forza essere associati a un odiatore seriale. La privacy è un valore, e non è detto che quello che è pubblico o che si è autorizzati in qualunque modo a pubblicare debba essere divulgato per forza quando non ha alcun valore dal punto di vista della definizione dei fatti e di quello che si vuole dire. Quella di @vanitosa95 è stata un’utenza del tutto fasulla. La falsità di questo account è stata dimostrata dai contenuti di odio che questo account ha veicolato. Punto. Basta così.Il resto non serve a nulla. Che cosa aggiunge alla nostra conoscenza il sapere che l’ignaro personaggio dell’immagine riportata è un transessuale? Assolutamente nulla. E sarà anche un transessuale da sito porno, ma magari non ha mai augurato il cancro a nessuno e allora non si vede il motivo di metterlo ulteriormente in vetrina.

Non si tratta, quindi, di utilizzare o non utilizzare elementi già pubblici per avvalorare una tesi, ma di verificare a monte se quegli elementi (pubblici, non pubblici, o autorizzati che siano) sono utili alla notizia che si intende dare oppure no.

Soprattutto quando sono riferiti alla sessualità, alla notorietà e alla immagine di terzi.

I video e le immagini di Giulia Sarti

Bisogna dirlo chiaramente e fuori dai denti: la minaccia di diffondere, trasmettere, o far circolare con qualsiasi mezzo delle foto e dei video intimi dell’onorevole Giulia Sarti è una bastardata unica e una e un atto triviale e tremendo da condannare senza mezzi termini, di qualunque colore politico sia la persona interessata. Un hacker ha già diffuso sui cellulari di politici e giornalisti otto immagini e un video (poi rivelatosi falso) degli incontri privati della parlamentare che si è dimessa “da presidente della commissione Giustizia della Camera perché si è scoperto che aveva denunciato il fidanzato accusandolo falsamente di essersi appropriato dei fondi del Movimento pur sapendo che non era vero.” (Virgolettato dal corriere.it). Ci sarebbero, poi, anche delle registrazioni di incontri con esponenti politici e comunque di spicco del Movimento 5 Stelle. Non si sa che siano incontri “privati” (nel senso lato del termine) o meno. Ma non importa. Non è questo il punto. Il punto è che l’avversario politico lo batti sul piano delle idee e dei comportamenti pubblici, la sua vita sessuale e la sua vita privata sono e restano sacrosanti affari suoi, anche se si tratta di una persona pubblicamente esposta ai mezzi di comunicazione di massa. Le immagini e i video se li fa per conto suo e non sono destinati ad essere diffusi ad altri che lei non voglia, è intervenuto perfino il Garante per la Protezione dei Dati Personali per sottolineare e «richiamare l’attenzione dei mezzi di informazione invitando all’astensione dal diffondere dati riguardanti la sfera intima di una persona per il solo fatto che si tratti di un personaggio noto o che eserciti funzioni pubbliche, richiedendo invece il pieno rispetto della sua vita privata quando le notizie o i dati non hanno rilievo sul suo ruolo e sulla sua vita pubblica»

Io mi auguro che una protezione di questo genere valga e sia disponibile sempre e per qualsiasi cittadino italiano, anche e soprattutto per quel cittadini che non è parlamentare e, quindi, ha meno possibilità e mezzi per difendersi. C’è gente che per un filmatino hard diffuso sui social network si suicida dalla vergogna, genitori di vittime di cyberbullismo che non escono più di casa, persone che non hanno più una vita privata e psicologi che intascano fior di quattrini per seguire i disagi psichici di chi è caduto nella trappola tesa da altri. Facciamo attenzione, sì?

Garante della Privacy: 600.000 euro di sanzione a Wind per telemarketing indesiderato

Ordinanza ingiunzione nei confronti di Wind Tre S.p.A. – 29 novembre 2018

Registro dei provvedimenti
n. 493 del 29 novembre 2018

IL GARANTE PER LA PROTEZIONE DEI DATI PERSONALI

NELLA riunione odierna, alla presenza del dott. Antonello Soro, presidente, della dott.ssa Augusta Iannini, vicepresidente, della dott.ssa Giovanna Bianchi Clerici e della prof.ssa Licia Califano, componenti e del dott. Giuseppe Busia, segretario generale;

VISTO l’art. 1, comma 2, della legge 24 novembre 1981, n. 689, ai sensi del quale le leggi che prevedono sanzioni amministrative si applicano soltanto nei casi e per i tempi in esse considerati; 

RILEVATO che l’Ufficio del Garante, con atto n. 21916/114323 del 20 luglio 2018 (notificato in pari data mediante posta elettronica certificata), che qui deve intendersi integralmente riportato, ha contestato a Wind Tre S.p.A, in persona del legale rappresentante pro-tempore, con sede legale in Rho (MI), largo Metropolitana n. 5, C.F. 02517580920, le violazioni previste dagli artt. 23, 130, 162, comma 2-bis, 164-bis, comma 2, e 167 del Codice in materia di protezione dei dati personali (d. lg. 196/2003, di seguito denominato “Codice”) nella formulazione antecedente alle modifiche introdotte dal d. lg. 101/2018;

RILEVATO che dall’esame degli atti del procedimento sanzionatorio avviato con la contestazione di violazione amministrativa è emerso, in sintesi, quanto segue: 

– il Garante ha adottato, in data 22 maggio 2018, il provvedimento n. 313 (in www.gpdp.it, doc. web n. 8995285), al quale integralmente si fa richiamo, all’esito dell’istruttoria di un procedimento amministrativo avviato nei confronti di H3G S.p.A. e quindi, a seguito dell’intervenuta fusione di Wind Telecomunicazioni S.p.A. e H3G S.p.A. in Wind Tre S.p.A.;

– il procedimento ha tratto origine da numerose segnalazioni che lamentavano la ricezione di telefonate con operatore e di sms indesiderati a contenuto promozionale nell´interesse di H3G;

– l’istruttoria svolta dall’Ufficio anche mediante verifiche ispettive ha consentito di appurare che “anzitutto in relazione ai segnalanti, la Società abbia violato gli artt. 23 e 130 del Codice, essendo stati gli stessi contattati, direttamente o tramite la propria rete di vendita […], telefonicamente o via sms, nonostante si fossero opposti ai trattamenti per finalità commerciali […]. E tale illiceità, come già si è rappresentato, trova causa anzitutto nella menzionata assenza di idonee misure preventive apprestate dalla Società per escludere i contatti commerciali indesiderati (o quantomeno minimizzare il rischio del loro verificarsi), mediante opportuni incroci con proprie liste di esclusione nelle quali i segnalanti tutti avrebbero trovato collocazione […]. Deve peraltro rilevarsi che anche i controlli ex post che la Società è comunque tenuta a porre in essere ‒ come dichiarato, al tempo delle verifiche effettuati per lo più nella forma dell’invio di formulari ai partner […] o dei richiami generalizzati […] e finanche nelle comunicazioni individualizzate nelle quali la Società si limita a ricordare i vigenti obblighi di legge […] ‒ non si sono rivelati efficaci, atteso che non di rado più di uno dei segnalanti ha potuto lamentare reiterati contatti effettuati da utenze facenti capo ad un medesimo operatore, risultato partner della Società, senza che l’intervento di quest’ultima abbia sortito alcun effetto” e che “la Società consente l’accesso ai propri sistemi ‒ e quindi alla base dati di rilevanti dimensioni riferita agli utenti dei propri servizi di comunicazione elettronica, come risulta dalle dichiarazioni rese in atti […] ‒ ad una platea assai ampia di partner contrattuali […] senza aver provveduto a designare la parte assolutamente predominante degli stessi ‒ come si è visto, il 93% […] ‒ quali “responsabili del trattamento” ‒, qualificandoli anzi espressamente, nella documentazione in atti, quali “titolari del trattamento”. […] In considerazione dell’omessa designazione di tali soggetti quali “responsabili del trattamento”, deve ritenersi che nel caso di specie ricorrano gli estremi per una sistematica oltre che prolungata nel tempo comunicazione illecita dei dati riferiti alla clientela a terzi, i partner contrattuali per i quali non si è provveduto alla designazione quali “responsabili del trattamento”, che vanno ben al di là dei casi a campione individuati nel corso delle verifiche […], riguardando, come detto, il 93% degli operatori economici che vanno a comporre la rete commerciale della Società. In ragione dell’accesso accordato a tale classe di soggetti al sistema gestionale della Società in assenza di alcuna designazione degli stessi quali “responsabili del trattamento” e non essendo detta operazione di trattamento (la comunicazione dei dati) fondata su un idoneo consenso informato degli interessati (artt. 13 e 23 del Codice) ‒ anche in ragione del fatto che tale tipologia di soggetti non è menzionata nell’informativa resa alla clientela: […] ‒, né risultando comprovato altro presupposto equipollente ai sensi dell’art. 24 del Codice, tale trattamento ‒ seriale e sistematico, anzitutto in relazione a quanti presso tali operatori hanno attivato un contratto o hanno richiesto assistenza ‒ deve pertanto ritenersi illecito”;

RILEVATO che con il citato atto del 20 luglio 2018 sono state contestate a Wind Tre S.p.A.:

a) la violazione delle disposizioni di cui agli artt. 23 e 130, comma 3, e 167 del Codice, sanzionata dall’art. 162, comma 2-bis, con riferimento alla mancata acquisizione del consenso per l’effettuazione di chiamate promozionali;

b) la violazione delle disposizioni di cui agli artt. 23 e 167 del Codice, sanzionata dall’art. 162, comma 2-bis, in relazione alla mancata acquisizione del consenso per la comunicazione di dati a soggetti terzi (partner commerciali)

c) la violazione prevista dall’art. 164-bis, comma 2, del Codice, per aver realizzato le condotte di cui sopra in relazione a banche dati di particolare dimensioni (la base di dati riferita al brand “Tre” è costituita da circa 10.000.000 di utenze facenti capo a circa 6.600.000 clienti oltre a circa ulteriori 3.000.000 di utenze relative a clienti cessati);

DATO ATTO che, per le violazione di cui ai punto a) e b), è intervenuto pagamento in misura ridotta, ai sensi dell’art. 16 della l. n. 689/1981, effettuato l’11 settembre 2018; rilevato altresì che per la violazione di cui al punto c) non è prevista la facoltà di estinguere il procedimento sanzionatorio mediante pagamento in misura ridotta;  

DATO ATTO che Wind Tre S.p.A. ha inviato, il 24 luglio 2018, una istanza di revisione in autotutela del provvedimento di contestazione di violazione amministrativa nella quale ha rappresentato che: 

– la società, prima ancora dell’adozione del provvedimento n. 313 del 22 maggio 2018, aveva posto in essere autonome iniziative sul brand “Tre” al fine di eliminare le criticità riscontrate in sede istruttoria;

– tali iniziative sono state rafforzate a seguito dell’adozione del richiamato provvedimento e anche al fine di giungere ad una piena armonizzazione delle procedure in essere presso i brand oggetto di fusione nonché al necessario adeguamento dei trattamenti al Regolamento (UE) 2016/679 (General Data Protection Regulation, di seguito “GDPR”);

– per il comportamento proattivo della Società con riferimento al complessivo procedimento amministrativo instaurato nei suoi confronti dal Garante può giungersi all’archiviazione delle sanzioni ovvero alla riduzione sostanziale dell’importo delle medesime anche in relazione alla circostanza che il provvedimento legislativo di adeguamento delle disposizioni del GDPR prevede una modalità di estinzione dei procedimenti sanzionatori  mediante il pagamento di una somma in misura ridotta (pari a due quinti del minimo edittale), facoltà che appare equo estendere anche al caso in argomento;

RILEVATO che la richiesta di annullamento in autotutela della contestazione di violazione amministrativa non può trovare accoglimento poiché non si ravvisano nel predetto atto gli elementi di nullità indicati nell’art. 21-septies della legge n. 241/1990, tuttavia le argomentazioni in essa contenute possono essere prese in considerazione alla stregua di scritti difensivi prodotti dalla parte ai sensi dell’art. 18 della legge n. 689/1981. Tali argomentazioni non riguardano le condotte oggetto di contestazione ma i comportamenti successivi della Società, la quale, si evidenzia, avrebbe intrapreso, prima ancora dell’adozione del provvedimento n. 313 del 22 maggio 2018, un percorso di eliminazione delle criticità riscontrate e di adeguamento alle novità introdotte dal GDPR, tale da consentire di valutare con favore, in termini di quantificazione della sanzione, l’azione svolta dalla società. Al riguardo, si rinvia ogni considerazione alla sezione della presente ordinanza-ingiunzione nella quale si prendono in esame gli elementi per giungere all’importo finale della sanzione. In questa sede deve confermarsi la responsabilità di Wind Tre S.p.A. in ordine alle violazioni contestate, non essendo stati portati all’attenzione del Garante elementi nuovi e idonei ad escluderla. Inoltre, per quanto riguarda l’applicabilità nel caso in argomento dell’istituto della definizione agevolata introdotto dall’art. 18 del d. lg. n. 101/2018, deve evidenziarsi che tale istituto, per espressa indicazione del legislatore, riguarda soltanto i procedimenti sanzionatori in essere (cioè avviati con contestazione di violazione amministrativa) e non definiti alla data di applicazione del GDPR (25 maggio 2018). Poiché, nel caso in argomento, l’instaurazione del procedimento sanzionatorio è avvenuta in epoca successiva (con la notifica in data 20 luglio 2018 dell’atto di contestazione di violazione amministrativa), tale procedimento risulta escluso dalla possibilità di definizione agevolata.

RILEVATO, quindi, che Wind Tre S.p.A., sulla base degli atti e delle considerazioni di cui sopra, risulta aver commesso, in qualità di titolare del trattamento, ai sensi degli artt. 4, comma 1, lett. f), e 28 del Codice, le violazioni indicate ai punti a) e b) dell’atto di contestazione n. 21916/114323 del 20 luglio 2018, per le quali è intervenuta definizione in via breve e, conseguentemente, la violazione prevista dall’art. 164-bis, comma 2, per aver realizzato le violazioni di cui ai punti a) e b) in relazione a banche dati di particolare rilevanza e dimensioni;

VISTO l’art. 164-bis, comma 2, del Codice che punisce le violazioni di un’unica o più disposizioni indicate nella parte III, titolo III, capo I del Codice (ad eccezione di quelle previste dagli articoli 162,  comma  2, 162-bis  e  164), commesse in relazione ad una banca dati di particolare rilevanza e dimensioni, con la sanzione amministrativa del pagamento di una somma da euro 50.000 ad euro 300.000;

CONSIDERATO che, ai fini della determinazione dell’ammontare della sanzione pecuniaria, occorre tenere conto, ai sensi dell’art. 11 della legge n. 689/1981, dell’opera svolta dall’agente per eliminare o attenuare le conseguenze della violazione, della gravità della violazione, della personalità e delle condizioni economiche del contravventore;

CONSIDERATO che, nel caso in esame:

a. in ordine all’aspetto della gravità, con riferimento agli elementi dell’entità del pregiudizio o del pericolo e dell’intensità dell’elemento psicologico, le violazioni risultano di rilevante gravità tenuto conto che, nel caso in argomento, sono stati impiegati differenti canali di contatto che hanno determinato un esponenziale aumento del livello di invasività delle campagne promozionali;

b. ai fini della valutazione dell’opera svolta dall’agente, deve essere considerato in termini favorevoli il fatto che Wind Tre S.p.A. abbia, prima ancora dell’adozione del provvedimento n. 313 del 22 maggio 2018, posto in essere autonome iniziative sul brand “Tre” al fine di eliminare le criticità riscontrate in sede istruttoria; tali iniziative sono state rafforzate a seguito dell’adozione del richiamato provvedimento e anche al fine di giungere ad una piena armonizzazione delle procedure in essere presso i brand oggetto di fusione nonché al necessario adeguamento dei trattamenti al GDPR;

c. circa la personalità dell’autore della violazione, deve essere considerata la circostanza che la Società risulta gravata da numerosi precedenti procedimenti sanzionatori definiti in via breve o a seguito di ordinanza ingiunzione (l’ultima ordinanza-ingiunzione è stata adottata il 22 maggio 2018, in www.gpdp.it, doc. web n. 9018431);

d. in merito alle condizioni economiche dell’agente, è stato preso in considerazione il bilancio ordinario d’esercizio per l’anno 2017 e i bilanci consolidati al 31 marzo 2018 e 30 giugno 2018; 

RITENUTO, quindi, di dover determinare, ai sensi dell’art. 11 della L. n. 689/1981, l’ammontare della sanzione pecuniaria, in ragione dei suddetti elementi valutati nel loro complesso, nella misura di euro 150.000 (centocinquantamila) per la violazione di cui all’art. 164-bis, comma 2, del Codice.

RITENUTO inoltre che, in relazione alle condizioni economiche del contravventore, avuto riguardo in particolare alla circostanza che Wind Tre S.p.A. è il primo operatore di telefonia mobile in Italia (con una customer base di 28.600.000 di sim card) e detiene anche una rilevante quota di mercato nel settore della telefonia fissa (2.700.000 linee), la sopra indicata sanzione pecuniaria risulta inefficace e deve pertanto essere aumentata del quadruplo, come previsto dall’art. 164-bis, comma 4, del Codice (da € 150.000 a € 600.000);

VISTA la documentazione in atti;

VISTA la legge n. 689/1981, e successive modificazioni e integrazioni;

VISTE le osservazioni dell’Ufficio formulate dal segretario generale ai sensi dell’art. 15 del regolamento del Garante n. 1/2000, adottato con deliberazione del 28 giugno 2000;

RELATORE la dott.ssa Giovanna Bianchi Clerici;

ORDINA

a Wind Tre S.p.A., in persona del legale rappresentante pro-tempore, con sede legale in Rho (MI), largo Metropolitana n. 5, C.F. 02517580920, di pagare la somma di euro 600.000 (seicentomila) a titolo di sanzione amministrativa pecuniaria per le violazioni indicate in motivazione;

INGIUNGE

alla predetta Società di pagare la somma di euro 600.000,00 (seicentomila), secondo le modalità indicate in allegato, entro 30 giorni dalla notificazione del presente provvedimento, pena l’adozione dei conseguenti atti esecutivi a norma dall’art. 27 della legge 24 novembre 1981, n. 689. 

Ai sensi degli artt. 152 del Codice e 10 del d.lg. n. 150/2011, avverso il presente provvedimento può essere proposta opposizione all’autorità giudiziaria ordinaria, con ricorso depositato al tribunale ordinario del luogo ove ha la residenza il titolare del trattamento dei dati, entro il termine di trenta giorni dalla data di comunicazione del provvedimento stesso, ovvero di sessanta giorni se il ricorrente risiede all’estero.

Roma, 29 novembre 2018

IL PRESIDENTE
Soro

IL RELATORE
Iannini

IL SEGRETARIO GENERALE
Busia

Lo spamming pre- e postelettorale di Pippo Civati

Mi arrivano e-mail di spamming da parte del PD di Pippo Civati. Il 20 maggio con l’invito a votare PD e le spiegazioni (che nessuno ha loro chiesto, peraltro) del perché lo votano loro.

Ma siccome vivo in Abruzzo, terra di elezioni regionali, mi scrive anche un certo Paolo della Ventura, che mi invita a votare Elena Gentile.

La terza mail per dirmi che loro vanno in Europa (e anche a quel paese, per quel che mi riguarda) rappresentati da Renata, Elly, Elena e Daniele.

E allora? Perché me lo dicono?? Perché ebbi la dabbenaggine, una volta, di partecipare a un loro sondaggio. TUTTO LI’. Cioè, uno partecipa ad un sondaggio, fornisce dei dati e loro si sentono in diritto di usarli per spedire della propaganda elettorale. E’ chiaro, sono o non sono i vincitori indiscussi di questa tornata elettorale? E allora la gente pretende anche che gli altri non facciano quello che vogliono LORO con i propri dati? Eh, non si può mica!

Come al solito comincerò la trafila per il ricorso al Garante della Privacy. Nel caso dovesse uscirne qualcosina di interessante, come al solito, ve lo dirò.

Privacy is not a crime!

Qualcuno mi ha chiesto (bontà sua) cosa io ne pensi delle intercettazioni selvagge rispetto al tema della privacy.

A parte il fatto che ho già scritto qualcosa in proposito, posso condensare il tutto in una breve sentenza: avete voluto l’“intercettatemi pure”, avete voluto il “siamo tutti puttane”, avete gridato “io non ho niente da nascondere!” adesso non vi lamentate!

“Ma tu hai un blog, metti tutta la tua vita in pubblico e poi vieni a ragionare della privacy…”

Sì, io ho un blog ma tutta la mia vita in pubblico non ce la metto. Quanto alla privacy, è molto semplice: la privacy è tutto quello che IO decido che gli altri possano fare (o non fare) con i miei dati e con le mie informazioni. Punto, non c’è altro.

Sembra semplice eppure lo è:

– se io metto sul blog il mio indirizzo e-mail, è perché mi fa piacere che la gente mi scriva sulle tematiche e sugli articoli che tratto nel blog. E quello è il motivo per cui lo pubblico. Se, invece, lo usa per mandarmi della pubblicità, lì sì, mi inalbero. Perché questo non rientra più nei limiti di quello che IO avevo stabilito fosse il confine del mio formire quel dato personale;

– se io scrivo sul blog che ho l’influenza, questo dato deve rimanere circoscritto alla sfera della lettura di pura fruizione (leggasi “cazzeggio”) e nessuna clinica privata è autorizzata, attraverso il mio blog, a raccogliere informazioni sulla mia salute;

– se io metto su Facebook il mio numero di telefono, è perché voglio che Facebook e le persone autorizzate a vederlo possano usufrirne per offrirmi dei servizi o comunicare con me a voce, se credono. Se, invece, in virtù di quella pubblicazione mi telefona l’agenzia dei cuori solitari Cupido per propormi una iscrizione quelli non sono più i MIEI scopi iniziali.

“Eh, va beh, ma tu così ti esponi…”

Anche voi siete esposti, bèi miei naccherini, o pensate che non conferire su Facebook il vostro numero di telefono, ma dare dati riguardo alla vostra religione e al vostro orientamento politico vi preservi ugualmente in saecula saeculorum amen? “Oh, no, il numero di telefono è una cosa così personale…” E il credo religioso e politico no?? Non volete rotture di scatole? Non andate su Internet! Se ci siete (e ci siete) accettate di rischiare, ma poi non venite a fare quelli che cascano giù dal pero se Obama vi incastra mentre parlate con l’amante (paura, eh???).

La privacy è qualcosa di molto articolato. Se voi il numero di telefono invece che darlo a Facebook lo deste al supermercato perché avete completato la raccolta dei punti per l’ottenimento di una zuppiera in purissimo dado da brodo, e poi il supermercato lo cedesse a un altro supermercato, che lo cede a un’agenzia di pompe funebri avete il brodino caldo gratis, la spesa con lo sconto e il funerale con l’offerta speciale, ma intanto il vostro numero di telefono va in giro, e voi ve la prendete con me perché ho dato il mio numero di telefono a Facebook!

Dovreste incazzarvi quando qualcuno fa qualcosa a vostra insaputa coi vostri dati. E anche quando vi dicono che Letta non può essere stato intercettato perché aveva il cellulare crittografato. Perché non li dànno a noi i cellulari crittografati? Noi intercettati e Letta no perché aveva il telefonino strafigo? Va mica bene! Spendiamo centinaia di euro per un telefono che nella migliore delle ipotesi tra sei mesi sarà vetusto e ci pigliano anche per il culo facendoci ascoltare dagli americani.

“Firmi qui qui e qui, è per la privacy” e poi ve lo tirano in quel posto perché per pagarvi il macchinone a rate dovete dare la liberatoria alle banche per l’appoggio del RID (“Ha un conto corrente lei?? Allora è tutto a posto, non ci saranno problemi…”). Vi piace avere almeno un paio di carte di credito nel portafoglio? Anche a me, ma si dà il caso che chi ha emesso la mia carta di credito sappia tutto di quello che compro, di quanto spendo, di dove lo compro. Se compro dei libri on line chi emette la mia carta potrà sapere che ho speso X presso il venditore Y, e non i titoli che ho ordinato. Ma quelli li conosce il venditore Y, appunto, e allora sono già due soggetti che hanno in mano i miei dati.

“Firmi qui qui e qui, è per la privacy” e poi lo prendete di nuovo in quel posto perché si dà il caso che se non firmate poi non avete quella prestazione sanitaria. Ma perché il centro che mi fa le radiografie ha bisogno di sapere se sono coniugato o se ho dei segni particolari di riconoscimento? E poi io dovrei firmare “per la privacy” mentre quelli mi chiedono se per caso ho un neo in fronte o con chi sono sposato?

Ecco, volevate il mio pensiero e ve l’ho detto. Ora firmate qui, qui e qui. E’ per la privacy.

Settimo: paga in contanti! [Forse…]

E’ bello doppo ‘l morir vivere anchora, ed è bello tornare a parlarvi di privacy dopo tanto tempo.

Quello della privacy sembra un tema noioso e incomprensibile, per certi versi lo è, ma il succo, l’enunciato fondamentale, quello che non bisogna mai perdere di vista è che la privacy è quello che noi non siamo disposti a tollerare che gli altri facciano coi nostri dati personali.

Una persona può benissimo essere disposta a postare le sue foto discinte pubblicamente su Facebook. Un’altra no. Ma magari la persona che non vuole pubblicarsi scollacciata su Facebook è stata un po’ troppo prodiga nel dare il suo numero di telefono in giro e viene contattata quotidianamente da agenzie che vendono di tutto.

Due giorni fa sul “Corriere” è stato pubblicato un decalogo per tutelare la propria privacy in rete. Già il fatto che si tratti di un “decalogo” mi rende un tantinello nervoso. Sa di Mosè che scende giù dal Sinai con le tavole della Legge in mano e i capelli scaruffati.

Il settimo comandamento recita: “Pagate sempre in contanti, quando possibile e a maggior ragione se acquistate qualcosa che potrebbe essere fonte d’imbarazzo: con la carta di credito siete sempre rintracciabili.”

Ora, non si capisce bene (o, meglio, lo si capisce FIN TROPPO bene) quale sia questa “fonte d’imbarazzo”, ma andiamo avanti.
La maggior parte delle transazioni per acquisti in rete avviene con pagamento anticipato (sì!). Ora ci dovrebbero cortesemente spiegare come si fa a pagare in contanti anticipatamente per un acquisto via internet se l’acquirente si trova a Bressanone e il venditore a Siracusa. Cosa si fa, si mette il contante dentro il modem e lo si invia?
C’è il contrassegno, certo, cioè pagare al postino o al corriere al momento della consegna. Ma il guaio è che c’è da pagare qualcosa di più, ok, per non essere sgamati dalla moglie mentre compriamo i nostri DVD porno si può fare questo ed altro, ma si dà il caso che il postino passa al mattino, e che potrebbe essere proprio nostra moglie a ritirare il pacco coi nostri sollazzi visuali, rompendoci le corna al nostro ritorno. No, non funziona.
E allora? E allora PayPal. E’ comodo, viene accettato da un numero sempre maggiore di siti in rete e, soprattutto, funziona.
PayPal non mi paga per dire bene di loro, solo che lo uso da anni con molta soddisfazione (sto scrivendo come Paolo Attivissimo, aiuto!). Lo si associa a una carta di credito ricaricabile, si trasferiscono i fondi, si acquista quello che si vuole e il gioco è fatto.

Non vi illudete, però. Le tracce rimangono sempre. Quella del trasferimento dalla vostra carta di credito impersonale ricaricabile e quella di PayPal che paga per vostro conto il venditore. Ma è già qualcosa.

E certo che con la carta di credito si è sempre rintracciabili! Il fare qualcosa in rete, come poter comperare quello che si vuole, costa qualcosa, e il costo in questione è esattamente una parte di noi stessi.
Bisogna vedere quanto siamo disposti a venderci.