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. One well-known messenger'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 it 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 such a service 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 (messaging) | Nothing | The message 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. |
| IP addresses (during a call) | The call relay sees them while a call is live | Call media cannot ride Tor, so it goes to a call relay over the clear internet. That relay sees both callers' IP addresses and the call's timing while the call is up — never its contents, which are end-to-end encrypted, and nothing is written to disk. A memory image or netflow captured at that host during a call would yield caller IPs and timing. The app warns the user before every call. Video calls, offered on Android, take the same path, and this row applies to them unchanged; on iPhone video calls are not built yet. |
| Connection or access logs | Nothing | There is no logging on the message relay's connection path. The call relay handles callers' IP addresses in memory only while a call is live, and does not persist them. |
| Stored or historical messages | Nothing | Undelivered messages wait in memory only, expire, and are never written to a disk. At a planned stop the relay checkpoints its queue table to a RAM filesystem, and the start that restores it deletes the checkpoint; a crash keeps nothing. There is no archive and no spool on a disk 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 held only by the account owner's phone and by the contacts who send to it. |
| Whether an email address, phone number or username belongs to a user | Not today. When the discovery service runs, a guessed handle can be confirmed by whoever holds that service | Private discovery is built and not yet deployed. When it runs, a person who chooses to be findable registers an opaque value derived from their handle, a sealed pairing packet the service cannot open, and a public key; the service holds those three and nothing else, not the handle and not who registered it. The residual is the one the design states: a single operator holding the service's key and its table can confirm offline whether a handle it guesses is registered, and nothing more. The two-operator split removes that, and until it is deployed we will say that an order naming an address could get a yes or a no from us, and no content. A username is held in clear, because a username is public by its nature. |
| A backup a user made by email | The sealed blob, when the service runs | The backup by email is built and not yet deployed. When it runs, the relay holds the sealed account bundle for six months and the discovery service holds a card pointing at it. A valid order could obtain both. Opening the bundle needs the passphrase the user chose, which we never see; what an order yields is the chance to guess that passphrase offline, at the speed of the key derivation, and the app says exactly that to the person before they make the backup. |
| Posts in a channel or a community | Sealed posts, for their ninety days | A channel's posts are sealed to the channel's own key before they reach the relay, and the relay keeps them in memory for ninety days (a picture or a video in a post for fourteen). An order could obtain the sealed posts of a channel whose identifier it names. The relay does not know who reads a channel: a reader pays with a token that carries no identity and lets go of its connection after each poll. |
| Company seats and developer credentials | Nothing that names a person | A company's seats and a developer's credentials are issued blind: the operator's console holds the hashes of codes it issued and the keys it signs with, never a serial it could match to a phone, and the relay's meter counts tokens, not people. An order could obtain the console's hashes and keys, which identify no one. |
| IP addresses (messaging, the direct road) | Not today. When the direct road runs, while a phone in the Simple posture is connected | The relay's clear listener is built and not yet deployed. When it runs, a phone set to the Simple posture connects to the relay over the clear internet rather than through Tor, and the relay sees that phone's address for as long as the connection lasts, with no account and no identity behind it; the Strict posture keeps Tor and this row stays "Nothing" for it. Nothing is written down either way. |
| Email people send us | Yes | This is the one genuine record we keep: mail sent to [email protected], in our mailbox. The early-access form on the website is not connected and stores nothing. The mail 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 for messages. Narrower orders, yes | For messages there is no user to name and no place to attach an instrument: the message relay sees no IP address and no account. This is the request that succeeded against another provider in a well-known case, and it is the specific attack this architecture answers. Two narrower orders could be carried out, and we say so. Given a queue code obtained elsewhere, for example from a seized phone, the relay could be made to note when sealed blocks arrive in that slot and when they are collected: timing and counts only, from inside Tor, nothing readable. And an order naming an IP address rather than a person could be served at the call relay, which sees that address, the other caller's address and the call's timing while a call is live, never its contents. We record neither today. Whether the law can oblige us to build a way to is a question we have not yet had answered. |
| 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. |
The ground that fits nearly every row. Under the e-Evidence Regulation (EU) 2023/1543, the authority enforcing a European Production Order may refuse enforcement where the order does not concern data stored by or on behalf of the service provider at the time it was received (Article 16(4)(d)). We, as the addressee, may raise that ground, and the authority of the state where we are established decides. For the rows marked Nothing above that is the position exactly: the data was never stored, by us or for us.
Process.
- Send it to [email protected], 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 email people have sent us, 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 count every government and legal request we receive, and our answer to it, in the transparency report on the proof page, category by category, as far as the law lets us: an order that must stay secret is counted when we are allowed to count it, and not described. To date we have received none, and every count there is zero.
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 order still has to be answered. Even where the answer is that we hold nothing, a European Production Order or a domestic warrant arrives on a form with a deadline (ten days, or eight hours in an emergency, under the e-Evidence Regulation), and a provider that does not answer inside it faces penalties. “We hold nothing” is the content of our answer, not a reason an order does not reach us.
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. One service was reached through its update mechanism. another by modifying the operator's own updates. a third was 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 limits. 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 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, pre-release builds go only to people who asked us for them, 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.