Security, with the limits written down

Record contents are encrypted in your browser with AES-256-GCM before they are stored. The vault key is wrapped by a passphrase and, separately, by a recovery key. Neither is sent to Heemnota. A release packet uses its own key, wrapped to the recipient or split across verifiers. The server stores those wrapped keys and the ciphertext. It does not have a master key that opens them.

What the server can still do

It can see account email addresses, plan, check-in dates, and who you named as a recipient or verifier. It can release a packet early or refuse to release it, because the schedule is enforced by the service. Without verifiers, a compromised database gives a recipient's wrapped packet to anyone who also has that recipient's private key. With a verifier threshold, the database alone is not enough: the shares are encrypted to the verifiers. A malicious operator could still delete data or ask verifiers to confirm early. Verifiers are the human check. They are not a time-lock the operator cannot influence.

What we will not recover

If you lose both the vault passphrase and the recovery key, the ledger cannot be decrypted. If a recipient loses their release private key, that packet cannot be decrypted. Support cannot reset either one. That is the cost of the server never holding the key.

What stays out of the vault

Do not store passwords, seed phrases, private keys for wallets, or authenticator backup codes. Heemnota is a map and a set of instructions. A copy that is released is information, not authority to take over an account.

Release attestations

Arming, cancelling, and releasing can leave a tamper-evident receipt. The chain, once the OpenTimestamps proof is upgraded, shows that a particular hash existed before a Bitcoin block. It does not show what was in the packet, who the people are, or that Heemnota waited the full grace period. The server chooses what hash to submit and could omit one. Treat the receipt as evidence of a commitment, and still read the rule numbers on the receipt yourself. Until a Bitcoin header confirms the merkle root, the proof only says a public calendar accepted the digest. Calendars are operated by other people. Verification instructions are on the verify page.

Hardening in the product

• Sign-in is a one-time email link, separate from the vault passphrase. An authenticator code can be required as a second step.
• Mutations require a same-origin request header. Session cookies are HttpOnly.
• Pages send a restrictive Content-Security-Policy. APIs are not cacheable.
• Request rates are limited. Security-relevant actions are written to an audit log that does not contain packet contents.
• You can export the ciphertext and metadata the service holds, and you can delete the account.

The design write-up, including the threat model, is in the project document encryption-design. The legal drafts are the privacy policy and terms. Both are marked for lawyer review and are not a claim that a review has already happened.