Eccoci di nuovo con questa rubrica mensile. Trovate qui tutti gli articoli della rubrica.
Oggi voglio parlare un po’ dei sistemi di contact tracing. Ne parlerò dal punto di vista prettamente tecnico, perché siamo pur sempre su /r/ItalyInformatica (se volete, qualcosina la scrissi a suo tempo su /r/italy).
L’obiettivo
L’idea del cosiddetto contact tracing, termine usato abbastanza impropriamente, è quella di cercare in qualche modo di capire quale sia la probabilità che una certa persona sia stata esposta a un patogeno attraverso il contatto con persone infette. Il fatto che ci si possa infettare in altri modi, ad esempio leccando corrimano, pur essendo eventualmente rilevante dal punto di vista epidemologico (non molto se la gente si comporta in maniera sensata), non lo è ai fini del contact tracing, che semplicemente non serve a capire “se sei infetto” ma “quanto è probabile che ti sia preso una malattia attraverso il contatto diretto con persone”.
Nell’impossibilità economica di fornire a ogni cittadino un dispositivo atto al contact tracing, l’obiettivo andrebbe raggiunto attraverso oggetti che le persone già hanno, e la scelta praticamente obbligata sono gli smartphone.
Non sono un dispositivo ideale, perché non tutti li hanno e non tutti quelli che li hanno ne hanno di sufficientemente recenti (o vecchi, a seconda della tecnologia che si vuol scegliere), ma comunque sono abbastanza diffusi.
Il GPS (e simili, ci siamo capiti)
La prima cosa che viene in mente di usare è il GPS. È ubiquo, essendo presente sui telefoni già dai tempi dei feature phone (ve li ricordate?) e sembra abbastanza adatto. Registrando la posizione di tutti, è facile capire quanto ogni persona è stata vicino a un’altra e per quanto tempo, e calcolarsi la percentuale di rischio a partire da questi dati è un gioco da epidemiologi.
Come chiunque si sia imbattuto in problemi simili sa (io lavoro molto su sistemi di gestione di grandi cantieri, sigh), le cose non sono così semplici. Il GPS, nonostante le apparenze, è un candidato pessimo.
Prima di tutto non è preciso, quantomeno non con le antenne che montano sui telefonini. Fa errori macroscopici, è fortemente influenzato da fattori ambientali sia fissi (edifici alti, vie strette, vegetazione), sia variabili (condizioni meteo). Poi, soprattutto, funziona solo e soltanto all’aperto, e le persone all’aperto tendono a starci poco. Infine, ma questo potrebbe (sigh) essere sacrificato all’altare della necessità, l’idea che qualcuno possa sapere dove si trovi l’intera popolazione (o quasi) in qualsiasi momento è un tantino inquietante.
Insomma, pessimo candidato, buttiamolo anche via e non ne parliamo piú.
Il Bluetooth
Di questo invece ne parleremo un bel po’, ché va molto meglio. Il Bluetooth è un protocollo nato per far comunicare dispositivi tra loro senza fili consumando il meno possibile, in un’epoca in cui le comunicazioni senza fili erano o pessime o esose, e talvolta ottiche. Tra revisioni varie è arrivato miracolosamente ai nostri giorni, principalmente perché permette di collegare controller e cuffiette senza piangere troppo (ma comunque piangendo un pochino).
Oggi funziona piuttosto bene e consuma molto poco, specialmente nella sua modalità Bluetooth Low Energy, che da qui in poi chiamo BLE e che è sostanzialmente un modo d’uso della versione 4, l’ultima, del protocollo.
Nonostante apparentemente non sia un sistema utile a tracciare alcunché (è grossomodo un USB senza fili, e a nessuno verrebbe in mente di dire “oh, tracciamo i contatti via USB”), in realtà è un buon candidato, poiché ha alcune funzionalità tipiche dei transponder, che sono i sistemi usati per fare queste cose quando servono, e che spesso si tirano su proprio con tecnologia BLE.
Rilevare e farsi rilevare
Prima che due dispositivi BLE possano iniziare a comunicare fra loro, devono connettersi. Senza addentrarsi troppo nelle particolarità, l’idea è che un dispositivo possa mettersi nello stato “ehi, sono disponibile!” e un altro dispositivo possa mettersi a cercare tutti quelli disponibili attorno a sé, connettendosi poi a quello opportuno.
In questa fase di ricerca, è possibile calcolare la potenza del segnale di ogni dispositivo disponibile, potendo quindi fare una valutazione della distanza tra il dispositivo che cerca e quello che si fa trovare.
Insomma, abbiamo lo strumento ideale. Se su ogni telefono installiamo un’app che accende il BLE sia in modalità “ricerca” che in modalità “sono disponibile” e trasmette il proprio identificatore, possiamo continuamente sapere chi c’è attorno a ogni telefono, quanto vicino e per quanto tempo. Abbiamo tutti i dati necessari a calcolare eventuali probabilità di rischio senza dare mai la posizione. Una figata, rispetto al GPS.
Centralizzato o decentralizzato
Ma come aggregare i dati in modo da poter calcolare il rischio? Beh, esistono sostanzialmente due modelli di raccolta dei dati.
Il primo implica che tutti i contatti, coi relativi dati di potenza del segnale, vengano caricati su un server centrale. Tale server fa gli opportuni calcoli di probabilità di passaggio del patogeno da una persona all’altra. Quando il Sitema Sanitario viene a conoscenza di una persona infetta, potrà avere dal server una lista di tutti i contatti avuti dalla persona e della relativa probabilità di contagio. Potrà quindi procedere a contattare le persone con alta probabilità di contagio e imporre loro di farsi un qualche genere di test di analisi (che potrà anche non essere a elevatissima precisione: se due analisi indipendenti, come il contact tracing e il test, danno entrambi un’elevata probabilità di contagio, la probabilità di contagio è molto elevata con una precisione maggiore di quella del test).
L’enorme vantaggio di questo approccio è la possibilità, per il sistema sanitario, di sapere con precisione chi è stato probabilmente contagiato. Il grandissimo svantaggio è sostanzialmente lo stesso: si caricano informazioni sulla salute di molte persone su un server centrale, mettendo in serio pericolo la loro privacy.
Il secondo modello, invece, implica che tutte le informazioni sui contatti restino sui telefoni delle persone, senza che venga caricato nulla su un server centrale. Quando il Sistema Sanitario viene a conoscenza di una persona infetta, caricherà il suo identificativo (eventualmente in maniera anonima) su un server centrale. I telefoni, ogni tanto, potranno controllare sul server centrale quali dei propri contatti siano stati segnalati come infetti, e calcolare quindi la percentuale di rischio per il proprio utente. Se la percentuale diventa sufficientemente alta, il telefono notifica il proprio utente pregandolo di isolarsi e contattare il Sistema Sanitario.
Questo secondo metodo offre una privacy elevatissima, se costruito a dovere, ma si fonda moltissimo sul senso civico delle persone, che potrebbero, per qualsiasi motivo, dalla paura dell’isolamento a quella di perdere il lavoro, non notificare il Sistema Sanitario.
Sicurezza e risparmio energetico
Purtroppo, tutto questo non è al momento possibile. Il presupposto da cui siamo partiti, quello dell’app che tiene il BLE acceso facendosi rilevare e rilevando, non è al momento attuabile. Vediamo come si comportano a riguardo i due sistemi operativi per smartphone piú diffusi.
Android
Android, dei due sistemi operativi, è notoriamente il piú permissivo. Per quanto riguarda BLE, permette alle app di accendere l’antenna e di restare in ricerca di dispositivi a cui connettersi, ma non permette di rendere il telefono rilevabile per tempi lunghi.
Il motivo è molto ragionevole: ogni antenna BLE ha un identificativo (circa) univoco, che viene fornito quando si rende l’antenna rilevabile. Tenere l’antenna sempre accesa e rilevabile permette a chiunque piazzi antenne BLE fisse di effettuare un tracciamento passivo delle persone. Immaginate un ufficio in cui tutti hanno il BLE acceso e rilevabile: il datore di lavoro potrebbe piazzare antenne ovunque e sapere costantemente dove sono tutti. Ovviamente si possono immaginare situazioni persino peggiori. Insomma, non è fattibile.
iOS
Apple, per iOS, ha fatto le medesime considerazioni di sicurezza, e allo stesso modo non permette di rendere il telefono rilevabile a tempo indeterminato. Inoltre, Apple è estremamente attenta ai consumi energetici del proprio sistema, e per questo impedisce anche di tenere il BLE acceso in ricerca: dopo poco, se non viene effettuata alcuna connessione, si spegne.
Workaround
Esistono workaround a questa situazione, che però non ho studiato troppo. A grandi linee implicano di tenere l’app aperta, talvolta anche con schermo acceso (l’app darà una schermata nera per fingere sia spento), in modo che possa fare svariate riaccensioni una dopo l’altra.
Oltre ad essere deleteri per la batteria, questi metodi espongono ai suddetti problemi di sicurezza.
Apple e Google
Per permettere di usare comodamente il BLE per il contact tracing, Apple e Google hanno sviluppato un set di regole e protocolli che possa permettere alle app di tenere tutto costantemente acceso in sicurezza.
L’idea di base è quella di cambiare automaticamente spesso l’identificatore dell’antenna, in modo da prevenire il tracciamento da parte di terzi. Il telefono memorizzerà tutti i propri identificatori cambiati nel tempo, e li comunicherà al Sistema Sanitario.
Apple e Google consigliano/impongono il sistema decentralizzato, anche solo perché comunicare di continuo il nuovo identificatore è estremamente esoso. Meglio, invece, comunicarli tutti in blocco al Sistema Sanitario al momento dell’identificazione come infetto. Il resto del sistema funzionerebbe in maniera identica alla versione a identificatore singolo.
Questo sistema comune non è però ancora disponibile su iOS e Android, e diventerà disponibile nei prossimi giorni tramite aggiornamento dei servizi di sistema. Qualunque app voglia essere effettivamente sicura dovrà necessariamente usarlo, e quindi dovrà seguire le linee guida, compresa la decentralizzazione. Questo fa sí che non vedremo app serie centralizzate (con buona pace di Immuni, che ha, sembra, dovuto cambiare tecnica in corsa).
Perché è interessante?
Trovo tutta questa vicenda estremamente interessante.
Prima di tutto ci fa notare che no, non è vero che avendo il telefono in tasca “diciamo tutto” a chi ce lo ha fornito. Stavolta è servita un’informazione nuova, che nessuno ha, o che quantomeno nessuno ha con precisione sufficiente.
Un po’ per questioni di costi e un po’ per praticità, si è stati obbligati a cercare la soluzione in qualcosa che già è molto diffuso, come gli smartphone. La soluzione che molti (compreso qualche nostro politico) avevano in testa, magari pure dicendosi “vabbè è facilissimo”, era però completamente sbagliata. Non era sufficientemente precisa e produceva dati contenenti informazioni rilevanti (la posizione geografica) e inutili. Il fatto che molti lo ritenessero accettabile l’ha detta estremamente lunga su quanto siamo attenti nel dare informazioni superflue a chi ce le chiede (la classica app che per fare fotografie chiede di poter usare il microfono).
La soluzione reale, che anche sembrava molto semplice e che fa uso di una tecnologia già ampiamente usata allo scopo in ambito industriale, si è invece scontrata violentemente con le impostazioni di sicurezza estremamente stringenti che gli smartphone hanno.
Per risolvere, le due maggiori aziende che si occupano di sistemi operativi per smartphone hanno dovuto elaborare un protocollo comune, per semplificare la vita a loro stesse e a tutti, cedendo su alcuni pilastri della loro tecnologia (il risparmio energetico per Apple è un caposaldo enorme), e imponendo ai produttori di app che stavano letteralmente partendo per la tangente alcuni rigorosi paletti infrastrutturali.
Insomma, a volte i problemi sembrano avere una soluzione scema. Quasi sempre tale soluzione è sbagliata, e quella giusta non è semplice come sembra. Spero che chi insegna ingegneria del software prenda ampio spunto da questa vicenda, perché è di gran lunga migliore di qualsiasi esempio abbia visto quando studiavo.
Perché Immuni non è ancora uscita? Beh, un po’ perché sono partiti per la tangente come tutti e hanno dovuto ricominciare, ma un po’ anche perché, se è ben fatta, non esiste ancora la piattaforma operativa su cui farla girare.
