Who is responsible for your data
The data controller for Aura — the party that decides what is collected and why, and that you can hold to this policy — is Orgware Construct Pvt. Ltd., registered at Prachin Marg-10, Old Baneshwor Height, Kathmandu, Nepal.
The encryption boundary, stated per platform
Everything else in this policy depends on this section, so it comes first.
Android and desktop (macOS, Linux). Your device private keys are generated and held on your own hardware. Messages, attachments, notes and Vault contents are encrypted there before they reach us, and we cannot decrypt them. What we receive is ciphertext plus the routing metadata listed below.
The hosted web app at app.auratt.com. The browser page contains no encryption code. Your device private keys are held by an Aura process running on our servers, which encrypts outgoing messages and decrypts incoming ones on your behalf. On this surface your message plaintext exists on our infrastructure, and we are technically able to read it.
We do not read, log, scan, profile or monetise hosted-web message content, and nothing in our code does so. But you are relying on our conduct, not on mathematics. If you need a guarantee that survives our goodwill, a subpoena, or a breach of that server, use the Android or desktop app, where we never hold the keys.
What we collect
This list is exhaustive for the server side. If something is not here, we do not collect it.
| Category | Precisely what | Why |
|---|---|---|
| Identity | A display name you choose, your public keys, and your device list (device name, which may be a model number or a name you typed, and its public keys). | To route messages to you and to let others verify they are talking to the right device. |
| Message content | Encrypted envelopes and encrypted attachment blobs. The MIME type and byte size of an attachment travel in the clear; its contents do not. | To deliver messages to devices that were offline when they were sent. |
| Routing metadata | Identity and Reach Contract identifiers, conversation identifier, sending device credential, object class, ciphertext size, timestamps, delivery sequence and acknowledgement, and short-lived presence and push-routing state. | Unavoidable: this is what makes delivery possible and what enforces the permission model. |
| Contacts | If you use contact import: keyed HMAC-SHA256 hashes (with an app-wide pepper baked into every build) of normalised phone numbers and email addresses, hashed on your device. Display names are never transmitted. The pepper defeats generic precomputed dictionaries of plausible numbers — it does not defend against a targeted attacker who has extracted it from the app itself, so we still won't call these hashes anonymised, only pseudonymous. Accounts created before this scheme shipped may still be matched by an older, plain (unkeyed) hash until they next open the "Find contacts" screen, at which point they upgrade automatically. | To find which of your contacts already use Aura, without uploading an address book in the clear. |
| Call metadata | Caller, callee, timestamps, and for group calls the initiator, host, status, and start and end times — from which duration is derivable. Call media itself is peer-to-peer and is not recorded; recording is not implemented and is disabled server-side. | To ring the right device and to show you your own call history. |
| Push token | On Android, your Firebase Cloud Messaging registration token. | To wake the app when a message arrives and it is not running. See Third parties. |
| Security and audit records | A hash-linked log of security-relevant actions on your account: device authorisation and revocation, recovery attempts, moderation decisions and appeals, account deletion. These record that an action happened, by which device, and when. | To make account takeover detectable and moderation decisions reviewable. |
| Appointments | If you use appointments, the IANA time-zone name of the device that created one (for example Europe/Berlin) travels with it. |
So both sides see the same appointment at the right local time. It is a coarse regional signal; we treat it as one. |
| Business features | If you operate a business account: the business record, its DNS-verified domain, member list, campaign and webhook configuration. | To run those features and to prevent domain impersonation. |
| Purchase data (Aura Pro only) | If you buy a Plus subscription in the separate Aura Pro app: the Google Play purchase token, product and subscription status, and its expiry date. We do not receive your card details, billing address, or any other payment information — that stays between you and Google. Aura Pro is a separate, optional app from the Aura messenger and has no messaging or address-book features of its own. | To verify the purchase with Google and grant the matching entitlement to your Aura identity. |
The hosted web app additionally processes, on our servers, the plaintext of the messages it is sealing or opening for you at that moment — see the encryption boundary. It is processed in memory to perform the operation you asked for and is not written to a message store in readable form.
What we don't collect
Stated positively because it is unusual, and because it is checkable in our source:
- No analytics, telemetry or crash reporting. There is no Crashlytics, Sentry, Google Analytics, Amplitude, Mixpanel, PostHog or App Center anywhere in the app. Diagnostics are kept on your device, capped at 500 entries, and are not uploaded.
- No advertising identifier, no ad SDK, no tracking pixels, on the apps or on this website. There are no cookies on this site.
- No phone number and no email address. Signing up requires a display name and a passphrase. We have no way to email you, which is exactly why the support page matters.
- No location. There is no location plugin in the app and no GPS or network-location permission. The time-zone name noted above is the closest thing, and it is coarse.
- No payment data in the Aura messenger app. There is no billing, no in-app purchase and no payment form in it. Plans are bought outside the app entirely — see what we collect for the one exception, the separate Aura Pro app.
- No message content scanning for advertising, model training, or any other purpose, on any surface.
Third parties
There is exactly one third party in the data path: Google, through Firebase Cloud Messaging (FCM), on Android only.
When your phone is not running Aura, the operating system will not hold a connection open for us, so we ask Google's push service to wake the app. The payload we send Google is data-only and contains an envelope identifier, a mailbox reference and an object class — no message content, and no ciphertext. The app then fetches and decrypts the actual message over Aura's own connection.
What Google can therefore see: that a particular device registration was woken, roughly what class of thing woke it, and when. That is unavoidable on a stock Android device, and it is the reason we describe the push as a doorbell rather than a letter. Google's handling of that data is governed by its own privacy terms, not this policy.
The desktop and web apps do not use FCM; they receive messages over Aura's own connection while they are open.
Beyond that: our servers are operated on infrastructure we rent, and a TURN relay may carry call media when a direct peer-to-peer connection cannot be established. We do not sell, rent or share personal data with anyone for their own purposes, and there is no advertising relationship of any kind.
Legal basis
For users in the UK, EEA and other jurisdictions with equivalent law, we rely on:
- Performance of a contract (GDPR Art. 6(1)(b)) for everything required to run the service you asked for: your identity record, device list, routing metadata, message delivery, calls and appointments. Without these there is no product.
- Legitimate interests (Art. 6(1)(f)) for security and abuse prevention: the audit log, rate limiting, replay protection, and handling reports. Our interest is keeping accounts from being taken over and keeping the service usable; we have kept the data involved to the minimum that serves that purpose.
- Consent (Art. 6(1)(a)) for contact import, which is entirely optional, initiated by you, and refusable without losing anything else. You can stop using it at any time.
- Legal obligation (Art. 6(1)(c)) where we are required to retain or produce something — see retention.
How long we keep it
These are the periods our code actually enforces, with the defaults our own deployment runs on. We have deliberately not written down a period we do not implement.
- Delivered messages: 30 days after your device acknowledges them. Once a device has collected an envelope, the routing record is pruned 30 days later, and the ciphertext itself is deleted as soon as no recipient's mailbox still points at it. Your device keeps its own copy; the server's is transient.
- Undelivered messages: kept until delivered. An envelope no device has collected is never pruned by age — a phone that has been off for a year still receives its backlog. There is also a cap of 10,000 stored entries per account, and when it is exceeded the oldest already-delivered entries are dropped first; undelivered ones are never dropped to make room.
- Attachment blobs: not currently pruned. Encrypted attachment bytes are stored separately from message envelopes, and the retention job above does not yet remove them. In practice an attachment's ciphertext can outlive the message that referenced it. We would rather disclose that than imply a sweep that does not exist.
- Transient state: minutes to hours. Replay nonces, presence leases, recovery challenges, signed download links and unused key packages expire and are pruned automatically.
- Security and audit records: retained indefinitely, including after account deletion. See the next section — this is the most important retention fact on this page.
- Local data on your own device is kept until you delete it, and is not governed by any server-side period.
Your rights
Where the GDPR or a comparable law applies to you, you have the right to access your data, to receive it in a portable form, to have inaccurate data corrected, to have data erased, to restrict or object to processing, and to withdraw consent where we relied on it. You also have the right to complain to your national data protection authority.
Access and erasure are self-service and immediate — see the two sections below. For the rest, or if a self-service route does not work for you, use the support page. We aim to respond within one month, which is the statutory period.
One honest limit: because we hold no email address or phone number for you, we cannot verify who you are except through your Aura account itself. A subject request that does not come from an authenticated Aura device is one we have no reliable way to authenticate, and we will not hand over account data on the strength of an unverifiable claim. This protects you; it also means the in-app routes are the ones that genuinely work.
Getting a copy of your data
On Android: Settings → Export my data. This produces a single JSON file combining everything held on your device with everything the server holds about your identity — devices, Reach Contracts, connection requests, relationships, conversation memberships, key packages, business records, workloads, security events and audit entries. You then save or share that file wherever you like.
Separately, Settings offers Export messages, notes, and calls to a file, for moving history to a newly linked device. That file is unencrypted on disk for as long as it exists — move it directly between your own devices and delete it once you have imported it.
On web and desktop: there is no export button in the interface today. The server-side half of the export exists as an API but no client surfaces it. Until one does, use an Android device on the same account, or ask through the support page.
Note what an export of an end-to-end encrypted service can and cannot be: the server half contains no message content, because we do not have your message content in readable form. The readable half comes from your own device.
Deleting your account
Full instructions, including for people who no longer have the app installed, are on the account deletion page. In short: on Android, Settings → Delete my account, confirmed by typing a phrase and re-entering your passphrase. It is irreversible and it also wipes the app's data from that device.
Deletion removes your identity record, your devices, your Reach Contracts and relationships, your connection requests, your key packages, your own mailbox and its contents, your appeals, and your membership of every conversation you were in.
Two things deliberately survive deletion, and you should know about both before you rely on the word "delete":
- Audit log entries are retained, and they are not anonymised. They record which device performed which security-relevant action and when, including the deletion itself. We keep them as the server's own compliance record — it is how a later dispute about whether an account was deleted, or a device revoked, can be answered at all. They do not contain message content.
- Encrypted messages you sent to other people stay in their mailboxes. When you delete your account, envelopes already fanned out to other members' undelivered mailboxes are left in place. They are opaque ciphertext to us, and they belong to the recipient's conversation as much as to yours — deleting them would be deleting someone else's mail. They age out under the ordinary retention rules above once collected.
If you believe an audit entry about you should not be retained, raise it through the support page; the balance between our record-keeping interest and your erasure right is one we will look at case by case rather than refuse by default.
Children
Aura is not for people under 16. During signup you are asked to confirm that you are 16 or older, and you cannot complete signup without confirming it.
That confirmation is self-attested and unverified. We do not check ages, because checking would mean collecting identity documents or a phone number — exactly the data this product is built not to hold. We would rather say plainly that the gate is a declaration than imply an assurance we do not perform.
If you believe someone under 16 has created an Aura account, tell us through the support page and we will remove it. We do not knowingly collect data from children.
Device permissions
Camera, microphone, notifications, contacts and file access are requested only when you use the feature that needs them, and you can change or withdraw them in your operating system's settings at any time. Declining a permission disables that feature, not the app.
On Android, Aura also runs a background service to keep collecting messages while the app is not in the foreground, and may ask to be exempted from battery optimisation so that it keeps working. You can refuse; messages will then arrive when the app is opened or when a push wakes it.
Sharing outside Aura
When you move content out of Aura through another application, a share sheet, or an external link, it leaves our protections behind and the destination's terms apply to it from that moment. Aura always presents external sharing as an explicit action you take, never as an automatic sync.
Public directory listings — the opt-in "find me by handle" feature for a personal identity — are opt-in. If you do not opt in, you are not discoverable by search. Listings use an opaque handle rather than your internal identifier, bulk listing of the directory is disabled, and result counts are capped, so it cannot be scraped into a user list.
This is separate from a business's Service Catalog listings, which a business explicitly marks public to be found: those support browsing without a search term ("Discover" self-discovery), the same way a storefront listing is meant to be seen rather than only found by a query. A business controls this per listing and per service, and can unpublish either at any time.
Changes to this policy
We will update this page as the product changes, and the effective date at the top will change with it. Where a change materially reduces your protections, we will surface it in the apps before it takes effect rather than relying on you to re-read this page.
Contact
For privacy questions, subject access requests, erasure requests or complaints: [email protected], or by post to Orgware Construct Pvt. Ltd., Prachin Marg-10, Old Baneshwor Height, Kathmandu, Nepal.
Every contact channel that is actually live today is listed on the support page, which is kept honest about which routes are monitored and how quickly. Security vulnerability reports have their own route, published at /.well-known/security.txt.
If you are in the UK or EEA and are not satisfied with how we have handled a request, you can complain to your national data protection authority. You do not have to come to us first.
AURA