Security Specs
We don't ask you to trust our words. We ask you to verify our architecture.
Last updated: March 2026
Encryption Architecture
AES-256-GCM: Application-Level Encryption
VerifiedEvery message stored in the Afterword vault is encrypted at the application layer before it reaches storage. We use AES-256-GCM: the same authenticated encryption standard used by governments and financial institutions.
GCM mode provides both confidentiality and integrity verification. Each encryption operation generates a unique 96-bit initialization vector (IV) and a 128-bit authentication tag, ensuring that even identical plaintext produces different ciphertext and that any tampering is immediately detected.
Algorithm: AES-256-GCM (Galois/Counter Mode) IV Length: 12 bytes (96-bit), cryptographically random per operation Auth Tag: 128-bit GCM authentication tag Key Source: VAULT_ENCRYPTION_KEY (256-bit, hex-encoded) Output: iv:authTag:ciphertext (hex-encoded, colon-delimited)
S3 Server-Side Encryption (SSE-S3)
VerifiedIn addition to our application-level encryption, all objects stored on Exoscale SOS are encrypted at rest using S3 Server-Side Encryption (SSE-S3). This means your data has two independent layers of encryption: our AES-256-GCM cipher, wrapped in Exoscale's storage-level AES-256.
Provider: Exoscale SOS (S3-compatible) Encryption: ServerSideEncryption: 'AES256' Scope: All message blobs (*.json.enc)
Key Management: Honest Disclosure
Transparency note: The current encryption key (VAULT_ENCRYPTION_KEY) is a server-managed secret stored in our deployment environment (Vercel). This means Afterword's infrastructure can technically decrypt vault contents.
This is encryption at rest with operator-managed keys: the same model used by most cloud storage providers. It protects against database breaches, stolen disks, and unauthorized infrastructure access. It does not constitute true end-to-end (E2E) zero-knowledge encryption, where only the user holds the decryption key.
Our commitment: We are working toward client-side key derivation, where encryption keys are derived from user credentials and never stored on our servers. Until then, our operational security controls ensure that no team member can access vault contents without a documented, auditable reason.
Swiss Data Sovereignty
Storage Provider: Exoscale SOS
VerifiedAll user-generated content: text messages, voice recordings, video notes, and file attachments: is stored on Exoscale Simple Object Storage in the ch-dk-2 datacenter (Zurich, Switzerland). Exoscale is a European cloud provider headquartered in Switzerland.
Your vault data physically resides on Swiss soil and is subject exclusively to Swiss federal data protection law (FADP/DSG): one of the strictest privacy regimes in the world.
Provider: Exoscale (Swiss-based, part of A1 Digital) Service: Simple Object Storage (SOS): S3-compatible Region: ch-dk-2 (Zurich, Switzerland) Endpoint: sos-ch-dk-2.exo.io Bucket: afterword-vault-storage
Metadata Layer: Supabase (EU-Hosted)
VerifiedAccount metadata (email addresses, recipient identifiers, protocol configuration) is stored in a Supabase PostgreSQL database hosted in the EU (Frankfurt). Message content is not stored in this database: it lives exclusively on Exoscale SOS in Switzerland.
This separation ensures that even if the metadata layer were compromised, the attacker would obtain only encrypted references: not the actual vault contents.
Provider: Supabase (PostgreSQL) Hosting: EU region (Frankfurt) Data stored: Account metadata, recipient identifiers, protocol settings NOT stored: Message content (moved to Exoscale SOS)
File Path Structure
VerifiedFiles are organized in a deterministic hierarchy for forensic clarity and clean deletion:
vault/
└── {userId}/
└── recipients/
└── recipient_{recipientId}/
├── message.json.enc ← encrypted message blob
├── voice_notes/ ← audio recordings
├── video_notes/ ← video recordings
└── attachments/ ← uploaded filesAccess Control
Row-Level Security (RLS): Closed by Default
VerifiedAfterword's database enforces Row-Level Security (RLS) with a closed-by-default posture. There are no public-facing database policies. All data operations pass through authenticated server-side API routes using the Supabase Service Role.
This means that even if an attacker discovered the database endpoint, they could not read, write, or modify any records without the service role credentials: which are never exposed to the client.
Policy: ENABLE ROW LEVEL SECURITY Default: ALL operations DENIED Public: No INSERT, SELECT, UPDATE, or DELETE policies Access: Service Role only (server-side, admin-level)
Authentication: Supabase Auth
VerifiedUser identity is managed through Supabase Auth with support for:
- →Magic Links: passwordless email-based login
- →OTP (One-Time Password): 6-digit codes for session verification
- →Google OAuth: federated identity via Google
- →JWT sessions: short-lived, scoped to the authenticated domain
Presigned URL Access Control
VerifiedMedia files (audio, video, images) are never served directly. Access requires a two-step authenticated flow:
- 01Client sends an authenticated request to the API with their JWT
- 02API generates a presigned URL valid for 60 seconds
- 03Client fetches the media directly from Exoscale using the short-lived URL
After 60 seconds, the URL expires and cannot be reused or shared.
Data Lifecycle
The Bridge: 17-Day Escalation Protocol
VerifiedWhen a Pulse Check is missed, a 17-day escalating countdown begins. During this period, multiple warnings are sent to the vault owner. If unresolved, the vault breaches and the designated Keyholder is contacted to verify the owner's status.
If the owner does not respond and the Keyholder confirms their passing, the platform triggers the automated release of vault contents to designated recipients. This duration ensures a balance between urgency and preventing false alarms.
The 45-Day Post-Release Protocol
VerifiedAfter a successful vault release, recipients have exactly 15 days to access the delivered content. After this window closes, access is aggressively revoked. 30 days later, Afterword permanently and irrecoverably erases all associated data from both Exoscale SOS and the metadata database. Unclaimed vaults are auto-shredded after 12 months.
This is not a soft delete. The data is destroyed: no backups are retained, no recovery is possible. This ensures that your legacy exists only for its intended recipients, for the intended duration.
Profile Snapshots: Forensic Audit Trail
VerifiedBefore any critical operation (sync, recovery, account modification), the system captures a point-in-time snapshot of the user profile. A rolling window of up to 50 snapshots is maintained per user, balancing forensic utility with storage efficiency.
These snapshots provide an audit trail that can be used to detect unauthorized modifications or to assist in account recovery scenarios.
What We Can and Cannot See
We will never use your data for advertising, analytics profiling, machine learning training, or any purpose beyond delivering your legacy to your designated recipients.
What's Next
Security is not a destination. It's a discipline. Here's what we're working toward:
Client-Side E2E Encryption
Planned: Client-side key derivation from user credentials, so the server never holds decryption keys.
Third-Party Security Audit
Independent penetration testing and code review by a certified Swiss security firm.
SOC 2 Type II
Formal compliance certification for enterprise-grade trust and audit readiness.
Bug Bounty Program
Responsible disclosure program inviting the security community to help strengthen our defenses.