Privacy Policy
We built Cloqd so your private communication stays private. Here's exactly what we collect, how we protect it, and the control you have over it.
Last updated:
Zero-knowledge when you choose it
Internal messages and mail you compose are encrypted in your browser, so no readable copy of them ever reaches us. Mail arriving from the internet reaches our server as plaintext — SMTP gives us no choice — and is sealed to your public key on arrival, before it is written down. Either way the stored copy is unreadable to us, and your private key never leaves your device unencrypted. For member-to-member messages we are the ones who hand your browser the recipient's public key, so each conversation carries a safety number the two of you can compare out of band to confirm we handed you the right one — section 2 explains it. It is a per-account setting, not the default — see section 2 for what each mode costs you.
Minimal data collection
We store only what's needed to run the service: your account, aliases, and the encrypted contents you choose to keep. We don't sell your data or run third-party ad trackers.
IP address masking
We never store raw IP addresses. Visitor addresses are shortened and irreversibly hashed with a key that changes daily, and with masking enabled your own address isn't recorded against your analytics at all.
You hold the keys
Your encryption passphrase is never transmitted to us. If you lose it, your zero-knowledge data is unrecoverable — that's the guarantee.
1. Data we collect
Account information: your name, email address, and authentication credentials (passwords are hashed; we never store them in plain text).
Service data: email aliases, message metadata, labels, and bio links you create.
Content: email bodies and internal messages. Depending on your chosen encryption mode, these are stored as plaintext, encrypted at rest with a server-managed key, or as zero-knowledge ciphertext we cannot read.
Mail sent to your aliases is stored so your inbox can show it to you — that storage is what the inbox, search and threading are built on. Forwarding to your own address, where you enable it, sends an additional copy; it is on top of the stored message, not instead of it. On the zero-knowledge tier forwarding is switched off, because a forwarded copy leaves our system readable and would defeat the setting. You can delete any message, or erase all of your email data at once, from Privacy & Security.
Usage analytics: the pages you visit in the app and the actions you take, so we can show you your own activity and improve the product.
Bio link visitor analytics: when someone opens a bio link you published, we record the visit along with the browser's user agent, the referring site, and an approximate country/city. We never store the visitor's raw IP address — see 'IP masking & metadata' below for exactly how it is shortened, hashed, and deleted.
2. How we encrypt your data
Standard: content is stored normally for maximum compatibility. Every feature works, including full-text search of message bodies, phishing scoring and the AI writing tools.
At-rest encryption: message bodies are encrypted on our servers using a managed key, protecting them in the event of a data breach. Encrypted bodies drop out of server-side search — you can still search by subject and sender.
Zero-knowledge: mail you compose and internal messages are encrypted in your browser with your personal key, so no readable copy of them reaches us. Mail arriving from the internet reaches our server as plaintext — SMTP gives us no choice — and is sealed to your public key on arrival, before it is stored. Each stored message uses a fresh, unique, random key and initialization vector; we keep only ciphertext and the public metadata needed to decrypt it on your device.
The limit of end-to-end encryption here, plainly: when you send a message to another member, your browser encrypts it to that member's public key — and your browser gets that key from us. The encryption itself is real. Nobody who steals the database can read your messages, we cannot read them, and there is no key on our side that opens them. What that alone does not prove is that the key we handed you was really your correspondent's.
So we publish a safety number, the way Signal and other serious messengers do. Every conversation has one: 60 digits derived from both members' public keys, shown identically on both screens, under 'Verify' in the conversation. Read it to each other over something we do not control — in person, on a call, in an app you already trust — and if the two match, no third key is in the conversation. Until you do that, the nobody-in-the-middle guarantee rests on our conduct; once you have, it rests on something you checked yourself. We record the number you compared in your own browser and nowhere else, so that we can tell you if those keys ever change, and so that we can neither see your verifications nor forge one. A verification we could grant on your behalf would be worth precisely nothing.
What zero-knowledge costs you: privacy this strong is paid for in features, and we would rather you knew before you turned it on than after. Anything we cannot read, we cannot act on — zero-knowledge messages are excluded from server-side search and the AI tools cannot work on them. Phishing is scored exactly once, on arrival, on the copy we hold in memory before sealing, and never again afterwards. Standard and at-rest keep the other features. This is an account-wide setting, not a per-message one.
Subject lines are stored readable on every tier, including zero-knowledge. The inbox list, notifications and digests display them, and PGP encrypts a body, not a header — protecting subjects needs a mechanism we have not built. If a subject would itself be sensitive, assume we can read it.
On the zero-knowledge tier, attachment contents are not stored — but each attachment's filename, type and size are recorded, so that 'no attachments' and 'attachments we did not keep' stay distinguishable. The filename is sanitised but readable, and a filename can say something even when the file is gone.
We hold the plaintext in memory during delivery on every tier, for the seconds it takes to sanitise it, score it and seal it. What the tiers buy is that it is never written down readable; what they cannot buy is that we never touched it.
| Tier | Live here | Why |
|---|---|---|
| Standard | Yes | Always available. Mail is stored readable, which is what full-text search runs on. |
| Encrypted at rest | Not yet | No server-side encryption key is configured on this deployment, so this tier cannot be applied yet: choosing it is refused, and mail for an account that chose it earlier is stored readable with a downgrade marker rather than silently labelled as encrypted. |
| Zero-knowledge | Yes | Needs nothing from our side: mail is sealed to the public key on your account, whose private half is generated in your browser or imported by you. |
3. IP masking & metadata
We never write a raw IP address to our database. Before storage, an address is shortened to its network prefix (the first three groups) and then irreversibly hashed with a secret key that rotates every day. The result cannot be turned back into an address, and because the key changes daily it cannot be used to follow anyone from one day to the next.
With IP masking enabled — the default — no address is recorded against your own analytics activity at all.
Security and compliance logs record the same daily-rotating hash rather than a raw address. We keep this on security events such as sign-ins, permission changes and administrative actions under our legitimate interest in protecting accounts against abuse — this is not analytics data, and it is not kept indefinitely: it is erased automatically after 90 days.
Visitor hashes on your bio links are erased after 30 days; the visit itself is kept only as anonymous aggregate statistics. Approximate location is stored no more precisely than about 11 kilometres.
We strip remote tracking pixels and known trackers from inbound mail, and we warn you about likely phishing before you interact with suspicious messages.
4. Your rights & controls
Export: download a complete, portable copy of your data as JSON at any time from Privacy & Security. Zero-knowledge content is exported as ciphertext alongside your passphrase-protected key so you retain access.
Erasure: permanently delete all of your email-service data — mail, encrypted messages, labels, and key material — without closing your account.
Account deletion: removing your account purges your associated records from our systems.
5. Data retention
We keep your data only while your account is active or as needed to provide the service. When you erase data or delete your account, the corresponding records are removed promptly.
Once zero-knowledge key material is deleted, any remaining ciphertext becomes permanently undecryptable.
| What | Kept for | Why, and measured from |
|---|---|---|
| Expired sign-in sessions | 7 days | A grace period measured from the moment the session expired, not from when it was created. Deleting the row the instant it lapses would destroy the only trace of a session during exactly the window an incident is likely to be investigated in. |
| Visitor identifier on a bio-link visit | 30 days | The hashed, daily-rotating visitor digest is erased from the visit record long before the record itself goes, so an old visit is anonymous even to us. |
| Mail you deleted | 30 days | Measured from WHEN YOU DELETED IT, not from when it arrived — so deleting a year-old message still gives you the full window to restore it. Starred mail is never swept. |
| Usage analytics | 90 days | Page views and feature usage are deleted wholesale once they pass this age. They are never linked to a raw IP address. |
| Source address on security and audit events | 90 days | Retained under our legitimate interest in protecting accounts against abuse, then erased. This is security forensics, not analytics. |
| Bio-link visit records | 180 days | Kept longer than analytics purely so long-run aggregate reporting survives — the only visitor-linkable value inside them is dropped far earlier, below. |
6. Who processes your data
The services below hold or handle your data on our behalf today. The list is rendered from the same module the transparency page reads, so the two cannot disagree; a processor that only joins after the mail infrastructure moves is not listed until it does.
Cloudflare Web Analytics is switched on at our Cloudflare account (measured 2026-10-07): Cloudflare injects a small script into every page it serves for us through its proxy, which today means pages on aliasvault.io, bio pages addressed there included. That script reports the page URL and load timings, with your network address, to Cloudflare. It sets no cookie. Hosts where Cloudflare only answers DNS carry no such script. It is the one third-party analytics script on any page we serve, and this sentence exists because three earlier documents said there was none.
Vercel
Hosting, and the blob store that holds attachments.
Every request to the app — the URL, your network address and browser — and the attachment bytes we store. Its Speed Insights beacon reports page-load timings and the URL to Vercel, same-origin, with no cookie.
Neon
The Postgres database.
Everything the app stores: accounts, aliases, mail (readable, encrypted at rest, or sealed, according to your tier), bio pages, credits. A copy of the database is a copy of all of it, which is what the at-rest and zero-knowledge tiers are for.
Resend
Receives mail sent to your aliases and sends the mail we send.
Every inbound message in full — their servers accept it, their webhook tells us it exists, and we fetch the body from their API. Every forward to your real mailbox also leaves through Resend as readable text. This is the single biggest reason the mail infrastructure is moving.
OpenAI, through the Vercel AI Gateway
The text model behind compose assist, the bio generator, alias suggestions and the chatbots.
Exactly what the AI section lists per feature: the draft or instruction you typed, the profile description, the alias you started typing, what you say to the chatbot. Never a message you received.
fal.ai
The image generator.
The image prompt you typed. Your browser then fetches the finished image from their CDN.
Upstash
The Redis store behind rate limits and the human-verification challenge.
Counters keyed on the address a request came from and, while a challenge is open, the challenge state. No mail, no account data.
Cloudflare
DNS for our domains, the proxy in front of aliasvault.io only, and Email Routing for beamd.lol.
Every request to aliasvault.io passes through it: the URL, your network address and browser. For the websites on our other domains, it only answers DNS lookups; the requests themselves go straight to Vercel and never pass through it. Mail sent to an address on beamd.lol is received by its Email Routing, in full; mail to our other receiving domains is received by Resend. Its Web Analytics beacon, when enabled at the account level, additionally reports page URL and timings from the pages it proxies to Cloudflare — see the analytics sentence on this page for the current state.
7. Contact
Questions about this policy or your data? Reach us through the in-app support centre and we'll respond as quickly as we can.