Whitepaper su sicurezza e privacy (panoramica)Appendix
Appendice: Indice degli ID delle richieste (unica fonte di verità)
Questa appendice è l'unica fonte di verità per tutti gli ID richiesta nel whitepaper. Ogni rivendicazione ha un identificatore e un ancoraggio univoci e stabili ed è presentata in un'unica riga con a Statement and Evidence. Le prove si collegano solo a riferimenti autorevoli ripetibili e verificabili (ancoraggi di capitolo o punti di ingresso di report di stato/terze parti) e non si collegano a screenshot o contenuti ri-ospitati.
Regole di manutenzione
- MUST: gli ID richiesta sono univoci e stabili; una volta pubblicati, non vengono mai riutilizzati.
- MUST: le prove di ciascuna richiesta devono essere verificabili in modo ripetibile (ancoraggi di capitolo o punti di accesso autorevoli di terze parti).
- MUST: le dichiarazioni devono affermare solo ciò che le prove supportano; evitare il linguaggio della “sicurezza assoluta”.
- SHOULD: quando le modifiche all'implementazione o alle politiche incidono su una rivendicazione, registrala nel registro delle modifiche e collega gli ID della rivendicazione interessata.
Capitoli 1–4 (ambito, modello di minaccia, architettura, AuthZ)
SCOPE-01
Statement: Il documento definisce chiaramente i rischi che rientrano nell'ambito e quelli che lo esulano e i limiti di sicurezza del sistema. Evidence:1.3， 1.4
THREAT-01
Statement: Il modello di minaccia copre attacchi di rete, download non autorizzati, tentativi di lettura lato server/archiviazione e aggressori lato browser. Evidence:2.2
BOUNDARY-01
Statement: I confini di fiducia separano chiaramente le responsabilità tra client, server, storage di oggetti e ambiente esterno; il server NON DEVE ottenere CEK. Evidence:2.4
FAILCLOSE-01
Statement: In caso di errore di autenticazione o contesto incoerente, il sistema deve fallire la chiusura e non restituire alcun testo in chiaro parziale. Evidence:2.5
ARCH-01
Statement: Gli oggetti dati principali sono chiaramente separati: blocchi crittografati, manifest e dati di controllo sono isolati gli uni dagli altri. Evidence:3.2
FLOW-UP-01
Statement: Il flusso di caricamento include la creazione di un transferId e l'emissione di token di accesso di breve durata (token di sessione basati sulla ricerca) con controlli rigorosi su ambito e scadenza. Evidence:3.3
FLOW-DL-01
Statement: I download analizzano il frammento dell'URL per ottenere la CEK; le letture manifest e Chunk utilizzano token con ambito diverso; gli errori di autenticazione falliscono la chiusura. Evidence:3.4， 2.5
AUTH-TOKEN-01
Statement: I token di accesso di breve durata sono token di sessione lato server (basati sulla ricerca) che scadono e vengono utilizzati per il controllo dell'accesso al testo cifrato e ai manifest. Evidence:4.2
AUTH-SCOPE-01
Statement: I token sono separati da ambiti come read_manifest / read_chunk / upload_chunk e sono rigorosamente convalidati. Evidence:4.3， 4.4， 3.4
AUTH-PAID-01
Statement: Gli utenti a pagamento accedono tramite un collegamento magico una tantum e ottengono un token client di lunga durata per le azioni di gestione lato mittente. Evidence:4.1， 3.5
REVOKE-01
Statement: Il mittente può revocare l'accesso: l'eliminazione di un trasferimento o la rimozione di file rende anticipatamente non validi i download e nega l'accesso successivo. Evidence:4.5
AUDIT-01
Statement: I dati di controllo come il conteggio dei download e l'avanzamento sono visibili solo al mittente e non al destinatario. Evidence:4.6， 3.5
LOG-01
Statement: I registri/telemetria del client e del server non includono CEK, frammenti di URL o qualsiasi materiale di chiave derivabile. Evidence:4.7， 10.2
Capitolo 5 (Crittografia e gestione delle chiavi)
CRYPTO-ZK-01
Statement: La CEK viene generata solo nel browser e distribuita tramite il frammento di URL; il server non genera mai un collegamento per il download completo contenente CEK. Evidence:5.3.1， 5.3.2
CRYPTO-ZK-02
Statement: Il server non riceve/memorizza/registra la CEK; l'archiviazione degli oggetti memorizza solo blocchi crittografati. Evidence:5.0， 5.5.1
CRYPTO-E2EE-01
Statement: I blocchi utilizzano AES-128-GCM; l'errore di autenticazione deve fallire e non restituire alcun testo in chiaro parziale. Evidence:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Statement: ChunkSize è fissato a 16 MB (16777216). Evidence:5.4.1， 5.8.1
CRYPTO-NONCE-01
Statement: IV è derivato come noncePrefix(8B)||uint32_be(chunkIndex) e non deve ripetersi sotto lo stesso CEK. Evidence:5.4.3， 5.8.1
CRYPTO-AAD-01
Statement: AAD è associato a transferId + fileId + ChunkIndex e codificato tramite EncodeAAD_v1. Evidence:5.4.4
CRYPTO-CLIENT-01
Statement: Le pagine di download/decrittografia non caricano script di terze parti; i registri/telemetria del client non includono frammenti o materiale della chiave. Evidence:5.6， 10.2
CRYPTO-TLS-01
Statement: Viene applicato il protocollo HTTPS a livello di sito; La configurazione TLS è verificabile tramite report pubblici di terze parti. Evidence:5.1.2， /status#tls-configuration
Capitoli 6–7 (Ciclo di vita dei dati/Difesa dagli abusi)
LIFECYCLE-01
Statement: Pulizia del trigger di eliminazione avviata dall'utente e in scadenza; è supportata la revoca per invalidare anticipatamente i download. Evidence:6.2， 6.3， 4.5
ABUSE-01
Statement: La difesa dagli abusi utilizza limiti di velocità e controlli a più livelli, operando senza oltrepassare il limite della conoscenza zero. Evidence:7.2， 7.4
Capitoli 8–9 (Privacy/Sicurezza web e isolamento)
PRIVACY-01
Statement: La definizione e gli impegni a conoscenza zero sono espliciti: CEK viene generato e utilizzato solo sul client; il server non può recuperare la chiave. Evidence:8.1
PRIVACY-02
Statement: Le implicazioni sulla privacy dei frammenti di URL (copia/incolla, perdita di referrer, registrazione) sono documentate con mitigazioni. Evidence:8.2， 10.2
WEB-01
Statement: Le pagine chiave applicano rigidi limiti CSP e risorse per ridurre il rischio di injection e clickjacking. Evidence:9.1， 9.3
WEB-HEADERS-01
Statement: La base delle intestazioni di sicurezza è verificabile tramite report pubblici di terze parti. Evidence:/status#security-headers
WEB-OBS-01
Statement: Il sito può essere controllato tramite scansioni pubbliche basate sulle migliori pratiche di terze parti. Evidence:/status#http-observatory
Capitoli 10–12 (Registrazione e IR/Divulgazione di vulnerabilità/Prove)
OBS-01
Statement: L'osservabilità segue un principio minimo, coprendo solo le esigenze operative/di sicurezza e utilizzando strategie di aggregazione/campionamento. Evidence:10.1
IR-01
Statement: Viene definito un processo di risposta agli incidenti di sicurezza (gravità, contenimento, post mortem, riparazione e avviso pubblico). Evidence:10.4
VDP-01
Statement: Esiste un processo di divulgazione delle vulnerabilità che dà la priorità ai problemi che potrebbero influenzare il confine di conoscenza zero. Evidence:11.2
EV-01
Statement: La pagina di stato aggrega punti di ingresso di prove di terze parti; le prove si collegano a fonti autorevoli e chiariscono i limiti di applicabilità. Evidence:12.2， 12.6