The decoy was deniable on day one. We measured day ninety.
YGOOW lets you set a second password that opens a decoy profile, while your real profile stays hidden in the same encrypted store. It is the idea VeraCrypt made famous for disks, and for a messenger it answers one of the ugliest situations there is: someone standing over you, demanding that you unlock the phone.
For months our site said the two profiles were indistinguishable on disk. That sentence was true on the day you set the decoy up. This post is about every day after that.
A hidden volume is not a state. It is a history.
Deniability is usually argued about a snapshot: here is the store, show me the hidden profile. But a phone isn’t a snapshot. It writes every time a message arrives, and an examiner is not limited to one look. So we stopped arguing and built the adversaries:
- One copy of the phone’s storage, with and without the decoy password.
- Two copies, taken days apart — a device seized, returned, seized again; or a backup and a later image.
- A stopwatch on the unlock — a camera on the screen is enough.
Then we simulated months of ordinary use on the production storage code — phones with a decoy and phones without, some opening the decoy weekly, some daily, some never — and let each adversary try to tell them apart. The pass criteria were written down before the run.
It failed, clearly
- After 30 days, one copy revealed the hidden profile in 69 % of simulated phones whose decoy was never opened; after 90 days, 87–88 %. “Same size” held at setup and then drifted.
- Two copies, taken a day to a month apart: 98–100 %.
- Unlocking the real profile took about 1.1 seconds longer than unlocking the decoy or a phone without one — cleanly separable in every run.
- And a finding we were not looking for: heavy use of the decoy could overwrite the hidden profile. Real data loss, on the path people would use most under pressure.
None of this was visible in a unit test, and none of it needed a clever attacker. That is the uncomfortable lesson: a deniability claim that is never measured over a lifecycle is a claim about the setup screen.
What the re-measurement shows
We changed how the store is written and how the app unlocks, then ran the same adversaries on the same simulated lifetimes. (The construction isn’t published yet; the measurements are.)
- No data loss in 600 simulated lifetimes, including the scenario that used to destroy the hidden profile.
- Without the decoy password, one copy or two: sizes give nothing away (0 size mismatches in 7 200 snapshots), and the size and change-pattern detectors find nothing.
- The strongest detector we built — one that learns what an ordinary write looks like on phones without a decoy — was the most instructive. Our first redesign still left rare events, like changing a password, with a signature of their own; after fixing those, it was down to 1.2–1.7 % of snapshot pairs, all of a single kind, which we then closed by construction and pinned with a test that fails without the fix. That last step was verified by the test, not by re-running the whole population, and we say so.
- The stopwatch no longer tells: on our reference phone the real profile now opens within −3 to +28 ms of a phone without a decoy. We haven’t measured a phone with only 2–4 cores yet.
What is still open — and why we’re telling you
Two edges remain once the decoy password is in someone else’s hands, which is, after all, the scenario a decoy exists for:
- Two copies with the decoy password still show that the real profile was used in between. Closing that needs encryption that can be re-randomised without the key, block by block — and in our measurements that costs 14 to 40 times the write budget a phone can afford with the current storage format. It stays open until the format changes.
- A decoy you never use is a clue. A handful of messages in storage sized for far more doesn’t prove anything, but it invites the question. The sizes are now equal; the contents can’t be.
So the practical advice is simple: use the decoy like a real profile, and assume that someone who can come back later can see that something changed, even if they can’t see what.
Why publish a failure
Because the alternative is a sentence on a website that nobody checks. The honest version of a decoy claim has a threat model attached, a number next to each adversary, and the edges written down — and the whitepaper’s §8 now says exactly that, with the old sentence recorded in the changelog as wrong.
Deniability buys you a credible denial with no evidence against it. It never bought invulnerability, and a decoy that only works on day one doesn’t even buy the denial.