Security
End-to-end encrypted, blind by design
Your calendar is encrypted on your device before it’s ever sent. The server that syncs it stores and relays opaque ciphertext and never holds a key — so it cannot read an event title, a person’s name, or who is in your family.
- One recovery phrase 24 BIP39 words derives your master key
- Master key encrypts your keystore the list of spaces you belong to
- Group key encrypts one space's documents every event, encrypted
Stores & relays encrypted blobs. Fans out live updates. Cannot decrypt anything.
Why it’s secure
-
End-to-end encrypted
Encryption and decryption happen only on your devices. Plaintext never leaves the device.
-
The server is blind
It's untrusted infrastructure by design: it stores and relays ciphertext and never holds a key. Compromising the server leaks nothing readable.
-
No accounts, nothing to breach
No email, no password, no profile. There's no user database to leak — just anonymous encrypted blobs keyed by hashes.
-
Open source
The apps, the encryption core, and the server are all public. Inspect the crypto or self-host the server — you don't have to take our word for it.
-
Standard, modern crypto
libsodium primitives (XChaCha20-Poly1305, BLAKE2b) and BIP39 phrases. No custom cryptography.
-
Works offline
A PWA with a local encrypted cache — it works without a connection and syncs when it's back.
The encryption, specifically
Everything is built on libsodium via its audited bindings — no home-rolled cryptography.
| Concern | Primitive | Notes |
|---|---|---|
| Symmetric encryption | XChaCha20-Poly1305 | libsodium authenticated encryption (AEAD), fresh 24-byte random nonce per message |
| Key derivation / hashing | BLAKE2b | derives sub-keys and the group / keystore identifiers from keys |
| Recovery phrase | BIP39 (24 words) | encodes a 32-byte master key you can write down |
| Keys / randomness | OS CSPRNG | 32-byte keys from libsodium randombytes |
The chain of keys
- Master key — 32 random bytes; your 24-word phrase is that key in BIP39 form.
- Keystore — your list of spaces, encrypted with the master key and stored as one opaque blob, addressed by a hash of the master key. The server holds it but can't decrypt it.
- Group key — encrypts one space's documents. Its server address is a hash of the key and reveals nothing about it.
- Documents — every event is
XChaCha20-Poly1305(group key, JSON)with a fresh nonce. The server sees ciphertext, a version number, and a change counter — never plaintext.
Private entries are unreadable, not hidden
Mark an event or task private and it isn’t filtered out of other people’s screens — it’s encrypted under a separate key derived from exactly the people it’s for. Everyone else in the family holds a document they genuinely cannot open, including whoever administers the family.
Two things follow from deriving the key from the audience rather than storing it. Changing who an entry is for moves it to the right key instead of editing one, so there is no revocation step to get wrong. And the key’s name says nothing: spelling the people out would announce in plain text that two parents have something private about a particular child, which is sharper than the leak already accepted — that private entries exist at all.
Limitations & honest caveats
Credibility matters more than marketing, so here's the honest list. None of this is unique to Family Manager — it's the shape of any serious end-to-end encrypted, account-free tool.
-
Your recovery phrase is the single secret
There's no password and no second factor. Anyone who obtains your 24 words can read and change everything in every space you're in — like a password manager's master secret or a crypto wallet seed. The phrase encodes the key directly, so treat the words like a house key.
-
Lose the phrase, lose the data — there is no reset
Because we hold no keys and no account, we cannot recover or reset anything. If every device is lost and the phrase isn't written down, the data is gone.
-
Sharing a space shares its whole history
Handing someone a group key gives them everything in that space, back to the beginning. Removing them rotates the key and re-shares it to everyone who remains, so they see nothing added afterwards — but what they already read cannot be clawed back. Removal cuts off the future, not the past. Share only with people you trust.
-
Roles are enforced by the app, not the server
Who may edit versus only read is advisory: it lives in an encrypted member record and the app honours it. The server can't check it, because the server can't read it. What the server does enforce cryptographically is ownership — who may destroy a space, rotate its key or remove a member.
-
The server sees metadata
It never sees your data, but it does handle opaque random-looking identifiers, the size and timing of encrypted blobs, and connection metadata such as your IP address. It cannot see contents, names, or who is in a space.
-
A space address is a bearer capability
Anyone who learns a space's identifier can fetch its ciphertext (still undecryptable without the key). Keep invite links and QR codes private.
-
No forward secrecy
Group keys are long-lived and only rotate when someone is removed; the model is encrypted document storage, not a messaging ratchet. Appropriate for a personal/family suite, but worth stating.
-
Emailed invites are not encrypted
A calendar invite is an email: the recipient holds no key, so it is plaintext, and it sits briefly in the server’s outbox on the way out. It is the only feature in the suite that crosses the end-to-end boundary. It is off until a family switches it on, off for every person without an address, and off entirely on a server with no relay configured.
-
Reminders tell the server when to wake you
A web app has no reliable background timer, so the schedule has to live on the server. It learns when a device wants waking and for which space — never what for, since the reminder’s id is opaque and minted on your device. The wake-up itself carries no content at all. Timing is real metadata and the minimum price of reminders that arrive.
-
Times are local, not converted
A start is stored as a wall-clock time with no timezone, the way a paper calendar works: 3pm pickup is 3pm wherever you read it, and an all-day event can never land on the wrong day. The cost is that a family genuinely split across timezones sees local times rather than converted ones.
Threat model in one line. The server is untrusted infrastructure — compromising it leaks nothing readable. Compromising your recovery phrase exposes every space it's in. Same trade-off as a password manager, appropriate for a personal/family suite.
Read it, then trust it
The apps, the encryption core, and the server are all open source — inspect exactly how this works, or run your own server.