Trust model

Most messengers ask you to trust that they will refuse the wrong request. YGOOW is built so the wrong request finds nothing to take.

The decision everything rests on

The server never negotiates your keys. A secret — or the knowledge of it — is agreed between people offline, outside the system. Our relay is never a party to that agreement.

The consequence is permanent: there is no key material on our side to subpoena, hand over, or backdoor. No one can be compelled to surrender what they never hold. This is the Lavabit lesson built in from the start, not bolted on after a court order — and it removes the operator as a point of pressure.

What it protects — and what it doesn’t

We would rather mark the edge of the protection than let you assume there isn’t one.

Direct coercion — being forced to unlock — sits in between, and we give you tools for it rather than a promise (see below).

What each party can see

The whole threat model fits on one screen — who learns what about a message:

  ┌──────────────────────────────────────────────────────────────┐
  │ YOUR DEVICE   plaintext · your keys · who you talk to         │
  │ TOR NETWORK   that *a* connection exists — never both ends    │
  │ THE RELAY     a fixed-size ciphertext block + a timestamp     │
  │               no sender · no recipient · no key · no IP        │
  │               the conversation address even rotates over time  │
  │ AN ATTACKER   with the relay seized: indistinguishable noise  │
  └──────────────────────────────────────────────────────────────┘

The one exception sits deliberately at the top of that list: your device. A phone unlocked in the wrong hands, or carrying spyware, reads your screen directly — no cryptography survives that. We put it first, because the projects that bury it are the ones to distrust. This is not hypothetical: it is exactly how EncroChat fell in 2020 — an implant on the handset, never a broken cipher. What a design like ours removes is the other half of that operation — the central servers that let a single infiltration expose tens of thousands of people at once (the full story).

Forced to unlock — the decoy

If someone can compel you to open the app, cryptography alone won’t save you. So YGOOW gives you a choice about what they see:

• A decoy profile. You can set a second password that opens a separate, empty profile — the one you reveal under pressure. Your real profile stays hidden in the same encrypted store, and on disk the two are indistinguishable: there is no flag, no extra file, nothing that proves a hidden profile exists at all. You unlock with your real password as always; the decoy password shows the fake.
• A panic lock. One tap disarms biometrics and re-locks the app, so a finger held to the sensor no longer opens anything — only your secret does, and a secret you can refuse or give as the decoy.
• Nothing on the screen to grab. Screenshots, screen recording, and the “recent apps” thumbnail are blocked, so the chat can’t be captured from outside the app.

And be honest about what deniability is: it lets you keep saying there is nothing else, with no proof to contradict you — but it can’t stop someone who keeps pressing on suspicion (the feature is public; a determined coercer assumes a hidden profile). Cryptography does not survive a wrench. The decoy buys a credible denial and no evidence against it — not invulnerability. The only thing that truly can’t be demanded is data that was never there: that is what Locked — nothing stored and a short message lifetime are for.

What we cannot hide is the line already in the table above: that YGOOW is installed at all. The decoy protects what’s inside, not the existence of the app — and we’d rather say that than sell deniability we don’t have.

Your key is only as strong as its secrecy

“Your key is anything” is the point — and it has an edge we won’t hide. A key is only as strong as the secrecy of your choice: a public file or a guessable link is not a secret. So the app measures the real strength of whatever you pick, stretches weak secrets with a memory-hard function before they are ever used, and never lets the weakest factor hide behind the strongest. The strength you see is the strength you have.

Three levels, and you choose

None of this is a single setting you trust. Before each conversation you pick how it is protected — a normal channel, content locked under a separate secret, or a secret that never touches the device at all — and there is no insecure default. The trade-offs, in plain terms, are laid out in choosing your protection.

The risk we can’t design away

One pressure point on us outlives the design: a malicious update pushed through an app store. We don’t pretend it’s gone. We mitigate it with signed, transparent releases, and we are committed to independent audit of our code — and we will never claim an audit we have not completed. Our standing disclosure terms are on the security page.

Verify, don’t trust us

“Trust us” is what every service says. Here is what you can check instead, without taking our word:

• The warrant canary is PGP-signed. Verify the signature against our published key — an unsigned or non-verifying canary means nothing. The steps are on the canary page.
• The security contact is machine-readable at /.well-known/security.txt (RFC 9116), pointing at the same key.
• The cryptography is written out, primitive by primitive, in the whitepaper — and the app re-runs the same known-answer test vectors on your own phone.
• An independent audit is something we have committed to, and will report when it is done — never before. We will not claim an audit we have not completed.

We do not ask you to believe us. We ask you to check.

The cryptography itself

Every primitive, the key derivation, the forward-secrecy ratchet, identity and quorum unlock are written out in full in the whitepaper. Nothing on this page is dressed up beyond what is written there.

Your key, your rules — everything else is redacted.