Gli Stati membri dell’Ue e la Commissione europea hanno stilato il primo documento che ipotizza l’interoperabilità delle app nazionali di alert per il coronavirus. Il sistema descritto consentirebbe di superare alcuni dei limiti dell’app nazionale italiana Immuni (e di sue cugine europee), se il nostro paese aderisse (come sembra) al progetto. Possiamo capirne di più con un approfondimento tecnico delle specifiche, che abbiamo analizzato.
I vantaggi pratici dell’interoperabilità europea per le app covid-19
Il limite più grave ora è che l’app rileva solo i contatti con altri utenti di Immuni. Sei entrato in contatto con un contagiato dal covid-19, dotato solo di un’altra app, di un altro Paese europeo? Immuni non ti avvisa. Il problema si pone reciprocamente per utenti Immuni contagiati che entrano in contatto con utenti di altre app europee.
C’è quindi un rischio di falso negativo e di contagio di ritorno man mano che si intensificano i viaggi tra Paesi per lavoro o turismo. Su iOs, inoltre, all’estero non si riceve affatto una notifica di esposizione (che invece si riceverebbe in Italia).
Si può dire che ad oggi per le migliaia di persone che viaggiano regolarmente in europa, o per chi vive alle frontiere l’app Immuni appare poco funzionale o, addirittura inutile.
Con la soluzione prospettata dalla Commissione nel documento che abbiamo analizzato, questi limiti potrebbero essere superati. Sarà ovviamente necessario un aggiornamento dell’app e le nuove funzionalità dovranno essere implementate da Bending Spoons sia nelle app che nel proprio backend.
E ovviamente tutto ciò funzionerà solo tra app che usano lo stesso framework Apple-Google (come Immuni appunto), ora adottato da Paesi come Germania, Belgio, Danimarca e – dall’autunno, con un volta faccia rispetto alla scelta precedente – Regno Unito; come anche Svizzera. Questi due, non appartenendo all’Unione europea, non è detto che si associno all’interoperabilità, però.
Tutto ciò che resterebbe uguale, invece, è il funzionamento di ciò che fanno i sistemi operativi dei nostri telefoni (lo scambio di dati), già pronti, a quanto pare, ad una soluzione “condivisa”. Ed è proprio su questo presupposto che si baserebbe l’intero protocollo prospettato.
Come funzionerà il nuovo sistema
Il sistema è veramente semplice, quasi scontato. Ma, rispetto a quanto già emerso sui media a riguardo, è importante andare a fondo sul funzionamento, per spiegare impatti pratici e implicazioni tecniche.
Il tutto si basa sul fatto che le singole APP nazionali, in realtà, servono solo a comunicare i dati degli infetti ai server statali e ai vari utilizzatori ma, in realtà, la funzione di interscambio delle chiavi di prossimità via bluetooth è interamente demandata ai sistemi operativi di Google ed Apple e, quindi, è uguale in tutto il mondo.
In sostanza, se un utente italiano ha Immuni installato vuol dire, con ogni probabilità, che ha attivato il sistema GAEN (Google Apple Exposure Notification). Di conseguenza, il sistema operativo del suo device trasmette e raccoglie le chiavi di esposizione di chi gli sta attorno.
- Ebbene, se un utente di Immuni si reca in un altro paese europeo, ove è in uso un’altra app nazionale di contact tracing, il sistema di Alert europeo permette al suo cellulare di acquisire e scambiare regolarmente le chiavi di prossimità dei cittadini di quel paese, visto che si tratta esattamente dello stesso protocollo.
- Se poi l’utente dovesse tornare in Italia e ricevere un controllo di esposizione, questi dati verrebbero addirittura coinvolti nel controllo stesso, tuttavia senza possibilità di trovare alcuna corrispondenza.
Immuni infatti ha un backend che raccoglie solo i dati dei cittadini italiani e che non dialoga con i backend delle app delle altre nazioni.
Non è chiaro se l’interoperabilità è un passo per consentire a un contagiato di collegarsi al server sanitario, per condividere le chiavi dei contatti avuti, anche quando si trova all’estero. Adesso è impossibile. Ma per risolvere questo limite servirebbe una collaborazione sanitaria tra Paesi perché il server italiano accetti una diagnosi covid-19 fatta da un sistema sanitario di un altro Paese europeo (e viceversa, i loro server devono accettare la nostra diagnosi).
Verso uno European Federation Gateway Service
La soluzione prospettata dal documento rilasciato ieri, che si avvale delle linee guide rilasciate da un’importante multinazionale tedesca di servizi IT, la T-Systems, è un single European Federation Gateway Service, ovvero un backend europeo che si occupa di sincronizzare, tra i vari backend, le diagnosis keys ogni tot di ore.
La Commissione si appoggia quindi al perfetto protocollo che Apple e Google hanno realizzato per consentire il miglior sistema possibile di contact tracing. Senza il “ricatto tecnologico” delle due aziende californiane a quest’ora ci troveremmo di fronte ad app nazionali che non potrebbero dialogare tra loro. Il coinvolgimento delle due Big è stato pertanto essenziale, a fronte del loro ruolo monopolistico.
Apple e Google sapevano che saremmo andati questa direzione.
Si va infatti verso una soluzione che era stata anticipata dalle due aziende già il 10 aprile scorso. Le stesse, infatti, avevano parlato di una seconda fase in cui avrebbero lavorato su una “ampia piattaforma di contact tracing” allo scopo di permettere proprio l’interazione con un più ampio ecosistema di app e autorità sanitarie governative.
È esattamente quello che accadrà e che si sta cercando di mettere nero su bianco sotto la guida dell’Europa, con delle regole e garanzie che siano stabilite da chi ci governa. Giustamente.
Come funzionerà il sistema di alert europeo
Sarà ammesso a dialogare con questo Gateway un numero ristretto di attori, uno per Stato appunto.
I dati che viaggeranno ogni giorno sono estremamente esigui, parliamo delle chiavi dei positivi, quindi è ragionevole ipotizzare 20-30 MB al giorno.
Con questo sistema sarà veramente semplice “aggiungere” un nuovo paese, semplicemente acconsentendo al dialogo con il gateway comunitario.
Da questo, quindi, passeranno tutte le chiavi degli infetti, ma non inviate direttamente da loro, bensì dal server nazionale.
I dati che transiteranno sul Gateway saranno quindi realmente anonimi e non vi sarà alcun riferimento agli utenti (su questo server non ci saranno nemmeno i log relativi alle chiamate delle app, visto che non c’è nessun rapporto diretto tra la Immuni di turno e il Gateway Comunitario).
Questo, quindi, fornirà sempre le chiavi di tutti ad ogni Stato.
Il documento non tratta gli aspetti relativi alla privacy. D’altro canto, sarebbe davvero superfluo. Innanzitutto, perché il sistema si basa su chiavi anonime (nel senso tecnico del termine) e, in ogni caso, saranno le app nazionali a doversi occupare dell’acquisizione di eventuali consensi relativi anche al trasferimento di dati ad altri enti.
Consenso che, allo stato attuale, non sembra avere alcun senso ai sensi del GDPR. Il dato, completamente anonimo, che lascia il server italiano per andare in giro per l’Europa, è un dato che non consente l’identificazione della persone e, pertanto, non è un dato personale ai sensi dell’art. 4 del regolamento UE 679/2016 che prevede che per «dato personale» si intende qualsiasi informazione riguardante una persona fisica identificata o identificabile.
Cosa deve fare Immuni
I backend delle varie app nazionali avranno quindi le diagnosis keys di tutti gli Stati.
Le app continueranno a scaricare le diagnosis keys (le chiavi degli infetti) di tutti gli utenti “nazionali” a meno che un utente non abbia effettuato un viaggio in uno Stato incluso nel progetto.
In tal caso, se l’utente diventa infetto, nel caricare le Temporary Exposure Keys deve in qualche modo avvertire di essere stato in determinati paesi. Al contrario, se l’utente riceve le chiavi di esposizione deve poter ricevere quelle dei paesi che ha visitato (altrimenti non verrebbe mai a sapere di aver incontrato un positivo).
Le soluzioni prospettate sono due. O tutti scaricano tutto oppure l’app dell’utente deve poter sapere i paesi che lo stesso ha visitato al fine di selezionare gli Stati e ridurre la quantità di dati scaricata (fattore di cui si tiene ancora conto, soprattutto in alcuni paesi dell’est europeo).
E qui il punto chiave.
Come dovrebbero essere eventualmente indicati i paesi dove l’utente è stato?
Tre ipotesi:
- Autorilevamento tramite la rete cellulare NMCC (Network Mobile Country Code)
- Inserimento manuale dell’utente
- Misto: l’app suggerisce, l’utente conferma.
Ad oggi la funzione non è implementata e non sembra essere tra quelle “ammesse” da Apple e Google.
In ogni caso è un dato che dovrebbe essere conservato per 14 giorni e in qualche modo comunicato al server nazionale, che poi lo utilizzerebbe per “filtrare” le diagnosis keys scaricate.
Comunicazione tra i vari backend (tramite Gateway)
Al momento quella descritta sopra sembra la soluzione più accreditata.
L’alternativa sarebbe optare per un sistema peer-to-peer. In questo modo i vari backend comunicherebbero i dati direttamente tra di loro. A nostro avviso si tratta però di un sistema leggermente più complesso da gestire, con più svantaggi rispetto a quello del Federal Gateway. Inoltre la potenziale entrata in campo di questo backend terzo europeo non sembra generare alcun tipo di problema, né legale né tecnico.
Tuttavia, per completezza, il documento sostiene che il sistema P2P (peer to peer) non è “categoricamente escluso”. In sostanza, non è detto che in futuro non venga adottato a supporto o come alternativa.
Ma, semplicemente, non è necessario.
Archivio dei dati
Il Federal Gateway salverà per 14 giorni i dati nei propri archivi. Ciò sarà necessario per evitare perdite di dati nel caso in cui uno Stato sia temporaneamente offline per un giorno o più. In questo modo avrebbe 14 giorni di tempo per riprendersi i dati.
Inoltre, in caso di ingresso di un nuovo Stato, questo potrà ricevere le chiavi degli ultimi 14 giorni, con apprezzabile vantaggio.
In relazione a ciò, consideriamo anche che gli altri Stati sono molto indietro nel lancio delle loro app rispetto all’Italia (tra i primi tre Stati, malgrado le ridondanti polemiche social sui ritardi). Di conseguenza gli altri entreranno nel sistema gradualmente.
Api rest
Per i nerd, l’analisi delle API conferma quanto sopra detto.
L’interfaccia del Federal Gateway ha solo 4 funzioni:
- diagnosiskeys/download/{date}: permette ai backend nazionali di scaricare le nuove diagnosis keys a partire dalla data inviata come parametro ({date}). Tra le chiavi scaricate, vengono omesse quelle del paese che effettua la richiesta, giustamente. I dati vengono scaricati in più blocchi, “batch”.
- diagnosiskeys/upload: tramite questo servizio i backend posso caricare nel Federal Gateway le nuove diagnosis keys raccolte.
- diagnosiskeys/callback: Questa funzione permette di registrare quelle che in gergo si chiamano callback, degli url che vengono “chiamati” dal Federal Gateway quando ci sono nuovi dati disponibili. In pratica il backend nazionale può dire al Federal Gateway “se ci sono novità avvisami a questo url”.
- diagnosiskeys/audit/download/{date}/{batchTag}
- Permette di verificare l’integrità di un batch di chiavi scaricate tramite verifica delle informazioni ottenute in risposta (Countries contained in the batch, Batch signatures by country, Uploading Information).
In conclusione
Insomma, il sistema di tracing prosegue la sua strada verso la migliore delle soluzioni tecnologiche possibili e risolve anche il problema della territorialità (grazie alla visione di Apple e Google).
A questo punto non resta quindi che aspettarsi qualche gilet che dica che la Germania ha messo su questo sistema perché vuole conoscere i dati di prossimità degli utenti italiani. Per controllarci meglio.
