Most of what we keep in Marvelist is everyday stuff: the shopping, the weekend jobs, the things to pack. But some lists hold more than that – medication schedules, financial to-dos notes from a difficult conversation, the personal things you'd rather keep to yourself.
Marvelist Vault is for those. It lets you give a list its own extra layer of encryption, so its contents are scrambled in our database and kept out of the Marvelist assistant (AI) – while the list itself looks and works exactly as it always has. It syncs across your devices, it shares with the people you choose, it works offline. You just see a small shield on it.
This post explains what Vault is in plain terms, and then – because I think you deserve the real picture, not a buzzword – exactly how it works under the hood and what it does and doesn't protect against.
What Vault actually does
When you protect a list with Vault, Marvelist encrypts that list's contents – its tasks, notes, checklist items, and comments – with keys that are unique to your account, before they're written to our database. So in the database, those contents are scrambled and can't be read on their own. Open the list in the app and it unlocks instantly, exactly as you'd expect.
Three things change for a protected list:
- Its contents can't be read straight out of our database – not from a query, a backup or an export.
- It's kept out of the Marvelist Assistant and AI connectors entirely. The assistant can't see, search, read, or change it. Notifications about it are kept generic, so nothing sensitive lands on your lock screen.
- You get a one-time recovery code when you first set up Vault. Save it somewhere safe – it's your backstop.
Everything else stays the same.
What's protected – and what isn't
I'd rather be precise than vague here, because "everything is protected" is the kind of claim that quietly isn't true.
Encrypted when you protect a list: tasks titles and details, notes, checklist (subtasks) titles, and comments on tasks.
Not encrypted, by design: the list's own name and description (they're used across the app for sharing and joining, so the list name isn't hidden), and operational fields like due dates, completion status, the "important" flag, assignee and colour – kept readable so sorting, reminders and filtering still work.
One honest consequence: searching protected lists happens on your device, not on our servers. We keep their contents out of server-side processing by design — the same choice that keeps them out of the AI — so search for them runs locally. That's expected, not a bug.
Let me be straight: what Vault is, and what it isn't
Vault is an extra layer of encryption. It is not end-to-end encryption, and it isn't zero-knowledge.
We hold the keys. They live in a key store that's kept separate from the database, and the running app can use them to decrypt your protected content when it needs to — to sync a list to your other devices, or to share it with someone you've chosen. That's a deliberate trade-off: it's what makes Vault compatible with the things you actually want Marvelist to do.
So Vault isn't "nobody can ever touch this." It's a meaningfully stronger lock on the drawer: your sensitive lists stop being readable from a database dump, a backup or an export, and they're taken out of the AI entirely. That's a real, useful protection — and I'd rather describe it accurately than dress it up as something it's not.
Under the hood
If you're the sort who likes to know how the lock is built, here's the mechanism.
The baseline (all data). Every byte in Marvelist is already encrypted at rest at the storage layer (Azure Storage Service Encryption) and in transit (TLS). But storage-layer encryption is transparent — the database decrypts on every read — so a normal query still returns readable data. That baseline is good hygiene, but it isn't what makes Vault different.
What Vault adds: application-layer encryption. A protected list's content values are encrypted before they're written to the database, so reading those columns back returns ciphertext, not text. Turning that ciphertext back into readable content happens in our application layer — the running service, using keys it unwraps — not transparently in the storage layer.
The keys (envelope encryption). Vault uses a layered key hierarchy, each key wrapping the one below it:
- A single root key lives in a secrets manager (Cloudflare Secrets Store) — a separate trust boundary from the database.
- Each user has a personal key, stored only in wrapped (encrypted) form.
- Each protected list has its own content key, which actually encrypts that list's content.
- The content key is wrapped by your personal key, which is wrapped by the root key.
To serve a protected list, the app unwraps that chain in-process. The important property is the separation: a copy of the database — a dump, a backup, a binlog, a stray query log — doesn't contain the root key, so protected content in it stays ciphertext.
The recovery code. When you enrol, you're shown a one-time, high-entropy recovery code. We never store it. Behind the scenes it protects a second wrapped copy of your personal key, as a break-glass backstop for account-recovery situations. Keep it somewhere safe — a password manager is ideal.
The algorithms, for the curious: AES-256-GCM for content, AES Key Wrap for the keys, and PBKDF2 to derive the key from your recovery code.
The honest threat model
The most useful thing I can give a security-minded reader is a straight table of what Vault does and doesn't defend against.
Threat | Does Vault protect against it? |
|---|---|
A leaked or stolen database dump, backup, binlog, or query log | Yes — it yields only ciphertext for protected content; the root key lives in a separate store. |
Someone reading the database directly, without the key store | Yes |
The Marvelist assistant or AI connectors seeing the content | Yes — protected lists are excluded entirely. |
Sensitive text leaking into a push notification | Yes — those notifications are genericised. |
A compromised live server, or an operator with access to the running app and the key store | No — the running app can decrypt to serve your data. |
A collaborator you shared the list with | No — by design, they can read it. That's sharing. |
A lost device | Not a data-loss event — keys are server-held, and the recovery code is an extra backstop. |
If a feature promises you the world, the "No" rows are the ones it isn't telling you about. I'd rather show you ours.
Sharing still just works
Protected lists share like any other list. When you share one and the other person accepts, Marvelist securely gives them access to that list's content key, re-wrapped under their own account — so they see the real contents normally. Remove their access, or if they leave, and their copy of the key is destroyed. (One nuance for the precise: read-only sharing is enforced by our normal permissions, not by the encryption itself.)
What it costs
Every account can protect one list for free. Protecting more lists is part of Marvelist Premium. The limit is only ever checked when you protect a new list — reading, editing, unprotecting and sharing lists you've already protected are never gated. So if a subscription lapses, you keep full access to everything you've already protected; you just can't protect new lists until you're back on Premium.
How to turn it on
Open any list, choose Protect with Vault, and follow the prompts. The first time, we'll set Vault up on your account and show you your recovery code — save it, confirm, and you're done. A shield appears on the list, and that's it: same list, extra lock.
---
I built Vault because "trust me" isn't good enough, and neither is a privacy buzzword that falls apart when you read the small print. This is a genuine, well-built extra layer of protection for the lists that need it — described exactly as it is. If you've got questions about how it works, I'm always reachable at _help@marvelist.co.uk_.
– Chris, Marvelist
---
No comments yet