Hello everyone,
A few months ago I saw a suggestion on the forum about adding passcodes that unlock a “decoy” user account for use under coercion. That discussion noted the idea didn’t align with GrapheneOS’s philosophy and would be complex to implement.
Recently I read a thread about Celebrity (the UK police tool for extracting data from locked devices), which got me thinking: people are often forced to reveal unlock codes to speed up encounters with authorities. With that in mind, here’s an alternative that may seem odd but feels practical and less problematic than explicitly creating “fake” accounts.
Main idea:
- Use the device’s existing multi-user support to create a “travel” or “benign” profile containing only ordinary apps and non-sensitive data (e.g., regular messaging, a gallery of innocuous photos, common apps).
- Before travelling or attending events, the user switches to that profile so that, if compelled to unlock the phone, the visible content is the benign profile.
Proposed GrapheneOS enhancement:
- Add an option in the user management controls to hide the existence of other profiles from the main UI.
- By default, the system would not surface any indication of extra profiles (neither on the lock screen nor in visible Settings).
- To access hidden profiles, provide an activation method — for example, entering a PIN/sequence into the Settings search box or another trigger that reveals user management and allows switching to the real profile.
- The visible profile should appear completely ordinary and legitimate to avoid drawing further scrutiny.
- The feature should be optional and user-configurable.
Motivation and benefits:
- Reduces the chance that the presence of extra profiles prompts deeper inspection.
- Simpler and ethically less fraught than designing explicit “decoy” accounts meant to deceive.
- Builds on existing user-profile mechanisms with finer visibility control.
This is effectively “security through plausible appearance,” but in threat models involving physical or legal coercion it could be a useful, practical option. Do you think this is feasible for GrapheneOS, or are there fundamental problems I’m missing?
Thanks to the team for your work the project is turning out great.