Don't trust us. Check us.
Some of this you can confirm in a single command. The rest you cannot confirm yet — and this page grades every claim we make on exactly that line, rather than hoping you will not ask.
Every one of these was broken the same way.
Between 2018 and 2024 most of the encrypted-phone businesses in Europe were taken apart by police: Phantom Secure, EncroChat, Sky ECC, Exclu, Ghost, MATRIX. From the headlines you would conclude the encryption failed. It did not. Not once, in any of them. What was attacked was the channel the company used to reach its own users, or something the app was quietly doing that its users could not see.
French investigators pushed what looked to users like a routine update. The handsets checked its signature and the check passed — the leading published analysis is that the signing key sat on EncroChat's own servers, so reaching the server was enough to sign anything. A signature check whose key is where the attacker already is is not a check; it is a delay.
The FBI did not break a messenger. It ran one. A hidden extra recipient was attached to every message and filtered out of the user's own contact list. Not one user could have discovered this from the app, because the app is what was lying.
The Australian Federal Police modified the operator's software updates and shipped them. Four years after EncroChat, against a platform whose operator certainly knew the EncroChat story.
Two things follow, and they set the shape of this page. First: the update and build channel is the attack surface that matters, more than the cipher. A perfect ratchet is worth nothing if the binary on your phone was reading your words before it encrypted them. Second: what convicted the operators was the marketing. Phantom Secure's chief executive and the people behind EncroChat and Sky ECC were prosecuted over running a service sold as untouchable — not over the code. A company that says "here is exactly what you can check, and here is what you cannot" is making a very different statement from one that says "we are untraceable."
Claim by claim, and whether you can confirm it.
"Checkable" means: you, or any researcher who has never spoken to us, can establish this from something we do not control — the binary in your hands, the network in front of you, a published artefact. Our saying so does not count. Neither does a passing test in a repository you cannot read.
The app declares only the permissions its features use — read the list yourself.
The Android package declares ten permissions, and you can read them straight out of the APK with aapt dump permissions: INTERNET and ACCESS_NETWORK_STATE to reach the relay; POST_NOTIFICATIONS and USE_FULL_SCREEN_INTENT for the arrival alert and the call ring; RECORD_AUDIO for the microphone; FOREGROUND_SERVICE, FOREGROUND_SERVICE_REMOTE_MESSAGING, WAKE_LOCK and RECEIVE_BOOT_COMPLETED for the optional, off-by-default stay-connected service; and HIDE_OVERLAY_WINDOWS. RECORD_AUDIO is the microphone — it is there for voice calls, requested the moment you place or answer one and never at launch. There is no camera, contacts, location or external-storage permission at all: the check is the point, so we print the real list rather than a shorter one.
The screen resists screenshots and screen recording.
FLAG_SECURE is set on the window: run adb shell screencap against a running Avano and you get a black image. Thirty seconds to check, and it is also its own limitation — it stops the operating system's capture, not a camera pointed at the screen.
Nothing leaves your phone except over Tor.
Put the phone behind a network monitor and see for yourself that the only destinations are Tor guard relays — no analytics host, no crash reporter, no content delivery network. What that does not show you is what happens inside the circuit, which is the part you would need the source for.
The relay cannot be reached except as an onion service.
A plain socket cannot resolve a .onion name at all — it fails outright. So you can confirm the address we publish is an onion address and that no ordinary connection reaches it. You cannot confirm from outside that we run no second, clearnet listener; only an operator can see that.
Every build we have produced is signed with the Android debug key.
Run apksigner verify --print-certs on any Avano package and it prints CN=Android Debug. That key is a documented constant with the password android, identical in concept on every developer machine on earth. This row is checkable, and what it confirms is bad news. We publish it because you would find it anyway, and because a company that hides this is the company from section 01.
The binary you are running was built from the source we publish.
There is no published source repository, no published build manifest, no signature under a key you can look up, and no transparency log. If somebody handed you a modified Avano, you could not tell, and neither could we. This is the single largest gap in the product and the history above says it is the one that matters most.
You can read the source.
A LICENSE file carrying the full AGPL-3.0 text was added on 29 July 2026; before that the licence existed only as a metadata field, which grants a reader nothing. Neither version makes the source public. The repository is private, so "open source" is an intention and we will not print it as a fact. The app's own trust screen says Open-source · PLANNED and this page says the same.
The build reproduces bit-for-bit from source.
One piece does. The native engine — the compiled cryptographic core — has been rebuilt twice from a clean checkout and the two results were byte-identical. That is real, and it is also the weakest useful version of the result: it was the same machine both times, and the rest of the app has never been rebuilt and compared by anyone, us included. Nobody outside this project has reproduced anything.
Everyone gets the same build — nobody got a special one.
This is the ANOM question and our answer is no. Detecting a build made for one person requires a public, append-only log that everyone watches. The machinery for that log exists in our code and no release has ever been put into one: zero entries, no published log, no independent witnesses.
An independent security firm has reviewed this.
Never. The message encryption is libsignal, which is audited and which we use unmodified — but everything we built around it, which is where all our distinctive claims live, has been reviewed by nobody outside this project. Do not read "built on audited cryptography" as "audited".
Our relays hold no record of who talks to whom.
We believe this is the strongest property Avano has, and you cannot confirm it from outside. A relay's own behaviour is visible only to whoever runs the relay. The honest position: a design claim awaiting published source and an audit.
Deleting your identity really destroys it.
The mechanism is checkable in principle: the platform key the on-device encryption is bound to is destroyed first, so the sealed data cannot be re-derived even if the files survive. What is not established is the layer underneath — phone flash storage does not overwrite in place, and an adversary imaging raw storage below the filesystem may still recover blocks we told you were gone. We have not carved one out ourselves, so we state it as a risk rather than a finding.
Rows are graded against what a person outside this project could establish on 29 July 2026. A row moves to Checkable when the artefact that would prove it is public — not when the code that would produce it is written.
What you must simply trust us for.
Five things, from the binary in your hand
That the app requests no permission capable of surveillance. That the window refuses screen capture. That the phone talks only to Tor guards and nothing else. That the relay address is an onion address a plain connection cannot reach. And that every build we have shipped is signed with the Android debug key — the bad news, confirmable in one command.
Six things, and they are the important ones
That the app you received is the one we built. That the binary matches the source, which you also cannot read. That you got the same build as everyone else — we have no way to know either. That the signing key has not been copied; it is a debug keystore on a laptop, so assume it is less protected than an email account. That nobody has compelled us. And that the relay behaves as described, which is the central claim of the product.
If you are considering Avano today because of a claim in the right-hand column, stop. Those are the claims we cannot back with anything but our word, and our word is exactly what the history in section 01 says not to accept. Avano is worth using today because it collects little and asks for nothing — not because you can verify it. That changes when the rows above change, and not before.
The order we are closing these in, and why that order.
A real release signing key, held somewhere the build machine is not.
Nothing further down matters while anyone who obtains one laptop can sign a build that Android installs over ours as a legitimate update. That is EncroChat's failure with the key moved from a server to a desk. Key custody belongs to the founder and nobody else — no tool in this project generates, stores or commits one, deliberately.
Publish a signed build manifest and a log entry for one real release.
The cryptography is written and tested. What is missing is the act. Even a static file moves "everyone gets the same build" from impossible to checkable.
A verifier that runs outside the app.
An app cannot honestly attest to itself — a malicious build prints the honest answer. Any "verify this build" button inside Avano would be decoration, and shipping one would be precisely the overstated claim this page exists to avoid.
Publish the source.
What turns three rows of the table above from no into yes-with-effort, and what lets a researcher check the relay claim we currently just assert.
A reproducible build of the whole app, confirmed on a second machine.
Ranked below the others because, as Signal's own experience shows, a reproducible build nobody performs protects nobody. Anchor it to a public log first.
Independent witnesses on the log.
Until other parties countersign what our log says, a log is a database with extra steps: we could show one version of history to one person and another to everyone else, and every check either of them ran would pass.
An external audit.
Last, not because it matters least, but because an audit of an unpublished, unreproducible build tells you about a snapshot nobody can tie to what they are running. Make it checkable, then have it checked.
Every request we have received. The number is zero.
Zero is a real number and this is a real report, not a placeholder waiting for content. Categories are listed exhaustively — including the ones we have never received — so that a future non-zero entry appears in a table whose shape did not change to accommodate it.
| Category | Received | Complied | Data produced |
|---|---|---|---|
| Subpoenas and equivalent orders for subscriber data | 0 | 0 | None |
| Search warrants and production orders | 0 | 0 | None |
| Interception or real-time collection orders | 0 | 0 | None |
| Preservation requests | 0 | 0 | None |
| Emergency disclosure requests | 0 | 0 | None |
| National-security process, where reportable | 0 | 0 | None |
| Content-removal or blocking demands | 0 | 0 | None |
| Requests to modify or target a build | 0 | 0 | None |
| Requests reaching the early-access email list | 0 | 0 | None |
For the messenger there is no account, no identifier, no address, no sender field, no contact list and nothing written to a disk — so an order reaching us produces essentially nothing. The one genuine record we hold is the early-access email list on this website. The full policy, category by category →
No warrant canary. Deliberately.
A canary is widely treated as a mark of seriousness, so the reasons are worth giving. The legal theory has never been tested in court — it rests on a distinction between compelled silence and compelled speech that no judgment has confirmed. Practitioners do not expect it to work: lawyers consulted publicly by others in this field have said they expect removing a canary to carry the same consequences as an explicit disclosure, which makes it the same act with extra steps. And an order can simply forbid triggering it, at which point the signal is worse than absent — it is actively false while looking healthy.
We are not going to build a user's safety on a gesture. Designing so that compulsion yields little beats promising to resist it. A person can be compelled, gagged or replaced, and a pledge is only as durable as the person making it. What survives is a system with nothing worth taking.
Found something? Tell us before you tell the world.
Write to [email protected]. That is the whole process. There is no portal, no form and no ticket number, and there is exactly one address because it is the only one we have confirmed a human reads.
The conventional thing is to publish security@. We are not going to, and the reason generalises. A dedicated security address nobody has confirmed receives mail is a trap with our name on it: a researcher writes to it, gets no bounce, and reasonably believes they have reported the issue and started the clock. Then nothing happens — not because we ignored them, but because the message went nowhere. That is strictly worse than having no security address at all, because an absent address at least makes a person look for a working one. Our machine-readable security.txt lists hello@ for the same reason.
Enough to reproduce it — component, build, steps. A reasonable window before you disclose publicly; we will keep you updated rather than going quiet. Do not access, modify or destroy other people's data, and test against your own identity and devices. If you need an encrypted channel first, ask in your first mail: we have not published a key and will not pretend otherwise.
To acknowledge, to tell you our assessment, and to tell you when a fix ships. Not to pursue legal action over good-faith research that respects user privacy and does not degrade the service. To credit you if you want it. And if your finding contradicts something we have published, to correct the page and record why the wrong version looked right, rather than quietly editing it.
In order of how much a user would be hurt: anything that links two conversing users; anything that reveals a conversation happened at all, including timing and volume attacks; anything that survives "erase everything"; and anything that reaches a release.
Our own words. If a claim on this website, in the app, or in a store listing is stronger than what the software does, that is a security issue and we treat it as one — because a user acts on it. This has happened to us repeatedly and each time it was found by somebody checking rather than reading.
No paid bounty — we will not advertise one until it is funded and real. No published contact key. No guaranteed response time. This is a very small team and we would rather say that than publish a number we have never had to meet.
The competitor table, held to the same standard.
Every cell names the policy, FAQ or source file it was read from — including the rows a rival wins and the cells we could not verify.