Skip to content
Legacy Guard

Security and privacy

Even we cannot read your stories. Here is why that is literally true.

Your stories are scrambled in your own browser before they are saved. The key that unscrambles them is never stored anywhere in a usable form. This page explains how, what it protects against, what it does not, and how we run the service.

A brass key, a sealed envelope, and a handwritten letter resting on navy linen

Encryption, in plain language

Five pieces

  1. 1

    Your key

    The first time you protect your stories, your browser makes a random 256 bit content key. It never leaves your device in the clear. It is stored locked with a key derived from your stories password (600,000 rounds of PBKDF2 and a random salt). The password itself is never sent to the server.

  2. 2

    Item keys

    Every story, letter, Organizer entry, and digital asset entry gets its own random key, and every recipient has a key for your personal message. Each field and each 4 MB file chunk is encrypted with that key (AES-256-GCM, a fresh nonce every time, the item id and field name baked in so nothing can be moved between rows). Sharing an item hands the recipient that one key, never your content key.

  3. 3

    The escrow split

    A second copy of your content key is locked to a platform escrow key. The private half of that key does not exist anywhere in storage. It is split in two: one half lives only in the server environment, the other only in the database. Either half alone is a random number that says nothing about the other.

  4. 4

    The two moments

    The server combines the halves in memory in exactly two moments: a release after two verifiers approve a passing, and a stories password reset you asked for. Then it forgets them. One file in the code can do this, and the verify script checks that nothing else imports the pieces.

  5. 5

    The audit trail

    Both moments are written to an append-only key audit table. Every step of a verification lands in an append-only release audit. Every settings change lands in a settings audit. Nobody can edit or delete a row in any of them.

What a database leak could reveal

  • The Plan side: reviews, assets, documents, the vault, the emergency card. Your firm already works on this with you; it was never private from the firm.
  • Story metadata: how many stories you have, of what kind, when, how long, how large, which prompt they answered, recipient names and contact details, and delivery choices.
  • Scrambled story content and locked keys, which are useless without your stories password. One escrow half is there; the other is not.

What it could not reveal

  • Any story's words
  • Any voice or video recording
  • Any photo or caption
  • Any letter
  • Any personal message to a recipient
  • Any Legacy Organizer or digital asset text
  • For anyone

Verified release

Nothing is delivered by a timer, by silence, or by any one person

A passing can be reported by family through the emergency card, by an authorized contact, by the firm, or by calling Legacy Guard. The moment a report opens, the person it is about is emailed a one tap halt link, their authorized contacts are told, the firm is asked to attest, every verifier is alerted, and the waiting period starts. Any sign in by the person halts it automatically.

Verifier one confirms the reporter by phone or video, confirms the relationship, confirms the passing by a second independent source, checks the death certificate, and records the firm's attestation. After the waiting period passes with no sign of life, a different verifier reviews every item again and approves by typing the person's last name. The database refuses one person approving alone, refuses the reporter as a verifier, and refuses any approval that skips the checklist.

Retention and deletion

  • Recipients: two years from release. A warning at month 20, monthly reminders at 21, 22, and 23, a last day notice at 24. The stories themselves are not deleted then; the household still owns them.
  • Kept mode: when Complete ends, everything saved stays readable, exportable, and deliverable for two years. Then twelve monthly notices naming a deletion date at 36 months, unless you reactivate, buy the 20 year hold, or export.
  • A trial that was never paid: stories readable and exportable for 90 days, then the Stories side is deleted. Nothing is ever delivered from it. The Plan side is untouched.
  • Deleting your account: a 30 day undo window with an emailed link. Only the person who asked is removed; the household and the spouse stay.
  • Recently deleted: 30 days, with Restore.
  • Never while a verification is open: no retention clock runs and nothing is deleted while a report about the household is being verified.

The honest limits

What this does not protect against

  • Both places at once. Someone who controlled the server environment and the database at the same moment, or who could change the server code, could read a key during one of the two moments. That is why the release needs two people first and why the key audit exists.
  • Your own device. Stories are decrypted on your device to be shown. Malware there sees what you see.
  • A weak stories password. 600,000 rounds slow down guessing but do not make a short password safe. The app requires at least 8 characters; choose more.
  • Metadata. How many stories, when, how long, what kind, and recipient names and contact details are visible.
  • A recipient. Once a story is shared or released to someone, that person can keep it.

How we run it

Commitments

  • Daily database backups and point in time recovery, so the database can be restored to any minute rather than to last night.
  • A nightly mirror of every file bucket to a second provider in a different company's hands. The objects are already encrypted, so the mirror holds no readable story.
  • Regular encrypted database exports to that second place, with a key held by the owners, so one account problem never means the data and its only backup are in one place.
  • The server half of the escrow key held in two sealed places outside the server, with a written record of who holds what.
  • Restore drills: restore to a scratch environment, sign in as a test client, open a story, write down how long it took and what broke.
  • An outside security review of the escrow setup, the release path, and the row rules, with the reviewer given the design documents, the migrations, and the crypto code.
  • Automated checks on every release that sign in as both spouses, a firm attorney, a paralegal, and the platform and prove each one sees only what this page says, including that a story saved through the real app is ciphertext at rest.

At a glance

Who can see what

Hover or tap a column.

Who can see what
Who can see each kind of information in Legacy Guard
Information
Plan documentsYour household and your firm share the Plan side.
Review answersEach spouse's answers are private from the other. The firm sees both.
Stories and lettersEncrypted on your device. Recipients get only what you chose, when you chose.
Who your recipients areEach recipient sees their own message, never the list.
Contact info and plan typeLegacy Guard sees contact details, plan type, dates, and your attorney.
Story totalsLegacy Guard sees four platform-wide totals, never a number per person.
  • Can see
  • Cannot see
  • Encrypted, cannot read
  • Only what was chosen or shared

Questions about security?

The FAQ has a section on it, and we answer email.

Security questionsContact us

Our privacy page states these commitments as policy.