Security, including what we have not done
Nothing is unhackable. Here is what we built, what it does not cover, and what is still missing.
What protects you
- Chat and calls: end-to-end encrypted with MLS (RFC 9420). The key exchange mixes a classic and a quantum-resistant method, so a future quantum computer is not enough on its own. We wrote none of the cryptography ourselves.
- The server sees little: it holds only scrambled messages it cannot open, never records who sent them, pads message sizes, and keeps no request logs.
- Fake-server protection: every server reply is signed and the app checks it against a pinned key, so someone who tricks a phone into trusting a fake certificate still cannot pose as the server.
- Identity checks: safety numbers you compare in person, and an alarm that pauses sending if a contact's keys change.
- Vault: Argon2id key stretching tuned to your device, XChaCha20-Poly1305 encryption, a vault whose size hides how many items it holds, a decoy passphrase, growing lockouts and erase after too many wrong tries.
- Screen: screenshots and screen recording are blocked inside the app and the app-switcher preview is blurred.
- Burner-number texts: locked to your key the moment our server receives them.
Where it can fail
- A phone that is already hacked cannot be made safe by any app.
- Another camera can photograph the screen.
- Root and jailbreak checks can be fooled.
- Text messages from the phone network are not end-to-end encrypted; your provider sees them first.
- A DNS server sees the names you look up, and a VPN moves trust from your Wi-Fi to the VPN's owner. Neither makes you anonymous.
- If you lose your vault passphrase, nobody can recover it.
Still to do
- Independent audit: required before launch and not done. The chat encryption library we use also states it has not had a formal audit.
- Testing on real phones, including phone calls, which depend on a component Expo flags as untested on the current React Native architecture.
- Certificate pinning at the network layer on phones, push delivery in real builds, and a published transparency log.
Report a problem
Email apexflowlabs@gmail.com. We will not take action against good-faith security research.