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 and rotates it on every check-in. The other half is generated in your recipient's browser at enrollment and never touches our server in plaintext. Neither half decrypts alone. At expiry we email our half to your recipient; they combine it with their half locally. 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 | None — recipient half lives only in this browser between create and finalize. | Switch is unrecoverable and must be destroyed. Documented on the create and finalize pages. Window is short (typically minutes-to-hours, until the recipient enrolls). |
| recipient lost their half of the key | None — payload is unrecoverable. | This is the price of true split-key. Documented prominently at recipient enrollment. |
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.