Claims against code · 15 September 2026
Audit
We took every claim on this site and in the App Store and checked it against the code that is supposed to keep it. Below: what holds, what we fixed the same day, and what we do not do.
This audit is internal. Tysha has never had an external audit, and we put that in the first line rather than in small print at the bottom. An internal review is worth less than an external one - but saying «we passed an audit» without naming an auditor would be worth nothing at all.
Why bother
A messenger sells trust, and trust cannot be shown in a screenshot. The only honest way is to name the claim, show the place that keeps it, and say how to check it without us. Where you cannot check it without us, we say so plainly instead of pretending otherwise.
442tests in the app
140tests on the server
2third-party components in total
3audits since 12 September
Claim against code
Three possible outcomes and no fourth: holds - the claim is kept; reworded - the wording was stronger than the truth, so we changed it; fixed - the claim was not being kept, and the bug is gone.
Messages and calls are encrypted on the phones
holds
The encryption is libsignal - the same engine Signal uses, pinned by tag and checksum. The client code is available on request: look for yourself.
Post-quantum key agreement
holds
ML-KEM-1024 sits in every branch of the handshake; there is no path around it. A test measures the real key size - a stub would not pass.
Keys never leave the phone
holds
They live in the Keychain marked «this device only»: never in an iCloud keychain, never moved to a new phone. Until now nothing guarded that - now a test does.
Conversations do not go into a backup
holds
The app's directories are excluded from backups. That had no test either - now it has one.
No third-party analytics, no tracking
holds
The app has exactly two third-party components: libsignal and a WebRTC build. No host other than our server and the relay.
A push notification carries nothing from your chat
holds
The server has no text and cannot put any in. Your own phone fills it in after decrypting the message itself.
There is no people search
holds
No «give me the keys for this username» request exists on the server - and its absence is held in place by tests, so it cannot appear unnoticed.
Calls hide your address by default
with a caveat
They go through the relay, and the relay cannot see the content. But if the relay is unavailable the call goes direct - and then the other side sees your address. The call screen says so.
Your queue address says nothing about you
fixed
It used to be computed from your username - so the table of envelopes on the server pointed at people, and anyone with a dictionary could confirm it. The address is now random and reaches the other person inside the invite.
The server does not know who writes to whom
false, corrected
On 15.09 we softened this to «sees it but does not store it». The 29.09 audit showed even that was stronger than the truth: the server keeps for an hour which queues an account wrote to, and the first envelope of a conversation carries the sender's key. The privacy page now says it plainly: the server knows who writes to whom. Hiding the sender (Sealed Sender) is planned.
Twelve words bring the account back
corrected
This used to say «and the messages too», which was false. The backup restores contacts, groups and settings; the text of conversations stays only on the phone that had it.
«Delete chat» deletes
fixed
Photos and videos stayed on disk: deletion looked for the file under the wrong name. Fixed, and a test now fails if it ever comes back.
«View once» disappears for good
fixed
The row disappeared; the file stayed in the phone's storage. Now the file goes.
Deleting your account removes everything
fixed
Attachments outlived the deletion and waited out their fourteen days. They now go with the account.
What we do not do
This list is deliberately the longer one. What is missing is usually learned later, and from someone else.
- No external audit. The biggest open item, and it can only be closed with money and someone else's name on the report.
- We do hold metadata. The username is stored in the clear, and the time and size of every envelope are visible. A group message goes as one envelope per member - so the size of a group shows in the count. The queue address is random now, but the server keeps it next to the username in one row: it is not hidden from the server itself, and could not be while delivery runs through it.
- The passcode locks the app, not the conversation. Messages are encrypted with a key from the iPhone Keychain - tied to this device and readable only while the phone is unlocked. That key is not derived from your passcode, and you can see it plainly: the text of a new message appears in a notification before you have entered the passcode. So the passcode and Face ID close Tysha screens, not the bytes themselves.
- We do not prevent screenshots. iOS cannot. We only tell the other side - and it is reciprocal: turn the notice off and you stop receiving it too.
- Attachments on disk rely on iOS file protection, not on our own key - unlike the conversation itself.
- The server is closed. The client code is available on request (AGPL); everything server-side has to be taken on trust - or verified by running your own, which we set up on request.
- The hosting platform sees what our server sees (it terminates the secure connection), and Apple sees the timing of every notification. That is the price of hosting and the price of iOS, and we cannot route around it.
- A report is the one place where text reaches the server in the clear. Only the messages you picked, and for 90 days.
How to check this without us
- Ask for the app's code. We hand it over on request - including the tests described here. It is AGPL; write to support and we will send it.
- Compare the safety code. Sixty digits or a QR code in the contact card: if they match, there is nobody in between. If a key changes, the app says so.
- Open Diagnostics. The call trace shows which path the audio takes and whether bytes are actually moving.
- Run your own server. For a team or an organisation we deploy Tysha on your hardware - then nothing has to be taken on trust.
Earlier reviews: 12 September 2026 (25 findings, 19 closed the same day), 13 September 2026 (a review of our own fixes), 15 September 2026 - this report.