We care deeply about what you share with Planless. She has access to your emails, calendar, tasks, documents, and the thoughts you put into words at 2am. That trust is not something we take lightly — it is something we built around. This page is our honest account of how your privacy is protected, what the architecture actually does, and where the real limits are.
The short version: your data is locked with a key that only you have, before it ever leaves your browser. We store the locked box. We do not have the key. We genuinely cannot open it — and we designed it that way on purpose.
Most apps can read everything you store in them.
When you type a note into a typical app, the words travel from your device to a server as readable text. The company, their employees, their vendors, anyone who gains access to that server — they can all read those words. Most companies have policies saying they won't look. But policies can be revoked, overridden by a court order, or bypassed in a breach.
Lock it in your browser before it leaves.
The vault flips the normal order. Your browser turns your words into an unreadable scramble — ciphertext — before they travel anywhere. The scramble is all the server ever receives.
Think of it like writing your note in a language only you know, sealing it in an envelope, and mailing the sealed envelope. The post office delivers it. The post office cannot read it.
Four steps, from passphrase to ciphertext.
You choose a vault passphrase
Separate from your login password. It never leaves your browser. If you forget it and have no recovery code, nobody can recover your data — not us, not anyone. That is the trade-off for genuine privacy.
Your browser turns it into an encryption key
The browser runs the passphrase through PBKDF2 — a deliberate slow-down algorithm — 600,000 times. The result is a 256-bit encryption key that lives only in your browser's memory. It is never sent anywhere. Close the tab and it is gone.
Everything is scrambled before it leaves your device
Every task, note, document, and chat message is locked with AES-256-GCM — the same cipher used by banks and governments — before it travels to our servers. We only ever receive the scrambled version.
Your browser decrypts when you return
You enter your passphrase, the key is re-derived, your browser downloads the scrambled data and unscrambles it locally. Planless sends you a locked box. Your browser opens it. We never see inside.
PBKDF2 runs 600,000 rounds because we want it to cost time. Not for you — the delay is barely noticeable. But for an attacker guessing your passphrase, every single guess requires the same computation. One million guesses takes roughly years on typical hardware. This follows the OWASP 2024 standard.
We store the locked box. Not the key.
Here is a precise map of what exists on our servers versus what stays on your device, and who can read what.
| What we store | What it is | Can we read it? |
|---|---|---|
| Salt | 32 random bytes, unique per user. Makes your key unique even if two people use the same passphrase. | Not sensitive |
| Verify blob | An encrypted check that lets your browser confirm you typed the right passphrase — without us ever knowing it. | Encrypted — no |
| Your workspace data | All tasks, notes, documents, chat history — stored as unreadable ciphertext. | Ciphertext — no |
| Recovery blob (optional) | If you set a recovery code at setup, this is your vault key encrypted under that code. Only your recovery code can open it. | Encrypted — no |
| Your passphrase | The passphrase itself — ever, at all. | We never have it |
What happens if you forget your passphrase.
If you forget your passphrase and did not save a recovery code, your data is permanently unreadable. Not recoverable by us. Not by anyone. The encryption cannot be undone on your behalf — and that is the point.
The recovery code
When you set up the vault, you can generate a recovery code — a 20-character code like A3F9B-2KP1M-7XQW-D8R4C. If you forget your passphrase, entering the recovery code restores access. Even this mechanism does not give us your key. The code you hold is the only thing that can decrypt the recovery blob we store. We have an encrypted package — we cannot open it.
Save your recovery code offline — a notebook, a password manager, printed paper. If you lose both your passphrase and your recovery code, nobody can get your data back. This is the trade-off for genuine privacy.
What happens when you talk to her.
An AI model cannot read encrypted scramble. AES-256 ciphertext is meaningless to a language model. So for her to understand your workspace and give you useful answers, your browser decrypts your data locally and sends the readable text to the AI inference system for that session.
What we promise: that plaintext is not stored permanently on any external server after the session ends. It is used for inference and discarded. But during an active session, she does have access to your readable content — that is what makes her useful. The vault protects your data at rest. The session is a temporary window of access.
The vault protects your data at rest on our servers. During an active AI session, a temporary plaintext window is necessary for the AI to work. We do not store that plaintext permanently. This is different from "we see nothing forever" — and we think you deserve to know the difference. See our Privacy Policy for full details on what is and is not logged.
What the claim does — and does not — guarantee.
The browser JS delivery question
The software that runs the encryption in your browser is JavaScript our servers deliver to you. In theory, if our servers were compromised and an attacker replaced that JavaScript with malicious code, it could intercept your passphrase before encrypting anything. This applies to every web app with client-side encryption — ProtonMail, 1Password's web interface, Bitwarden's web vault. Our desktop app reduces this surface because it ships with a fixed, auditable code bundle not served fresh from a server on every load.
Session cache and XSS
To avoid asking for your passphrase on every page refresh, we cache the encryption key in your browser's sessionStorage for up to 30 minutes of inactivity. An XSS vulnerability in our app could, in theory, expose that cached key. The expiry reduces the window. Our security practices aim to prevent XSS entirely. But you deserve to know the mechanism exists.
The system is real. The encryption is strong. The honest edge cases are what you just read.
Your workspace data is encrypted with one of the strongest symmetric ciphers available, with a key only you possess, using parameters that meet the current security standard. For data at rest on our servers, the guarantee holds. The limits are browser-based JS delivery and the temporary AI inference window — both are inherent to the medium, not corners we have cut.
We built the vault because she asked for a level of access to your life that required us to design around our own ability to misuse it. That constraint is structural, not just a policy we could revoke tomorrow.
1 PBKDF2-SHA256 at 600,000 iterations follows the OWASP Password Storage Cheat Sheet 2024 recommendation for AES-256 key derivation.
2 AES-256-GCM provides authenticated encryption: any tampering with the ciphertext is detected and rejected on decryption.
3 The salt stored on our servers is 32 random bytes. Not sensitive — it makes your key unique, but it does not help an attacker who lacks your passphrase.
4 SessionStorage is cleared when the browser tab is closed. Our 30-minute inactivity expiry means an idle tab's cached key goes stale before the browser session ends in most usage patterns.
5 The full technical audit — 75 test results, threat model, and all four bugs found and fixed — is in Zero-Knowledge by Design on Brainsless.