Threat model.
What SilentBeat defends against, and what it doesn't.
The claim in one paragraph.
The payload key is split into two halves. Our server holds one half. The other half is generated in your recipient's browser at enrollment, AES-wrapped under a key that only their passkey + WebAuthn PRF can re-derive, and stored on our server in that wrapped form. We never see the unwrapped half. Neither half decrypts alone. At expiry we email our half to your recipient; their browser unwraps the second half with a passkey tap, combines locally, and decrypts the message. SilentBeat — the company, the operator, the database — cannot read your message at any point.
Actors and what we defend against.
| actor | defended | residual risk |
|---|---|---|
| curious operator (us reading the database) | Cannot decrypt your payload (no recipient share). Cannot read your recipient's email plaintext (KMS-wrapped DEK; access is logged). Cannot tell defuse from duress hash. | We can observe metadata: switch existence, expiry times, check-in cadence, recipient domain via outbound mail logs. |
| compelled operator (subpoena, NSL, court order) | Crypto holds: server share alone doesn't decrypt. Audit log is signed; suppression leaves a gap detectable by mirrored copies. | A court can compel us to email the recipient with our key share + ciphertext. Combined with a compromised recipient, that decrypts. Sealed gag orders prevent us from publishing certain entries. |
| network attacker (TLS in flight) | TLS 1.3 + HSTS. Payloads encrypted client-side before upload. Share B encrypted to recipient pubkey. | Traffic analysis: timing of check-ins, presence of an account. |
| malicious recipient | Cannot decrypt without server our half. Cannot force timer expiry. | Can wait. Can lie about losing recipient half to coerce you into early disclosure. Can publish the payload after release — we have no DRM. |
| malicious user (using SilentBeat to threaten release) | Recipient knows they were enrolled. Recipient can refuse / discard recipient half = preempt release. | We cannot prevent this product being used as a coercion tool. ToS forbids it. Abuse reports terminate accounts. |
| coercer with the user (forcing defuse) | Duress PIN purges the payload + sends bare-keys email so recipient sees something happened. | A sophisticated coercer who knows duress PINs exist will demand evidence of which PIN was entered. Duress only protects against unsophisticated coercion. |
| lost device / lost PIN | 72h / 24h / 1h escalating warnings. Two-window grace. Recovery codes at signup. Magic-link + PIN fallback for lost passkey. | Genuine memory loss or hospitalization mid-window will fire the switch. By design — that's what the switch is for. |
| user clears browser before finalize (legacy invite-by-email flow only) | None — recipient half lives only in this browser between create and finalize. | Only applies when you target a brand-new recipient by email. If you target a pre-enrolled recipient, the switch arms immediately and there is no finalize step. |
| recipient loses their device / passkey | If their passkey was synced to a backup (iCloud Keychain, Google Password Manager) it survives device loss. New device, same Apple/Google account → the passkey is there. | If the passkey was created without sync (a non-syncing security key, or a device whose cloud sync was off) and the device is lost, the message is unrecoverable. We tell recipients to enroll on a synced device. |
What happens if Cloudflare goes down.
SilentBeat runs entirely on Cloudflare — Workers, Durable Objects, D1, R2. A region-wide Cloudflare outage at expiry time means your timer fires late or not at all. We do not run a hot standby on a second cloud. The Durable Object holding your timer's setAlarm() resumes at the next available moment; the cron sweeper catches anything missed within ~5 minutes of recovery. For most use cases this is fine. For a use case where minute-precision matters at the edge of a multi-hour outage, SilentBeat is the wrong tool.
What happens if we're compelled.
SilentBeat is operated by a Pennsylvania entity in Philadelphia, USA, and is subject to US federal and state law. We will respond to lawful subpoenas and warrants. If we are compelled to disclose the encrypted blob and our key share for a specific switch, we will do so — and disclose the request publicly to the extent the order permits. National Security Letters with gag orders are the exception: we cannot publish those individually, but we maintain a warrant canary on the public site that is removed if we receive one. We publish a quarterly transparency report aggregating all legal requests received and complied with.
What you are trusting us with.
That we ran the code we say we ran. The crypto only protects you if our server actually behaves the way this document describes. To make that auditable: every switch creation, check-in, defuse, release, and duress event is written to a signed, append-only public log. The log entries are signed with an Ed25519 key whose public counterpart is published. Anyone can mirror the log and verify the chain. If we omit entries, mirrors will detect the gap.
This is not the same as cryptographic certainty. A determined operator could rewrite history before signatures were widely mirrored. To narrow that window, we publish a fresh signed checkpoint of the log root every minute, and we will publish the root to a public timestamping service (planned). Read the public log and form your own opinion.
Last revised: 2026-05-05. The threat model is a living document. Material changes are committed to the public log under policy_revision events, with a diff link.