How your photos are protected.

Photos are encrypted before sending and remain encrypted in app storage. One click requests permission to open them; a second closes them. Screenshots are blocked on protected Android screens. And the sender can withdraw access after sending.

Each photo is protected with its own key before it leaves your device. Photo files, the app’s local database and the preview cache are encrypted. A blurred thumbnail is a visual cue: protection is more than a blur effect.

Private keys stay in secure device storage. A photo is decrypted in memory for authorised display; the file stored by the app stays encrypted. Automatic Android backup is disabled for the app.

Your partner clicks the photo. The app requests a protected key envelope from the server, and their phone opens it using its own secrets. The server checks device authorisation and the active partner link. Without a connection or permission, the photo cannot be opened.

A second click closes it. A later opening requires access to the key again. The website demo simulates this behaviour using a public marketing image; the actual control takes place in the Android service.

Photos and messages are end-to-end encrypted. Content encryption uses AES-GCM with 256-bit keys; photo keys are wrapped for authorised devices using X25519. In practical terms, the server carries protected data without the private keys needed to read it.

The production connection uses HTTPS and secure WebSockets. The device also proves its identity through a signed challenge. A QR code and security code help you verify that you linked the right person.

The backend keeps information needed to route exchanges and check permissions: technical identifiers, partner links, encrypted data and key envelopes. It validates requests, limits their frequency and rejects reuse of the same key request. Firebase App Check and Play Integrity help check that a connection comes from the expected app.

The server therefore knows some operational metadata even though it cannot read photo or message content. Encryption does not mean no data processing: our privacy policy explains this.

Only the sender can withdraw their photo. Once the server processes withdrawal, it removes access to the key envelope and notifies the recipient. An encrypted file already on their phone is no longer enough to reopen the photo in the app.

The request must reach the server to take effect. Revocation cannot erase what someone has already seen or a copy made outside the app.

As with a banking app, Amoris Secret asks you to authenticate before accessing your photos and conversations. Unlocking uses Android biometrics or your phone’s system PIN, pattern or password. A device lock must therefore be configured.

When the app moves to the background, its content is hidden. After an extended absence, it requires you to unlock it again. This complements encryption by restricting access if someone picks up your phone. Keeping your unlock code private remains essential.

Amoris Secret enables Android protection on sensitive screens, blocking screenshots and limiting capture by compatible recording tools. A system lock (biometrics, PIN, pattern or password) is required. The app refuses to start when it detects a rooted device.

These safeguards depend on the operating system and device integrity. They are not a guarantee on a compromised phone. Fingerprints and biometric data are not sent to our servers: verification is handled by Android.

Another camera can always photograph the screen. No encryption or screenshot blocking can prevent that external copy. Amoris Secret combines multiple protections to make sharing as safe as possible, but does not promise zero risk.

Only share with someone you trust, with freely given mutual consent. Consider the possible consequences before sending, keep Android updated and protect access to your phone.

Email contact@amoris-secret.com. Describe the issue and app version without sending intimate photos, private keys, unlock codes or unnecessary sensitive information.