How it works
You write one file. One command seals it. Three people each hold one printed share of the key. There is no account to create and nothing to configure.
How it works
estate.yaml --setup.sh--> estate.yaml.age + share1 / share2 / share3
(your Executor File) (2-of-3, printed on paper)
On death, the executor reads the printed Executor Instructions, collects shares from two of the three holders, and runs three commands: install, ssss-combine -t 2, age -d. No account, no company, no login, no script of ours. The two-page walkthrough — written for a non-technical person under stress — is templates/EXECUTOR-INSTRUCTIONS.md (scripts/make-guide.sh fills it from your register); Windows recovery has its own printed sheet. After decrypting, scripts/render.sh turns the register into a sorted, printable triage report — helpful, never required.
Your own way back in is simpler: the passphrase lives in your password manager, like every other credential you own. The shares exist so your executor can get in without you; they are not your access path. At review time you type the passphrase, not collect shares.
README.md at 4ac7b582-of-3, for humans
Think of the register as a map and the passphrase as the key to the box it is locked in. The key is cut into three pieces and three people you trust each keep one piece. Any two pieces remake the key; one piece alone is useless.
- Nobody could read the file while you were alive, because no one person holds a working key.
- Losing one share loses nothing. A holder can die, move away or lose the paper, and the file still opens.
- Your own way back in is simpler: the passphrase sits in your password manager, like every other credential you own. The shares exist for your executor, not for you.
Worried this sounds technical? The sealing is one command, and the opening is three, printed on the page your executor will hold. If you can copy and paste, both ends of this are within reach.
The threat model, in plain English
Below is the project's own threat table, pulled from the README at build time. Two lines of translation first:
- What it defends: a leaked copy of the encrypted file (useless without two shares), a nosy or compromised share holder (one share reveals nothing), credential theft through the register (no credentials are in it), and the project itself disappearing (recovery uses two standard tools that are not ours).
- What it does not defend: a compromised computer, two share holders acting together, or a lost passphrase with fewer than two shares. If you lose the passphrase and two of the three shares, the file stays sealed forever. That is not a flaw to apologise for; it is the design working. There is no back door to lose control of.
Threat model
| Threat | Mitigation |
|---|---|
| Someone opens the record while you’re alive | 2-of-3 Shamir split; no shareholder holds the whole passphrase (you hold it in your password manager, like every other credential) |
| One shareholder lost / unreachable / dies first | 2-of-3 tolerates one loss |
| The encrypted file leaks | age scrypt passphrase encryption; the file alone is useless without the passphrase |
| Credentials exposed via this file | None stored; the register only points at your password manager |
| A service shuts down and breaks access | There is no service — static binaries and a local file |
| Wrongful or early access | Shares are physical and held by trusted parties; access requires two humans agreeing |
| Shares that open nothing (passphrase typo at setup) | setup.sh reconstructs the passphrase from the just-issued shares and test-decrypts before reporting success |
| The record goes stale | Not solved by software alone — review.sh makes the update loop one command, reports which entries are stale before you edit, and emits calendar nudges; last_confirmed is required on every active entry (unknown is an honest answer); the executor report lists stale entries so the reader knows what to double-check |
| Shares rot while nobody looks | test-recovery.sh drills the real printed shares yearly and stamps the result on the printed guide; rotate-shares.sh re-keys when a holder or share is lost |
README.md at 4ac7b58The fuller version, including what is explicitly not defended, is on Why trust this.
Platform legacy tools come first
Apple, Google and Meta run their own legacy-access schemes, and in the US those settings outrank your will. Set them deliberately and record what you set in the register. The project README covers this in full:
Platform legacy tools come first
Under RUFADAA (the Revised Uniform Fiduciary Access to Digital Assets Act, enacted in nearly every US state), access to digital accounts follows a strict hierarchy: (1) the platform’s own online designation tool outranks (2) your will and estate documents, which outrank (3) the provider’s terms of service. A forgotten legacy-contact setting beats your will — so set these deliberately, keep them consistent with the will, and record them in the register:
| Platform | Tool | Where to set it |
|---|---|---|
| Apple | Legacy Contact | Settings > [your name] > Sign-In & Security > Legacy Contact. The contact later needs their access key + your death certificate at digital-legacy.apple.com. Keychain passwords and licensed media are not included. |
| Inactive Account Manager | myaccount.google.com/inactive. Timer-based (3–18 months of inactivity), up to 10 contacts, per-contact data selection. Also prevents Google’s 2-year inactive-account deletion from surprising your estate. | |
| Meta / Facebook | Legacy Contact | Settings > Memorialization settings — name a legacy contact (manages a memorialised profile; cannot read messages) or choose deletion on death. Instagram offers memorialisation only. |
In the UK there is no RUFADAA equivalent: executors have no statutory right of access, and each provider’s terms plus data-protection law govern — which makes the platform tools and this register more important, not less.
Example estate-document wording (not legal advice — take it to whoever drafts the will):
“I authorise my executor to access, manage, control, transfer, and dispose of my digital assets and digital accounts, and I expressly consent to the disclosure to my executor of the content of my electronic communications, to the fullest extent permitted by the Revised Uniform Fiduciary Access to Digital Assets Act or any similar applicable law.”
README.md at 4ac7b58When you're ready
The whole setup is about an hour at the computer, one command at a time, then a trip to the printer. Get started, or look at a sample Executor File first.