Our Core Principle
Your data is encrypted on your device before it ever reaches our servers. We designed Worklist so that we—the company—cannot decrypt, read, or access your work lists, tasks, or comments. This is called "zero-knowledge" architecture.
What Makes Worklist Different
Traditional Task Managers
- Store your data in plaintext on their servers
- Can read every task, comment, and file you create
- May scan your content for ads, AI training, or "features"
- Vulnerable to data breaches exposing everything
Worklist (Zero-Knowledge)
- Encrypts on your device before sending to our servers
- We cannot decrypt your tasks, even if we wanted to
- No scanning, no AI training on your private work
- Data breaches reveal nothing meaningful—only encrypted blobs
How Zero-Knowledge Encryption Works
1. You Create Your Account
When you register, your password never leaves your browser in plaintext. Instead:
- Your browser uses Argon2id to derive a wrapping key from your password
- A random 32-byte "data key" is generated on your device
- This data key is encrypted with your password-derived wrapping key
- The encrypted data key is stored on our servers—but we can't decrypt it without your password
- We use OPAQUE PAKE protocol so our servers never see your plaintext password
Key point: The wrapping key never leaves your device. Without your password, the encrypted data key is useless to us.
Why store the encrypted data key?
So you can log in from any device! When you switch computers or use your phone, we send you the encrypted blob, you re-enter your password to decrypt it locally, and you're back in. Without storing it, you'd need to manually copy a 32-byte key between devices—terrible UX for the same security.
2. You Create a Work List or Task
Every piece of sensitive data gets encrypted on your device:
- Work list titles, descriptions, and settings
- Task titles, bodies, checklists, and comments
- Recurring task templates and schedules
- Everything is encrypted using ChaCha20-Poly1305 AEAD (a modern, audited cipher)
- Each work list has its own unique encryption key derived from your data key
Our servers store only the encrypted ciphertext—they cannot read the plaintext.
3. You Invite Team Members
When sharing work lists with teammates:
- Each member gets their own encrypted copy of the work list key
- Keys are exchanged using HPKE (Hybrid Public Key Encryption)
- Public keys are published to a transparency log (Merkle tree) to prevent man-in-the-middle attacks
- If you remove a member, the work list key is rotated and all remaining members get new encrypted copies
4. Our Servers Verify Without Decrypting
You might wonder: "If the server can't decrypt, how does it enforce permissions?"
We use HMAC proofs—cryptographic signatures that prove you have the right to access data without revealing the plaintext:
- Your browser computes an HMAC (keyed hash) of the encrypted data using a membership-specific key
- The server validates the HMAC to confirm you're an active member
- Tampering or replaying someone else's data fails the HMAC check
- We never decrypt the payload—just verify integrity and authorization
What Our Servers Can and Cannot See
We CANNOT See
- • Work list titles or descriptions
- • Task titles, bodies, or checklists
- • Comments or discussions
- • Recurring task templates
- • Any content inside encrypted payloads
- • Your password (even hashed)
We CAN See
- • User account email (for login)
- • Membership relationships (who's in which work list)
- • Task status (open/closed) and priority
- • Due dates and timestamps
- • Delegation assignments (user IDs only)
- • Metadata needed for queries (IDs, created dates)
Why some metadata is visible: Certain fields (like task status and due dates) must be stored in plaintext so our servers can efficiently filter queries, enforce due date reminders, and maintain database indexes. These fields contain no sensitive content—only operational metadata that enables the app to function.
Security Guarantees
Password-Based Unlocking (Client-Only)
Your password never leaves your device in plaintext. All key derivation happens in your browser using Argon2id and HKDF.
Server Cannot Decrypt Payloads
Our backend code never calls decrypt operations on user data. It only validates HMAC proofs to confirm authorization.
Key Rotation on Member Changes
When a member is removed or leaves, the work list key is rotated. All remaining members receive new encrypted copies, ensuring the departed member cannot decrypt future content.
Invite Key Transparency
Public keys for invitations are logged in an append-only Merkle tree. Clients verify inclusion and consistency proofs, preventing the server from silently substituting keys to intercept work list data.
Open Source Cryptography
We use battle-tested libraries: strong-box (ChaCha20-Poly1305), Argon2id (key derivation), OPAQUE (password authentication), and HPKE (key exchange). All our crypto code is open source and auditable.
Trade-offs of Zero-Knowledge Design
No Password Recovery
If you forget your password, we cannot recover your data. There's no "reset password and keep your data" option because we don't have the keys to decrypt it.
No Server-Side Search
Because your task content is encrypted, we can't provide server-side full-text search across all your tasks. Search happens in your browser after decryption.
Mitigation: We optimize client-side search with indexed lookups and fast decryption to keep it performant.
Technical Specifications
| Symmetric Encryption | ChaCha20-Poly1305 AEAD (via strong-box library) |
| Password Hashing | Argon2id (64 MiB memory, 3 iterations, 1 parallelism) |
| Key Derivation | HKDF-SHA256 |
| Password Authentication | OPAQUE PAKE (Ristretto255 curve) |
| Key Exchange (Invites) | HPKE (Hybrid Public Key Encryption) with X25519 |
| Integrity Proofs | HMAC-SHA256 |
| Serialization | CBOR (Concise Binary Object Representation) |
| Key Size | 256-bit (32 bytes) for all symmetric keys |
All cryptographic operations happen in your browser using WebCrypto APIs and audited WASM modules compiled from Rust.
Audits & Transparency
Open Source Crypto Stack
Our entire cryptographic implementation is open source and available on GitHub. We welcome security researchers to audit our code.
View on GitHub →Third-Party Security Audit
We're planning a comprehensive security audit by an independent cryptography firm in 2026. Results will be published publicly.
Compliance
Our zero-knowledge architecture is designed to meet requirements for GDPR (data minimization), HIPAA (encrypted PHI), and SOC 2 Type II (access controls).
Common Questions
What happens if you get hacked?
If an attacker gains access to our database, they'd only see encrypted blobs—essentially random bytes. Without your password (which we never store), the data is mathematically impossible to decrypt with current technology.
Can government agencies force you to decrypt my data?
No, because we genuinely cannot. We don't have the keys. Even with a warrant or court order, we can only provide the encrypted ciphertexts—which are useless without your password.
How is this different from "encrypted at rest"?
"Encrypted at rest" means data is encrypted on the server's hard drives, but the server still has the keys to decrypt it. End-to-end encryption means only you (the endpoints) have the keys—the server never has plaintext access.
Can Worklist employees see my data?
No. Our backend code is designed to never decrypt user payloads. Even database administrators with full access to our servers cannot read your work lists or tasks.
What if I want to export my data?
You can export your decrypted data anytime from the app. Since decryption happens in your browser, you'll get readable JSON/CSV files—not encrypted blobs.
Ready for Real Privacy?
Join teams who trust Worklist to keep their work truly private. Start your free 7-day trial—no credit card required.
Start Free TrialHave security questions? Email us at security@worklist.app