Our threat model, published

The zero-knowledge guarantee

Everything in your vault — logins, notes, files, including their names and metadata — is encrypted in your browser before it is sent to us. All ciphertext sits under your Account Key, derived from your master password with Argon2id, never stored server-side in any form. Items are encrypted with AES-256-GCM under per-item keys.

The following attacks are cryptographically defeated — not policy-defeated, math-defeated:

• A full database dump or a stolen backup — yields only ciphertext.
• A curious DBA or a platform admin browsing tables — sees only ciphertext. Our own admin panel has no decrypt path; no server endpoint returns plaintext to anyone, ever.
• A network eavesdropper — only ciphertext, auth-hashes, and wrapped keys cross the wire (with TLS on top).
• Server compromise at rest — the server never possesses your master password, your Account Key, item keys, or plaintext.
• Even the server-held time-lock wrap key doesn't help an attacker: it gates time, not content. Stripping it still yields ciphertext under your Account Key.

What the server holds — and never holds

Holds: ciphertext, wrapped (encrypted) keys, a one-way auth-hash used to verify your unlock, schedule rules (it must read the windows to enforce them), and audit metadata.

Never holds: your master password, your Account Key, any item key in usable form, or any plaintext secret, name, field, or file.

Honest limitations — disclosed up front

No password manager can defend against everything. Here is what our design does not solve, and what we do about each gap:

1. A malicious operator shipping tampered client JavaScript. Any browser-delivered end-to-end-encrypted app trusts the code the server ships; a truly malicious operator could push JavaScript that captures your master password as you type it. We minimize what the server can do (it never receives your master password or keys) and we mitigate with a strict Content Security Policy, Subresource Integrity, published client build hashes, and reproducible builds. Above all, the signed browser extension — packaged and signed through the browser web stores — cannot have its code swapped per-request by a server, making it the strongest-assurance way to use TimeLock. Signed desktop clients and self-hosting are on the roadmap. We make this attack detectable and narrow — we do not claim it is solved.
2. A compromised device. A keylogger, malware, or a malicious browser extension on your machine can capture anything you type or view. This is out of scope for any password manager, including this one.
3. A weak master password. Mitigated, not eliminated: expensive Argon2id derivation, a strength meter, and an optional breach check at set-time — but a guessable master password is still your weakest link.
4. Scheduling controls the app, not your memory. A time-locked secret is un-openable outside its window — but once revealed inside a window, you (or anyone you've shared it with) can copy or remember it. Scheduled items also require being online during the window, because the server participates in every scheduled unlock.
5. Lost master password + lost Recovery Key = permanently unrecoverable data. By design. We cannot reset your master password, because we never have it. The mandatory Recovery Kit you save at setup is the only way back. The single exception is org escrow recovery on Team — opt-in only, and always disclosed to every member while it's enabled.

How unlocking works

Signing in and unlocking are separate layers. Sign-in is a passwordless one-time email code, with optional TOTP or passkey (WebAuthn) two-factor. Unlocking your vault then takes your master password, run through Argon2id in your browser — the server receives only a derived verification hash, never the password. Decryption keys live in memory only, with auto-lock on inactivity.

How time-locking is enforced

A scheduled item's key is wrapped twice: once under your keys (content), and once under a server-held wrap key (time). The server removes its layer only while the item's window is open, using its own clock — so the lock isn't a client-side rule you can bypass by changing your system time. The server's layer gates when, never what: it cannot decrypt anything, in or out of a window.

Found a vulnerability?

We want to hear about it. Contact us with "security" in your message and we'll prioritize the response.