Why encryption does not prevent screenshots

Two different questions

Encryption answers: who can read the content while it is delivered and held on the messaging server? For encrypted AiThao messages, the server relays encrypted copies, and the participating devices hold the keys. This does not cover a separate request to translate decrypted text in the cloud.

Screenshot protection answers: will the app allow the displayed conversation into a screenshot or screen recording? It acts after decryption, on the device showing the words. An encrypted connection alone cannot impose that screen rule.

Example: sending a private address

Suppose you send an address in an encrypted chat. Encryption protects the message content on its delivery path. Your contact’s phone then opens it so they can read it. Without a screen restriction, an ordinary screenshot can capture that readable view.

If you enable Ask not to screenshot, the other person’s supported AiThao app applies its capture protection to the conversation. That adds a restriction at the screen; it does not change who has received the address. Your contact can still remember it, type it elsewhere or photograph the screen with another device.

What each layer covers

End-to-end encryption: message content in delivery and encrypted copies on the server. It does not hide all metadata: the service still needs information such as who communicates with whom, delivery state and group membership. It also does not protect plaintext on a compromised endpoint.

Screenshot protection: app and operating-system handling of screenshots and screen recording on supported screens. It does not encrypt the message in transit, secure an unlocked phone, or guarantee that content cannot be copied.

Together: encrypted delivery plus restrictions on the displayed conversation. Neither layer proves that a person who legitimately receives a message will keep it confidential.

How AiThao applies the screen restriction

In a one-to-one chat, either person can request screenshot protection in the chat settings. In a group, an admin controls the group setting. A separate preference applies the request to new one-to-one chats; it is off until enabled. The practical screenshot page has the exact switches.

On iPhone, the app shields the conversation and images opened from it using a system behaviour that may change with iOS updates. On Android, the chat uses the system’s secure-window mechanism. These are platform behaviours, not a promise that every capture method is blocked.

Where protection stops

A camera pointed at the screen is outside the app’s control. Modified clients, compromised phones and external mirroring or capture can also defeat the intended restriction. On iPhone, if the underlying system behaviour changes, content can remain visible without the protection.

For encryption, the endpoints matter: someone who can read an unlocked device or control its software may get the plaintext there. Safety-number checks help verify device identities; they do not stop the recipient from taking a photograph.

Cloud translation is a separate boundary

When a received encrypted message is translated, the phone decrypts it and sends content for cloud processing. The message’s encrypted delivery does not make that translation request end-to-end encrypted. Turning on screenshot protection does not change where translation happens.

For calls, translation also needs readable audio. A translated call is not end-to-end encrypted. Turning translation off stops cloud processing but does not undo a key already shared during that call. Keep these distinctions separate from any screenshot setting.

Choosing what to share

Use encrypted delivery for private communication and screenshot protection when you want supported apps to restrict capture. Check translation settings before sharing content you do not want processed in the cloud. For something that must never be copied, the useful decision comes before sending: share less detail, or do not send it.