App Immuni: valutazione di impatto e indici di rischio inattendibili

Il piano di gestione del rischio per Immuni non è attendibile e, ad oggi, rende l’uso della app pressochè inutile in quanto mancano dati reali a sostegno del sistema. I criteri di rischio per determinare la notifica di esposizione sono dettati dalle API di Apple e Google che peccano di astrazione dalla realtà non essendo stati integrati dai criteri del Ministero della Salute attualmente incapace di verificare nella realtà le ipotesi dell’algoritmo a causa della mancanza di una campagna di test e tamponi a tappeto e peccano altresì dell’impossibilità di autenticare i dispositivi funzione attiva solo per iOS .

Obiezione è appena iniziata la sperimentazione e gli elementi fattuali verranno implementati strada facendo. Vero, ma il tempo di Immuni scade al 31 dicembre 2020 ovvero tra sei mesi. È inverosimile che in pochi mesi il Sistema vada a regime. Il tutto potrebbe assumere significato se il cronoprogramma del piano di gestione del rischio fosse stato previsto per tempistiche molto più lunghe cioè in termini di anni . Pertanto al netto degli undici punti da perfezionare indicati nell’Autorizzazione 1.06.2020 dal Garante, le vere criticità di Immuni restano la mancanza di una verifica con test a tappeto e la mancanza di tempo . Tutto questo salvo che il cronoprogramma sia stato previsto in una prospettiva temporale che vada molto al di là del 31 dicembre 2020. Le due finalità di Immuni e le relative basi giuridiche. Immuni ha la finalità di allertare i cittadini ove abbiano avuto un contatto a rischio di contagio ai sensi dell’art. 9 co.2, lett. i e art. 6 co.1, lett. e GDPR. Immuni ha altresì la finalità di rendere disponibili informazioni anonime ed aggregate per ricerca e statistiche ai sensi dell’art. 9 co.2, lett. j GDPR. Algoritmo crogiolo dei due trattamenti grazie a criteri di rischio verificati. L’algoritmo del sistema Immuni ragiona” sulla base dei criteri di rischio implementati a livello tecnico-teorico durata e distanza e a livello esperienziale correttivi inferiti dalla realtà dei casi . Attualmente il sistema lavora unicamente con i criteri di rischio dettati da Gapple . Tuttavia spetta al Ministero della Salute introdurre criteri più aderenti alla realtà e caratterizzanti. I criteri di rischio devono essere innanzitutto verificati tramite i risultai dei test sierologici e dei tamponi al fine di garantire la qualità del dato alla base del data model e l’attendibilità dei risultati. Nei criteri di rischio confluiscono e dai criteri di rischio dipendono sia gli esiti del trattamento di contact tracing sia gli esiti del trattamento di studio statistico e ricerca. Il contact tracing raggiunge l’efficacia quando copre la maggior parte dell’utenza che dev’essere un’utenza verificata autentica . Gli analytics Operational Info relativi ai dispositivi dei contattati” con o senza esposizione al contagio potrebbero costituire dei validi elementi dei criteri di rischio ove verificati. Infatti gli Operational Info hanno un flusso informativo che attraverso il crogiolo dell’algoritmo passa dagli esiti del contact tracing al server della PA per costituire materiale degli esiti delle statistiche per poi ritornare sotto forma di statistica a costituire una componente dei criteri di rischio applicati dall’algoritmo per affinare gli esiti del contact tracing. Parimenti per gli analytics Epidemiological Info che, veri in partenza in quanto attinenti al dato reale del tampone, costituirebbero anche essi validi elementi dei criteri di rischio. Gli Epidemiological Info hanno un flusso informativo che attraverso il crogiolo dell’algoritmo passa dagli esiti di contact tracing sui positivi al server della PA per costituire materiale degli esiti delle statistiche per poi ritornare sotto forma di statistica a costituire una componente dei criteri di rischio applicati dall’algoritmo per affinare gli esiti del contact tracing. La sequenza del flusso informativo è la medesima algoritmo - esiti contact tracing – server PA – statistiche – algoritmo – affinamento esiti contact tracing” e così via in cicli sempre più virtuosi. I criteri di rischio vengono ciclicamente determinati dalle risultanze dei due trattamenti contact tracing e statistiche . I criteri di rischio sono al fondamento dell’algoritmo. Quindi l’algoritmo si alimenta e racchiude quale anello di una catena virtuosa sia il trattamento di contact tracing sia il trattamento a fini statistici e di ricerca. La trasparenza dell’algoritmo a garanzia del diritto di opposizione e di cancellazione dell’interessato. L’algoritmo costituisce elemento centrale del sistema unitamente ai criteri di rischio. Pertanto risulta di enorme importanza assicurare la trasparenza del meccanismo che lo governa e la trasparenza dell’elaborazione dei criteri di rischio. Cosicché l’interessato, una volta appreso il meccanismo dell’algoritmo, possa decidere liberamente di opporsi o di cancellarsi. L’opposizione ex art. 21 GDPR avviene mediante la disinstallazione dell’app e la cancellazione ex art. 17 GDPR avviene mediante una funzione appositamente messa a disposizione dal Framework A/G API Gapple volta a interrompere l'utilizzo dell'app in qualsiasi momento che implica l’eliminazione di tutte le TEK e dei relativi RPI. Attualmente, purtroppo, la valutazione di impatto presentata dal Ministero della Salute non ha precisato la descrizione del funzionamento dell’algoritmo come osservato appunto dal Garante Privacy nell’Autorizzazione del 1.06.20 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 . Pertanto uno dei 12 punti di raccomandazione dell’Authority nei confronti del titolare del trattamento è costituito dalla raccomandazione di assicurare che l’algoritmo - sia 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 - sia reso disponibile allo scrutinio da parte della comunità scientifica . Il Garante raccomanda altresì che gli utenti siano adeguatamente informati in ordine al diritto di opposizione concretizzato nella possibilità per l’interessato di disinstallare l’app facendo presente che le chiavi saranno via via cancellate, al termine del quattordicesimo giorno di vita, anche sull’infrastruttura centrale e siano informati altresì in ordine al diritto di cancellazione 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 facendo presenti anche le conseguenze di tale cancellazione. I 12 punti da perfezionare secondo il Garante Privacy. All’esito della disamina della DPIA presentata dal Ministero della Salute, il Garante Privacy nel Provvedimento di autorizzazione al trattamento dei dati personali effettuato attraverso il Sistema di allerta Covid-19 - App Immuni del 1° giugno 2020 ha focalizzato sotto forma di raccomandazione 12 punti da perfezionare 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 dei falsi positivi ovvero 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. informare adeguatamente gli utenti della possibilità di disattivazione temporanea dell’app 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 misure di sicurezza adeguate es. anonimizzazione secondo i principi di privacy by design e privacy by default a proteggere gli analytics nel backend di Immuni, evitandone ogni forma di riassociazione a soggetti identificabili § 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. adeguare la composizione del messaggio di allerta alla comprensione anche dei minori ultraquattordicenni § 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 la valutazione di impatto con la descrizione dei ruoli privacy di terzi coinvolti nel trattamento Immuni es. provider della Content Delivery Network incaricato quale sub-responsabile da Sogei evidenziando la sussistenza di eventuali rischi per gli interessati i cui dati siano trattati dal sistema § 6 10. limitare al massimo i tempi di conservazione degli indirizzi IP dati identificativi in chiaro nella misura strettamente necessaria al rilevamento di anomalie e di attacchi § 7.3 11. adottare misure di tracciamento dei file log di tutti gli operatori del sistema Immuni e non solo quelli relativi agli accessi degli amministratori sui sistemi operativi, sulla rete e sulle basi dati § 7.3 12. adottare misure tecniche e organizzative per ridurre il rischio di implementare TEK errate non rispondenti a soggetti positivi reali ma apparsi come tali a seguito di errori materiali o diagnostici § 7.3 . Al netto di queste preziose raccomandazioni e del rischio di re-identificazione, in questa sede preme evidenziare determinati tipi di criticità ovvero quelli relativi ai criteri di rischio derivanti dai data analytics Epidemiological Info e Operational Info. Trattamento per finalità di allerta. Dati di contact tracing TEK e RPI. Si tratta della gestione dei dati del sistema di allerta contagio tramite strumenti elettronici complementari al SSN. Il sistema di allerta si compone di due parti la app installata sui dispositivi e il backend costituito dal server della Pubblica Amministrazione Ministero Sanità e da altri server strumentali. Si parte dal dato reale dell’individuo positivo al virus rilevato tramite tampone dall’operatore sanitario competente. Quest’ultimo - una volta censito il caso con data tampone, data ultimo contatto a rischio e provincia - chiede all’interessato se voglia condividere i dati di contact tracing raccolti dal proprio cellulare con tutti gli altri utenti di Immuni riversandoli nel server della PA. Nell’ipotesi affermativa si apre l’onboarding del soggetto positivo in cui l’operatore sanitario richiede all’utente di avviare sul proprio dispositivo la funzione per generare la chiave di sblocco OTP – One Time Password della durata di circa 2 minuti che – una volta inserita nel server dal sanitario autorizzato e identificato tramite il Sistema Tessera Sanitaria Sistema TS – consente al soggetto di scaricarci le TEK Temporary Exposure Key e gli analytics Epidemiological Info . Ogni TEK contenuta nel telefono ogni giorno si genera una nuova TEK produce 144 codici identificativi random o RPI Rolling Proximity Identifier che vengono diffusi all’esterno tramite tecnologia BLE Bluetooth Low Energy . Ogni volta che un dispositivo entra in contatto con un altro, i rispettivi codici random RPI vengono scambiati e ciascun telefono registra in un elenco interno il codice dell’altro. In tal modo il cellulare raccoglie una lista di tanti codici per quanti sono i dispositivi incontrati”. Ogni giorno, il backend di Immuni elabora un file contenente tutte le TEK dei positivi scaricate nel server della P.A ., file che – dopo essere stato crittografato e firmato digitalmente – viene pubblicato nella Content Delivery Network CDN dedicata affinchè venga scaricato da ogni dispositivo per la verifica di avvenuto contatto matching . Dalle TEK si risale ai codici da queste generati e in caso di matching con la lista interna al dispositivo interviene l’algoritmo di Immuni per determinare se il contatto sia stato significativo o meno sotto il profilo del rischio di contagio. In ipotesi affermativa, l’algoritmo comunica al dispositivo una Notifica di Esposizione al virus in cui si raccomanda di rivolgersi al medico o al pediatra di fiducia. Criticità criteri di rischio astratti. Preme evidenziare che i criteri di rischio a fondamento della valutazione algoritmica sono – almeno ad oggi – determinati dal sistema di interoperabilità di GAPPLE. Essi sono distanza e durata del contatto. In realtà tali criteri dovrebbero essere elaborati e dettati dal Ministero della Sanità ??? . L’art. 6, comma 2, lett. b , d.l. n. 28/2020 stabilisce appunto che spetta al Ministero della Salute stabilire i criteri di rischio mentre nella realtà le cose stanno in modo diverso perchè è l’infrastruttura di Apple e Google a dettare i criteri di rischio come si legge del resto anche nelle parole del Garante Privacy nel Provvedimento di autorizzazione della DPIA su Immuni presentata dal Ministero 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” Provvedimento di autorizzazione al trattamento dei dati personali effettuato attraverso il Sistema di allerta Covid-19 - App Immuni– Garante Privacy, 1° giugno 2020 . I criteri di rischio per stabilire l’attivazione o meno della Notifica di Esposizione svolgono un ruolo centrale in tutto il sistema Immuni sia lato periferico dispositivi sia lato centrale server P.A. . La Notifica di Esposizione che appare sullo schermo dello smartphone viene anche inviata al Server per indicare in forma anonima gli ipotetici contagiati. Pertanto se i criteri di rischio sono aderenti alla realtà avremo un quadro generale di media effettivo ma se tali criteri sono generici senza elementi caratterizzanti stabiliti ad esempio dal Min. Salute avremo un quadro generale di media inattendibile o addirittura falsato . Poniamo il caso in cui si registri un contatto ravvicinato di notevole durata per il quale l’algoritmo GAPPLE stabilisca la Notifica. Verificando i fatti però si capisce che trattasi di falso positivo perchè i due dispositivi erano separati da uno schermo di plexiglass . Al di là dell’ipotesi del falso positivo, l’elaborazione dei criteri di rischio necessita di qualità del dato che l’algoritmo non può evincere perchè il ragionamento della macchina appartiene al regno dell’ipotesi mentre il ragionamento umano attiene al regno della realtà. Soltanto i soggetti coinvolti dal fenomeno epidemiologico sono in grado di evincere elementi di fatto specifici, caratterizzanti un criterio di rischio in grado di conferire concretezza all’algoritmo. Alla luce di quanto appena esposto, possiamo osservare che allo stato i risultati del contact tracing relativamente alla parte inerente alla Notifica di Esposizione restano privi di significato senza un riscontro col dato reale dell’effettivo contagio emerso grazie all’immediata applicazione di test sierologici o di tampone. Un’altra criticità del sistema Immuni si registra nel trattamento a fini statistici e di ricerca a causa dell’impossibilità almeno attuale di verificare l’autenticità del dispositivo. Anche in questo caso, l’affidamento su metadati Operational Info estratti da dispositivi non autenticati conduce a risultati viziati. Trattamento per finalità statistica e di ricerca. Criticità Analytics Edpidemiological Info e Operational Info. Si tratta dello studio sui dati analytics a fine di ricerca e statistica. Inoltre questi dati sarebbero importanti anche per il trattamento di contact tracing in quanto contribuirebbero a migliorare il funzionamento di Immuni e dell’algoritmo di determinazione del rischio. I dati analytics sono costituiti da due tipologie gli Epidemiological Info relativi al soggetto positivo e gli Oprational Info relativi a ciascun dispositivo a prescindere dalla Notifica di esposizione ipotetici contagiati o meno soggetti neutri . Tutti questi metadati sono prodotti all’interno dello smartphone rispettivamente del soggetto positivo epidemiological info e del soggetto neutro o ipoteticamente contagiato operational info . I primi servono a mappare il virus e le sue caratteristiche con i relativi indici di rischio. I secondi servirebbero per verificare l’effettivo corretto uso della app e la diffusione del virus sul territorio. Tuttavia - non essendo allo stato possibile eseguire una procedura attendibile di verifica dell’autenticità del dispositivo salvo che per i dispositivi Apple - si preferisce abbandonare questo secondo tipo di valutazione in quanto risulterebbe deviata da informazioni parziali inerenti ai soli smartphone iOS. Nonostante la loro attuale inattendibilità, gli Operational Info devono comunque essere indicati 1 analytics token 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 GAPPLE 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 . Le uniche risultanze che parrebbero più attendibili sono quelle generate dal telefono del soggetto positivo sotto forma di Epidemiological Info ma vedremo nel proseguo che non è così. Gli Epidemiological Info sono costituiti da 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 Epidemiological Info attiene alle TEK degli ultimi 14 giorni. Le Epidemiological Info offrirebbero lo scenario per verificare le effettive componenti del rischio sia a livello generale-statistico sia a livello individuale-statistico fino ad elaborare i rispettivi indici di rischio. Consentirebbero mediante la provincia di appartenenza dei soggetti positivi di ricostruire la mappa del virus sul territorio. Tuttavia gli esiti delle Epidemiological Info essendo stati estratti unicamente dai soggetti positivi non sono rappresentativi del vero andamento del virus a livello generale e dei relativi indici di rischio che necessiterebbero del confronto con i risultati dei soggetti neutri e dei possibili contagiati operational info . Confronto impossibile a causa dell’attuale difficoltà di verifica dell’autenticità dei dispositivi. Infatti la mappa dei positivi per quanto effettiva non rispecchia la realtà della diffusione del virus sul territorio perchè mancano gli asintomatici. Inutilità del Sistema Immuni salvo un orizzonte temporale in deroga alla scadenza del 31.12.20. Abbiamo esordito nella presentazione evidenziando la riflessione conclusiva del presente contributo ovvero l’inutilità del sistema Immuni essendo impossibile che vada a regime nell’arco di appena sei mesi. Tutto cambierebbe se in realtà l’orizzonte temporale immaginato non fosse il termine del 31 dicembre 2020 bensì un orizzonte temporale in deroga almeno di due anni . Tali nuove tempistiche potrebbero consentire la verifica e l’implementazione dei criteri di rischio attualmente inconferenti per cogliere la realtà del fenomeno epidemiologico e per garantire un’effettiva efficacia del sistema di contact tracing.