Draft

This is an unreviewed draft and it is not in force. It was written in good faith from the system as built, by engineers rather than lawyers. It must be reviewed by qualified counsel — against the jurisdictions we operate in and applicable data-protection law — before it is published as a policy or relied on by anyone. The specific questions it depends on are listed here.

Legal · privacy policy

The shortest honest privacy policy we could write.

Most of this document is about what we don't collect, because that is most of the truth. The exhaustive version — every category, including the empty ones — is the data inventory.


Status: draft, not yet effective. Applies to: the avano.app website and the Avano messenger application (pre-release). Operating entity: to be confirmed — see the imprint, which is also incomplete for the same reason.

The short version

Avano is built to know as little about you as possible. You do not create an account. You do not give us a phone number, an email address or a name in order to use the messenger. We run no analytics and no advertising, and we do not sell data — there is essentially nothing that could be sold.

The one exception is the early-access list on this website, which is a genuine list of email addresses that people typed in. If that matters to you, do not use the form.

What the messenger collects

  • No account and no identifiers. Your identity is a key generated on your device from a recovery phrase, and it is never transmitted to us. We hold no phone number, email, name or username for you, and there is no accounts table in our infrastructure — not an empty one, none.
  • No contact list and no social graph. Your contacts and groups live only on your phone. Our relay has no contacts table, no group membership, and no sender field in its protocol at all.
  • No IP address. Messaging travels over a Tor client built into the app, to a relay published only as an onion service. Your address does not reach us — this is not a retention choice, it is a structural one.
  • Message contents. Sealed end-to-end on your device before they leave it. We never hold a key that opens one.
  • In transit. Undelivered messages wait in the relay's memory as sealed, identical-size blocks under random codes, with a time-to-live, and are never written to a disk. Their arrival time is held coarsened to the hour so that expiry can work.
  • On your device. Your messages and contacts are stored encrypted and can be locked behind a passphrase. That data stays on the phone; we never receive it. What a seized device does still yield is described honestly on the threat model — we would rather tell you than have you assume.
  • No notifications, no push. Avano has no push integration on any platform, so no third party is told that a message arrived for your device.

What the website collects

  • The email address you type into the early-access form, if you choose to. It is stored for one purpose — sending you builds and related updates — and nothing else is collected with it. Ask us to delete it at hello@avano.app and we will.
  • No cookies, no analytics, no advertising, no third-party requests of any kind. Every asset on this site is served from this origin, fonts included. There is no consent banner because there is nothing to consent to. The detail →
  • Hosting records. Our website host may keep transient technical records to deliver the service and prevent abuse. We do not use them to profile anyone and we do not hold a copy. We cannot currently state a retention period for them, because it is the host's and we have not confirmed it — so we are not going to write a number here.

Third parties

  • Hosting providers. The website and the relays run on commercial infrastructure. A relay host cannot see message contents or user identities. What such a host can do under legal compulsion is set out plainly on what a relay sees, because the alternative is letting the good news be over-read.
  • The Tor network carries messaging traffic and is operated by independent relays we neither run nor control.
  • Nobody else. No analytics vendor, no advertising network, no data broker, no push provider, no crash reporter.

Your rights, and where they hit a wall

Depending on where you live you may have rights to access, correct, export or delete data held about you. For the early-access list, exercising them is simple: write to us.

For the messenger, we want to be straight about something a normal policy would smooth over. We cannot fulfil an access or erasure request for your messages or your identity, and it is not because we are refusing. Nothing in our systems links a person to anything. We could not find your data if you asked, we could not confirm you are a user, and we could not verify your identity in order to try — there is no identity on our side to verify against. The remedy that does work is in your hands: erasing your identity in the app destroys everything locally, and undelivered mail expires on its own.

How this should be worded to be both accurate and legally sound is one of the open questions for counsel.

Children

Avano is not directed at children and we do not knowingly collect data from them. We collect no age-identifying information of any kind, which means we cannot determine any user's age and could not enforce a limit if we wanted to. Stated as a fact rather than as a policy, because a policy we cannot enforce is not a policy.

Legal requests

Because we hold so little, a legal request can only ever produce what our systems actually contain. That, category by category, is set out in our law-enforcement request policy, and how many we have received is on the transparency page. The answer today is none.

Changes

Avano is pre-release and this policy will change as the product and the infrastructure mature. Material changes will appear here with a date, and — once this document exists in a reviewed form — a proper effective date.

Contact

Privacy questions and deletion requests: hello@avano.app. Security issues: see reporting a vulnerability, which uses the same address deliberately.

Before this can be published as a policy

Counsel must confirm: the operating entity and its jurisdiction; whether a queue identifier held in relay memory is personal data, and what follows if it is; the lawful basis and consent record for the early-access list; retention periods for that list and for hosting records; whether processor agreements and a published sub-processor list are required; and the correct wording for access and erasure requests we structurally cannot fulfil. All of these are on the register.