Don't trust us. Check us.
Below is every significant claim Avano makes, sorted by one question: can you confirm it without taking our word for it? Most rows currently say no. We would rather publish that table than a better-looking one.
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. If you read only the headlines you would think 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.
- EncroChat (2020). French investigators pushed what looked to users like a routine software update. The handsets checked the signature on that update and the check passed — because 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.
- ANOM (2018–2021). 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.
- Ghost (2024). 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 from that record, 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." We will not make the second statement, and this page is the reason we do not need to.
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 claim | Checkable today | How, or why not |
|---|---|---|
| The app asks your phone for no permission that could spy on you | Yes | The Android package declares exactly three permissions: INTERNET, ACCESS_NETWORK_STATE and HIDE_OVERLAY_WINDOWS. No microphone, no camera, no contacts, no location, no external storage. Read it out of the APK yourself with aapt dump permissions, or any APK inspector. An app that cannot request the microphone cannot record you even if someone later compromises it. |
| The screen resists screenshots and screen recording | Yes | FLAG_SECURE is set on the window. Run adb shell screencap against a running Avano and you get a black image. This is checkable in thirty seconds and it is also its own limitation — it stops the operating system's screen capture, not a camera pointed at the screen. |
| Nothing on your phone leaves it except over Tor | Partly | You can 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. So this row is half checkable and half trust. |
| The relay cannot be reached except as an onion service | Partly | A plain socket cannot resolve a .onion name at all — it fails with no address associated with hostname. 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. |
| The app is signed with a real release key you could pin | No — and it is worse than that | Every build we have ever produced is signed with the Android SDK debug key. Run apksigner verify --print-certs on any Avano APK 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 the section above. |
| The binary you are running was built from the source we publish | No | There is no published source repository yet, 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 it is the one the history above says matters most. |
| You can read the source | Not yet | The code is licensed AGPL-3.0-or-later, which is the licence recorded in the project itself. It is not published: the repository is private today. Until it is public, “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 thing. |
| The build reproduces bit-for-bit from source | Partly, and not by you | One piece of it does. The native engine — the compiled cryptographic core — has been rebuilt twice from a clean checkout on one machine and the two results were byte-identical. That is a real result and it is also the weakest useful version of one: it was the same machine both times, and the rest of the app (the Android half: code, resources, packaging) 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 | No | This is the ANOM and EncroChat question, and our answer is no. Detecting a build made for one person requires a public, append-only log that everyone watches, so a targeted build cannot be delivered without leaving a record the world can see. 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 | No | We have never had a third-party audit. 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”. They are different sentences. |
| Our servers hold no record of who talks to whom | No — this needs the source | We believe this is the strongest property Avano has, and you cannot confirm it from outside. A relay's own behaviour is only visible to whoever runs the relay. The honest position is that this is a design claim awaiting both published source and an audit, and until then it is exactly the kind of statement this page exists to label. |
| Deleting your identity really destroys it | Partly | The mechanism is checkable in principle: the platform key that the on-device encryption is bound to is destroyed first, so the sealed data can never be re-derived even if the files survive. What is not established is the layer underneath. Phone flash storage does not overwrite in place; an adversary who can image the 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. See the threat model. |
Rows are graded against what a person outside this project could establish on 28 July 2026. A row moves to Yes 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.
- That the app requests no permission capable of surveillance — three permissions, none of them microphone, camera, contacts or location.
- That the window refuses screen capture.
- That the phone talks only to Tor guards, and to nothing else.
- That the relay address is an onion address a plain connection cannot reach.
- That every build we have shipped is signed with the Android debug key — the bad news, confirmable in one command.
- That the app you received is the one we built. No published hash, no key you can look up, no log.
- That the binary matches the source — which you also cannot read yet.
- 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; assume it is less protected than an email account.
- That nobody has compelled us. There is no warrant canary, no threshold signing, no independent witnesses.
- That the relay behaves as described — the central claim of the product, and the one you cannot see from outside.
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.
Ranked by the harm each one prevents divided by what it costs — not by how interesting it is. The first item is not the clever one; it is the one where the harm prevented is total and the work is an afternoon.
- A real release signing key, held somewhere the build machine is not Nothing further down this list matters while anyone who obtains one laptop can sign a build that Android will install 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 to nobody else — no tool in this project generates, stores or commits one, deliberately.
- Publish a signed build manifest, and a public log entry, for one real release The cryptography for this is written and tested. What is missing is the act: put a real release into an append-only log and publish the signed head of that log at a fixed address. 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. The deliverable is a separate tool that you run, that we cannot influence.
-
Publish the source
Licensed
AGPL-3.0-or-lateralready. Publishing it is what turns three rows of this table from “no” into “yes, with effort”, and it is what lets a researcher check the relay claim we currently just assert. - A reproducible build of the whole app, confirmed on a second machine The engine reproduces on one machine. The rest — the Android code, the resources, the packaging — has not been attempted, and one machine is not a reproduction. This is the item that removes trust in us entirely, and it is 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 on this list, 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. The order is: make it checkable, then have it checked.
No hidden recipient. Ever.
ANOM's defeat came down to a single mechanism: an extra party attached to every message, hidden from the contact list. That is not a subtle cryptographic weakness — it is a feature somebody deliberately wrote.
The rule we take from it is not “don't be evil.” It is don't build the mechanism. A capability that exists only for the operator to use when required will be used by whoever acquires, compels or compromises the operator. Avano has no administrator mode, no message-copy facility, no way to add a party to a conversation from our side, and no account recovery — there is nothing on our side to recover, which is also why nobody impersonating our support can ever ask you for anything useful.
That is a promise about what does not exist, and it has the same problem as everything else on this page: today you cannot check it, because the source is not published. It is on the list. See everything else Avano deliberately does not do →
The rest of the honest documentation.
This page is one of four that exist to say what Avano is not. The others are just as unflattering.