Found something? Tell us before you tell the world.
Write to hello@avano.app. 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.
A channel that silently drops mail is worse than no channel.
The conventional thing is to publish security@. We are not going to, and the reason is worth stating because it generalises.
A dedicated security address that 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. They believe they have disclosed responsibly and we never knew. That is a strictly worse outcome than having no security address at all, because at least an absent address makes a person look for a working one.
So the machine-readable file at /.well-known/security.txt lists hello@avano.app, deliberately, and this page agrees with it. If you have seen security@avano.app published elsewhere by us, treat it as unconfirmed and use the address above.
The same reasoning gave us that file in the first place. Before it existed, a request for /.well-known/security.txt returned the homepage with a success code, because the host falls back to the index page for any missing path. A researcher's tooling saw a valid response containing markup — which reads as a broken file rather than an absent one, and is worse than a clean not-found.
- Send enough to reproduce it: the affected component, the build, and the steps.
- Give us a reasonable window to investigate and fix before disclosing publicly. We will keep you updated rather than going quiet.
- Do not access, modify or destroy data belonging to other people, and do not degrade the service for them. Test against your own identity and your own devices.
- If you need encrypted contact before disclosing, ask for a key in your first mail — we have not published one and we will not pretend otherwise.
- We will acknowledge your report, tell you our assessment, and let you know when a fix ships.
- We will not pursue legal action over good-faith research that respects user privacy, avoids data destruction, and does not degrade the service for others. Whether that statement is binding as written is a question for counsel; we mean it either way.
- We will credit you if you would like to be credited, and not if you would not.
- If your finding contradicts something we have published, we will correct the page and record why the wrong version looked right, rather than quietly editing it.
Four classes of finding, in order.
This is not a scope restriction — send us anything. It is a statement of which findings would hurt a user most, so you know what we consider serious.
- Anything that links two conversing usersA way for a relay, a network observer, or a third party to establish that two particular people are in contact. This is the property the entire product exists to provide, so a break here is the most severe class of finding there is.
- Anything that reveals that a conversation happened at allIncluding timing, volume and shape attacks. For many of our users the fact of a conversation is the damage, independent of who was on the other end.
- Anything that survives “erase everything”If data we told a user was destroyed is recoverable, that is a promise we made and did not keep, and somebody may have acted on it under pressure.
- Anything that reaches a releaseOur build and distribution chain is the weakest part of the product and we say so on what you can check yourself. Findings there are welcome even though several of them are already documented by us — a second pair of eyes on a gap we already know about is still worth having.
If a claim on this website, in the app, or in a store listing is stronger than what the software actually 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. Send those to the same address.
No bounty, no key, no service-level agreement.
There is no paid bug-bounty programme and we are not going to advertise one until it is funded and real. Nothing about the process above is contingent on that — we will treat your report seriously regardless — but you should know before spending days on it that there is no payout at the end.
There is no published contact key. Key custody has not been arranged and publishing a key we cannot commit to holding properly would be worse than publishing none. Ask in your first message and we will sort out an encrypted channel.
There is no guaranteed response time. This is a very small team. We would rather say that than publish a number we have never had to meet.
Machine-readable version, kept in agreement with this page: /.well-known/security.txt