Privacy policy

1. Who we are and who this policy covers

Vardum is operated by an individual sole trader carrying on business in Australia ("the Operator", "we"). The Operator is a small business. While the Privacy Act 1988 (Cth) exempts many small businesses from some of its obligations, the Operator handles information as described in this policy regardless of any exemption that may apply.

This policy covers the Vardum mobile app for iOS ("the App"), including messaging, vaults, notes, steganography tools, identity and device-transfer features, and this website.

Vardum owns and operates the App's relay servers: a virtual server at Hetzner in Singapore, controlled directly by the Operator, who runs the service from Australia. The relay stores and routes encrypted content without its decryption keys. This website is a marketing and documentation site only; no web messaging client is offered.

2. How Vardum is designed: the short version

Message, note, vault and media contents are encrypted on your device before anything is transmitted. The servers hold ciphertext they cannot open.
Your cryptographic identity (a "Vardum ID") is derived from a public key generated on your device. Its private half never leaves your device.
Trust between people is established by comparing fingerprints out-of-band or pinning public keys, never by the server vouching for anyone.
Records on the servers are designed to be minimal, short-lived and, where possible, hard-deleted automatically.

The Operator receives no readable message, media, note or vault content. The sign-in label, routing records and network activity remain metadata, separate from encrypted content. Signing up without a phone number or email does not mean metadata-free operation; the details are below.

3. No phone number. No email.

Creating a Vardum identity needs no phone number, no email address and no name. When you create an identity, the App generates 24 random words on your device and derives from them, one way only, a random-looking sign-in label (in the form v…@veil.app) and a sign-in password. You never see or type either, and the label is not a real mailbox.

Accounts created before October 2026 may instead use an address-shaped sign-in value the user chose, real or invented. It was never verified, never contacted and never shown to anyone the user talks to. Those accounts can switch to 24-word sign-in in Settings.

What sign-in data remains

The sign-in label (derived, or chosen on older accounts) and a hash of the sign-in password. The label is a sign-in identifier, not proof of a real-world identity.
Account identifiers, creation dates and sign-in session data needed to operate the service.
Request-level operational metadata such as timing and sizes. See section 10 for how IP addresses are handled.

The sign-in label remains data held by the service. We do not claim it is encrypted at rest or that account and routing metadata disappear. Your 24 words are the only recovery path, and the service never sends recovery or verification messages.

4. Your Vardum identity and public key material

Your identity record contains only public material: your Vardum ID label (derived from the hash of your public key), your Ed25519 identity public key, your X25519 signed prekey and its signature, and an ML-KEM-768 post-quantum prekey. Private keys and your 24 words are generated and stored on your device only and are never uploaded.

Identity proofs use short-lived single-use challenges held for at most 5 minutes and deleted at first use.

Contact pins and display names

Pins (a contact's Vardum ID and public key, and whether you compared their fingerprint) live only in your device's local storage. The servers hold no contact book, no contact graph and no record of who you have pinned. The two exceptions are named where they appear: a contact-initiated session record names the two public Vardum IDs so the relay can deliver (section 5), and a group roster names each member's public key (section 6). Both are deleted with the session or the group.

Display names are sent inside end-to-end encrypted identity introductions. They are also written into the session record as plaintext display-name fields when a chat is created or joined, sourced from your nickname, so the relay operator can read that name for the life of that session; those fields are deleted with the session. The nickname itself is device-local and is never sent on its own.

5. Conversation records held by the relay

The relay holds session records and message envelopes. These are the price of asynchronous delivery; each field is listed here.

Session records

A random, unguessable session token and the two participating client IDs (random per-device identifiers, not identities).
Ephemeral public keys: ECDH public keys and post-quantum ML-KEM-768 public material.
SHA-256 hashes of each side's 256-bit write credentials; the credentials themselves stay on the devices.
The session fingerprint (a hash) and each side's fingerprint-verified flag.
Presence timestamps: while a conversation is open, each device refreshes its timestamp every few seconds so the other side can show presence.
Lifetime settings: burn-after-open, per-message lifetime, inactivity window and expiry timestamps.
Group fields where relevant: an encrypted group label, group key epoch and group public key material.
For contact-initiated sessions: the public Vardum ID and public keys of the requester, and the addressee's public Vardum ID.

Message envelopes

AES-GCM-256 ciphertext, padded to fixed-size buckets so sizes do not reveal content length precisely.
A nonce, a plaintext routing header (the sender's ratchet public key and counters; for groups, a per-message pseudonym and the group epoch), the envelope's byte length, expiry time, delivery state and protocol version.
Per-message sender tags: pseudonyms derived from ratchet keys, not stable identities.
Cover traffic: to obscure message timing and volume, the App submits decoy envelopes indistinguishable from real ones on the relay. Decoys are discarded by the recipient's device.

Burn-after-open is 5 minutes to 24 hours after the recipient opens the message; unopened messages expire 12, 24, 36 or 48 hours after sending, with a separate 30-day forum tier. Background fetching does not start the burn clock. Expired envelopes are discarded on read and physically removed by the relay sweeper every 2 minutes.

6. Group records

Groups support up to 100 members, including the creator. Membership records contain group routing tokens, public Vardum IDs and identity keys, join epochs, roles and signed attestations. These records are metadata, not message content. Group invitations travel inside the end-to-end encrypted conversation with each invitee.

Joining requires proof of possession of the member's identity key. Signed removal records can deny a removed identity. Group keys rotate manually at the creator's choice, plus automatically at 100 messages or every 24 hours. Removing a member does not erase keys or content they already received. Group labels are stored encrypted.

7. Vaults, notes, steganography and stored files

Vaults

A vault record stores only the label you give it, the private-storage location of its container, the container's size, and the key-derivation and cipher identifiers (PBKDF2-SHA256; AES-GCM-256). The container is encrypted on your device with a key derived from your passphrase; the passphrase never leaves your device and cannot be recovered.

Notes

Notes are stored as AES-GCM-256 ciphertext under a key derived from your 24 words; the key is never stored on the relay. The relay holds the ciphertext, its size and a nonce.

Media in conversations

Pictures, video and voice notes are capped at 25 MB per file and encrypted with a fresh AES-GCM-256 key on your device. The encrypted file goes to private storage, and the key travels only inside the end-to-end encrypted envelope. A small record binds the stored file to the session that sent it, so a credential from another conversation cannot fetch it. The relay sees the file's size and upload and download times.

Steganography

The steganography tools run entirely on your device. No record of embedding or extraction is transmitted or stored. Resistance to statistical steganalysis is explicitly not claimed (NC-01).

Unreferenced media files on the relay are purged after 49 hours, and an opened media message that burns has its encrypted file deleted from relay storage at the burn window, not just its envelope. Operational logs or backups are separate from live-record expiry and may persist until cleanup processes remove them. The relay has no content keys to decrypt residual ciphertext.

8. Device-transfer links

Moving your encrypted state to a new device creates a short-lived record: a one-time token, the private-storage location of an encrypted transfer bundle, the bundle's size, your account identifier and a single-use claim flag. The bundle is encrypted with a key that travels only in the link fragment, which is never sent to the server. Records expire after 10 minutes, work once, and are swept after expiry.

9. Data stored only on your device

The following never reaches the servers. It lives in the App's local storage or in memory, and losing it means losing the data:

Private keys. Your 24 words are shown once and not stored by the App at all.
Session keys, stored encrypted under a device wrap key, optionally sealed by the device's Secure Enclave, or kept in memory only with Nothing at rest.
The decrypted local message cache, stored encrypted, and switched off entirely when you turn off local history or use Nothing at rest.
Contact pins and contact nicknames; your own nickname.
App-lock settings: a salted hash of your app password and of any decoy or duress password. Automatic locking is fixed at one minute of inactivity.
Device preferences: read receipts (off until you allow them), hold-until-unlock, privacy settings and the self-destruct countdown.
Vault contents you have not yet uploaded, and all steganography inputs and outputs.

Deleting the App, entering your duress password, or using Settings → Delete account removes these. Because they exist only on your device, they cannot be backed up, exported or restored by us.

10. Our self-owned relay and network visibility

Vardum owns and operates its relay servers. The relay receives encrypted messages, media, notes and vault containers without the device-held keys needed to read their content.

What the relay can observe

The sign-in label, public identity keys, session and group routing records, timestamps, sizes, delivery state and expiry settings.
Network requests, including the source IP address as each request arrives, endpoints, timing and transfer sizes. The relay does not store IP addresses: for rate limiting it keeps only a keyed one-way code whose key changes daily and is deleted within 48 hours, and those rate-limit records expire within 24 hours.
Operational logs and storage or backup copies where retained. This policy does not assert zero logging, no backups or metadata-free infrastructure.

The relay also keeps aggregate daily totals for running the service: how many accounts, Vardum IDs and chats were created, and how many encrypted envelopes passed through (including cover traffic) each day, plus current totals. These are counts only, never linked to any account, identity or conversation, and are deleted after 400 days.

Your network provider can still observe that you connect to the service and roughly how much data moves. Self-owned servers do not remove device risks or global traffic correlation. A VPN or Tor you configure yourself can change the address the relay sees, but adds its own trust relationship.

11. This website, cookies and visit counting

This website is served from the Operator's own server. It sets no cookies, stores nothing in your browser, runs no advertising or third-party analytics, embeds no third-party content, and is configured to keep no visitor access logs.

To understand how the site is used, each page sends one small message to our own server with the page address, the name of the website that linked you (for example reddit.com, never the full address), an optional campaign tag from the link (?ref=), and a few button clicks (such as Join the beta). The server keeps only daily totals: page views, visitors, referring websites, campaign tags, phone or computer, and clicks.

To count visitors without tracking anyone, the server makes a keyed one-way code from your IP address and browser type. The key changes every day and is deleted within 48 hours, and the code is deleted within 48 hours, so no visit can be linked to you or to another day. Your IP address and browser details are never stored. If your browser sends Global Privacy Control or Do Not Track, you are not counted at all.

Data you choose to send us by email is handled as described in section 13.

The App uses device storage for the local state in section 9 and sign-in session data for access. It contains no advertising. No data is sold, rented, or used for profiling or targeted advertising.

12. What Vardum is designed never to receive in plaintext

Message, media, note and vault contents; session passphrases; app, decoy and duress passwords; private keys; your 24 words; contact relationships; and the keys to any stored file. These exist only on devices.

This design depends on the App reaching your device unmodified, the absence of implementation defects, safe key handling on your devices, and no compromised device or other software on it. The cryptography is self-reviewed; an independent cryptographic audit is planned. The public claims register states the scope and limits of the App's claims.

13. How and why information is used

The Operator uses the limited information it can access only to operate the service (route envelopes, run sessions, deliver vaults, notes and identity lookups); authenticate accounts and protect them (sign-in lockout, single-use tokens, rate limits); prevent abuse of the infrastructure; respond to messages you send us; and respond to legal obligations where lawfully compelled. There is no direct marketing, no marketing lists and no behavioural profiling.

14. Disclosure to third parties and law enforcement

The Operator does not sell or trade your information. Disclosure happens only to infrastructure services as needed to operate the relay or website (section 10); where required or authorised by Australian law, or compelled by a valid and enforceable request such as a subpoena or warrant; or where you instruct the service itself, for example by sharing an invitation link.

What compelled disclosure can and cannot produce

If lawfully compelled, the Operator could be required to produce the sign-in label; the metadata in relay records (timestamps, sizes, tokens, public keys, expiry windows, presence timestamps, nickname fields); and ciphertext. The Operator cannot produce message, note or vault plaintext, private keys, passphrases, passwords or 24-word phrases, because it never holds them. The Operator may be legally restricted from notifying you of a request.

15. Overseas hosting and international users

The relay and this website run on a virtual server in Singapore, operated by the Operator from Australia, so the records described in sections 5 to 8 are stored in Singapore. Where operation of the service involves overseas processing, the Operator applies the Australian Privacy Principles handling standard described above.

If you use the App from the EU, UK or elsewhere, you may have additional rights under your local law, for example under the GDPR. The Operator will honour access, correction, deletion and objection requests on the terms of this policy, noting that content the Operator never holds cannot be produced.

16. Retention and deletion

Message envelopes: unopened, 12, 24, 36 or 48 hours, with a separate 30-day forum tier; burn-after-open 5 minutes to 24 hours after opening. Removed by the two-minute sweep.
Sessions: hard-deleted the moment either side ends them, or automatically after the inactivity window you choose (1 hour to 30 days, or never).
Device-transfer links: at most 10 minutes, single use.
Identity-proof challenges: at most 5 minutes, single use.
Sign-in protection: five failed sign-in attempts lock the account for 10 minutes; fifteen failures from one network lock that network for 15 minutes. These records expire on their own.
Identities, vaults, notes and group records: until you delete them, or until account deletion.
Invitation windows for pending sessions: 24 hours.
Unreferenced media files: purged after 49 hours.
Operational logs and backups are separate from live-record expiry. Self-hosting is not a claim that no logs or backup copies exist.

Deleting your account (Settings → Delete account) permanently removes every record the account owns (sessions, envelopes, vaults, notes, group memberships, identities and transfer links) and destroys the device keys. It cannot be undone.

17. Security measures and their limits

Measures in the current build include AES-GCM-256 end-to-end encryption with a double ratchet (message keys are discarded after use); hybrid ECDH P-256 plus ML-KEM-768 key establishment, with X25519 signed prekeys for contact sessions; signed prekeys and server-verified identity publications; per-record credential checks; single-use, short-lived tokens; cover traffic; and hard deletion at expiry.

Limits, stated plainly:

The App runs on your device: the operating system, other software, swap and device backups are outside its control. Screen-capture deterrence cannot stop a camera pointed at the screen.
Relay request metadata, any retained logs and backups, and network traffic analysis remain distinct from encrypted content (section 10).
The cryptography is self-reviewed. An independent cryptographic audit is planned for early 2027; it is not a completed assurance.
Steganography remains detectable by advanced statistical analysis (NC-01).
A well-resourced observer can still infer that you use the service and roughly when.

Do not rely on the App as your only protection for high-risk content.

18. Data breaches

If the Operator becomes aware of a data breach involving information it holds, where serious harm to an individual is likely, the Operator will assess the breach and notify the Office of the Australian Information Commissioner and affected individuals as required under the Notifiable Data Breaches scheme, as soon as practicable. Because the Operator holds ciphertext and metadata rather than content, a breach of Operator-held records would not by itself expose message, note or vault contents.

19. Your rights and choices

Access and correction: you can ask what information the Operator holds about you and have it corrected. The App's Settings show most of it directly.
Deletion: sessions, notes, vaults, pins and identities can be deleted at any time; Settings → Delete account removes everything at once.
Content: because content is end-to-end encrypted, the Operator cannot produce copies of your messages, notes or vault contents. Keep your 24 words and vault passphrases safe.
Choice over features: local history, read receipts, hold-until-unlock, key storage and the self-destruct countdown are under your control in Settings.

20. Children

The App is not directed at children and must not be used by anyone under 13. The Operator does not knowingly collect personal information from children under 13; if any is discovered it will be deleted. Parents who believe a child under 13 has created an account should contact the Operator.

21. Changes to this policy

This policy is updated when practices change, with a new effective date at the top. Material changes will be surfaced in the App before or when they take effect. Continuing to use the App after the effective date means you accept the revised policy; if you do not, delete your account before that date.

22. Contact and complaints

Complaints about privacy are dealt with first by the Operator directly: write to support@tryveil.app. The Operator will respond as soon as practicable and aims to resolve complaints within 30 days. If a complaint is not resolved to your satisfaction, you may complain to the Office of the Australian Information Commissioner (www.oaic.gov.au).