Introduction

Most privacy guides assume you are either alone with your secrets or you trust a corporation with them. This guide is built on a third option — and it changes everything.

Self-custody, third-party custody, and the option nobody talks about

When it comes to managing digital secrets, most people end up in one of two places.

The first is self-custody — you hold your own passwords, keys, and sensitive information, and nobody else has access. This is the gold standard for sovereignty. It is also, for most people, practically unachievable. One forgotten master password, one house fire, one stroke, and everything is gone. The burden is real and the failure modes are catastrophic.

The second is third-party custody — you hand your secrets to a corporation. A password manager in the cloud. A service that promises to store your digital estate. A platform you hope will still exist when your family needs it. This is convenient. It is also a fundamental betrayal of the thing you were trying to protect.

The Bitcoin protocol has been wrestling with exactly this tension, and the most elegant answer to emerge is a concept called second-party custody — pioneered by the Fedimint protocol. The insight is simple: between the corporation and the individual, there is a third option. People you actually know. People you can look in the eye. People who are embedded in your life and cannot disappear with your keys without consequence. Not a bank. Not a platform. A circle of trust — people who will notice if something goes wrong, and who have something to lose if they betray it.

This guide applies that insight to personal secrets management in its broadest sense — passwords, encryption keys, private documents, digital accounts, and the problem that almost nobody has solved: what happens to all of it when the bus hits you.

Who this is for

This guide is for everyone in the sense that everyone deserves control over their digital life. It is technical in the sense that some of what it describes requires a technical person to implement. That tension is resolved by the second-party model itself.

If you are reading this, you are probably the technical person. The computer wiz, as your grandmother would say. This guide is not just for you to help yourself — it is a tool for helping the people you care about. In some cases that means walking them through a process. In most cases it means acting as a trusted custodian of their digital privacy and security. The guide is written for that relationship.

If you are the non-technical person without a technical friend at hand, you can still use this guide. In the age of language models, a surrogate computer wiz is available to anyone. Paste the URL of this guide into an LLM and start asking questions. This is not the ideal arrangement — a human being who knows you and your family is always preferable — but it is a real starting point. The guide functions as a stable source of truth that you or a future technical person can return to and reason from.

The guide is also for people with genuinely high stakes — journalists, activists, people operating under repressive conditions. The protocol it describes is not designed specifically for them, but it scales in that direction. If that is you, read the manual first and then seek additional specialist guidance — this guide is a foundation, not a ceiling.

What this guide is not

It is not a corporate security awareness training programme. You know the kind — soul-destroying slide decks designed to generate compliance rather than understanding. This is the opposite of that.

It is not a James Bond manual. The romantic idea of the self-sovereign individual — fully independent, trusting no one, cloak-and-dagger techniques to outsmart every adversary — is both naive and dangerous. We are interdependent creatures. Trust is not a vulnerability. It is the foundation of every functioning society. The reason this guide exists is not that trust is bad. It is that sh!t happens, we make mistakes, and sometimes some people try to steal from us. We build systems that account for those people without pretending everyone is one of them.

If you currently have a cloak-and-dagger system, ask yourself one question: what happens when you have a stroke and lose half your memories? What happens when you are in hospital for a month and cannot maintain it? A system that only works while you are present, alert, and alive is not a system. It is a single point of failure.

It is not a learning resource. If you want to understand the tools and concepts in this space, Privacy Guides is excellent. Tools in this guide are not explained from first principles — the reference section points outward to better explanations than this guide could provide. The exception is where no good external explanation exists.

What this guide is

A highly opinionated, step-by-step implementation playbook for managing secrets within a circle of trust — typically a family and group of friends.

Opinionated not because this is the only way, or even the best way, but to relieve the burden of choice. The single greatest barrier to personal secrets management is not technical complexity. It is the overwhelming number of options. This guide removes that burden by making the decisions for you. The protocol described here is good enough for most people. It has been chosen for resilience, simplicity, and longevity — not for elegance or technical sophistication.

The guide is designed to solve for three failure modes: attack — someone actively trying to access your secrets, including under duress — where you are physically present and under pressure to hand over access; mistakes — human error in using or managing them; and loss — secrets becoming inaccessible because of death, incapacity, or forgotten credentials.

A protocol designed only for remote attacks is incomplete. The moment someone can compel you in person — a robbery, a border crossing, a coercive authority — the technical sophistication of your system becomes irrelevant unless the protocol has accounted for that scenario from the start.

Throughout, the emphasis is on the why as much as the how. A protocol you understand is a protocol you will maintain. A protocol you follow blindly is a protocol that will decay.

The rituals are the protocol

Most security guides treat the technical layer as the whole system. This guide takes the human layer equally seriously — and that means being concrete about what maintaining it requires.

The tools — the password managers, the encrypted vaults, the secret sharing schemes — are scaffolding. The load-bearing structure is human. It is the annual review where everyone checks in. It is the named person whose job it is to notice when something has changed. It is the simple habit that proves the system is still alive.

A circle of trust with no maintenance ritual is just a very well-intentioned arrangement that will quietly decay until the moment it is needed, at which point it will fail. The rituals prevent that. They are not administrative overhead. They are the product.

The manual makes this concrete. But it is worth knowing from the start what kind of guide this is — one that takes the human layer as seriously as the technical one.

The circle of trust is not a security weakness. It is the security model.

Structure

This site is a structured field guide. It is not a wiki, not a traditional blog, and not a documentation site — though it borrows something from each. The website format is for easy navigation and cross-referencing, but it reads like a book — and like a book, it will demand your attention. It’s long because the problem deserves it.

It is built around three kinds of content that serve different reading modes.

The manual

The manual is for reading in order. Each page builds on the last. Start at the beginning if you want to understand the whole subject from the ground up, or navigate to a specific chapter if you already know what you need.

The manual is opinionated and linear by design. It makes choices so you don’t have to.

The reference section

The reference section is for looking things up. Entries are self-contained: a comparison table, a glossary definition, a template you can copy. Dip in when you need something specific; you do not need to have read the manual first.

Posts

Posts are where the thinking happens before it is ready for the manual. Notes, updates, things that don’t yet have a permanent home. Loosely structured, dated, filtered by tag.

Where to start

If you are new here, start with the manual:

• If you want context first, begin at the beginning.
• If you have a specific problem, use the reference section.
• If you want to follow along as this develops, subscribe via RSS or check the posts.

More

Visitor tracking

This site does not employ any kind of visitor tracking. No Google Analytics. No Umami. No cookies. This is deliberate.

Engagement as a number is not an important metric here. Engagement as a relationship is. If something in this guide helped you, or if something is wrong, or if you have built on it in some way — that is worth far more than a pageview. Get in touch.

How this site is built

Built with Hugo, a static site generator. No JavaScript frameworks, no tracking, no cookies. The source is plain Markdown files. See the License page for terms of use.

About the author

Written pseudonymously — not out of secrecy, but because the guide should stand on its own merits. If the ideas are sound, they are sound regardless of who wrote them. If they are flawed, they should be challenged on those grounds.

The author is the technical person in their circle. This guide is what they built for themselves, and then could not find a good reason to keep private.

AI transparency

AI plays three roles in this project:

Editor. The primary reason I write this manually is the pure joy of it. But English grammar is not my strongest suit, and AI has been a useful second pair of eyes for catching bad spelling, clumsy sentences, and awkward transitions.

Critic. I use AI-as-a-judge to cross-reference this work against well-established sources — a first-pass agent for punching holes in the security reasoning before humans do.

Developer. I’m a software engineer by day, but I don’t hand-craft infrastructure the way I used to. I used Claude to build the Hugo-based site that pulls content from the corresponding Obsidian notebook — a workflow I can highly recommend.