A duress password defends against a person, not a lab

Disclosure first: I work on StealthOS, an iOS privacy app that ships a duress password, so I have an interest here. I am writing this up because duress passwords get handed out as general safety advice, and they are much narrower than that.

What the feature actually is

A second credential that does something other than unlock. Usually it wipes, sometimes it opens a decoy space holding plausible but unimportant data. If someone is forcing you to type your password, you type the other one.

Start with who is holding the phone

Three cases, and they behave nothing alike.

Opportunistic thief. They want the hardware, or they want to see whether your banking app is still logged in. iPhone full disk encryption already covers this. A duress password adds nothing, because nobody is watching you type.

Someone in your life with physical access. A partner, a roommate, a coworker who borrowed the phone for a minute. This is the most common real case and almost nobody models it. Nothing was broken. The phone was already open, or they already knew the passcode.

Someone who can compel you. Border agents, an abusive partner escalating, a robbery where the phone is the means rather than the target. This is the only tier where a duress password does anything at all, and even here it is conditional.

Three conditions people skip

1. It only helps if the copy in front of them is the only copy. Anyone competent images the device before touching it. Wiping the live device after an image exists accomplishes nothing except telling them you tried.

2. It only helps if they cannot tell. The feature is documented publicly, in app listings and in threads like this one. If the person coercing you knows a duress mode exists, a wipe does not get you out of the room, it just changes what happens next in it.

3. It only helps if the data lives only on that device. Anything synced, backed up, or already sent to someone else survives the wipe intact.

One more, and I am not a lawyer: destroying data while under legal process is a separate offense in a lot of places. That turns a privacy problem into a criminal one.

The part that generalizes

Duress is a party trick. The lesson sitting underneath it is dull and far more useful: opening the device and opening the data should not be the same event.

Nearly every compromise in the second tier happens after the phone is already open. Put the sensitive material behind a credential that the phone unlock does not satisfy, and the whole "they had my unlocked phone" category shrinks. Things worth doing before you think about duress at all:

• A passcode you do not reuse anywhere else, six digits minimum, alphanumeric if you can tolerate typing it.
• Lock screen previews off. Control Center and Wallet off while locked.
• If you expect to be compelled, remember that US courts have split repeatedly on biometrics versus passcodes, and passcodes have generally drawn the stronger protection. Powering the phone off before a checkpoint forces the passcode path.
• Lockdown Mode, if targeted spyware is a plausible threat for you specifically.
• Keep the material that matters inside something with its own encryption and its own password.

Where our app sits, including what it does not do

StealthOS keeps the browser, vault, notes, passwords and messages inside one sandbox behind a master password separate from the iOS passcode, AES-256-GCM, keys held in the Secure Enclave. The duress password wipes that sandbox rather than the phone, which avoids the "you destroyed a device" problem, but it does nothing about condition 1 or condition 3 above. If someone imaged the phone first, we do not help you. Neither does anybody else's duress feature.

The rest, plainly. The app is closed source, though the relay and crypto pieces are public at github.com/Olib-AI (StealthRelay, TorClient, ConnectionPool, PoolChat). Every privacy feature is free, with no account, no ads and no analytics. There is a $4.99 a month tier that adds workstation extras like an SSH terminal, a code editor and NetMap. It buys tools, not protection. The attached screenshot is the browser's threat screen rather than the duress screen, for fairly obvious reasons.

https://apps.apple.com/us/app/stealthos-private-browser/id6756983634

The question I would actually like answered by people here: is there a duress design that survives the imaging problem, or is the whole category theatre the moment a competent examiner is involved?