The current technical path from local secret creation to ticketed browser reveal.

Security Architecture Overview

Last updated: 23 March 2026

This document describes the security architecture and technical design principles used by the Anomonus platform.

It explains how the system processes encrypted secrets, how access control is enforced, and how the platform attempts to minimize sensitive data exposure.

This document is provided for informational purposes only and does not constitute a guarantee, certification, or formal security assurance. The architecture described reflects design intent and may evolve over time. Actual security properties depend on implementation, deployment configuration, user behavior, and external factors.

⸻

1. System Overview

The Service is designed with a security architecture intended to reduce unnecessary exposure of sensitive data.

The platform consists of several components:

Client Applications
Mobile applications and web interfaces used to create and access secrets.

Application Backend
Server components responsible for storing encrypted secret payloads and managing access verification.

Infrastructure Layer
Networking, proxy, and deployment components used to route and secure traffic.

Cryptographic Operations
Encryption and verification operations performed primarily on the client side.

The backend service is designed to operate without requiring access to plaintext secret content under normal operation.

⸻

2. High-Level Architecture

The architecture separates secret creation, storage, and access control.

User Device
↓
Client Encryption
↓
Encrypted Payload Upload
↓
Secret Storage
↓
Ticket / Challenge Verification
↓
Authorized Secret Retrieval

The sequence above represents a simplified conceptual flow and may vary depending on feature configuration and client implementation.

Secret payloads are encrypted before being transmitted to the server.

The server stores encrypted data and operational metadata needed to enforce access rules.

⸻

3. Client-Side Cryptography

When a user creates a secret:
1. The secret content is encrypted on the user’s device.
2. The encrypted payload is transmitted to the server.
3. The server stores ciphertext and metadata only.

Encryption is performed using cryptographic libraries integrated into the client applications. The specific algorithms, parameters, and implementations may vary by platform and version and are subject to change over time.

Client-side cryptography is intended to ensure that plaintext secrets are not required by the server to provide secret-sharing functionality.

⸻

4. Secret Storage Model

Secrets stored on the server consist of two categories of data:

Encrypted Payload
The encrypted secret content generated by the client.

Operational Metadata
Metadata required to enforce access restrictions.

Metadata may include:

• expiration timestamp
• maximum view limits
• burn-after-read status
• secret type classification
• encrypted payload size
• device binding parameters

The backend service uses this metadata to enforce secret lifecycle policies.

⸻

5. Secret Lifecycle Management

Secrets may follow different lifecycle rules depending on creator configuration.

Possible lifecycle mechanisms include:

Time-Based Expiration
Secrets automatically expire after a configured duration.

Maximum View Limits
Secrets become unavailable after a specified number of accesses.

Burn-After-Read
Secrets may be automatically invalidated after being accessed.

These controls allow secret creators to define the persistence of shared information.

⸻

6. Access Verification Mechanisms

To prevent automated scraping or unauthorized access attempts, the platform may use temporary verification mechanisms.

These mechanisms may include:

Access Tickets
Short-lived tokens required to retrieve a secret.

Verification Challenges
Cryptographic or request-based validation steps required before secret retrieval.

Rate Limiting
Server-side controls designed to prevent abusive request patterns.

Access tickets and verification challenges are designed to expire automatically after a short time period.

⸻

7. Device Binding

An optional device-binding mechanism may be used to restrict access to a specific device.

When enabled:

• the client generates a device public key
• the server stores the public key associated with the secret
• the client must prove possession of the corresponding private key

Device binding is intended to reduce the likelihood that a secret can be accessed from unauthorized devices.

⸻

8. Transport Security

Communication between clients and servers is protected using encrypted transport connections.

Security mechanisms may include:

HTTPS connections
Encrypted communication channels between clients and servers.

Certificate validation mechanisms, including certificate pinning in certain client environments, may be used to reduce the risk of interception. The availability and effectiveness of such mechanisms may vary by platform and application version.

Reverse Proxy Layer
Requests may pass through a proxy that handles routing and network protections.

⸻

9. Tor Network Support

Some versions of the Anomonus client support optional Tor connectivity.

When Tor mode is enabled:

• client traffic may be routed through the Tor network
• network path anonymity may be improved depending on configuration

Tor connectivity is optional and depends on user configuration and device environment.

⸻

10. Rate Limiting and Abuse Protection

To prevent abuse or automated attacks, the backend service may implement rate-limiting mechanisms.

These mechanisms may rely on temporary request identifiers derived from network-level data.

These identifiers may be ephemeral and may not be retained beyond what is necessary for short-term enforcement and security purposes.

Rate limiting helps protect the service against:

• automated secret harvesting
• brute-force access attempts
• denial-of-service attacks

Rate limiting is implemented in a way intended to minimize persistent storage of network identifiers.

⸻

11. Logging Model

The system is designed to reduce logging of sensitive information.

Application-level logging is designed to avoid recording:

• secret plaintext
• decrypted secret payloads
• private cryptographic material

However, logging behavior may vary depending on deployment configuration, infrastructure components, and operational requirements.

Operational logs may still exist for debugging, infrastructure monitoring, and abuse prevention.

⸻

12. Local Secure Storage

Client applications may store certain data locally on the user’s device.

Examples include:

• cryptographic identity material
• session state
• local application preferences
• optional mnemonic recovery phrases (stored only on device)

Local data storage uses device-provided secure storage mechanisms where available.

⸻

13. Third-Party Security Components

The platform uses open-source and infrastructure components for cryptography and networking.

Examples include:

• cryptographic libraries used for encryption
• Tor networking components
• secure storage APIs
• SSL transport security libraries

These components provide foundational security capabilities used by the system.

⸻

14. Threat Model Considerations

The system attempts to mitigate several classes of risks.

Examples include:

Network interception
Mitigated through encrypted transport connections.

Unauthorized secret access
Mitigated through tickets, challenges, and optional device binding.

Automated scraping
Mitigated through rate-limiting protections.

Data persistence risks
Mitigated through expiration and burn-after-read features.

⸻

15. Security Limitations

While the system incorporates several security mechanisms, no system can guarantee complete protection against all threats.

Potential limitations include:

• compromised user devices
• malicious secret recipients
• infrastructure misconfiguration
• vulnerabilities in third-party components

Users are responsible for evaluating the risks associated with sharing sensitive information and should not rely on the Service as a guarantee of confidentiality or anonymity.

⸻

16. Responsible Disclosure

Security researchers who discover vulnerabilities affecting Anomonus are encouraged to report them responsibly.

Security contact:
security@anomonus.com

Responsible disclosure helps improve the security of the platform.

⸻

17. Continuous Security Improvements

The security architecture of Anomonus may evolve over time.

Changes may include:

• improved cryptographic protections
• enhanced rate-limiting controls
• stronger network privacy protections
• infrastructure hardening

Updated architecture documentation will be published when major changes occur.