What we can produce, and what does not exist.
This page is written for investigators, prosecutors and lawyers, so it is written plainly and without advocacy. The short answer is that Avano is designed so that almost nothing exists to produce — and that is a fact about the architecture, not a posture of refusal.
Make compulsion useless rather than refused.
Some services answer a legal order by resisting it. We think that is the weaker strategy, because it depends on a person, and a person can be jailed, gagged, replaced, or simply wrong. It is also unfair to the person.
Avano is built on the opposite principle: hold so little that an order produces nothing worth having. No accounts. No identifiers. No addresses. No sender field. No contact lists. No social graph. Nothing written to a disk. That is not a promise about how we will behave under pressure — it is a description of what our systems contain when nobody is under pressure at all.
We are not the originators of this idea. Signal's published answer to a subpoena demanding a user's name, address, correspondence, contacts, groups and call records was two timestamps, because that is all Signal has. We hold less.
Where we can comply, we comply. This is a lawful communications tool and we are not a jurisdiction of our own. If a valid order reaches us for something we actually have, we will produce it, and we will publish that it happened where we are permitted to.
What a valid order can and cannot obtain.
Ordered the way a request usually is. Each row is a technical statement about the system as built; the full inventory is here.
| If you request | We can produce | Why |
|---|---|---|
| Subscriber information for a user | Nothing | There is no subscriber. Avano requires no phone number, no email and no registration, and there is no accounts table anywhere in our infrastructure. There is no record that a given person is a user. |
| Account creation or last-connection times | Nothing | These do not exist because the account does not exist. This is the one thing Signal can produce and we cannot, and it is a deliberate difference. |
| Message content | Nothing readable | Messages are sealed end-to-end on the sender's device. We never hold a key that opens one and there is no point in the system where plaintext exists outside the two phones. |
| A user's contacts or groups | Nothing | Contacts and group membership live only on the user's device and are never uploaded. There is no contacts table and no membership list on any server we operate. |
| IP addresses | Nothing | The relay is reachable only as a Tor onion service and binds to loopback. Connections arrive from inside the Tor network. We do not discard client addresses; they never reach us. |
| Connection or access logs | Nothing | There is no logging on the relay's connection path. |
| Stored or historical messages | Nothing | Undelivered messages wait in memory only, expire, and are never written to a disk. There is no archive, no backup and no spool to seize. A warrant for the disk, or a snapshot request to the hosting company, produces nothing. |
| Data associated with a specific queue identifier | Possibly, and it is not useful | If you supply a queue code, we could in principle report whether that slot currently exists and holds sealed blocks. We cannot tell you whose it is, who deposited into it, or what is in it — and the blocks are opaque to us. Note that a queue code is only obtainable from a seized device in the first place. |
| The early-access email list | Yes | This is the one genuine record we keep. It is a list of email addresses submitted through the website form. It is not linked to any app use — there is no mechanism by which it could be — but it is real data and a valid order would reach it. |
| Prospective interception of a named user | Not possible | There is no user to name and no place to attach an instrument. This is the request that succeeded against another provider in a well-known case, and it is the specific attack this architecture answers. |
| A modified build for a specific person | Refused | See section 05. We would treat this as an order to compromise every user, resist it by every lawful means, and — where permitted — say so. |
Process.
- Send it to hello@avano.app, marked for the attention of the legal contact. This is the same address published for everything else; we do not maintain a separate law-enforcement portal and we will not pretend to have one.
- Include the legal basis, the issuing authority, and specifically what is sought. Given the table above, a request naming a user cannot be actioned even in principle, so a request that identifies what it wants technically will get a faster and more useful answer than one that does not.
- Emergencies. We have no dedicated emergency channel and it would be dishonest to advertise a response time we have never tested. Mark the subject clearly and it will be read as quickly as a small team can read it.
- Jurisdiction. The operating entity and its jurisdiction are not yet settled, which means we cannot yet state which orders bind us directly and which require mutual legal assistance or a European Production Order. This is the first question on our list for counsel and it is unanswered. We are not going to invent an answer here.
A named legal contact. A defined response time. A statement of which authorities we accept service from. A retention schedule for requests we receive. A defined escalation path. All five are missing because they depend on an entity and counsel that do not yet exist, and stating them would be inventing a process rather than describing one.
What we will tell the user, and the world.
Notice to the affected user is a promise we are careful about, because for the messenger there is no user we could notify — we have no way to reach anybody. For the early-access list, we intend to notify the affected address unless we are legally prohibited from doing so. Whether that intention can be stated as a commitment is one of the open questions for counsel.
Publication. We intend to publish every government and legal request we receive, and our answer to it, on our transparency page. To date we have received none, and that page says zero because zero is the number, not because the page is unfinished.
Warrant canary: we do not run one, deliberately. The legal theory behind canaries — that compelled silence and compelled speech are different — has never been tested in court. Practitioners consulted publicly by others in this field expect removing a canary to carry the same consequences as an explicit disclosure, and a secret order can simply prohibit triggering it. We will not build a user's safety on a gesture, and we would rather explain that than display a reassuring monthly signature. This decision is on the list for counsel to confirm or overturn.
An instruction to ship a build to one person.
The honest reading of how comparable services were actually defeated is that the attack was almost never on the cryptography. It was on the channel the operator used to reach its own users. EncroChat was reached through its update mechanism. Ghost was reached by modifying the operator's own updates. ANOM was a platform run from the start with an extra recipient attached to every message and hidden from the user's contact list.
So the request we would treat as categorically different from all of the above is an order to build or deliver a modified version of Avano to a particular user. That is not a request for records; it is a request to compromise every user of the product, because a channel that can deliver one targeted build can deliver any build, and once it has been used nobody can trust it again.
We would resist it by every lawful means and, where not prohibited, we would say that we had received it.
And we will not pretend our position is stronger than it is. The way Avano is distributed today — a hand-built package, signed with a development key, with no published manifest and no public log — means we currently have no technical defence against this at all, and neither do our users. It is the single largest gap in the product and we describe it in full on what you can check yourself. A transparency log does not prevent a compelled build; it makes one public. That is a real difference and it is not the same as prevention.
Two things worth knowing before you spend time on us.
The device, not the service. Everything meaningful in Avano exists on the endpoint. If a lawful investigation needs message content, the service is not where it is — we describe our own endpoint exposure candidly on the threat model page, including where a seized device does still yield information. We are not offering investigative advice; we are saying that a request to us for content is a request that cannot succeed for structural reasons and we would rather you knew that at the start.
We are not a service marketed to criminals. Avano exists for people whose safety depends on the fact of a conversation not being discoverable — journalists and their sources, lawyers and their clients, people organising where organising is punished, people leaving relationships that monitor them. We have never advertised the product as being beyond the law, we do not sell it through resellers into closed communities, we run no invite-only distribution, and everything we claim is published alongside what we cannot do. Our own documentation treats overstatement as a defect to be corrected rather than a style to be maintained.