Show HN: Anonymous Dead Man's Switch(alcazarsec.com)
alcazarsec.com
Show HN: Anonymous Dead Man's Switch
https://alcazarsec.com/deadmanswitch
6 comments
Anonymous signup is a smart move, no PII means no breach surface. But for a dead man's switch specifically, anonymity creates an interesting tension.
You want the service to be able to verify you're actually gone (not just on vacation, not just changing phones, not incapacitated temporarily). But you don't want it to know what it's guarding or who you are. Those two goals pull in opposite directions. The more the service knows about you, the better it can distinguish "dead" from "busy." The less it knows, the safer your secrets are.
That's a genuinely hard protocol problem. Multi-party verification, tiered escalation, trusted contacts as oracles, ... there are approaches, but nobody's cracked it cleanly yet. The 12-word anonymous account is a solid starting primitive, though.
You want the service to be able to verify you're actually gone (not just on vacation, not just changing phones, not incapacitated temporarily). But you don't want it to know what it's guarding or who you are. Those two goals pull in opposite directions. The more the service knows about you, the better it can distinguish "dead" from "busy." The less it knows, the safer your secrets are.
That's a genuinely hard protocol problem. Multi-party verification, tiered escalation, trusted contacts as oracles, ... there are approaches, but nobody's cracked it cleanly yet. The 12-word anonymous account is a solid starting primitive, though.
“There are no solutions, only trade-offs” - Thomas Sowell
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
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
The multi-channel verification and tiered escalation are the way to go. that's the hard part on the trigger side.
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.
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.
Here we prioritize ease of use.
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 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.
Smart trade-off. The "two separate infrastructures" model is pragmatic — perfect security that nobody can use is no security at all.
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?
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?
Most users stick to plaintext. That's expected. Under typical threat models, convenience & ease of use outweigh perfect security.
I'm a fan of Mullvad and their approach to accounts, so I copied it. But instead of 16 digits (53 bits of entropy), we generate 12 random words from the Monero wordlist (128 bits) and derive the account identifier+"password" using libsodium.
The app is built on top of our existing Flare code and infrastructure. It uses SvelteKit, Shadcn, Tailwind CSS on the frontend, and FastAPI, SQLAlchemy, Celery on the backend. It’s hosted on Hetzner and uses Scaleway for sending email.
I’d appreciate any feedback (positive or negative) on the product. I’ll be in the comments responding to questions.
Website: https://alcazarsec.com/deadmanswitch
Signup (quick & anonymous): https://switch.alcazarsec.com/signup