You can also add a friend or even yourself with another email address as the first contact to notify before it sends the final messages. This friend can ping you, and you can acknowledge before it notifies your other contacts.

I'm also publishing a hackernews daily digest.

This story was included in the March 9th issue (https://hn.alcazarsec.com/daily?date=2026-03-09).

  Hacker News users are currently developing a diverse range of projects, from a retro-inspired city builder game [0] and an award-winning daily word puzzle [4] to a European-based search engine alternative [2] and a NSFW filter for the Marginalia search engine [8]. Several developers are focusing on practical tools for family and personal life, including an educational site to help relatives identify AI-generated content [1], a "statphone" for emergency family alerts [3], and a local-first financial tracking app using double-entry accounting [6]. Others are experimenting with advanced technical implementations, such as using LLM agents to backtest stock trading strategies [5], "vibe-coding" CLI tools, and designing a new language for bare-metal embedded devices [7].

- Portable Secret (https://alcazarsec.github.io/portable-secret/) - self-contained HTML files that decrypt in the browser.

- Dead Man's Switch (https://alcazarsec.com/deadmanswitch) - sends messages when you stop checking in.

- Flare (https://alcazarsec.com/) - silent alert when your device is accessed without authorization.

I ask because I was recently thinking about how to preserve information for the future like this

This seems unlikely, however, since our infrastructure costs for the dead man's switch are covered by just a handful of subscriptions. Besides, we host it next to our other more profitable main product, so it gets free maintenance.

We are up for the challenge of making this last for many decades, though. It is a beautiful mission.

We spend ours on our laptops and assume others do too. But many people don't even own a laptop. They handle all their computing needs from their phones, using proprietary apps, with the data living in WhatsApp messages.

I have used rhash (https://github.com/rhash/RHash) before to do something similar - but with all the hashes for a directory stored in a single file (which I can diff against past or future versions).

Backing up private data and verifying it for corruption is crucial.

We would rather err on the side of not knowing about our customers. But it’s a choice that comes with consequences.

As you mentioned, we mitigate this with:

- Multi-channel verification: We send check-in links to multiple channels at once (email, Telegram, Signal). It’s unlikely you’ll miss all of them accidentally.

- Long escalation times: You can set the grace period up to 3 months - far longer than most vacations and longer than anyone we’ve met has been away from their phone.

- Tiered escalation: We keep sending check-ins until it’s time to alert your contacts.

- Trusted contacts: You can alert a friend earlier than family, and they can warn you that messages are about to go out.

Thank you for checking us out! If you’d like to discuss anything else or share more feedback, reach out: https://alcazarsec.com/contact

What I keep coming back to with anonymous services is the delivery experience. Once the switch fires, what does the recipient's journey actually look like? Especially if they're non-technical (which, statistically, they probably are).

There's an interesting tension between keeping the service zero-knowledge and making the output usable by someone who's never touched a terminal.

Curious how you're thinking about that side of it.

The only way to make a message-sending service truly zero-knowledge is to require contacts to upload a public key beforehand and encrypt every message with that key before storage in the database.

Unfortunately, this approach requires contacts to be technical people who understand encryption, keys, and key custody. When you die, you want to reach your family and friends—not only the tech-savvy ones.

So we encrypt messages at rest with a key stored separately from the database. This forces attackers to compromise two separate infrastructures (and before we notice and rotate the keys) to access any data. When sending the messages, we decrypt them in memory and deliver them in plaintext. That way, your parents don’t need a computer science degree to read your last message.

And if your threat model requires it, you can also use our Portable Secret to password-protect the documents. We provide both options.

The Portable Secret option is a nice touch for the paranoid-but-organized crowd. Do you find most users actually use it, or does the convenience of plaintext delivery win out?

I do two separate summaries: one for the story (sometimes impossible if paywalled) and one for the comments.

AMA about technical implementation.

It doesn't have a checksum, though, that seems like an improvement that's worth a few bytes.

The formalization interests me. Shame they shifted the UUID 2 bits right. Otherwise our implementations would be almost compatible (only the last 2 bits of the 26th character + the last 3 characters would differ). In my next clean codebase, I may use TypeID and append a 15-bit checksum.