Who this protects you from — and who it doesn't.
A threat model is a list of the specific people you are defending against and, just as importantly, the ones you are not. Ours exists as an engineering document. This is the same content, written for someone deciding whether to trust an app with their safety.
The person we had in mind has a government as an opponent, not an advertiser.
That single sentence decides every trade-off in this product, and it explains the ones that look strange. It is why there is no phone number. It is why there are no calls. It is why the app locks itself and stops receiving when you put it down.
Concretely, the people this is built for are the ones for whom the fact that a conversation happened is already the damage: a journalist and a source, a lawyer and a client, someone organising in a place where organising is punished, someone leaving a relationship that monitors them. For all of these, "nobody could read the message" is not the win. "Nobody can show that the two of you spoke" is the win.
Every serious messenger encrypts the contents of a message. Signal does it excellently and we build on the same cryptography they wrote. What almost all of them still hand to a server is the pattern around the message — who, when, how often. That pattern is the map of a life, and it is what a court order actually collects, because it is what exists to collect.
There is a documented case that makes this concrete. In 2021 French police, via Europol, obtained a Swiss order compelling ProtonMail to start logging the IP address of an account used by a climate activist group. Proton complied; arrests followed. Proton's encryption was never broken and was never relevant. An account existed, it had a name, a court could point at it, and the provider could be ordered to instrument it going forward.
Avano's design is a direct answer to that specific case: there is no account to point at, and no place for such an instrument to be attached. That is the thing we are actually building.
Three attacks that have worked on other services, and why they do not have a target here.
“Hand over the records for this account”
There is no account. You do not register, so there is no phone number, no email, no username in any database of ours, and no creation timestamp. Your identity is a key made on your device from a recovery phrase and it is never sent to us. An order naming a user has nobody to name.
“Give us this person's contact list”
We do not have one. There is no contacts table, no group membership list and no social graph on our servers, because your contacts live only on your phone and are never uploaded. Messages cross the relay as sealed, identical-size blocks under random codes, with no sender field at all — the sender is not concealed, it is never transmitted.
“Log this user's IP address”
Messaging runs over a Tor client built into the app, and our relay is reachable only as an onion service. The connection arrives from inside the Tor network. We never see your address — not because we throw it away, but because it never reaches us.
The principle underneath all three is worth stating on its own, because it is the one thing we would defend hardest: make compulsion useless rather than refused.
A promise to resist is a promise made by a person, and a person can be jailed, gagged, replaced or simply wrong. What survives that is a system that has nothing to give up. Compulsion yields whatever the records contain, and we spent the design trying to make the records nearly empty.
We are not the first to say this. Signal's published answer to a subpoena asking for a user's name, address, correspondence, contacts, groups and call records was two timestamps — when the account was made, and when it last connected. Not because Signal refused. Because that is all Signal has. We hold less than that, and there is a page setting out exactly what we do hold: what we hold, line by line →
A threat model without this section is marketing.
Each of these is a real, documented capability held by real adversaries. None of them is a bug we intend to fix, because none of them is a bug.
- Commercial spyware — the Pegasus and Predator families — reaches the device, not the channel. Once code runs on your phone with the app's privileges or above, it reads what is on your screen, the text of your notifications, and the message after it has been decrypted.
- Under this adversary, Avano, Signal, and a paper notebook photographed by the front camera are equivalent. No protocol property survives it and no future version will change that.
- What we can do is raise the price and shrink the prize. What we cannot do is make it infinite, and we will not pretend otherwise.
- We are currently worse than Signal here, and it is worth knowing why: our interface is rendered by the system web view rather than written natively, which is a wider surface. This is a real cost of the way the app is built today.
- An adversary who can see the traffic at both ends of a conversation can confirm the conversation by timing alone, without reading a byte. This is called traffic confirmation and it defeats every deployed messenger, including this one.
- Cover traffic — which Avano runs by default, free, for everyone — is a partial answer. It hides how much you send in a session. It does not hide that you are connected, and it cannot hide you going offline.
- The full answer is a mixnet, which delays and reorders traffic between hops. We have researched one and prototyped against it. It is not shipped.
- Our relay runs on rented infrastructure, which means it runs inside somebody else's machine. That company can be ordered — without telling us, and without needing anything from us — to copy the relay's memory from the layer beneath it.
- Our design keeps everything in memory and writes nothing to the disk. That defeats a warrant for the disk, and a subpoena for backups, completely.
- It does not defeat the machine underneath. A memory image would contain the live queues, their keys, any undelivered messages, and the relay's own identity key. We say so plainly because the in-memory design is easy to over-read as an answer to this, and it is not one.
- Privacy is a property of a crowd. If a relay is serving a handful of people and an investigator knows their target is one of them, arithmetic does most of the work and no protocol saves you.
- There is a well-known case: a student who used Tor to send a bomb threat was identified not by any break in Tor, but because he was the only person on that campus network using Tor in that window.
- Avano's user base is currently very small. This is the one weakness on this page that only growth fixes, and it is not a reason to over-trust an early build.
What a forensics lab gets, honestly.
This is the most likely serious attack against an ordinary person, and it is the one people ask about least precisely. The answer depends entirely on one thing: whether the phone was locked when it left your hands.
If the app was locked
Everything Avano stores is encrypted item by item, and the key that opens it is not derivable from the phone alone. If you have set a passphrase, that key is an entanglement of a hardware-held key and your passphrase, stretched with a deliberately slow, memory-hungry function so that guessing is expensive rather than instant. Someone who extracts the hardware key still cannot open anything without the passphrase.
What a modern forensics tool then reads out of the storage is sealed blocks — not your messages, and not the contents of your contacts.
What it still gets, and this part is not comfortable
Three pieces of the database are not sealed today, and a seized device does still leak them:
- The names you gave your contacts. Some housekeeping records are stored under keys built from a contact's name. The contents are sealed; the key itself is readable. So a seized phone can still yield a list of who you have contacts with, even though it cannot yield what any of you said.
- A stable group identifier, which means two seized phones can be shown to have been in the same group.
- Database structure and indices, because whole-file database encryption is not in use — the sealing is per-item.
Until those three are closed, the accurate sentence is: your messages, your identity and your session state are sealed; your contact list is not. We would rather write that than a shorter, better sentence.
If the app was unlocked, or the phone was on and in use
Then the keys are live in memory and a sufficiently capable extraction reads what you can read. This is not specific to Avano. It is why the app locks itself after a short idle period and when it leaves the foreground, and it is why a locked Avano cannot receive messages at all — a design decision we made on purpose and describe under what it deliberately does not do.
“Deleted” is a stronger word than the hardware supports
When you erase your identity, the platform key that everything is bound to is destroyed first, and without it the sealing key can never be reconstructed — so even a surviving file is unopenable. That is the mechanism and we are confident in it.
The layer underneath is where honesty is required. Phone flash storage does not overwrite in place; it writes elsewhere and marks the old location invalid, and the chip's own controller may never physically erase it. An adversary who can image the raw storage — below the filesystem — may still find blocks of a record we told you was deleted. We have not recovered one ourselves, so this is a stated risk rather than a demonstrated one. It is not a reason to distrust deletion; it is a reason not to treat it as shredding.
A note on duress features
Avano has a duress passphrase and a wipe-after-repeated-failures counter. Both are currently weaker than they should be and we will not describe them as protections yet: each depends on a small side file that can be deleted to disable it, and the decoy identity a duress passphrase opens is distinguishable from a genuine fresh one by its timestamps. Under coercion, a decoy that can be detected is worse than none, because it is discovered while you are in the room. Do not rely on these.
Three things a relay can still work out about you.
These are the residual leaks in the part of the design we are proudest of. They are here because a threat model that lists only its wins is not a threat model. There is a longer, more technical version on what a relay sees.
- Groups become visible over time When you send to a group, your phone posts one sealed block to each member's private address. A relay that watches which addresses receive something, and when, can eventually work out which addresses belong to one group — without opening anything. This is a published attack against this whole family of designs, not something specific to us, and the number of observations needed grows only slowly as a service gets bigger, so growth does not dilute it. What we have done: your inbound addresses are spread across eight separate connections rather than one, and each one is polled on its own randomised schedule rather than all together. What that bought is measurable and it is not concealment — it stopped a relay re-joining all your connections every twenty seconds, which it previously could do with certainty. It did not stop a relay accumulating each connection's membership over a few minutes.
- Opening and closing the app links everything together All of those connections appear within seconds of you unlocking Avano, and they all go quiet together when it locks. That start-and-stop pattern is available to a relay at every session, and closing it would require the app to keep polling while locked — which we have refused, because anything that keeps polling while locked has not locked. This is the largest remaining gap and it is one we have chosen not to close.
- Both directions currently land on the same relay The design splits a conversation so that no single relay sees both ends of it. That code is written and wired. Today it has one relay to work with, so both directions reach the same host — separate connections and separate Tor circuits, which defeats one kind of correlation and not the other. A second, independent relay in a second country exists and is not yet the one the app dials. Until it is, treat the split as designed rather than delivered.
Compared with Signal, honestly.
Signal is an excellent, honest application and this comparison is not an attack on it. A state adversary attacks the weakest thing, not the strongest, so what matters is where we are weak.
| Signal | Avano | |
|---|---|---|
| Release signing | Store-held key, published signatures | No release key exists. Debug-signed only |
| Distribution & updates | App stores, automatic security updates | Hand-built, sideloaded, no update or revocation path |
| Reproducible builds | Documented and performed for years | Engine only, one machine, never independently |
| Source published | Yes | Not yet |
| Third-party audits | Multiple, published | None of our own work |
| iOS | Shipped and widely deployed | Still being built |
| Interface attack surface | Native | System web view |
| Infrastructure | Large organisation, real legal counsel | One relay in use, one operator, founder-run |
| Anonymity set | Hundreds of millions | Very small |
| Identifier required to sign up | Phone number | None |
| Social graph on the server | Reduced, but the account exists | None |
| IP hidden from the service, by default | Calls only | All traffic, over Tor |
| Hides how much you send | No | Cover traffic, on by default |
The summary, and it is the sentence to take away: Avano's design for hiding who talks to whom is ahead. Its engineering, distribution, verification and operational maturity are well behind. A state adversary attacks the weakest of those, which today is not the design.
Is this enough for you?
If your concern is that a company is building a profile of your life to sell — Avano is comfortably enough, and so is Signal. Choose either and stop reading threat models.
If your concern is that a court might one day ask our service who you talked to — this is exactly what Avano is for, and the design answer is good. The remaining risk is not the design; it is that you cannot yet verify we built what we describe.
If your concern is that a well-resourced state is specifically interested in you, today — be careful, and read this in order. Your phone is the target, not the protocol. The way Avano is distributed today is its weakest link and it is weaker than Signal's. And a small service is a small crowd to hide in. Avano may still be the right choice for the metadata, but it should not be the only thing you are doing, and nothing on this site should be read as saying it is enough on its own.
The rule we hold ourselves to, throughout the code and throughout this site: an overstated security claim is worse than no claim, because someone acts on it. If you find a place where we have broken that rule, tell us — that is a security report and we treat it as one.
The rest of it.
Nothing on these pages is written to make you feel better about the product.