If you go silent,
someone gets the
message.
SilentBeat is a dead man's switch. You set a timer, an encrypted payload, and a recipient. If you don't check in before the timer ends, the payload is released. That's it.
How it works.
The payload key is split in two. We hold one half. Your recipient's browser generates the other and we never see it unwrapped. Neither half decrypts alone.
-
01
You write. Your browser AES-256-GCM-encrypts the payload before anything leaves the page. The data key is split: half A goes to us in the clear; half B is AES-wrapped under a key derived from your recipient's WebAuthn passkey + PRF and stored on our server in that wrapped form. We never see half B unwrapped.
-
02
You check in. A Durable Object holds your timer with setAlarm(). Each check-in pushes the deadline back. A 5-minute cron sweeper catches anything the DO ever misses.
-
03
If you stop, it ships. At the deadline, we email half A to your recipient along with a link to fetch the ciphertext. Every release is appended to a signed, public audit log.
-
04
Recipient decrypts in-browser. They fetch the wrapped half B, tap their passkey to unwrap it locally, combine with half A, and decrypt the message. SilentBeat — the company, the operator, the database — cannot do this for them.
The full enumeration of what we defend against and what we don't is in the threat model.
What the server can do
Hold an encrypted blob. Hold half of the key. Release that half to your recipient when your timer expires. it cannot decrypt alone
What it can't do
Decrypt your payload. Read your recipient's email in plaintext. Survive a Cloudflare-wide outage. Protect you from a recipient who can be coerced.
What you trust us with
Running the timer honestly. Publishing every release in our public log. Telling you when we're compelled by court order, to the extent we legally can.