Our security posture is strongest where architecture removes trust entirely. Drop is designed so we cannot access file plaintext or keys, vault-enabled accounts derive secrets client-side with Argon2id, and Alias relies on a separate published forwarding stack built around transient routing, reply-tokenized responses, and optional PGP for delivered copies.
Drop is zero-knowledge. Alias has a different trust model centered on forwarding rather than mailbox hosting, with optional PGP for the delivered copy.
• Files are encrypted in your browser before upload
• AES-256-GCM encryption with unique keys per file
• Keys are embedded in the URL fragment (never sent to our servers)
• Even filenames are encrypted
• Recipients decrypt in their browser
• Aliases are disposable identities
• Mail is forwarded to your real inbox instead of stored in a hosted mailbox
• Optional PGP encryption for the delivered copy
• Reply-by-alias uses tokenized @reply.anon.li addresses
• Standard forwarding still requires transient server-side processing
• Your real email stays hidden
• Alias labels and notes are being migrated into vault-backed encryption as users unlock
• Optional TOTP-based 2FA for all accounts
• Works with any authenticator app
• Backup codes for account recovery
• Password-backed sign-in for vault-enabled accounts
• Magic-link verification and recovery
• Export all your account data (GDPR compliant)
• Permanent account deletion on request
• Removes all aliases, drops, and domains
• Live account data purged immediately on deletion
• Self-service from your dashboard settings
When you upload a file, your browser generates a random 256-bit AES key using the Web Crypto API. This key never leaves your device unless you share the link.
Your file is split into chunks and encrypted with AES-256-GCM. The filename is also encrypted. All encryption happens in your browser - we only receive encrypted data.
Encrypted chunks are uploaded to our storage. Without the key, this data is indistinguishable from random noise. We cannot decrypt it.
The encryption key is placed in the URL fragment (#). URL fragments are never sent to servers - they stay in the browser. Only people with the full link can decrypt.
When someone opens your link, their browser extracts the key from the URL fragment, downloads the encrypted data, and decrypts it locally.
Our architecture means there are things that are literally impossible for us, even if compelled.
Read your files
Files are encrypted with keys we don't have
See file names
Even filenames are encrypted
Read PGP-encrypted emails
Encrypted with your public key
Recover lost keys
No key escrow means no recovery
We classify every security claim by how it can be verified. Some are backed by published source across our app and mail repositories. A smaller set still depends on runtime infrastructure you must trust separately.
Zero-knowledge file sharing
This claim is supported by code or configuration in our published source repositories.
Last verified: April 5, 2026
Source reference: lib/crypto.client.ts
Caveats
Files encrypted in your browser before upload
This claim is supported by code or configuration in our published source repositories.
Last verified: April 5, 2026
Source reference: components/drop/file-uploader.tsx
Alias forwards mail instead of hosting mailbox storage
This claim depends on runtime configuration or the deployed service, not just the published source.
Last verified: April 4, 2026
SourceCaveats
Known tracking pixels and tracking parameters are stripped from forwarded HTML emails
This claim depends on runtime configuration or the deployed service, not just the published source.
Last verified: April 4, 2026
SourceCaveats
Open source
This claim is supported by code or configuration in our published source repositories.
Caveats
Logs auto-deleted after 7 days
This claim depends on runtime configuration or the deployed service, not just the published source.
Last verified: April 5, 2026
SourceCaveats
12 claims are directly tied to published source files across the web app and mail stack, including Drop encryption, reply-by-alias flows, PGP forwarding, 2FA, and download-limit enforcement.
6 claims still rely on runtime infrastructure, such as log retention policy and whether the hosted deployment exactly matches the published source.
Don't trust us—verify us. Our public application code is open source on Codeberg so researchers can inspect the implementation directly. Hosted infrastructure and the separate mail stack still need to be trusted and audited on their own terms.
We're happy to explain our security architecture in detail and review specific trust-boundary questions.