Option to set an alternative passcode ("double bottom") that either opens a limited set of chats, opens a different account, or destroys one of the connected accounts completely when entered.
Use cases
Could be used by political activists in opressive countries when they are required to unlock their chats.
Potential issues
If such an emergency passcode is set, the app won't be able to use your fingerprints or other biometric data to unlock chats. As a result, the absense of biometric unlock could be used a clear indicator that a person has something significant to hide – and it becomes impossible to prove this is not the case.
This might provide a false sense of security and might actually make the situation worse for an activist's or an innocent bystander.
It would be really good to have passwords for chats, channels, and groups, as well as for saved messages and archived items—passwords and individual locking.
This proposal is close, but I think the important part is to avoid making the emergency passcode itself the security boundary. The main requirement should be plausible deniability: there must be no reliable way to determine whether a hidden state is configured at all. That means the mechanism should be built into every Telegram client in the same form, without changing the normal unlock flow or disabling biometrics. A secret action could switch the account into a sanitized state, but nothing in the UI or authentication behavior should reveal whether such a state exists. Also, this should go beyond hiding chats in the interface. In the sanitized state, Telegram should behave at the protocol, local database, cache, indexing and synchronization levels as if the hidden data did not exist. The threat model should include forensic analysis of an unlocked device, not only manual inspection of chats. A separate duress action could still be useful, but for a different purpose: not to hide the existence of the feature, but to irreversibly destroy the ability to restore the hidden state if the user expects coercion.
The main requirement should be plausible deniability: there must be no reliable way to determine whether a hidden state is configured at all.
That means the mechanism should be built into every Telegram client in the same form, without changing the normal unlock flow or disabling biometrics. A secret action could switch the account into a sanitized state, but nothing in the UI or authentication behavior should reveal whether such a state exists.
Also, this should go beyond hiding chats in the interface. In the sanitized state, Telegram should behave at the protocol, local database, cache, indexing and synchronization levels as if the hidden data did not exist.
The threat model should include forensic analysis of an unlocked device, not only manual inspection of chats.
A separate duress action could still be useful, but for a different purpose: not to hide the existence of the feature, but to irreversibly destroy the ability to restore the hidden state if the user expects coercion.