Security

Security is the product here, not a feature — so we treat reports as gifts. If you have found a weakness in the YGOOW relay, the Android app, or the cryptography, we want to hear from you.

How to report

Email security@ygoow.com. A machine-readable contact lives at /.well-known/security.txt (RFC 9116). For encrypted reports, use our PGP key — fingerprint 4B01 B8B1 132F 33C5 DC06 7DC2 6893 22E3 4899 BB1B, the same key that signs our warrant canary. Until 8 October 2026 that key had no encryption subkey, so encrypted reports were not actually possible — if you tried and failed, please try again; the fingerprint is unchanged.

Please tell us what you found, how to reproduce it, and the impact you believe it has. A working proof-of-concept helps us confirm quickly.

What we commit to

• No legal action against good-faith research that respects the boundaries below. Test against your own devices and your own data.
• Acknowledgement within a few days, and honest updates as we work the issue.
• Credit when a fix ships — publicly if you want it, silently if you do not.
• Coordinated disclosure: give us a reasonable window to fix before going public. We will not sit on it.

In scope

• The relay server — API, WebSocket, store-and-forward, one-time token handling, Dead Drop creation and pickup.
• The Dead Drop page — the only place YGOOW code runs in a browser: the link format, the proof-of-key pickup, its Content Security Policy, and the browser self-test.
• The Android app — key handling, on-device storage (including the hidden decoy profile against storage snapshots), the embedded Tor path, the native crypto backends.
• The cryptographic core — key derivation, AEAD (“Variant C”), the symmetric forward-secrecy ratchet used in live conversations, the Double Ratchet and its post-quantum hybrid (X25519 + ML-KEM-768 — built and tested, not yet wired into live conversations), Shamir quorum, identity and QR exchange, the backup file.
• Side channels and traffic analysis — timing of the primitives on ARM64, the size buckets, cover traffic, and the background schedule. We publish our own measurements in the whitepaper, including the findings we have not fixed yet; a stronger adversary than ours is exactly what we want to hear about.

We are especially interested in the parts we built ourselves rather than inherited: the prekey-server-free bootstrap (a deterministic starting key for the classical half, a long-term identity key for the post-quantum half), the hybrid combiner, the safety number over both identity and encryption keys, and the transactional decryption path. If you can desynchronise a live ratchet, forge a state transition, or show that our ML-KEM implementation deviates from FIPS 203 on any input, we want that report before anyone else gets it.

Out of scope

• Social engineering, physical attacks, or anything targeting our users or staff.
• Denial-of-service or volumetric testing against the live relay.
• Findings that require an already-compromised device — we say plainly that no messenger survives that.
• Automated-scanner output with no demonstrated impact.

What we don’t pretend

We do not run a paid bug bounty yet, and we will not imply otherwise. What we offer is a fast, honest, no-lawyers response and public credit. As the project matures — and ahead of the independent audit we have committed to — this will grow.