How MemoryVault protects what you store

Why this page exists

Security claims in consumer products are usually written to reassure rather than to inform. The result is a genre of copy that says "bank-level encryption" and "your data is safe with us" without ever telling you the one thing that actually matters: who can read your data, and under what circumstances.

This page is an attempt to answer that directly, including the parts that are less flattering. You are being asked to store messages for your children and details of your accounts in somebody else's system. That is a significant thing to ask, and it deserves a precise answer rather than a comforting one.

What is encrypted

The sensitive parts of what you store are encrypted before they reach the database or file storage. That covers the content of your memories, including their titles and notes, the notes attached to a loved one, uploaded media files, and email addresses.

Encryption happens at the API layer, which is a deliberate choice. It means the protection applies to the data on its way in, regardless of which part of the application it came from, rather than being a setting on the database that could be misconfigured or a feature of one particular code path that another path forgets to use.

The algorithm is AES-256-GCM. The AES-256 part is a standard, widely reviewed cipher. The GCM part matters more than people usually credit: it is an authenticated mode, which means it does not only keep the content confidential, it also detects tampering. If stored data is altered, decryption fails loudly rather than quietly returning something plausible but wrong. For a system whose entire purpose is delivering an accurate final message, failing loudly is the correct behaviour.

What that protects you against

The primary threat this addresses is exposure of data at rest.

If a database backup leaked, or somebody obtained the stored files directly from the storage bucket, the sensitive content would not be readable. They would hold ciphertext. This is not a hypothetical concern; leaked backups and misconfigured storage are among the most common ways data actually escapes from real services, and they are precisely the scenarios where encryption at rest earns its keep.

Access to delivered content is gated separately, and it is worth understanding as its own layer. Delivery links are token-based, and can be protected with a password. When a recipient unlocks a delivery, that unlock is scoped to specific media rather than granting general access, and it is short-lived. Decryption only happens after the access checks have already passed, so a failed check does not produce readable data anywhere in the process.

The practical effect is that possessing a delivery URL is not by itself sufficient to read somebody's messages, and a recipient who was given access to one delivery does not thereby gain access to anything else in the vault.

What it is not: end-to-end encryption

This is app-managed encryption, not end-to-end encryption. The difference matters enough that it belongs here in plain language rather than in a footnote.

End-to-end encryption would mean the key never leaves your device, and that nobody running the service could read your content even if they wanted to, were compelled to, or were compromised. That is not what is happening here. The application holds the key material, which means the running service is technically capable of decrypting your data.

That is a real trade-off, and it was made deliberately rather than by accident. The reason is the entire point of the product: content has to be delivered to a recipient who was never a user, who has no key, no app and no account, potentially many years from now, at a moment when you are not available to help. True end-to-end encryption makes that essentially impossible without handing your loved ones a key in advance and hoping that they still have it, still understand what it is, and have not lost it in three house moves and two phone upgrades.

Given that choice, an honest app-managed system that actually delivers seemed better than an end-to-end system that quietly fails at the one job it exists to do. But you should know which one you are using, and you should be suspicious of anybody who claims to offer both. If a service tells you it is end-to-end encrypted and also that it can hand your data to somebody else after your death, one of those two claims is doing some work.

What this means in practice

It is worth being concrete about what the app-managed model does and does not imply.

It means your data is protected against the most likely failure modes: a leaked backup, stolen storage files, an attacker who gets at the database but not the running application. In those cases, what they hold is unreadable.

It also means that the security of your content depends on the security of the running service and the key it holds. That is a smaller set of assurances than end-to-end encryption offers, and it is the honest limit of the claim. Anybody with sufficient access to a running production system holding the key is, in principle, in a position to decrypt data. No amount of wording changes that.

What reduces that risk is not a promise but a structure: keeping the key separate from the data, limiting who can reach production, and being able to show exactly what the code does with the key. Which brings us to the part you can check yourself.

Why you can verify this rather than trust it

None of the above has to be taken on faith. The Community Edition is open source, and the encryption module, the delivery flow, and the access checks are all in code you can read.

That is the strongest guarantee available for a service that is not end-to-end encrypted. You cannot verify a promise. You can verify an implementation. You can read exactly what gets encrypted and when, confirm that decryption sits behind the access checks rather than in front of them, and see for yourself that the delivery unlock is scoped and time-limited rather than a general key to the vault.

If you would rather not rely on somebody else running that code correctly, you can run it yourself. Self-hosting changes the trade-off described above entirely, because then you hold the key material and the "running service" is your own machine. That is a real option, deliberately kept open, and it is the honest answer to anybody who reads this page and concludes that app-managed encryption is not enough for them.

Both answers are legitimate. What would not be legitimate is describing this as something stronger than it is, and then hoping nobody looks.