TL;DR
Worklist utilizza la crittografia ChaCha20-Poly1305 con architettura zero-knowledge. I tuoi dati vengono crittografati sul tuo dispositivo prima di raggiungere i nostri server utilizzando primitive moderne e verificabili. Non possiamo fisicamente leggere le tue attività, anche con accesso completo al database. Una chiave di riserva che salvi può ripristinare l'accesso una sola volta se perdi la password, senza consegnare a Worklist una chiave di decifratura. Supporta la minimizzazione dei dati GDPR e può aiutare con le protezioni tecniche HIPAA/SOC 2 se abbinato agli accordi richiesti e ai controlli operativi.
Il nostro principio fondamentale.
I tuoi dati vengono crittografati sul tuo dispositivo prima che raggiungano i nostri server.Abbiamo progettato Worklist in modo che noi, l'azienda, non possiamo decrittografare, leggere o accedere ai tuoi elenchi di lavoro, attività o commenti. Questo si chiamazero-knowledgearchitettura.
Cosa rende Worklist diverso.
Task manager tradizionali.
Cosa fanno i concorrenti
- • Memorizza i tuoi dati in chiaro sui loro server
- • Può leggere ogni attività, commento e file che crei
- • Può eseguire la scansione dei tuoi contenuti alla ricerca di annunci, addestramento AI o "funzionalità"
- • Vulnerabile alle violazioni dei dati che espongono tutto
Worklist (zero-knowledge).
Cosa facciamo
- • Crittografa sul tuo dispositivo prima di inviarlo ai nostri server
- • Non possiamo decrittografare le tue attività, anche se lo volessimo
- • Nessuna scansione, nessuna addestramento AI sul tuo lavoro privato
- • Le violazioni dei dati non rivelano nulla di significativo: solo BLOB crittografati
Come la crittografia zero-knowledge funziona.
Crei il tuo account.
Quando ti registri, la tua password non lascia mai il tuo browser in chiaro. Invece:
- Usiamo il protocollo OPAQUE PAKE in modo che i nostri server non vedano mai la tua password in chiaro
- Dopo una registrazione o un accesso riuscito, OPAQUE consegna al browser una export key segreta che noi non riceviamo mai
- Sul tuo dispositivo viene generata una "chiave dati" casuale da 32 byte
- Questa chiave dati viene crittografata localmente con una chiave di wrapping derivata da quella export key OPAQUE
- La chiave dati crittografata è archiviata sui nostri server, manon possiamo decrittografarlasenza il materiale di sblocco lato client
- Puoi scaricare una chiave di riserva monouso. Avvolge la stessa chiave dati nel browser, e noi salviamo solo un wrapper di recupero crittografato
Punto chiave: la chiave di sblocco e la chiave dati vengono gestite nel tuo browser. Conserviamo solo wrapper crittografati, mai password in chiaro o chiavi del workspace.
Perché archiviare la chiave dati crittografata?
Così puoi accedere da qualsiasi dispositivo. Quando cambi computer o usi il telefono, inviamo il blob crittografato, il browser lo sblocca localmente dopo l'accesso sicuro e sei di nuovo dentro. Senza memorizzarlo, dovresti copiare manualmente una chiave da 32 byte tra i dispositivi: una pessima UX per la stessa sicurezza.
Crei un elenco di lavoro o un'attività.
Ogni dato sensibile viene crittografato sul tuo dispositivo:
- Titoli, descrizioni e impostazioni delle liste di lavoro
- Titoli delle attività, descrizioni, liste di controllo e commenti
- Modelli e pianificazioni di attività ripetute
- Tutto è crittografato utilizzandoChaCha20-Poly1305 AEAD(un codice moderno e controllato)
- Ogni lista di lavoro ha la propria chiave di crittografia univoca derivata dalla chiave dati
I nostri server memorizzano solo i filetesto cifrato crittografato– non possono leggere il testo in chiaro.
Inviti i membri del team.
Quando condividi elenchi di lavoro con i membri del team:
- Ogni membro riceve la propria copia crittografata della chiave della lista di lavoro
- Le chiavi vengono scambiate utilizzandoHPKE(Crittografia ibrida a chiave pubblica)
- Le chiavi pubbliche vengono pubblicate su aregistro della trasparenza(Merkle tree) per prevenire attacchi man-in-the-middle
- Se rimuovi un membro, la chiave dell'elenco di lavoro viene ruotata e tutti i membri rimanenti ricevono nuove copie crittografate
I nostri server verificano senza decrittografare.
Potresti chiederti: "Se il server non può decrittografare, come fa a imporre le autorizzazioni?"
Utilizziamo prove HMAC: firme crittografiche che dimostrano che hai il diritto di accedere ai dati senza rivelare il testo in chiaro.
- Il tuo browser calcola un HMAC (keyed hash) dei dati crittografati utilizzando una chiave specifica dell'appartenenza
- Il server convalida l'HMAC per confermare che sei un membro attivo
- La manomissione o la riproduzione dei dati di qualcun altro non supera il controllo HMAC
- Non decodifichiamo mai il payload: ne verifichiamo solo l'integrità e l'autorizzazione
Cosa possono fare i nostri server (e non può) vedere.
NON POSSIAMO vedere
- × Titoli o descrizioni delle liste di lavoro
- × Titoli di attività, descrizioni o liste di controllo
- × Commenti o discussioni
- × Modelli di attività ripetute
- × Qualsiasi contenuto all'interno di payload crittografati
- × La tua password (anche con hash)
POSSIAMO vedere
- ✓ E-mail dell'account utente (per l'accesso)
- ✓ Rapporti di appartenenza (chi è in quale lista di lavoro)
- ✓ Stato dell'attività (aperta/chiusa) e priorità
- ✓ Date di scadenza e timestamp
- ✓ Assegnazioni di delega (solo ID utente)
- ✓ Metadati necessari per le query (ID, date di creazione)
Perché alcuni metadati sono visibili: Alcuni campi (come lo stato delle attività e le date di scadenza) devono essere archiviati in testo normale in modo che i nostri server possano filtrare in modo efficiente le query, applicare promemoria delle date di scadenza e mantenere gli indici dei database. Questi campi non contengono contenuti sensibili, ma solo metadati operativi che consentono il funzionamento dell'app.
Sicurezza garanzie.
Sblocco autenticato dalla password (solo client).
La tua password non lascia mai il dispositivo in chiaro. Un'autenticazione OPAQUE riuscita consegna al browser una export key che sblocca localmente la chiave dati. La chiave dati viene quindi espansa con HKDF per derivare chiavi separate per ogni lista di lavoro.
Il server non può decrittografare i payload.
Il nostro codice backend non chiama mai operazioni di decrittografia sui dati dell'utente. Convalida solo le prove HMAC per confermare l'autorizzazione.
Rotazione delle chiavi sulle modifiche dei membri.
Quando un membro viene rimosso o abbandona, la chiave dell'elenco di lavoro viene ruotata. Tutti i membri rimanenti ricevono nuove copie crittografate, garantendo che il membro deceduto non possa decrittografare i contenuti futuri.
Invita la trasparenza chiave.
Le chiavi pubbliche per gli inviti vengono registrate in un albero Merkle di sola aggiunta. I client verificano le prove di inclusione e coerenza, impedendo al server di sostituire silenziosamente le chiavi per intercettare i dati della lista di lavoro.
Le chiavi di riserva restano zero-knowledge.
Una chiave di riserva viene generata nel browser e deve essere salvata da te. Crea un wrapper crittografato separato per la stessa chiave dati; noi memorizziamo solo il file credenziale di recupero e il wrapper crittografato, quindi non possiamo reimpostare la password o leggere i dati senza quella chiave salvata.
Crittografia open source.
Utilizziamo librerie testate sul campo: strong-box (ChaCha20-Poly1305), OPAQUE (autenticazione con password), HKDF (derivazione chiave), Argon2id (rafforzamento della password OPAQUE e migrazione legacy) e HPKE (scambio di chiavi). Tutto il nostro codice crittografico è open source e verificabile.
Come verifichiamo la nostra sicurezza.
Le nostre affermazioni sulla sicurezza sono verificabili, non solo marketing. Ecco come garantiamo che la nostra architettura zero-knowledge funzioni come promesso:
- Codice crittografico open source disponibile su GitHub per il controllo pubblico da parte dei ricercatori di sicurezza
- Librerie verificate in produzione tra cui ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) e HPKE
- Prove crittografiche (HMAC) che impediscono matematicamente la decrittografia lato server
- Registri di trasparenza (alberi Merkle) per rilevare attacchi di sostituzione delle chiavi
- Lo sblocco lato client dalle export key OPAQUE garantisce che non vedremo mai la tua password o le chiavi di crittografia
- Le chiavi di riserva monouso sono generate e conservate dall'utente, mai da Worklist
Compromessi di zero-knowledge.
Una chiave di riserva può ripristinare l'accesso se perdi la password.
Salva una chiave di riserva una volta e tienila privata. Se perdi la password, quella chiave ti consente di reimpostarla e mantenere l'accesso ai dati crittografati. Poiché Worklist non ne conserva una copia, gli account senza una chiave di riserva salvata non possono essere recuperati.
Nessuna ricerca lato server.
Poiché il contenuto della tua attività è crittografato, non possiamo fornire la ricerca full-text lato server in tutte le tue attività. La ricerca avviene nel tuo browser dopo la decrittazione.
Mitigazione: ottimizziamo la ricerca lato client con ricerche indicizzate e decrittografia rapida per mantenerla performante.
Specifiche tecniche.
| Crittografia simmetrica | ChaCha20-Poly1305 AEAD (tramite la libreria strong-box) |
| Sblocco della chiave dati | Export key OPAQUE + HKDF-SHA256 — deriva chiavi di wrapping locali per la chiave dati crittografata |
| Gerarchia delle chiavi | HKDF-SHA256 — deriva le chiavi delle liste di lavoro e delle appartenenze dalla chiave dati |
| Autenticazione con password | OPAQUE PAKE (curva Ristretto255) |
| Chiavi di riserva | Una chiave di riserva attiva e monouso per utente; generata lato client e conservata dall'utente |
| Scambio di chiavi (inviti) | HPKE (Hybrid Public Key Encryption) con X25519 |
| Prove di integrità | HMAC-SHA256 |
| Serializzazione | CBOR (Concise Binary Object Representation, rappresentazione binaria compatta degli oggetti) |
| Dimensione chiave | 256 bit (32 byte) per tutte le chiavi simmetriche |
Tutte le operazioni crittografiche avvengono nel tuo browser utilizzando le API WebCrypto e moduli WASM controllati compilati da Rust.
Audit e trasparenza.
Stack crittografico open source.
La nostra intera implementazione crittografica è open source e disponibile su GitHub. Diamo il benvenuto ai ricercatori di sicurezza per verificare il nostro codice.
Visualizza su GitHubConformità.
La nostra architettura zero-knowledge supporta la minimizzazione dei dati GDPR e può aiutare con le protezioni tecniche HIPAA o SOC 2. Le PHI regolamentate richiedono comunque un accordo scritto o BAA, oltre ai controlli operativi e alla conferma del fornitore richiesti dal programma di conformità.
Domande comuni.
Cosa succede se vieni hackerato?
Se un utente malintenzionato riuscisse ad accedere al nostro database, vedrebbe solo blob crittografati, essenzialmente byte casuali. Senza lo sblocco autenticato dalla tua password o una chiave di riserva salvata, i dati sono matematicamente impossibili da decrittografare con la tecnologia attuale.
Le agenzie governative possono obbligarti a decrittografare i miei dati?
No, perché sinceramente non possiamo. Non abbiamo le chiavi. Anche con un mandato o un'ordinanza del tribunale, possiamo fornire solo i testi cifrati crittografati, che sono inutili senza lo sblocco autenticato dalla tua password o una chiave di riserva che hai salvato.
Cosa succede se dimentico la password?
Se hai salvato una chiave di riserva, puoi usarla una sola volta per reimpostare la password e mantenere l'accesso ai dati crittografati. Se non hai salvato una chiave di riserva, Worklist non può ripristinare i dati per te.
In cosa differisce da "crittografato a riposo"?
"Crittografato a riposo" significa che i dati sono crittografati sui dischi rigidi del server, ma il server ha ancora le chiavi per decrittografarli. La crittografia End-to-end significa che solo tu (gli endpoint) hai le chiavi: il server non ha mai accesso in testo normale.
I dipendenti Worklist possono vedere i miei dati?
No. Il nostro codice backend è progettato per non decrittografare mai i payload degli utenti. Anche gli amministratori di database con pieno accesso ai nostri server non possono leggere le tue liste di lavoro o attività.
Cosa succede se voglio esportare i miei dati?
Puoi esportare i tuoi dati decrittografati in qualsiasi momento dall'app. Poiché la decrittografia avviene nel tuo browser, otterrai file JSON/CSV leggibili, non BLOB crittografati.
Riferimenti e standard.
Le nostre scelte crittografiche seguono gli standard di settore e le specifiche sottoposte a revisione paritaria.
- 01 RFC 8439: ChaCha20 e Poly1305 per protocolli IETF — Il nostro standard di crittografia simmetrica
- 02 RFC 9497: OPAQUE Protocollo asimmetrico PAKE — Zero-knowledge autenticazione tramite password
- 03 RFC 9180: crittografia ibrida a chiave pubblica (HPKE) — Scambio di chiavi per gli inviti del team
- 04 RFC 9106: funzione di memoria dura Argon2 — Derivazione della chiave basata su password
- 05 NIST SP 800-175B: Linee guida per l'utilizzo di standard crittografici — Guida crittografica federale
- 06 GDPR Articolo 32: Sicurezza del trattamento — Requisiti di protezione dei dati dell'UE
Pronto per vera privacy?
Unisciti ai team che si affidano a Worklist per mantenere il proprio lavoro veramente privato. Inizia la tua prova gratuita: non è richiesta la carta di credito.
Inizia la prova gratuitaHai domande di sicurezza? Inviaci un'e-mail a security@worklist.app