How Postscrypt holds secrets you still control.

Overview

Postscrypt is a vault for encrypted messages and files, combined with a check-in (“heartbeat”) workflow that can authorize delivery to people you name when you stop responding under rules you define. The product goal is continuity without daily password sharing: you pre-compose, pre-encrypt, and pre-authorize release.

Threat model

We design around a few grounded scenarios: loss of access while traveling, sudden incapacity, coercion or device compromise, and inheritance of digital access without custodial key recovery. The app assumes the user is the ultimate authority over who receives material and when silence counts as intent to release.

Postscrypt does not try to solve every adversary. It reduces single-point failure for pre-authorized, encrypted instructions when you cannot complete check-ins.

Cryptography & zero-knowledge posture

Vault content is protected with strong, industry-standard encryption. As described in our security page, we do not have human-readable access to vault plaintext; automated systems operate storage and delivery only. You should treat “zero-knowledge” in the practical sense: we cannot read your vault content, and keys are handled so that routine operations do not expose plaintext to staff.

• Client-side intent. Composition and encryption happen in your environment; the server stores ciphertext and enforces account rules.
• Verify and export. Skeptics should use in-app flows (where available) to inspect ciphertext handling and backup discipline—pair with your own device hygiene.

Heartbeat & release

Check-ins prove liveness on a cadence you choose. If check-ins lapse past thresholds you set, the service can progress a release workflow to recipients you defined ahead of time. Timing, escalation, and notifications are product-controlled; the important trust claim is that release is gated on your policy, not on ad-hoc access by operators.

Heartbeat proves activity—not moral intent, not freedom from coercion, and not perfect security on a compromised device. Pair the feature with your own operational security.

Metadata & logging

Some metadata necessarily exists to run accounts: authentication identifiers, device and app version signals, notification tokens, and operational logs for reliability and abuse prevention. Our privacy policy lists categories at a high level. We minimize what we collect and retain, and we do not use vault content to train models or for advertising.

Legal process

We maintain a warrant canary as a transparency signal. It states, in plain language, whether we have received certain classes of compelled requests. It does not replace counsel, and it cannot disclose requests we are legally barred from mentioning—hence the narrow, structured wording on the canary page.

Persona lenses

The same vault behaves differently in how you explain it. We publish focused landing paths for travel, crypto access planning, high-risk roles, and family continuity. Threat emphasis changes; the cryptographic posture does not.