Anonime Security Overview & Architecture

Effective date: June 12, 2026

This document describes the security posture and cryptographic architecture of Anonime. It is designed to provide transparency into how we protect data, the limits of our infrastructure, and our operational security practices.

1. Security goals

Anonime is built to:

• Minimize what the server can read.
• Keep secret content encrypted on the client wherever possible.
• Limit the blast radius of account compromise.
• Separate secret content from routing and billing metadata.
• Delete expired or revoked content through automated retention and purge workflows.

2. Data classification

Anonime treats data in two broad classes:

• Secret content: vault items, drop bodies, whisper messages, and sealed email content.
• Operational metadata: account identifiers, aliases, session data, notification references, billing records, and routing information.

Operational metadata is stored in plaintext because the service cannot fundamentally route messages or validate sessions without it.

3. Cryptography

3.1 Vault encryption

The browser utilizes:

• PBKDF2 with SHA-256
• AES-GCM with a 256-bit derived key
• A random salt
• A random IV

The master Vault Key never leaves the user's device. The server does not receive, store, or escrow it.

3.2 Private key protection

The user's private key is stored only as a client-encrypted blob. The server stores the public key in the clear, and the encrypted private key blob alongside its required cryptographic metadata.

3.3 Email sealing

Inbound email is sealed using a hybrid cryptographic model:

• Random AES-GCM content encryption.
• RSA-OAEP wrapping of the content key with the owner's public key.

The server stores the sealed envelope and cannot open it without the user's private key, which strictly requires the client-side Vault Key to decrypt.

3.4 Drops and Whispers

Drops and Whispers utilize a per-link random AES-GCM key. The key is carried exclusively in the share link fragment (the URL portion after #) and is never sent to the server. A wrapped copy of the key is stored on our infrastructure solely so the owner can recover the item on an authenticated secondary device. The wrapped key remains encrypted and can only be unwrapped using the owner's cryptographic keys. The wrapped copy does not permit the server to decrypt the content.

3.5 Sensitive plaintext workflows

Support tickets and administrative mail are plaintext by design. They are not intended for end-to-end secrecy because a human operator must be able to read and answer them.

Outbound email is transmitted as standard, ordinary email once it leaves the Anonime network because the external recipient does not possess an Anonime encryption key.

4. Authentication and access control

Identity Verification: Anonime authentication platform verifies user identity and issues secure session tokens.

Backend Verification: The backend explicitly verifies the authentication session token before granting access to any protected routes.

Internal Masking: Internal identifiers, such as authentication id, are strictly backend-only and are not exposed to API clients.

Authorization: Owner-scoped routes verify ownership at the server level prior to fulfilling requests. Admin routes strictly require an admin role verified server-side.

5. Feature gates and subscription enforcement

The backend enforces paid-feature access through server-side entitlements. Current gated features include outbound email sending, Whispers, high-capacity Drops, and custom Nyms. While the frontend application may hide or pre-check features for user experience, the backend server acts as the ultimate zero-trust authority for feature access.

6. Rate limiting and abuse controls

The Anonime infrastructure implements strict server-side controls, including:

• Per-IP throttling on public retrieval and inbound network paths.
• Per-owner sending throttles to prevent spam relay.
• Quota checks for object storage, message counts, attachment sizes, and drop read limits.
• Validation of request sizes and multipart payloads.

These controls are designed to mitigate abuse, protect infrastructure availability, and constrain malicious resource consumption.

7. Storage and retention security

7.1 Expiry-driven deletion

Anonime utilizes strict expiry and purge workflows for ephemeral content:

• Inbound email expires after a maximum of 72 hours.
• Drops expire based on their user-defined TTL and maximum read limits, with a hard limit of 72 hours.
• Whispers expire via thread TTL configurations, with a hard limit of 72 hours.
• Account deletion relies on an automated 72-hour physical purge cycle.

7.2 Object storage

Encrypted content and attachments are stored in secure object storage. Object keys are treated as operational identifiers and are systematically released and reclaimed when the owning record is deleted or purged.

7.3 Account deletion protocols

When an account is marked for deletion:

• The account is locked out immediately and rendered inaccessible.
• All active sessions are revoked.
• Owned data is permanently removed from active production systems within 72 hours.
• Service-specific purgers are executed prior to the final deletion phase to ensure external object storage and caches are reclaimed and scrubbed.

8. Notifications and push tokens

In-app and push notifications contain operational metadata only. Push tokens are stored securely to allow the application to route device-level notifications, but they do not contain secret vault content.

9. Logging and observability

The application utilizes structured logging for operational troubleshooting and security monitoring. Logs are explicitly sanitized to avoid storing raw secrets, plaintext vault content, or data that would unnecessarily widen cryptographic exposure.

Security logs may include:

• Request or correlation identifiers.
• Error contexts and stack traces.
• Account or owner identifiers required for debugging.
• Provider status codes or transaction failure reasons.

10. User responsibilities

Because Anonime employs client-side encryption, security is a shared responsibility. Users are strictly responsible for:

• Protecting their physical devices and browsers from malware.
• Safeguarding the master Vault Key.
• Keeping Drop and Whisper share links entirely private.
• Reviewing active sessions and promptly revoking access if compromise is suspected.
• Utilizing strong authentication methods, such as passkeys or strong identity provider passwords, where available.

If a user shares a link or grants device access to another individual, they must assume that individual possesses full access to the associated content until access is revoked or the item expires.

11. Built-in Security Features

Anonime employs standard infrastructure protections across all layers, including:

• TLS encryption for all network communications.
• Signed JWT validation.
• Server-side authorization checks.
• Expiring access tokens.
• Rate limiting.
• Structured audit logging.
• Automated retention enforcement.

12. Limitations and threat model

While Anonime drastically reduces what the server can read, it does not eliminate all digital risks. The following threat vectors remain possible:

• Compromise of a user's authenticated browser session.
• Compromised end-user devices, such as keyloggers or screen scrapers.
• Malicious, accidental, or careless link sharing.
• Exposure of operational metadata necessary for routing or billing.
• External-service failures or compromise.
• Lawful disclosure of operational metadata where required by binding legal process.

The service is not designed to protect against advanced persistent threats targeting physical endpoints, zero-day malware, or gross user error.

13. Vulnerability handling

If a security vulnerability is identified, our security team may take immediate action to:

• Patch or mitigate the specific issue.
• Disable or aggressively throttle affected features.
• Rotate infrastructure credentials or operational keys.
• Purge or revoke affected network artifacts.
• Notify affected users directly when appropriate and legally required.

14. Third-party dependencies

Our security posture depends in part on the integrity of vetted third-party vendors, including:

• Mailgun: For inbound and outbound email routing.
• Paystack: For subscription and payment processing.
• Firebase FCM: For device-level notifications.
• Object storage and GeoIP data providers.

Infrastructure failures or policy changes within these services may impact our security posture or service availability.

15. Lawful Disclosure

We may disclose operational metadata as required or permitted by applicable law, binding legal process, or to protect the rights, physical safety, security, or integrity of the service and its users.

16. Responsible Disclosure & Reporting

If you believe you have discovered a security vulnerability within the Anonime application or infrastructure, please report it immediately to our security team at security@anonime.io or via your standard support channels.

When reporting, please provide:

• A detailed description of the issue.
• The affected feature, URL, or network path.
• Explicit steps to reproduce the vulnerability.
• Any relevant timestamps, request identifiers, or payload examples.