Modello di privacy e sicurezza

I tuoi file vengono de-identificati e cifrati nel tuo browser. Il server conserva dati che non può leggere. Questa pagina spiega come, e dove finisce la promessa.

La de-identificazione avviene sul tuo dispositivo

Prima di caricare qualsiasi cosa, il browser rimuove da ogni file i metadati identificativi:

DICOM segue il Basic Application Confidentiality Profile dell’Annex E di PS3.15, più le opzioni scelte dal progetto (mantenere le date longitudinali con uno spostamento, mantenere età e sesso, ripulire le descrizioni). I tag privati vengono rimossi. Gli UID vengono sostituiti con valori derivati da un segreto del progetto, così lo stesso studio caricato due volte riceve gli stessi nuovi UID.
Le intestazioni NIfTI e NRRD perdono i campi di testo libero.
Le fotografie perdono i metadati EXIF, XMP, IPTC e GPS.
I segnali mantengono i campioni così come sono stati registrati: i file EDF e BDF perdono l’identificazione del paziente e della registrazione, la data e l’ora di inizio e le loro annotazioni testuali; i record WFDB perdono i commenti (età, sesso, diagnosi, farmaci), l’ora e la data di base e i nomi del record e dei file.
I nomi dei file vengono sostituiti da ID casuali.

La schermata di caricamento mostra che cosa è stato rimosso da ogni file prima che tu confermi. I pazienti ricevono codici pseudonimo assegnati dal loro centro, o generati dallo schema del progetto (il codice del centro e un numero, come MODENA-0001); l’identità reale, e la corrispondenza tra questa e lo pseudonimo, non entrano mai nella piattaforma.

I pixel sono una tua responsabilità. Il testo impresso nelle immagini, i volti nelle scansioni della testa e i cartellini con il nome nelle fotografie non vengono rimossi automaticamente. La schermata di caricamento segnala le modalità e i file noti per contenere testo impresso e, per l’ecografia, mostra dove si trova la regione calibrata dello scanner (nomi e date di solito sono al di fuori); l’amministratore del progetto decide che cosa si può caricare. Controlla i pixel nella revisione mostra l’anteprima di un’immagine di una serie, vi trova il testo (sul tuo dispositivo; può non rilevarlo tutto) e ti permette di disegnare maschere: rettangoli oscurati in ogni immagine della serie prima della cifratura. Le maschere si applicano a PNG e DICOM non compresso; JPEG, HEIC e DICOM compresso vanno prima convertiti, perché mascherarli significherebbe codificarne di nuovo i pixel. Le foto HEIC vengono caricate come HEIC, con i metadati rimossi. TC e RM della testa possono essere sottoposte a defacing da un processore, se l’installazione ne offre uno. Lo stesso vale per le scansioni di superficie: l’intestazione, i nomi e i commenti di una mesh vengono rimossi, ma un volto acquisito in 3D resta riconoscibile.

Cifratura e chiavi

Ogni progetto ha la propria chiave. La sua metà privata esiste solo sui dispositivi dei membri: è cifrata per la chiave pubblica di ciascun membro e decifrata nel browser.
Ogni file e ogni annotazione ha la propria chiave, derivata dalla chiave del progetto o sigillata con essa. I file sono cifrati in blocchi da 64 KiB, così i visualizzatori scaricano e decifrano solo ciò che mostrano.
Le tue chiavi vengono generate nel tuo browser al primo accesso, e quel browser diventa un dispositivo attendibile. Il server le conserva solo dentro un pacchetto cifrato che si apre con un dispositivo attendibile o con la tua passkey.
Per accedere basta un codice via email; per sbloccare i dati serve un dispositivo attendibile o una passkey. Un nuovo browser viene approvato da uno attendibile: confronti un codice di 6 cifre sui due schermi. Una casella di posta rubata dà a un attaccante un account vuoto.
Se perdi tutti i dispositivi attendibili e le passkey, ricominci con nuove chiavi. Gli amministratori dei tuoi progetti condividono ogni progetto con le nuove chiavi solo dopo aver confrontato con te un codice di sicurezza, e le tue altre sessioni e il tuo indirizzo email vengono avvisati che le tue chiavi sono state sostituite.
Nel browser, le chiavi private vivono in un unico worker isolato e i dati decifrati restano in memoria: non vengono mai scritti in chiaro nelle cache su disco o nella memoria del browser. Il lavoro in corso che si salva automaticamente sul dispositivo (risposte, forme, tratti delle maschere) viene prima cifrato con la chiave del progetto.
Tutte le primitive provengono da librerie verificate (libsodium, WebCrypto, HPKE come da RFC 9180). Il formato contenitore, YGG1, è pubblicato con i vettori di test.

I membri sono firmati

Gli amministratori del progetto firmano ogni modifica ai membri, alle chiavi, al manifest e ai processori di un progetto. Ogni browser verifica questo registro firmato e fissa il primo amministratore del progetto al primo contatto, così il server non può aggiungere un membro, sostituire una chiave o cambiare il manifest senza che i client se ne accorgano. Quando cambia la chiave di un membro, per esempio dopo che ha perso i suoi dispositivi, un amministratore confronta con lui un breve codice di sicurezza attraverso un altro canale prima di condividere di nuovo la chiave del progetto. Il codice copre le chiavi di entrambe le persone e il primo record della cronologia firmata del progetto, quindi dice anche se entrambi vedono lo stesso progetto. Non copre i record successivi: un browser che vede il server trattenere o riscrivere record che ha già verificato resta bloccato finché il server non serve di nuovo l’intera cronologia, qualunque codice si confronti.

Le risposte sono firmate dai loro autori

Ogni membro firma con la propria chiave, nel browser, ogni risposta che salva, sul contenuto cifrato della risposta e su ciò a cui si riferisce. Tutti i membri del progetto detengono la chiave del progetto, quindi è la firma a dire chi ha scritto una risposta: i browser e le esportazioni la verificano rispetto al registro firmato dei membri. Una risposta la cui firma manca o non corrisponde al membro indicato dal server viene mostrata come Autore non verificato ed è esclusa da consenso, correzioni ed esportazioni. Un membro che ricomincia da capo o lascia il progetto mantiene verificate le sue risposte precedenti: la sua vecchia chiave vale ancora per ciò che è stato scritto prima della sostituzione.

I processori ricevono l’accesso minimo che basta

Un processore esterno riceve solo le chiavi degli input della sua attività, sigillate con la sua chiave pubblica; il browser che avvia un’attività concede solo input che ha verificato rientrare nel bersaglio dell’attività. Un amministratore del progetto può invece concedere a un processore l’intera chiave del progetto; in quel caso ogni membro vede un badge che lo segnala. I risultati dei processori arrivano come proposte che le persone correggono, a meno che un’attività non sia impostata per prenderli così come sono.

L’amministratore fornisce a un processore la radice del progetto (l’hash con cui inizia la sua cronologia firmata) attraverso un altro canale: il processore rifiuta qualsiasi altra cronologia, e le chiavi che gli vengono concesse si aprono solo con quella reale. Tutto ciò che scrive è firmato con la sua chiave registrata, e i browser dei membri verificano quella firma prima di mostrare o accettare un risultato. Vedi la guida rapida all’SDK dei processori.

Le esportazioni escono dalla cifratura, di proposito

Solo gli amministratori del progetto esportano. Un worker di esportazione registrato dal progetto decifra esattamente i dati scelti dall’amministratore e scrive uno zip in chiaro, conservato dietro un link fino alla scadenza (da 1 a 30 giorni) e poi eliminato. Con il worker di esportazione di questo server, il gestore può vedere i dati mentre vengono impacchettati, e l’archivio è leggibile sul server fino alla scadenza; un worker gestito dall’istituzione tiene fuori l’host. L’amministratore viene informato di quale dei due si tratta prima di confermare, e il registro di audit registra ogni passaggio. Vedi Esportare i dati.

I progetti aperti non sono cifrati end-to-end

Un admin di progetto può rendere un progetto aperto quando lo configura, prima che la sua chiave esista: solo per dati pubblici. Il server custodisce allora la chiave del progetto e la consegna da sé ai membri, quindi il gestore può leggere tutto ciò che quel progetto contiene. Ammette inoltre gli invitati appena configurano le chiavi, senza attendere che un admin apra l’app: può ammettere solo persone invitate da un admin, mai come admin, e non può mai cambiare le chiavi di un membro. Rimuovere un membro di un progetto aperto non cambia la sua chiave. I dati vengono comunque de-identificati sul tuo dispositivo e conservati cifrati, e la scelta è firmata nella storia del progetto, dove il browser di ogni membro la vede; non si può mai annullare, e un progetto con chiave end-to-end non può mai diventare aperto. Ogni progetto aperto mostra il badge Senza cifratura end-to-end — dati pubblici; ogni altro progetto mostra Cifrato end-to-end.

Che cosa può vedere il gestore

Il server ha bisogno di alcuni dati in chiaro per instradare i dati, applicare i permessi e riportare l’utilizzo. Vede:

account: indirizzi email, orari di accesso e dispositivi;
progetti: titolo, riepilogo pubblico, membri e relativi ruoli, quote, il manifest;
dati: quanti pazienti, studi, serie e file ci sono, le loro dimensioni, i tipi di modalità, gli orari di caricamento e il centro;
annotazioni: chi ha annotato cosa e quando, l’avanzamento delle attività e il loro stato, ma non il contenuto.

Valori clinici, pseudonimi, descrizioni, immagini, contenuto delle annotazioni e log dei processori sono cifrati.

I limiti, onestamente

Metadati visibili. Dimensioni, conteggi, tempistiche, tipi di modalità e avanzamento delle attività sono visibili al gestore, come elencato sopra. La lunghezza dei dati cifrati rivela la lunghezza di ciò che cifrano.
La limitazione per centro all’interno di un progetto è applicata solo dal server. Ogni membro di un progetto detiene la sua chiave.
I membri rimossi possono conservare chiavi o dati che avevano in cache prima della rimozione. Rimuovere un membro ruota la chiave del progetto per i nuovi dati (non in un progetto aperto, la cui chiave è comunque custodita dal server), ma un gestore che collabora con un membro rimosso potrebbe far continuare gli altri membri a scrivere con la vecchia chiave nascondendo loro la rotazione.
Il server distribuisce la web app. Un gestore malintenzionato potrebbe fornire JavaScript alterato. Gli script dell’app portano hash Subresource Integrity (il browser non verifica quelli dei suoi worker), la build web è riproducibile da un tag di rilascio e i rilasci sono firmati con hash pubblicati, così chiunque può confrontare ciò che un server invia con il rilascio (verifica ciò che esegui). Nulla nel browser verifica la pagina stessa; l’auto-hosting elimina la necessità di fidarsi di un altro gestore.
Il primo contatto con un progetto o con la chiave di un membro è fiducia al primo utilizzo (trust on first use), e il server può sapere quali browser sono al primo contatto. I codici di sicurezza permettono di verificare le chiavi e la cronologia del progetto attraverso un altro canale.
Un dispositivo attendibile sblocca le chiavi per chiunque possa usare quel profilo del browser. Bloccare cancella le chiavi solo dalla memoria; rimuovi il dispositivo, oppure non considerare mai attendibili i computer condivisi. Uno script in esecuzione nell’app su quel profilo (uno script iniettato, una dipendenza malevola) potrebbe copiare le chiavi per sempre.
Gli indirizzi email degli invitati sono nella cronologia firmata del progetto, che ogni membro e processore legge.
Il solo codice via email basta per ricominciare da capo. Chi si impadronisce della tua casella di posta può dare al tuo account nuove chiavi. Non apre nulla finché un amministratore di ciascun progetto non confronta con te un codice di sicurezza, quindi non confermare mai un codice di sicurezza che non hai visto tu stesso, e avvisa i tuoi amministratori se ricevi una notifica che non ti aspettavi.
Un dispositivo approvato riceve le tue chiavi. Approva solo i tuoi dispositivi, e solo quando entrambi gli schermi mostrano lo stesso codice.
I progetti aperti sono leggibili dal gestore, per scelta (sopra).
Gli archivi di esportazione non sono cifrati. Fino alla scadenza, un archivio sul server può essere letto da chi ne possiede il link (e il codice, quando il link ne ha uno), dal gestore e da chiunque abbia accesso allo storage del server.
Chiavi perse significano dati persi. Se tutti gli amministratori di un progetto perdono l’accesso alle loro chiavi, nessuno può recuperare i dati, nemmeno il gestore. I progetti hanno bisogno di almeno due amministratori, e i membri dovrebbero tenere un secondo dispositivo attendibile o una passkey.

Segnalare una vulnerabilità

Vedi la politica di sicurezza.