What protects your vault
You are considering putting a parent’s bank login into a website you had not heard of last week. These are the questions that deserve straight answers.
- Can you read my mother’s passwords?
- No. Every secret is encrypted in your browser before it is sent, with a key we never receive in usable form. Our servers hold ciphertext and a copy of that key wrapped by AWS KMS. We can prove we hold your data; we cannot show you what is in it.
- What can you read, then?
- The labels. The item title, the service name, the web address, the category, and who you have designated. So we can tell that you store a Chase account — we cannot tell you anything about it. If the existence of an account is itself sensitive, do not label it accurately.
- What happens if you get breached?
- An attacker with our database gets ciphertext and wrapped keys, not credentials. Unwrapping requires AWS KMS to authorise it for an authenticated session, which a stolen database does not provide.
- What happens if Relay disappears?
- You can export everything, decrypted in your browser, from your account page at any time — not on request, and not only if we are still around to answer. It asks for your authenticator code first, because the file it produces is unprotected once it leaves. Keep it the way you would keep a password list.
- What if someone gets to my computer while I am signed in?
- They can see your vault labels, and they cannot take permanent control of it. The three things that would outlast the session — exporting everything, issuing new recovery codes, and closing the account — each ask for your authenticator code again before they will run, and that permission lasts five minutes rather than the whole day. Signing out ends it immediately, everywhere, not just on that machine.
- Can someone trick you into opening my vault?
- Releasing requires the trigger you configured AND confirmation from the people you named. A real Relay message never asks you to click a link and then enter anything — codes are typed at our address, which you come to yourself — so a convincing email cannot, by itself, open anything.
- What if I lose my phone?
- You get recovery codes when you create the vault. One of them enrols a new authenticator. Losing the phone costs you your sign-in, not your data — but lose the codes too and nobody can let you in, including us.
One thing we will not claim. Relay is early-stage software, built and run by one person. The engineering above is real and you can inspect it, but a young product is a young product — please do not make this the only place something important is written down. Our terms say the same thing.
How it is built
For readers who want the mechanism rather than the reassurance.
- A release does not expire on its own
- Access opens when the conditions the owner set are met — including their check-ins stopping — and closes when they check in or stand it down. Nothing closes it automatically. If an owner never returns, what was opened stays open to the people they named, and what was never scoped to anybody stays shut. Relay does not offer estate or inheritance services and confers no legal authority on anyone; recipients are told so, once, before they see anything, and the acknowledgement is written to the owner’s audit log.
- Client-side envelope encryption
- A per-item AES-GCM-256 data key is generated in the browser via SubtleCrypto, used to encrypt the secret, then wrapped by an AWS KMS customer master key. The server stores ciphertext plus the wrapped key and never handles the plaintext data key.
- A release state machine, not a share button
- ARMED → PENDING → GRACE → RELEASED, with exactly seven permitted transitions. Each one is a compare-and-set against a strongly-consistent store, so an owner, a verifier and the scheduler acting at the same moment cannot double-release. Exhausting a retry always lands back in ARMED — the safe state is the default, not the exception.
- Reversibility as a property of the trigger
- Whether a release can be undone is derived from the trigger type rather than a flag someone could set wrongly. Every trigger an owner can choose is reversible: checking in closes access that has already opened. The one irreversible class, a permanent handover, is not offered.
- Hash-chained audit log
- Every access, grant and release is an append-only entry whose hash includes the previous entry’s. Editing history is detectable, and the chain is verifiable in your own browser rather than on our word. A failed audit write blocks the operation it was recording.
- Zero-knowledge boundary for the ranking
- The component that works out which credentials unlock the others reads labels only. It is structurally prevented from decrypting anything, so the analysis that makes the product useful cannot become the thing that exposes you.
- Aurora DSQL, active-active across regions
- The correctness invariant is owned by the database rather than reconstructed in application code, and the data survives the loss of a region.
Relay won Most Impactful at the H0 hackathon, judged on this architecture. The build is public and open to inspection.
Still deciding? The clearest way to judge it is to see what happens.