Il 29 aprile Apple e Google hanno rilasciato la versione beta delle loro API per le Public Health Agencies. Di colpo, la via maestra per l’allerta covid-19 su smartphone.
Le novità sono molte e iniziano a delineare lo scenario, che a questo punto possiamo definire “mondiale”, all’interno del quale si muoverà la maggior parte della tecnologia di exposure notification, ossia allerta (non più contact tracing) tesa a coadiuvare le indagini epidemiologiche per limitare la diffusione del Covid-19.
La sensazione, man mano che si conoscono maggiori dettagli sul progetto, è che quella ideata dalle due “big sister” potrebbe essere la soluzione ideale per far tornare la fiducia della gente verso un sistema che, in effetti, ad oggi, sembra minimizzare considerevolmente l’impatto sui diritti e sulle libertà degli individui.
Requisiti minimi
Partiamo innanzitutto dai requisiti di sistema che gli smartphone dovranno avere per essere contact-tracing-ready, recintando così la community globale che potrà usufruire del servizio: la buona riuscita del progetto sarà direttamente proporzionale al numero di persone interessate.
In relazione ai dispositivi Android, sarà sufficiente aggiornare l’app Google Play Services (si aggiorna in background, l’utente non se ne accorge quasi mai). Si tratta dell’app che permette alle altre app di accedere a determinate funzioni del sistema operativo. Grazie a questa tecnica non servirà aggiornare il sistema operativo. Questo sembrerebbe essere un grande vantaggio, anche alla luce del fatto che esistono decine di versioni di Android (Samsung ha la sua versione, Xiaomi idem etc..). Secondo il documento, l’unico requisito minimo è che Android sia dotato almeno della sua versione 5 (94.6% dei dispositivi ha almeno il 5[1]), anche se alcune voci provenienti da fonti autorevoli dicono che, alla fine, le funzionalità sul contact tracing si potranno avere solo a partire dalla versione 6. Inoltre, lo smartphone dovrà essere ovviamente dotato di Bluetooth low energy (oltre il 90% dei dispositivi ce l’aveva già nel 2018).
In base a quanto sopra esposto, verrebbero tagliati fuori i telefoni che, pur avendo Android, non hanno i play services perché non hanno fatto l’accordo con Google, come Huawei, che nel 2019 ha conquistato il 18% del mercato europeo degli smartphone. I Play Services, infatti, non sono open source e gratuiti. Google ha dichiarato che, in caso di necessità, spiegherà a queste aziende escluse come implementare il tutto nelle versioni di android “non ufficiali”. Probabilmente i Huawei acquistati prima della rottura, avvenuta a metà 2019 saranno comunque compatibili.
Apple ha invece una filosofia diversa e rilascia molto più facilmente (e con ottimo tasso di aggiornamento) nuove release del sistema operativo. Per attivare le nuove funzioni su dispositivi iOS sarà quindi necessario aggiornare il sistema operativo. Sarà supportato da tutti gli iPhones che hanno iOS 13.5.
Novità nel workflow
All’interno del documento rilasciato da Apple e Google troviamo anche notizie più precise sui processi di generazione e salvataggio di Keys e ID. Sebbene la procedura già descritta in precedenza da Agendadigitale sia confermata in ogni passaggio, oggi scopriamo dettagli maggiori che incidono, in modo significativo, sulla valutazione relativa all’utilità delle app che verranno generate dai governi.
Il documento richiamato, infatti, specifica ad esempio che l’app avrà un impatto bassissimo sulla batteria degli smartphone (era una delle principali preoccupazioni che avrebbero influito più di ogni altro aspetto sulla usability dell’app). Inoltre, l’app si avvierà in background ogni cinque minuti e, pertanto, gli “incontri” che inizieranno e finiranno tra un “risveglio” e l’altro non verranno tracciati, anche se “intensi” come un veloce abbraccio.
Abbiamo invece conferme, con qualche dettaglio in più, sulle informazioni aggiuntive che verranno salvate insieme ai Proximity ID che un dispositivo “incontra”. Queste saranno: l’intensità del contatto (anche se avere il telefono in mano o in tasca influisce molto), la data di contatto con l’infetto e quale è stato il tempo di esposizione (ovviamente con step di cinque minuti e fino ad un massimo di esposizione totale di trenta minuti, per questioni di riservatezza).
Infine, secondo il documento, saranno quattordici i giorni che verranno monitorati: le chiavi resteranno nel dispositivo per due settimane e non oltre. Si occuperà il protocollo di eliminarle (l’app non ha alcun controllo).
Alla disinstallazione dell’app conseguirà sempre la cancellazione di tutti i dati.
La versione beta delle API
Chi voleva realizzare un’app per il contact tracing, utilizzando la soluzione Apple/Google, fino a qualche giorno fa poteva già sviluppare e scrivere il codice, utilizzando un documento (rilasciato dalle due big) in cui gli si diceva: “quando la tua app vorrà ricevere da noi le chiavi giornaliere scrivi getTemporaryExposureKeyHistory() e noi te le daremo. Quando invece la tua app vorrà verificare se la rilevazione via Bluetooth è attiva, allora scrivi nel tuo codice isEnabled() e noi te lo diremo. Etc. etc.”
Di fatto, però, si poteva solo scrivere l’app, sapendo che ad un certo punto avrebbe chiamato tot funzione, ma non era possibile avviare alcunché. Ci si poteva solo portare avanti con il lavoro.
Da un paio di giorni, invece, sono state rilasciate le librerie, solo in “private beta”.
Adesso è possibile testare l’app, ottenendo quei dati e, entrando nel dettaglio del documento, adesso è possibile scoprire, con esattezza, qual è il ruolo dell’azienda che deve sviluppare l’app e quale invece quello di Google e, di conseguenza, quali dati può manipolare l’app e quali invece rimangono invisibili anche alla stessa.
In maniera molto empirica e non cara agli sviluppatori (a cui sin d’ora chiediamo scusa), immaginiamo una casa. Questa casa appartiene ad Apple o Google ed è il sistema operativo. All’interno di questa casa ci sono due stanze separate, una ad uso esclusivo di Apple o Google, ed una, invece, affittata all’App di tracciamento (per es. Immuni). Tra queste c’è un’apertura, un passavivande, attraverso il quale l’App richiede ad Apple o Google alcune informazioni, e per farlo utilizza delle “parole d’ordine”. Queste parole d’ordine sono le API. Le stanze di Apple e Google sono le cosiddette “librerie”.
Dalla lettura delle API, delle “parole d’ordine”, è quindi possibile capire quali sono le (uniche) informazioni che l’app può richiedere a Apple o Google, e quindi, di conseguenza, cosa rimane nella stanza di questi ultimi senza che possa essere letta dall’esterno.
Senza entrare nel dettaglio degli ID e delle Key, il cui funzionamento è stato già descritto da Agendadigitale, ricordiamo solo che ci sono tre principali tipologie di codici identificativi:
- La Device Tracing key. È una chiave segreta del dispositivo, non cambia mai e non lascia mai il dispositivo, neanche in caso di positività. È completamente anonima (a detta di Apple e Google)..
- La Temporary Exposure Key. Generata dalla secret key, cambia ogni 24 ore. Il dispositivo ne conserverà solo le ultime quattordici. Sono quelle che vengono poi inviate al server in caso di positività (diventando le cosiddette Diagnosis Keys)
- I Rotating Proximity Identifiers (RPIs). Sono i famosi ID (derivati dalla temporary exposure key) che vengono esposti tramite bluetooth e che cambiano ogni quindici minuti. Queste chiavi vengono salvate dagli altri utenti con cui si viene a contatto ma non vengono mandate sul server.
Cosa viene quindi fatto all’interno della stanza di Google ed Apple e cosa invece nella stanza affittata dall’app?
Nella loro stanza Google ed Apple fanno praticamente quasi tutto. In primis gestiscono tutte le chiavi random. Si occupano della trasmissione, ricezione e salvataggio delle Keys e degli ID, propri e degli altri, dei tempi di esposizione, del rilevamento di altri dispositivi in prossimità e, infine, calcolano il livello di rischio di esposizione (ma sulla base dei parametri Impostati dall’app al primo avvio, allo start).
Questa stanza, come detto, comunica con l’altra, quella in affitto all’app. Da quest’altra stanza, l’app chiederà. tramite quell’apertura, alcune cose, limitatamente a quelle consentite dalle “parole d’ordine” (API).
In particolare, l’app innanzitutto potrà chiedere di attivare la generazione della chiave segreta e di sottoporre al possessore dello smartphone il consenso per scan e broadcast (queste librerie non partono ad insaputa dell’utente).
Durante il normale utilizzo quotidiano, poi, dalla loro stanza Apple e Google gestiranno tutto il flow delle scansioni, dei salvataggi degli ID altrui e della generazione dei propri, conservando tutto per sé.
Nel caso in cui il possessore dell’app diventi positivo al virus, allora l’app potrà richiedere “potreste passarmi le mie chiavi giornaliere (Temporary Exposure Key), che dovrei mandarle al server centralizzato ministeriale, visto che l’utilizzatore dello smartphone è infetto?”. A questo punto, dalla stanza di Apple e Google (e previo consenso espresso dell’utente) verrà trasmesso all’app il pacchetto delle proprie keys, e solo le ultime quattordici (che a questo punto prendono il nome di Diagnosis Keys), in modo che questa possa poi inviarle al server.
Nessun’altra informazione o chiave (ad esempio quella segreta che non cambia mai) e nessun ID delle persone che vengono incontrate per strada, potranno mai essere passate da una stanza all’altra: queste verranno custodite solo da Google ed Apple.
Una volta mandate le Keys dell’infetto nel server, queste vengono poi scaricate da tutte le altre app uguali, per esempio, da tutti i dispositivi che hanno installato “Immuni”.
Queste app riceveranno le keys dell’infetto e dovranno verificare se tra i proximity ID delle persone incontrate ce n’è uno riferibile alle Keys scaricate (il che vorrebbe dire che si è stati a contatto con un positivo). Tuttavia, come detto, questi Proximity ID si trovano nella stanza di Apple e Google e sono documenti riservati. Di conseguenza, le App non potranno fare altro che passare, tramite il passavivande, le Keys ricevute, chiedendo ad Apple e Google di verificare per conto loro. Apple e Google verificheranno e restituiranno all’app l’informazione: sì, sei stato a contatto con un positivo, oppure no. E l’app genererà una notifica. In realtà le librerie sono in grado di dare due tipi di informazioni: a) blanda, il semplice matching, b) approfondita, data e durata del contatto. Sarà l’app a decidere quale richiedere.
Tutti questi processi, ad eccezione delle richieste di permesso, vanno in background: non consumano quasi nulla (low-power) e sono totalmente anonimi.
Unica soluzione possibile
Del resto, anche alla luce di tutti i protocolli che sono stati analizzati, la soluzione prospettata da Apple e Google sembrerebbe l’unica realmente sostenibile sotto l’aspetto tecnologico.
Nel report del 30 aprile sulle attività svolte dal sottogruppo di lavoro del MID, nella parte in cui si fa riferimento alle interviste di valutazione per l’assegnazione dell’incarico a Bending Spoons, lo stesso sottogruppo dichiara, parlando di Immuni che “per quanto riguarda la rilevazione degli eventi di contatto tra due device con sistema operativo iOS, il team ha proposto due possibili alternative: la prima consiste in un artificio software, mentre la seconda consiste nell’utilizzo del segnale GPS.”. Serviva un “artificio”. Questo avveniva prima che Google ed Apple concedessero al mondo la possibilità di far dialogare i loro Bluetooth in background con lo stesso standard.
Si dovrà fare come dicono loro e, in base ai compiti e alle mansioni descritte sopra, saranno quindi le due big californiane, in sostanza, a sopportare la quasi totalità delle funzioni del software e a decidere sul tipo di chiavi da generare, su cosa salvare e cosa scartare, lasciando all’app solamente il compito di gestire l’interazione con il server madre e configurare i parametri per stabilire quando considerare l’esposizione abbastanza intensa da generare una notifica.
Per semplificare ulteriormente il lavoro agli sviluppatori, Apple e Google hanno rilasciato il 4 maggio schermate e sample code che mostrano come dovrebbe essere sviluppata un’app che usa le loro API. Non è azzardato affermare che per i developer il lavoro è praticamente fatto.
Che cosa accade all’interno delle librerie di Apple possiamo saperlo solo in relazione alle dichiarazioni della stessa. Google, per il momento ha preferito non esprimersi sul carattere open-source o meno delle librerie.
Di conseguenza, la licenza open source, ribadita anche dalla ministra Pisano durante l’ultima audizione del 29 aprile, necessaria (a quanto pare) per permettere una maggiore trasparenza, perderà buona parte di senso.
I nodi privacy
Probabilmente, le App di tracing saranno dei software così semplici che potranno essere analizzati dalla community in soli dieci minuti. Queste analisi potranno essere relative solo alle poche funzioni delle app. Si potrà solamente esaminare la procedura di invio della chiave al server. Si potrà verificare che questo invio coinvolga effettivamente solo la chiave e non vada a pescare altre informazioni altrove (tra quelle disponibili al di fuori del tracciamento, perché abbiamo chiarito che in relazione al contact tracing, l’app non avrà la possibilità di conoscere altro fuorché la chiave giornaliera) e pochissimi ulteriori processi.
Il modo di generare i codici e il fatto che questi siano realmente anonimi e non pseudonimi, lo lasciamo alle dichiarazioni di Apple e Google.
Questo fa drizzare le orecchie ai puristi della privacy. Innanzitutto, per l’impossibilità di sorvegliare cosa accade dentro la stanza di Google ed Apple e, conseguentemente, per la difficoltà a comprendere se la key può essere definita un “dato personale” ai sensi del Regolamento UE 2016/679 e se quindi si applichi o meno la normativa sul trattamento dei dati personali, con ogni effetto del caso. Tuttavia, è necessario precisare che Google ha dichiarato di essere disponibile a concedere audit alle società che vorranno implementare la libreria. Attendiamo che accada.
Ma tanto, diciamocelo, il processo ormai appare inevitabile. Google ed Apple hanno deciso di attivare questa funzione e, con il consenso dei governi o meno, hanno già predisposto gli aggiornamenti di Service e sistemi operativi necessari per farla funzionare.
La responsabilità delle Big Sister
Tra qualche giorno, volenti o nolenti, ci troveremo all’interno del nostro smartphone, nella sezione privacy, la possibilità di abilitare il tracing, col consenso dell’utente, e con buona pace dei dibattiti social sul valore dei nostri dati.
Appare chiaro tuttavia che, almeno al momento, sarà necessaria un’app a supporto di questa funzione. Ad oggi le piattaforme di tracing non vengono fatte da Google ed Apple che mettono a disposizione solo lo strumento per consentire a terzi di acquisire questi dati.
Una domanda sorge quindi spontanea: queste chiavi generate dalla libreria, sono private e solo per l’app che effettua il tracing o sono accessibili da qualsiasi app?
Analizzando i metodi (funzioni) messi a disposizione dalla libreria, consideriamo lo “start()” e lo “stop()”. Lo start, previa inderogabile accettazione dell’utente, avvia la trasmissione, ricezione e conservazione delle keys. Lo “stop()” ne blocca la trasmissione / ricezione e, in fase di disinstallazione dell’app, viene richiamato in automatico eliminando anche tutto lo storico dei contatti e delle chiavi.
Di conseguenza, se qualche app dovesse invocare (attivare) questa libreria, Google condividerà con essa le chiavi e tutto il resto.
Senza un’app che li attivi, invece, sembrerebbe che Google ed Apple non facciano partire la trasmissione dei codici. Del resto, sarebbe facile verificarlo: basterebbe “sniffare” i pacchetti che viaggiano su rete bluetooth dai dispositivi che si sono aggiornati e verificare che questi non trasmettano nulla senza l’app di tracing.
Ma tanto non abbiamo scelta: è necessario affidarsi comunque alle loro decisioni e mai, come in questo caso, ci si rende conto dell’enorme potere nelle mani delle big sister che stanno assumendo decisioni per tutti costringendo i governi a adeguarsi a loro, e non viceversa. Qui si tocca con mano l’eterno contenzioso UE vs Big Sister, fatto di procedimenti, sanzioni e prese di posizione tecnologiche.
In ogni caso appare doveroso specificare che, ad ulteriore garanzia dell’utente e della sua privacy, le Big Sisters hanno posto alle Public Agencies dei paletti imprescindibili che, se non rispettati, le farà decadere dal diritto di utilizzo del sistema.
Ebbene, un’app che utilizzerà le API di Google ed Apple non potrà avere nessun altro scopo al di fuori del contact tracing. Questo toglierebbe totalmente di scena l’ipotesi che l’app diventi, ad esempio, una sorta di diario medico con funzioni successive all’emergenza Covid-19, così come ipotizzato nella fast call del ministero.
Le società californiane, prima di approvare un’app di alert “anti-covid”, verificheranno che non venga richiesto l’utilizzo del GPS, tantomeno l’accesso all’advertising ID e, in ogni caso, il sistema verrà dismesso una volta terminata questa emergenza.
Detto ciò, ricordiamo che Apple e Google hanno dichiarato che sorveglieranno gli store al fine di non permettere ad altre app di accedere a questi dati, ma ci piace qui ricordare, a scopo meramente scientifico, quello che è accaduto qualche anno fa con Facebook.
Nel settembre dello scorso anno, le persone che hanno scaricato la prima versione di iOS 13, si sono ritrovati una notifica inaspettata sul loro dispositivo: “Facebook vorrebbe usare il tuo Bluetooth”.
L’aggiornamento software conteneva nuove funzionalità di privacy che miravano a dare alle persone un maggiore controllo sui dati che condividevano con le app.
Si è così scoperto che Facebook raccoglieva dati per indirizzare meglio gli annunci pubblicitari e che questo veniva fatto probabilmente già da tempo.
Uno di questi metodi di raccolta prevedeva la possibilità di attingere silenziosamente alla tecnologia Bluetooth di un telefono per tracciare la posizione fisica di una persona (che non aveva attivato il GPS) grazie alla sua vicinanza agli smartphone di altri. Esattamente quello che fa il tracing per il covid-19.
Sostanzialmente Facebook teneva traccia e accumulava i dati personali relativi alle connessioni degli utenti tra loro, combinando informazioni di prossimità raccolte dal Bluetooth per fare deduzioni sulle loro relazioni. Incredibile, no? Mi viene in mente quella volta in cui ho conosciuto una persona in un bar e poi mi è stata suggerita come “amicizia”. Chissà.
Ecco. Alla luce di questo siamo totalmente nelle mani di Google ed Apple, che hanno garantito una sorta di “sorveglianza” sull’utilizzo della funzione.
In realtà, per completezza di esposizione, diciamo pure che, anche se Google ha disegnato questa specifica libreria al fine di garantire una maggiore privacy, su Android il tracing si poteva comunque tranquillamente fare anche prima, senza utilizzare la loro libreria.
Con Apple la situazione appare differente. L’azienda di Cupertino è sempre attenta all’utilizzo delle risorse hardware da parte delle app. Ha infatti bloccato a Facebook l’utilizzo in background del bluetooth e ora ha scritto un apposito kit (libreria) per accedervi. Soprattutto Apple, quindi, dovrà vigilare per fare in modo che altre app non lo utilizzino. Tuttavia, come già detto, il tracing di prossimità, si poteva comunque fare anche prima, con vari stratagemmi. La libreria migliora le funzioni, le anonimizza, ma non inventa nulla di nuovo.
Probabilmente l’unico dato (desunto) che si aggiunge rispetto a quello che si poteva fare prima è la “positività”.
Per questo, in entrambi i casi, l’unica accortezza è non permettere che le altre app conoscano la positività di un individuo.
Probabilmente, fermo restando che le app come “Immuni” utilizzeranno la libreria e salveranno nell’app storage dedicato a loro questi dati criptati, l’unico modo per prendere l’informazione utente positivo è intercettare la chiamata https dell’autodiagnosi.
Qui siamo costretti a ripassare la palla ai governi e agli sviluppatori delle app. I sistemi di sicurezza che proteggono i dati mentre viaggiano nella rete e che proteggono i log del server sono loro prerogativa. E non c’entra nemmeno l’open source, in questo caso. Torniamo a sostenere che, se i dati sono realmente anonimi, l’unica criticità del trattamento è la chiamata per l’upload dei dati, che contiene un dato personale pseudonimizzato ma certo: l’indirizzo IP.
E se Google e Apple fossero la soluzione?
Certo non si può auspicare che siano sempre loro a raccogliere i nostri dati e ad utilizzarli. Non possiamo tuttavia ignorare il fatto che Google già potrebbe, in effetti, utilizzare i dati di prossimità a prescindere dalle nuove librerie ed Apple, se decidesse di farlo, ci metterebbe un flash.
Non entreremo qui in seri discorsi di geopolitica del potere digitale: restiamo sul topic scelto, che è il contact tracing.
Esiste una informazione che in molti ignorano e dalla quale non possiamo nasconderci. Nel famoso annuncio del 10 Aprile, con il quale Apple e Google rivelavano la collaborazione, questa veniva programmata in due step. Il primo, previsto per maggio, nel quale entrambe le società avrebbero rilasciato le API per consentire l’interoperabilità tra dispositivi Android e iOS, utilizzando le app delle autorità sanitarie pubbliche, disponibili poi nei rispettivi app store.
Questo step sembra in fase di ultimazione: è comunque ciò di cui stiamo parlando in queste settimane.
Successivamente, il testo continua, ampliando enormemente la portata del loro intervento. Infatti, Apple e Google dichiarano congiuntamente che, nei mesi successivi al primo step, lavoreranno per realizzare una più ampia piattaforma di tracciamento dei contatti basata sul Bluetooth, che sarà a disposizione delle piattaforme sottostanti. L’idea dovrebbe essere di rendere interoperabili le varie App nazionali, mettendo a tutte un cappello unico, quello di una “piattaforma” vera e propria gestita dalle sorelle.
Nello stesso documento Apple e Google specificano inoltre che si tratterebbe di una soluzione più solida delle API e che consentirebbe “a più persone” di partecipare, previo consenso delle stesse.
Verso dove stiamo andando, quindi? L’esperienza ci insegna che gli utenti hanno molta più fiducia nelle grandi multinazionali digitali che dei governi.
Del resto, se il Ministro durante l’audizione e anche il Presidente del Consiglio parlano di “cancellazione di dati personali” in relazione ad un’app che dovrebbe essere, a loro dire, anonima, appare normale che venga a mancare la fiducia nei confronti di un governo che risulta assolutamente confuso e sembra non possedere le basi di conoscenza della materia.
L’app che il Governo italiano si appresta a rilasciare, Immuni, probabilmente non troverà l’approvazione dei cittadini che non risultano propensi a scaricarla. Google ed Apple godono di consenso addirittura esagerato. Esagerato vista l’estrema profilazione e la quantità di nostri dati che possiedono.
Ci chiediamo quindi: e se al netto dei discorsi sul potere che stanno assumendo, sono loro la soluzione per far tornare la fiducia della gente verso un sistema che, in effetti, ad oggi, sembra minimizzare considerevolmente l’impatto sui diritti e sulle libertà degli individui?
Ma tanto, la strada è già segnata, non c’è molto da decidere né da discutere. Si fa per dire.
_______________________________________________________________
- Android Studio ↑
