A high-level explanation of what Anomonus actually is and how the current system is divided.

Transparency & Security Overview

Last updated: 23 March 2026

This document provides a high-level overview of the architecture, privacy model, and security design principles used by the Anomonus platform.

The purpose of this document is to explain how Anomonus is designed to reduce unnecessary data collection and protect user-generated secrets.

⸻

1. Design Philosophy

Anomonus is designed as a privacy-focused secret sharing platform.

The system architecture follows several core principles:

• minimize personal data collection
• encrypt secret payloads before transmission
• limit server-side knowledge of secret content
• use expiration and burn mechanisms to reduce long-term storage
• reduce persistent identifiers where possible

The platform is designed to support a client-side encryption model for secret distribution, where secret content is encrypted before reaching the server.

⸻

2. Client-Side Encryption Model

The application is designed to encrypt content on the user’s device before transmission to the server.

The server receives encrypted payloads (“ciphertext”) rather than plaintext content.

The server stores:

• encrypted secret payloads
• expiration metadata
• access control metadata
• ticket/challenge verification data

The server is designed to operate without requiring access to plaintext secret content.

⸻

3. Secret Lifecycle

Secrets may follow several lifecycle models depending on how the creator configures them.

Possible secret behaviors include:

• time-based expiration
• maximum view limits
• burn-after-read deletion
• device-bound access restrictions

These controls allow secret creators to limit how long content remains accessible.

When a secret expires or reaches its configured limit, the system marks the secret as unavailable.

⸻

4. Ticket and Challenge Access Model

Access to secrets may use temporary verification mechanisms designed to prevent automated scraping or unauthorized access.

These mechanisms may include:

• short-lived access tickets
• verification challenges
• device-binding validation

Tickets and challenges are designed to expire quickly and are used to validate legitimate secret access requests.

⸻

5. Device Binding

In some configurations, secrets can be bound to a specific device.

When device binding is enabled:

• a public key associated with the device may be stored
• the server verifies cryptographic proofs associated with the device to confirm the requesting device

This mechanism helps ensure that only the intended device can access a secret.

⸻

6. Ephemeral Data Controls

The platform uses several mechanisms intended to reduce persistent data storage.

Examples include:

• expiring access tickets
• expiring verification challenges
• configurable secret expiration
• burn-after-read options

These features allow secret creators to control how long information remains available.

⸻

7. Logging Philosophy

The service is designed to minimize logging of sensitive information.

The platform attempts to avoid logging:

• secret payloads
• decrypted content
• private cryptographic material

Operational logs may still exist for purposes such as:

• system stability
• debugging
• abuse prevention
• rate limiting

Logging practices may vary depending on infrastructure providers and deployment environments.

⸻

8. Network Protections

Anomonus implements several protections intended to reduce the risk of interception or tampering.

These may include:

• encrypted HTTPS connections
• SSL certificate pinning (may be implemented in supported mobile application environments)
• reverse proxy request handling
• rate limiting protections
• abuse mitigation controls

Transport-level encryption protects communications between clients and servers.

⸻

9. Tor Connectivity

Some versions of the Anomonus application may support optional Tor connectivity.

When Tor mode is enabled:

• network requests may be routed through Tor
• additional privacy protections may be applied to network traffic

Tor functionality depends on the device environment and user configuration.

⸻

10. Cryptographic Components

The platform may use established cryptographic libraries and security components.

Examples may include:

• modern cryptographic libraries (such as libsodium or platform-native frameworks)
• SSL pinning libraries
• device secure storage APIs

These libraries provide the cryptographic primitives used by the client applications.

⸻

11. Third-Party Components

Third-party components operate under their own security and privacy policies, which are outside the control of Anomonus.

The Anomonus platform may rely on infrastructure components and open-source libraries to operate.

Examples may include:

• mapping frameworks used for location-based secrets
• Tor networking components
• cryptographic libraries
• transport security libraries

External navigation applications (such as map applications) may process data independently when users open location links.

⸻

12. Mobile Application Permissions

The mobile applications request only the permissions necessary for core functionality.

These may include:

• Camera — used for scanning QR codes containing secret links
• Location — used when creating or viewing location-based secrets
• Photo Library — used when decoding secrets hidden inside images
• Biometric Authentication — used for local application unlocking
• Internet Access — required for communication with backend services

Biometric authentication is handled by the device operating system.

⸻

13. Data Minimization Approach

The platform is designed to limit the categories of personal data processed.

The service generally does not require:

• email addresses
• phone numbers
• contact lists
• social media accounts
• advertising identifiers

Users can interact with the service without creating traditional identity accounts.

⸻

14. Architecture Scope

The current system architecture represents a secret viewer and distribution service, rather than a full identity-based social platform.

The backend primarily manages:

• encrypted secret storage
• access tickets and verification challenges
• device-binding verification
• RSVP interactions for event-type secrets

⸻

15. Security Limitations

While the platform is designed with privacy in mind, no technical system can guarantee absolute security.

Potential risks may include:

• device compromise
• malicious recipients of secrets
• infrastructure misconfiguration
• network attacks outside the control of the service

Users should treat secret sharing responsibly and avoid transmitting highly sensitive information without appropriate precautions.

The platform is designed to improve privacy but does not guarantee anonymity.

The security of secrets also depends on how users handle access links, passwords, and devices.

⸻

16. Responsible Disclosure

If you discover a security vulnerability affecting the Anomonus platform, please report it to:

[Security contact email]

Responsible disclosure helps us improve the security of the platform.

⸻

17. Threat Model

The platform is designed to reduce exposure to common risks such as:

• unauthorized access to stored secrets
• passive network interception
• automated scraping or enumeration
• excessive data retention

However, the platform does not protect against:

• compromised user devices
• users voluntarily sharing secrets
• screenshots or external recording

⸻

18. Updates

This document may be updated as the platform evolves.

The latest version will be available at:

https://anomonus.com/transparency-security-overview/