Is there an existing request for feature?
What feature would you like?
Summary
Introduce support for multiple encrypted profiles within Session, where each profile is unlocked using a different pattern or password. Each unlock credential would reveal only the conversations belonging to that profile, providing meaningful protection against coercive access while maintaining Session’s privacy-focused design.
Motivation
Many Session users rely on the app because privacy is a matter of personal safety, not just convenience. This includes people experiencing domestic violence, journalists, human rights defenders, political activists, and others who may be forced to unlock their phone or messaging app under threat.
A traditional app lock protects against unauthorized access, but it offers little protection when a user is compelled to unlock the application. Multiple encrypted profiles would provide plausible deniability by allowing users to maintain completely separate messaging environments.
Proposed Design
When Session is opened, the user is first presented with a pattern or password prompt (the implementation details are, of course, up to the development team).
- Entering an existing pattern unlocks the encrypted profile associated with that credential.
- Only the conversations belonging to that profile are visible.
- If the user enters a new pattern that has never been used before, Session opens as a new, empty profile, ready for use.
- Any contacts, conversations, media, and future messages created while using that credential become part of that encrypted profile.
- Once a profile has been unlocked, Session behaves exactly as it does today. The separation between profiles happens behind the scenes, with each profile remaining cryptographically and logically isolated.
- The only additional interface element that may be needed is an option to return to the initial unlock screen to switch profiles.
- Closing the app, locking the phone, or navigating away would require the user to authenticate again before accessing a profile.
Benefits
- Protects users against coercive access rather than only unauthorized access.
- Provides plausible deniability by allowing multiple independent encrypted profiles.
- Requires minimal changes to the day-to-day user experience.
- Aligns closely with Session’s mission of protecting users in high-risk situations.
I recognize this would be a substantial feature to implement, but I believe it would provide meaningful real-world protection for users whose safety depends on privacy. It also feels like a natural extension of Session’s philosophy: not just encrypting messages, but helping protect users in situations where encryption alone is not enough.
Anything else?
I am not a security developer but would be happy to help with use cases, requirements writing, and or testing
Is there an existing request for feature?
What feature would you like?
Summary
Introduce support for multiple encrypted profiles within Session, where each profile is unlocked using a different pattern or password. Each unlock credential would reveal only the conversations belonging to that profile, providing meaningful protection against coercive access while maintaining Session’s privacy-focused design.
Motivation
Many Session users rely on the app because privacy is a matter of personal safety, not just convenience. This includes people experiencing domestic violence, journalists, human rights defenders, political activists, and others who may be forced to unlock their phone or messaging app under threat.
A traditional app lock protects against unauthorized access, but it offers little protection when a user is compelled to unlock the application. Multiple encrypted profiles would provide plausible deniability by allowing users to maintain completely separate messaging environments.
Proposed Design
When Session is opened, the user is first presented with a pattern or password prompt (the implementation details are, of course, up to the development team).
Benefits
I recognize this would be a substantial feature to implement, but I believe it would provide meaningful real-world protection for users whose safety depends on privacy. It also feels like a natural extension of Session’s philosophy: not just encrypting messages, but helping protect users in situations where encryption alone is not enough.
Anything else?
I am not a security developer but would be happy to help with use cases, requirements writing, and or testing