Add correction

bib.bib

@@ -77,6 +77,15 @@
   file = {/home/norangebit/Zotero/storage/4SV9VW2H/installation.html}
 }
 
+@online{KeyvalueData,
+  title = {Save Key-Value Data},
+  journaltitle = {Android Developers},
+  url = {https://developer.android.com/training/data-storage/shared-preferences},
+  urldate = {2020-07-22},
+  file = {/home/norangebit/Zotero/storage/N7AEME4M/shared-preferences.html},
+  langid = {english}
+}
+
 @online{NotificheDiEsposizione,
   title = {Notifiche di esposizione: un aiuto alla lotta al COVID-19 - Google},
   shorttitle = {Notifiche di esposizione},

documentazione.md

@@ -59,7 +59,7 @@ Inoltre si utilizza il rak per produrre una firma `sig` per il report e verrà i
 
 Poiché la rvk è contenuta all'interno del report, chiunque può verificare l'integrità del report e ricavare i vari tcn. 
 
-## Implementazione del protocollo per la JMV
+## Implementazione del protocollo per la JVM
 
 Al fine di utilizzare il protocollo precedentemente descritto all'interno dell'applicazione Android, ne è stato sviluppato un'implementazione per la *Java Virtual Machine*.
 La gestione della coppia di chiavi derivate dalla curva ellittica *Ed25519* è stata affidata alla libreria ***ed25519-elisabeth*** [@CryptographycafeEd25519elisabeth2020].
@@ -103,7 +103,7 @@ fun nextTemporaryContactKey(
 }
 ```
 
-Sempre a partire dalla tck è possibile ricavare il numero di contatto temporaneo (tcn) e da esso l'UUID utilizzato all'interno dei beacon bluetooth.
+Sempre a partire dalla tck è possibile ricavare il numero di contatto temporaneo (tcn) e da esso settare il campo UUID utilizzato per il broadcast del beacon bluetooth.
 Questa operazione può essere eseguita mediante la funzione `deriveTemporaryContactNumber()` la cui implementazione è stata riportata nel @lst:derive-tcn.
 
 ``` {.kotlin #lst:derive-tcn caption="Derivazione del numero di contatto temporaneo."}
@@ -154,29 +154,29 @@ fun readReportDataFromByteArray(bytes: ByteArray): ReportData {
 # Applicazione
 
 L'applicazione permette di tracciare i contatti degli utenti attraverso l'impiego del Bluetooth Low Energy (BLE).
-In particolare lo smartphone di ogni utente si comporta sia da trasmittente di beacon bluetooth che da ricevente.
+In particolare lo smartphone di ogni utente esegue il broadcast e la scansione di beacon bluetooth.
 In questo modo quando due utenti entrano nel raggio di azione del bluetooth il contatto verrà memorizzato sui rispettivi dispositivi.
 
 L'applicazione prevede differenti modalità di funzionamento, ognuna delle quali garantisce un diverso livello di privacy.
 Nella modalità di funzionamento ***A*** ogni qual volta si verifica un contatto l'applicazione si occupa di notificare immediatamente l'evento al server in modo tale che esso possa essere aggiunto al database remoto.
-Questa modalità è quella meno *privacy friendly* in quanto la comunicazione avviene in *real-time* e all'interno del messaggio scambiato viene riportato sia l'UUID dell'utente sia quello della persona incontrata.
+Questa modalità è quella meno *privacy friendly* in quanto la comunicazione avviene in *real-time* e all'interno del messaggio scambiato viene riportato sia il *tcn* dell'utente sia quello della persona incontrata.
 
 La modalità ***B*** prevede lo scambio delle stesse informazioni previste per la modalità precedente, ma solo se richiesto dalle autorità sanitarie.
 In questo modo non solo si evita che i dati siano catturati dal server in *real-time*, ma si espongono le informazioni dell'utente solo quando queste sono strettamente necessarie.
-Sia in questa modalità, che nella precedente si è scelto di non ruotare gli UUID identificativi degli utenti in modo da facilitare la generazione del grafo sul server.
+Sia in questa modalità, che nella precedente si è scelto di non ruotare i *tcn* identificativi degli utenti in modo da facilitare la generazione del grafo sul server.
 Questa soluzione può mettere a repentaglio la privacy degli utenti ed essere sfruttata da *avversari* per ottenere informazioni sulle abitudini degli utilizzatori[^catena-negozi].
 
 [^catena-negozi]: Per esempio una catena di negozi attraverso l'impiego di uno scanner bluetooth potrebbe ricostruire la *fedeltà* degli utenti, conoscere i settori del negozio preferiti ecc.
 
 L'ultima modalità, la ***C***, è quella che tutela maggiormente la privacy degli utilizzatori attraverso due accorgimenti:
 
-- Rotazione degli UUID
+- Rotazione dei *tcn*
 - Matching locale
 
-La generazione degli UUID avviene attraverso una derivazione deterministica come visto nella @sec:tcn-protocol, in modo tale da avere lo stesso livello di privacy di una soluzione randomica, ma con una migliore scalabilità.
+La generazione degli *tcn* avviene attraverso una derivazione deterministica come visto nella @sec:tcn-protocol, in modo tale da avere lo stesso livello di privacy di una soluzione randomica, ma con una migliore scalabilità.
 Mentre il matching locale permette di condividere il minor numero di informazioni possibili e solo quando questo è strettamente necessario.
 Infatti in questa modalità l'applicazione carica le informazioni sul server solo in seguito alla richiesta delle autorità sanitarie.
-Inoltre a differenza delle prime due modalità è previsto l'upload unicamente degli UUID che il dispositivo ha assunto nel tempo, in questo modo il server non è in grado di conoscere o ricavare i contatti avuti dall'utente.
+Inoltre a differenza delle prime due modalità è previsto l'upload unicamente dei *tcn* che il dispositivo ha assunto nel tempo, in questo modo il server non è in grado di conoscere o ricavare i contatti avuti dall'utente.
 
 ## API covid di Apple e Google
 
@@ -194,7 +194,7 @@ Questa caratteristica, unita alle regole stringenti di utilizzo imposte della li
 [^regole-api-apple-google]: Le due società californiane consentono lo sviluppo di applicazioni che fanno uso della loro API solo ad enti governativi e impongo un numero massimo di applicazioni per nazione pari ad uno.
 Dalla documentazione ufficiale non è ben chiaro se questi vincoli riguardino solo la pubblicazione sugli store o anche lo sviluppo.
 
-## Bluetooth
+## Interazione via bluetooth
 
 L'interazione tra l'hardware bluetooth del dispositivo e l'applicazione è stata gestita attraverso l'impiego della libreria *Android Beacon Library* [@AndroidBeaconLibrary] che permette di gestire più facilmente le operazioni con beacon bluetooth.
 Inoltre per rendere l'applicazione più funzionale, e quindi garantirne il funzionamento anche in background o a schermo spento è stato utilizzato un *foreground service* [@ServicesOverview], che consente di mantenere in *primo piano* le operazioni di trasmissione e scansione anche quando l'applicazione non lo è.
@@ -209,12 +209,14 @@ Poiché queste operazioni vanno ad interagire con le funzionalità del sistema o
 Si è scelto di collegare l'oggetto `BluetoothManager` all'*application* e non ad una `Activity` in quanto i servizi devono essere utilizzati anche quando non sono presenti *activity* in *foreground*.
 Per questo motivo è stata sviluppata anche una classe `BluetoothApplication` che va ad estendere le funzionalità di `Application` e fornisce a sua volta due metodi di start e stop che vanno a richiamare quelli esposti da `BluetoothManager` in modo tale da rendere possibile il controllo dei servizi legati al bluetooth anche da altre componenti dell'applicazione.
 
+I beacon bluetooth gestiti dall'applicazione sono caratterizzati dal seguente formato `s:0-1=2a,i:2-17` dove il parametro `s` specifica i bit destinati al tipo di servizio e il suo valore, mentre il parametro `i` specifica i bit destinati all'UUID.
+
 ### Trasmissione
 
-Il dispositivo dell'utente deve eseguire il broadcast di un beacon bluetooth contenete l'UUID identificativo.
+Il dispositivo dell'utente deve eseguire il **broadcast** di un beacon bluetooth contenete nel campo UUID il *tcn* identificativo.
 Questa operazione è stata svolta attraverso la classe `BeaconTransmitter` messa a disposizione dalla *Android Beacon Library*.
-Inoltre per la modalità di funzionamento *C* è stato necessario prevedere un meccanismo di rotazione delle chiavi.
+Inoltre per la modalità di funzionamento *C* è stato necessario prevedere un meccanismo di rotazione delle chiavi di contatto.
-Questa rotazione viene settata attraverso la funzione `rotateTCN()` (@lst:rotate-tcn) che sfrutta un `Handler` per programmare la rotazione dell'UUID.
+Questa rotazione viene settata attraverso la funzione `rotateTCN()` (@lst:rotate-tcn) che sfrutta un `Handler` per programmare la rotazione del *tcn*.
 
 ``` {.kotlin #lst:rotate-tcn caption="Codice necessario alla rotazione del tcn."}
 private fun rotateTCN() {
@@ -290,12 +292,12 @@ $TxPower$ è la potenza di trasmissione nominale che si misurerebbe alla distanz
 Il valore di $TxPower$ deve essere precedentemente ricavato per ogni emettitore e deve essere inviato all'interno del beacon bluetooth.
 Lavorando con dispositivi eterogenei tra di loro non è stato possibile calcolare in modo esatto questo valore, ma si è scelto di utilizzare il valore $-59$ poiché si adattava mediamente a tutti i dispositivi utilizzati in fase di test.
 
-## UI
+## Interfaccia utente
 
 L'applicazione opera prevalentemente in background, ma comunque è dotata di una serie di elementi grafici che consentono all'utente di interagire con essa.
 Quando l'applicazione viene avviata per la prima volta l'utente ha la possibilità di scegliere la modalità di funzionamento che desidera utilizzare (si veda @fig:ui-welcome).
 Una volta compiuta questa scelta viene chiesto all'utente di concedere l'accesso alla posizione.
-Sebbene l'applicazione non utilizzi il GPS o altri strumenti di posizionamento ciò si rende necessario al fine di abilitare la scansione bluetooth anche in background.
+Sebbene l'applicazione non utilizzi il GPS o altri strumenti di posizionamento ciò si rende necessario al fine di abilitare la scansione dei beacon BLE anche in background.
 
 ![Schermata di benvenuto.](fig/welcome.jpg){#fig:ui-welcome width=130}
 
@@ -304,13 +306,14 @@ La schermata principale dell'applicazione, riportata in @fig:ui-main, si compone
 - `TextView` che indica la modalità di funzionamento.
 - `Button` *start/stop* che consente di avviare o stoppare il servizio bluetooth.
   Questo pulsante viene abilitato unicamente se sono stati concessi i permessi di accesso alla posizione.
-- `Button` *upload*, abilitato solo nelle modalità *B* e *C*, consente all'utente di raggiungere l'activity attraverso la quale è possibile caricare sul server le informazioni locali al dispositivo (@fig:ui-upload).
+- `Button` *exposed* consente all'utente di raggiungere l'activity, @fig:ui-upload, attraverso la quale è possibile comunicare al server il proprio stato di contagiato.
+  Nel caso della modalità *B* e *C* vengono caricati sul server anche i dati di contatto presenti sul dispositivo.
 
 ![Schermata principale.](fig/main.jpg){#fig:ui-main width=130}
 
 ![Schermata per l'upload.](fig/upload.jpg){#fig:ui-upload width=130}
 
-## Memorizzazione
+## Memorizzazione ID
 
 In base alla modalità di funzionamento l'applicazione deve memorizzare diversi tipi di dati.
 La gestione della persistenza è stata realizzata attraverso la libreria ***Room*** [@RoomPersistenceLibrary], una componente di *Jetpack* [@AndroidJetpackAndroid] la suite di librerie supportate da *Google*.
@@ -343,6 +346,8 @@ Anche in questo caso, per quanto riguarda il timestamp, restano valide le consid
 Questi dati persistenti sono stati acceduti mediante l'utilizzo di due *Data Access Object* (DAO).
 Le interfacce dei DAO utilizzate sono riportate nei listati -@lst:dao-contact e -@lst:dao-tcn.
 
+Oltre alla memorizzazione sul database sono state impiegate anche le *shared preferences* [@KeyvalueData] per memorizzare la modalità di funzionamento scelta dall'utente, la *rak*, l'ultima *tck* e il *tcn* associato ad essa.
+
 ``` {.kotlin #lst:dao-contact caption="Interfaccia ContactDataDao."}
 @Dao
 interface ContactDataDao {
@@ -371,21 +376,24 @@ interface TCNDataDao {
 }
 ```
 
-## Rete
+## Comunicazione report
 
 La comunicazione con il server avviene mediante un brocker MQTT fornito da un altro gruppo di studenti.
 Come implementazione del client MQTT si è scelto di utilizzare *Paho* [@EclipsePahoMQTT], un client realizzato da Eclipse.
 Questa libreria oltre a fornire un client MQTT per la JVM fornisce anche un *service* per Android che permette di sollevare lo sviluppatore da alcuni dettagli implementativi.
 
-L'applicazione, all'interno dell'architettura, svolge il ruolo di *publisher* e si occupa della pubblicazione di due tipologie di messaggi:
+L'applicazione, all'interno dell'architettura, svolge il ruolo di *publisher* e si occupa della pubblicazione di tre tipologie di messaggi:
 
 - ***Messaggi di contatto***:
   utilizzati sia nella modalità *A* che nella *B*, permettono di notificare al server un contatto tra due utenti.
-  Nel caso della modalità *A* viene svolto un invio in *real-time*, mentre nella configurazione *B* l'invio avviene solo dopo aver eseguito l'*upload*.
+  Nel caso della modalità *A* viene svolto un invio in *real-time*, mentre nella configurazione *B* è manuale e viene eseguito solo quando l'utente risulta essere contagiato.
   Il contenuto di questi messaggi coincide con la rappresentazione JSON dei dati di contatto illustrati nel @lst:contact-data.
 - ***Messaggi di report***:
-  utilizzati esclusivamente nella modalità *C*.
+  utilizzati esclusivamente nella modalità *C* e sono inviati manualmente dall'utente quando risulta essere contagiato.
   Questi messaggi trasportano come *payload* la rappresentazione esadecimale del report TCN firmato discusso nella @sec:report e vengono inviati solo quando l'*upload* è richiesto dall'utente.
+- ***Messaggi di esposizione***:
+  contengono l'identificativo associato al dispositivo e permettono di notificare lo stato di contagiato al server.
+  Questi messaggi sono inviati unicamente dalla modalità *A* poiché nella modalità *B* e *C* il caricamento dei dati locali di contatto implica lo stato di contagiato.
 
 Anche in questo caso si è scelto di *wrappare* la libreria utilizzata all'interno di una classe sviluppata in proprio.
 Poiché l'unica funzionalità di nostro interesse è la *publish* è stato necessario scrivere un'unica funzione statica che si occupa di eseguire quest'operazione.
@@ -434,7 +442,7 @@ fun publish(
 }
 ```
 
-Le funzionalità di rete sono state testate attraverso l'impiego di un brocker pubblico (`tcp://broker.hivemq.com:1883`) ed un'istanza locale di *ActiveMQ Artemis* inoltre è stato utilizzato il topic `untori` per la pubblicazione dei messaggi.
+Le funzionalità di rete sono state testate attraverso l'impiego di un broker pubblico (`tcp://broker.hivemq.com:1883`) ed un'istanza locale di *ActiveMQ Artemis* inoltre è stato utilizzato il topic `exposed-test-topic` per la pubblicazione dei messaggi.
 Entrambi i parametri sono stati settati tramite delle costanti e quindi possono essere modificati facilmente.
 
 # Riferimenti 

header.yaml

@@ -1,7 +1,7 @@
 ---
 lang: it-IT
 papersize: a4
-title: Documentazione dell'applicazione Untori
+title: Documentazione dell'applicazione Covid Protector
 author:
   - Raffale Mignone
   - Noemi Mincolelli