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.
Try to find your own message.
This is a live model of what leaves the phone. Type into it, send, and watch your message ride out on a pulse that looks like every other pulse.
Your message rides out on the next pulse — lit here, because you know which one it is.
Type furiously or sit still: while the app is open the wire looks identical either way. What it does not hide is that you opened it — cover runs only while Avano is open, and no amount of cover makes a stopped stream look like a running one. On Android a locked Avano keeps its connection to the relay open for up to about half an hour, or up to a day with message alerts on, which shows that it is online, never what arrives. We would rather show you the limit inside the demo than underneath it.
Not an illustration of cover traffic: the behaviour. One fixed-size block leaves per slot whether you are mid-conversation or reading in silence, and a real message pre-empts a decoy rather than adding to the stream.
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, one after another. 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 the operator'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 later, against a platform whose operator certainly knew the earlier 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. The people behind those services 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. No build has been published yet, so the rows that need one are checkable by anyone who holds a build, which today means testers we sent one to. 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 sixteen permissions of its own, and you can read them straight out of the APK with aapt dump permissions, which lists a seventeenth that AndroidX adds at build time, DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION: the app defines it at the signature level and holds it itself, so no other app can, and it keeps the app's internal receivers closed to other apps on older Android. The sixteen: 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; MODIFY_AUDIO_SETTINGS to put the phone in its call mode for a call, which reaches nothing of yours and is never asked for; CAMERA for the in-app camera; ACCESS_COARSE_LOCATION for sharing your approximate location, asked for only when you tap to share it; READ_CONTACTS for finding which of the people in your address book are on Avano, asked for only when you tap to look through it, and read on the phone: every email and number is blinded there before anything leaves, so the service learns neither your book nor who matched, and none of it is kept; QUERY_ADVANCED_PROTECTION_MODE to read whether the phone's Advanced Protection is on; FOREGROUND_SERVICE, FOREGROUND_SERVICE_REMOTE_MESSAGING, WAKE_LOCK and RECEIVE_BOOT_COMPLETED for the optional, off-by-default stay-connected service; FOREGROUND_SERVICE_MICROPHONE so a call is still heard when the screen goes off, for the length of that call and no longer; and HIDE_OVERLAY_WINDOWS. RECORD_AUDIO is the microphone — it is there for calls, placed or answered, and for voice and video messages, requested the first time one of them needs it, never at launch. CAMERA is the same shape: requested the first time you scan a code, take a photo, record a video message or start a video call, and the camera is open only on those screens. There is no precise-location or external-storage permission at all, and the contacts permission uploads nothing readable: 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.
Messages leave your phone over Tor. Calls do not.
Put the phone behind a network monitor and you will see it: while you are messaging, the only destinations are Tor guard relays — no analytics host, no crash reporter, no content delivery network. Place a call and you will also see a direct UDP connection to our call relay, in the clear. The audio inside it is encrypted end to end and the relay cannot open it, but the relay does see your IP address, and so does anyone watching your line. It is the one part of Avano that is not behind Tor, because a live call's latency budget, about four hundred milliseconds one way for everything, does not survive a Tor circuit. Until 12 August 2026 this row claimed the opposite, and it had been wrong since the day calls shipped. The check we invite you to run is the check that would have disproved it.
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 that the relay address built into the app 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.
The whole app does now, on one machine. On 23 July 2026 the native engine was rebuilt twice from a clean checkout and the two results were byte-identical; on 20 and 21 October 2026 the published recipe ran for the first time, on a rented build box, through fifteen stops that it records one by one, and two container builds of one commit gave an unsigned APK that was byte-identical but for the signature block. That is real, and it is also the weakest useful version of the result: it was the same machine both times, and nobody outside this project has reproduced anything, because no APK is published yet.
Everyone gets the same build — nobody got a special one.
This is the hidden-recipient 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 published, formally analysed and used by Signal, 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 analysed 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. The table was first graded on 29 July 2026 and each row has been revised since when the thing it describes changed. 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 the microphone, the camera and approximate location only for the features that use them, and no contacts, precise-location or storage permission at all. That the window refuses screen capture. That while you are messaging, the phone talks only to Tor guards — and that when you place a call it also talks directly to our call relay, which is the one thing here that is not behind Tor. 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 the pushed-update 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. Built on 24 October as a page outside the app: check a download runs the command-line verifier, compiled to WebAssembly, on files you give it, in your browser, and says what it cannot prove against whoever runs this site. It has nothing to check until row 02 is done.
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 the largest messengers' 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. One limit, stated now rather than discovered later: Estonian law requires a communications undertaking to keep confidential the information related to surveillance (Electronic Communications Act § 113(9)), so an order of that kind is counted here when the law lets us count it, and never described.
| 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, where reportable | 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 email people send us | 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 mail people send to [email protected]. 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.