Thread by @_happycactus_

Ho costruito un piccolo schemino di come dovrebbe essere strutturato un sistema di tracking basato sul framework Apple + Google.
Non è detto che sia quello definitivo, ma è ciò che ho potuto dedurre dalla lettura delle specifiche. Soggetto a revisione. Commenti in calce

Innanzi tutto due parole sulla struttura. Quando si parla di "framework" si intende una parte del sistema operativo, cioè un set di funzioni definite e implementate dai costruttori (Apple, Google e altri eventuali); le specifiche definiscono questa parte del sistema,oltre alle 1/

regole per utilizzarle ("API"). La "App" è la parte che l'utente "vede" e che gestisce alcune interazioni tra l'utente e gli altri sistemi coinvolti. Non tutte però. La App interagisce con il framework per poter accedere alle funzioni che quest'ultimo gestisce. 2/

Come si può leggere dalle specifiche, i dispositivi scambiano dei pacchetti Bluetooth tramite "broadcast". Ogni dispositivo dovrebbe usare dei timeout di 5 minuti circa.
I dispositivi nelle vicinanze (e lo stesso trasmittente) sono in ascolto e ricevono tali pacchetti. 3/

I pacchetti contengono, tra le altre cose: un Rolling Proximity Identifier (16byte) e alcuni metadati criptati (4 byte). I riceventi ricevono e memorizzano tali dati assieme alla data e ora precisa e al livello del segnale ricevuto, che servirà per stimare la distanza. 4/

La memorizzazione e lo scambio delle chiavi è gestito dal framework. Nello schema sopra disegnato il dispositivo di sx invia i propri dati al dispositivo di dx che è in "ascolto". A turno i ruoli si scambiano. 5/

Nello schemino sopra mostrato ho ipotizzato che ad un certo punto il dispositivo di sx venga identificato come positivo. Il modo in cui questo avviene non è specificato, ma verosimilmente la app invierà una istruzione al framework. Potrà avvenire tramite azione dell'utente 6/

Oppure tramite comando "remoto" da parte del SSN.
A questo punto il framework autonomamente invierà al Server delle notifiche una propria chiave chiamata "diagnosis key"; il server delle notifiche provvederà ad inviare a tutti i dispositivi tale chiave che inizieranno 7/

l'operazione denominata "scanning" o "matching" (eseguito dal framework): da quel momento (e retrospettivamente) tutte le chiavi ricevute via bluetooth vengono confrontate con le diagnosis key; in caso di matching, il framework allerterà la app, la quale potrà ottenere 8/

i dati dei match: numero totale di contatti con soggetti diversi e i dettagli dell'ultimo, ossia data e ora, durata, distanza.
La app quindi potrà decidere cosa fare: avvertire l'utente e opzionalmente inviare un segnale al SSN in modo che l'utente non possa semplicemente 9/

ignorare l'alert.
In verità quest'ultima parte è totalmente demandata all'implementazione della App per cui la mia è speculazione, ma è ragionevole pensare che funzioni in questo modo.
Quel che non è dato sapere è quali dati verranno raccolti dalla app, il framework... 10/

tratterà soltanto le informazioni di contatto, e le proteggerà, tutto sommato, in modo direi molto accurato. Viene utilizzata crittografia forte per proteggere tutti i dati gestiti; i dettagli sono molto tecnici e non li ho padroneggiati a fondo. Ma direi che l'approccio è 11/

cautelativo e molto rigoroso nella protezione della privacy.
Resta l'incognita app. Sappiamo che il framework non farà uso di altri dati (GPS, numero telefonico), ma nulla sappiamo della app, che costituisce un anello molto importante nel sistema. Se la app fosse 12/

poco rigorosa nel trattamento delle informazioni, i danni potrebbero essere rilevanti. Immaginate per esempio se il meccanismo di notifica al SSN dell'avvenuto contatto (a dx del diagramma) non fosse rigorosamente validato e autenticato; sarebbe possibile creare il panico. 13/

Inoltre la app potrebbe tranquillamente raccogliere altri dati, anche GPS,il framework protegge e gestisce esclusivamente i contatti via Bluetooth, che comunque sono l'aspetto decisamente più critico; ma non sono l'unico.
Sempre che abbia interpretato bene le specifiche e che 14/

la gestione della parte demandata ai governi sia effettivamente così come descritta. Le informazioni sono poche e dunque, la mia è pura speculazione (ma progettare sistemi e software è il mio lavoro. Questo non per attribuirmi da solo un autorevolezza,ma per indicarvi quale 15/

tipo di professionista dovreste ascoltare riguardo gli aspetti tecnico-implementativi).
Non prendete dunque per oro colato ciò che ho scritto. Le specifiche non sono 100% chiare e ne sapremo di più nei giorni a venire. Potrei aver preso un granchio colossale... 16/

Sentitevi liberi di commentare quanto detto sopra. Sarò felice di confrontarmi con idee e considerazioni costruttive e circostanziate.

Grazie dell'attenzione...