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. 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:
- Il tuo browser utilizzaArgon2idper ricavare una chiave di wrapping dalla tua password
- Sul tuo dispositivo viene generata una "chiave dati" casuale da 32 byte
- Questa chiave dati è crittografata con la chiave di wrapping derivata dalla password
- La chiave dati crittografata è archiviata sui nostri server, manon possiamo decifrarlosenza la tua password
- UsiamoOPAQUE PAKEprotocollo in modo che i nostri server non vedano mai la tua password in chiaro
Punto chiave: la chiave di wrapping non lascia mai il tuo dispositivo. Senza la tua password, la chiave dati crittografata è inutile per noi.
Perché archiviare la chiave dati crittografata?
Quindi puoi accedere da qualsiasi dispositivo. Quando cambi computer o usi il telefono, ti inviamo il blob crittografato, inserisci nuovamente la password per decrittografarla localmente e torni indietro. 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 basato su password (solo client).
La tua password non lascia mai il tuo dispositivo in chiaro. Viene allungata utilizzando Argon2id per creare una chiave di wrapping che decrittografa la chiave dei dati master. La chiave dati viene quindi espansa utilizzando HKDF per derivare chiavi separate per ogni elenco 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.
Crittografia open source.
Utilizziamo librerie testate sul campo: strong-box (ChaCha20-Poly1305), Argon2id (derivazione chiave), OPAQUE (autenticazione con password) 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
- La derivazione della chiave lato client tramite Argon2id garantisce che non vedremo mai la tua password o le chiavi di crittografia
Compromessi di zero-knowledge.
Nessun recupero della password.
Se dimentichi la password, non potremo recuperare i tuoi dati. Non esiste l'opzione "reimposta password e mantieni i tuoi dati" perché non abbiamo le chiavi per decrittografarli.
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) |
| Estensione della password | Argon2id (64 MiB di memoria, 3 iterazioni, parallelismo 1) — converte la password in una chiave di wrapping |
| 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) |
| 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 la tua password (che non memorizziamo mai), 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 la tua password.
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