Secrets are encrypted before storage
The app performs secret encryption locally, so the service is designed around storing encrypted bundles plus metadata rather than readable secret bodies.
Trust center
Security, encryption, privacy controls, and transport hardening explained without marketing fog.
The strongest trust signal here is precision: what the secure messaging app does, what the browser viewer does, and where access control, device binding, or Tor-aware transport hardening actually lives.
The web is intentionally viewer-first
The current website opens secrets and serves legal/public pages. It is not presented as a full authenticated dashboard or browser creation studio.
Access can be layered beyond a passcode
Ticket validation, link fragments, and optional device-binding challenge flows add explicit control boundaries around secret retrieval.
System flow
Explain the current secret flow in four concrete steps.
The mobile app encrypts the secret locally, packages metadata, and uploads the ciphertext bundle to the backend.
The user distributes an Anomonus link, QR code, or PNG-hidden link that carries the secret route and optional key fragment.
The recipient enters a passcode, requests a one-time ticket, and may need device-bound challenge verification for protected secrets.
The browser or app fetches ciphertext with the ticket and performs client-side decrypt, with burn-after-read and lifecycle rules applied after access.
Commitments
The public commitments the current product can support honestly.
Describe the real product boundary
Anomonus should clearly state that the mobile app authors secrets and the web surface primarily opens them.
Explain where encryption happens
The product story should keep repeating the key fact: encryption happens locally before upload, and decrypt happens locally after ticketed fetch.
Be honest about limits
Browser support, device-binding boundaries, settings-driven hardening, and backend inference limits should be explained without marketing fog.
Comparison
How the implemented Anomonus model differs from more conventional service patterns.
Category
Anomonus posture
Typical legacy pattern
Secret handling
The app encrypts payloads before upload and the service stores ciphertext plus metadata.
Many products rely on server-side trust to hold or process readable user content.
Open flow
Recipients use passcode, link fragment, ticket issuance, and local decrypt in the viewer.
Typical services render the message directly from server-side application state.
Transport and device controls
The mobile app includes pinning, Tor routing, device binding, biometrics, and wipe audit paths.
Transport is often just standard HTTPS with fewer native security boundaries around device state.