How the security works

Your documents are encrypted before they leave your device

When you add a birth certificate, the file is encrypted in your browser with AES-256-GCM. What travels over the network, and what sits in storage, is ciphertext. The server has no key and no way to obtain one.

The same applies to passport numbers, policy numbers and medical details. Those columns hold ciphertext, not text. A database dump leaks no identity numbers.

What is encrypted, and what is not

Encrypted on your device, so that we cannot read it and a stolen copy of the database cannot either: every uploaded file and its filename, every reference number, and what each health record says.

Not encrypted, and protected instead by the access rules described below: names and dates of birth, document titles and dates, money figures, school results, the calendar and chores. The app needs to sort, total and remind on these. Encrypting them is planned; until then this page will not claim it.

The key comes from a passphrase we never see

Your vault passphrase is stretched into a key using PBKDF2-SHA-512 with 600,000 rounds, entirely inside your browser. That key unwraps your private key, which unwraps the family vault key, which unwraps an individual document's key.

Four layers sounds like a lot. It buys three things: changing your passphrase re-wraps a few hundred bytes instead of re-encrypting every document; a single document can be shared with one person without handing over anything else; and revoking that person is a row deletion rather than a re-encryption.

Which is why we cannot reset it

There is no password-reset email for the vault passphrase, because there is no copy of your key on any server we control. That is the trade: real confidentiality means real responsibility.

So the vault issues a recovery key at setup: 160 bits of randomness, shown once, meant to be printed and kept with the physical documents it protects. It unwraps a second copy of the same private key.

Access is enforced in the database, not the interface

Every table has Row-Level Security policies. A child's session cannot read the will even if the app asks for it, because Postgres will not return the row. The worst a bug in the interface can do is hide something it should have shown.

Storage follows the same rules: the policies on the file bucket call the same functions the tables do, so there is one access model rather than two that drift apart.

An executor sees nothing until they should

A will can be assigned to a named executor today, with the condition that it only opens once a death certificate has been filed and verified. Until then the database does not return the grant at all, so the executor cannot read the document, and cannot even read the encrypted key that would open it.

The same mechanism handles releasing something to a child on their eighteenth birthday.

The log cannot be edited

Revealing a reference number, downloading a file, sharing a document, inviting somebody and changing a record are written to a log. No policy permits a signed-in person to edit or delete a line of it, not a parent and not the vault owner.

Two honest limits. Simply reading a list (titles, dates, amounts) is not logged line by line. And the log belongs to the family, so deleting the whole family would delete its log with it.

A child can be allowed to see a document without downloading it

Every document about a child or teenager carries a setting a parent controls: not visible, visible on screen, or visible and downloadable. New uploads start at visible on screen. The database applies the first choice, so a hidden document is not returned to that child at all, not even its title.

The difference between seeing and downloading is applied by the app, not by the server: to show a page the browser must receive the file. See-only removes the Download button and the save-as route and keeps the file out of the phone's storage. It cannot stop a photograph of the screen. We say so here rather than imply otherwise.

The browser is locked down too

A strict Content-Security-Policy with a per-request nonce means injected script cannot run, and background connections are limited to this site and its database. That makes stealing data much harder; it is a strong barrier, not a guarantee.

On the web the vault auto-locks after fifteen idle minutes and keys are held only in memory, never in local storage, never in a cookie. Closing the tab discards them. On Android it locks two minutes after you leave the app, and the screen cannot be captured.

If you switch on two-step verification, the database itself refuses your documents, health records and money to a session that has not entered the code, not just the sign-in page.