Edit: Apprendiamo dalle fonti dirette che Bending Spoon d’accordo con il ministero all’innovazione ha già deciso di virare verso il nuovo modello, alla luce di queste considerazioni
Dobbiamo progettare l’applicazione di contact tracing italiana, se necessaria ed utile (argomento su cui si dovrebbero spendere molti più ragionamenti di quanti non se ne spendano), minimizzando i dati raccolti, ovvero raccogliendo il minimo assoluto di dati che ne garantiscano l’efficacia.
Un buon principio per progettare applicazioni informatiche, in particolare se devono essere utilizzate da gran parte della popolazione e gestire informazioni molto riservate come i nostri contatti personali, è infatti quello della minimizzazione dei dati. Non è solo un dovere imposto da leggi e regolamenti come il GDPR; è un principio raccomandato dalla Commissione Europea proprio nelle linee guida ue su come reagire all’emergenza COVID-19.
Il modello migliore è decentralizzato
Ad oggi, la soluzione che meglio garantisce la minimizzazione dei dati è quella “decentralizzata” creata dal consorzio europeo DP-3T e non a caso sposata anche dal framework Apple-Google (con minime modifiche). Quest’ultimo punto è importantissimo, perché – questioni di privacy a parte – solo la compatibilità con tale framework consentirà ad una app di funzionare in modo efficace ed efficiente sulla stragrande maggioranza degli smartphone in circolazione (infatti, l’esperienza degli implementatori francesi già sta dimostrando i limiti di soluzioni che non tengano conto di ciò).
Come funziona il modello decentralizzato (Apple-Google-Dp-3T)
Il punto sostanziale che caratterizza questo modello è che ogni cellulare genera un codice identificativo anonimo (pensate ad un lungo numero casuale) e lo tiene solo nel dispositivo stesso. Non esiste quindi nessun registro, nessun modo per de-anonimizzare tali identificativi.
Vediamo come funziona questo modello decentralizzato.
- Ogni volta che due cellulari si “incontrano” (ovvero rimangono ad una certa distanza per un certo tempo, due parametri che dovranno definire le autorità sanitarie) essi si scambiano (usando il protocollo Bluetooth, ed in particolare una versione nota come BLE, Bluetooth Low Energy) il proprio identificativo anonimo. Quindi il cellulare di ognuno di noi porta con sé soltanto una lista di numeri (privi di qualsiasi elemento identificativo), che verranno poi cancellati dopo un certo tempo (un numero di giorni che le autorità sanitarie definiranno come il “periodo massimo” entro cui un contatto è significativo).
- L’operatore sanitario, dopo aver identificato (tramite test, o sintomatologia) un nuovo caso di COVID-19, durante l’intervista di contact tracing (che, ricordiamolo, verrebbe comunque fatta “manualmente” in assenza di app), fornisce al paziente un “codice di sblocco” che permette al paziente stesso – se vuole – di caricare il proprio identificativo anonimo su un server
- L’app contatta a intervalli regolari il server scaricando la lista di codici di contagiati e la confronta con la lista dei propri codici di contatto in memoria.
- A questo punto, solo il cellulare che “riconosce” uno di quei codici di contagiati all’interno della propria lista di codici di persone con cui è stato in contatto avvisa con notifica l’utente, che quindi è l’unico a sapere di avere avuto un contatto, e nemmeno “con chi”. Questo processo di validazione avviene tutto in locale sul nostro cellulare.
Il server non contiene quindi né la lista dei tracciamenti né le chiavi per deanonimizzare i contatti avvenuti, o altri fantasiosi dati; interviene solo per fornire i codici dei contagiati (anonimi e di cui non ha le chiavi usati per crittografarli). Questa modalità tra l’altro prevede un server con un carico enormemente ridotto rispetto a soluzioni centralizzate (dove il server crittografa i codici e – in alcune soluzioni – persino ha tutta la lista delle persone tracciate). Il che oltre ad essere enormemente meglio dal punto di vista della sicurezza (infatti il server non conterrebbe sostanzialmente nessun dato “interessante” per un aggressore) rende fattibile erogare il servizio con un’infrastruttura in-house di tipo pubblico, anziché doversi appoggiare a fornitori esterni.
Ovviamente, questo non significa che i sanitari non raccolgano, su un sistema diverso, le cartelle cliniche e i dati sui tamponi e sui malati, per motivi epidemiologici! Ma si tratta di due sistemi separati che non hanno nessun motivo utile per comunicare l’uno con l’altro.
Questo modello totalmente decentralizzato non è l’unico. Per brevità non discutiamo nemmeno di un modello “completamente centralizzato” in cui tutti i contatti di tutti i cittadini vengono salvati da qualche parte: si tratterebbe di una scelta disastrosa e completamente contraria ad ogni normativa, etica ed anche al banale buonsenso.
La differenza tra l’attuale Immuni e il modello decentralizzato
Tuttavia, molte app, anche in Europa, hanno sperimentato una versione “ibrida” di centralizzazione: sembra essere stata scelta anche nell’attuale versione dell’app Immuni italiana ora in test, oltre che nella “cugina” francese (app pensate, ricordiamolo, prima che Apple-Google annunciassero la propria mossa; e i cui sviluppatori ora, non a caso, già parlano con Apple e Google per prepararsi all’eventuale cambio di modello). In questa versione è il server di back-end a generare i codici univoci per ogni dispositivo. I dati dei contatti vengono mantenuti nel singolo cellulare, ma il semplice fatto che siano stati attribuiti centralmente consente, volendo, di de-anonimizzare i dati.
È importante sottolineare che questa scelta non fornisce alcun valore aggiunto rispetto al modello totalmente distribuito. Ad esempio, un tipico motivo che è stato suggerito per optare per questa soluzione parzialmente centralizzata è dare la possibilità ai sanitari di avere i dati dei “contatti” per poter procedere ad esempio a chiamarli attivamente a fare i test, o per verificare il rispetto di eventuali disposizioni (come la quarantena preventiva). Questo motivo, in realtà, non sussiste.
Intanto, se si pensa che sia necessario, è possibile programmare la app per condividere i dati di ricontatto delle singole persone di interesse, senza bisogno di costruire un database centrale “a priori”. Inoltre, è possibile usare l’app stessa, eventualmente “esibita” dal cittadino, per attestare la presenza o l’assenza di condizioni di quarantena. Entrambe queste scelte, si noti, vanno ben ponderate, per bilanciare invasività e utilità: ma in ogni caso sono molto migliori, in quanto decentrate, della costruzione di un database centralizzato.
In altre parole, nella centralizzazione non c’è nessun vantaggio per le autorità sanitarie (né per i cittadini), ed esistono solo dei potenziali svantaggi: ad esempio, ciò significa un maggior carico e richiesta di continua disponibilità per il server centrale, oltre a renderlo un ghiotto bersaglio per aggressori. Lo svantaggio è evidente: se nel primo caso il server non richiede particolari misure di protezione, in questo caso creiamo un sistema da proteggere da attacchi cyber con misure estremamente raffinate, perché contiene dati di contatto de-anonimizzabili di (potenzialmente) milioni di cittadini.
Un server tutto italiano grazie al decentramento
Minore carico del server ha anche un altro vantaggio: renderebbe la soluzione compatibile con la scelta che il Governo sembra al momento preferire (come detto ieri anche da Domenico Arcuri, commissario all’emergenza nominato dal premier Conte). Ossia un server non in cloud ma residente su infrastrutture tutte italiane e pubbliche.
In conclusione, la palla al Governo
Non si vede veramente alcun motivo per optare per questa soluzione. La soluzione de-centralizzata ci tutela da questo e da molti altri rischi. Ci deve essere un motivo forte per fare diversamente, che in questo momento francamente non si vede. L’app Immuni dovrebbe virare verso questo modello e usare il framework di Apple-Google appena il relativo codice sarà disponibile (metà maggio). I suoi sviluppatori, a quanto risulta, già hanno deciso di sposare questo nuovo modello, ma il committente dell’app – il Governo – deve ora comunicare alcuni aspetti necessari, come la natura e collocazione del server; l’interfaccia verso gli operatori sanitari.
