Privacy policy.
This is the legally binding version of the claims in our no-logs audit pack. Where this policy and our marketing ever appear to disagree, this policy and the audit pack govern. We have written it to be specific and falsifiable rather than reassuring and vague.
1. Who we are
0trust ("we", "us") operates a privacy-focused mesh VPN service at
0trustvpn.com. We run three server nodes, in Switzerland,
Iceland, and Romania — all outside the Five, Nine, and Fourteen Eyes
intelligence-sharing alliances. Contact:
0trustvpn@proton.me (PGP key at
/.well-known/security.txt).
2. What we collect
The complete list of what we store:
- A SHA-256 hash of your account token (never the token itself)
- Your devices' WireGuard public keys and assigned mesh IPs (required to route packets to you)
- Your chosen region(s) and routing mode
- Your subscription expiry date, and the invoice ID and USD amount of what you paid — kept while the subscription runs and for 30 days after it ends (the refund window), then deleted along with the account
- 2 days of web-server access logs, with IP addresses truncated to the /24 (IPv4) or /48 (IPv6) before they are written
- Up to 7 days of application error logs on the control plane (tokens are hashed before logging; device keys never appear)
That is the entire list. If a category of data is not named above, we do not store it.
3. What we never collect
- Your real IP address (we never write it un-truncated)
- The websites or services you visit through the VPN
- The amount of data you transfer (bandwidth counters are disabled)
- The times you connect or disconnect, or session durations
- Your name, email, or phone number — we never ask for them
- Your cryptocurrency wallet address (our payment processor handles payment; the control plane only learns "invoice paid: yes/no")
- Any device identifiers, advertising IDs, or analytics
4. Data at each stage of using the service
| Stage | We learn | We do not learn |
|---|---|---|
| Signup | That an anonymous token was minted; an invoice was opened | Who you are |
| Payment | That invoice X was paid (yes/no), the USD amount | Your wallet, the transaction ID, your identity |
| Connecting | Your device pubkey + assigned mesh IP | Your real IP, your destinations, your traffic |
| Using the VPN | Nothing per-session — no logs are written | Everything about your activity |
4a. If you pay by card
Paying by card is not anonymous, and we will not pretend otherwise. Everything else on this page describes a service that holds no identity. A card payment is the one route that breaks that, and it breaks it completely.
When an operator has enabled Stripe or Square, choosing that option means:
- the processor receives your name, card number and billing address, and keeps them under its own policies, not ours;
- the processor knows you bought a VPN subscription, and from whom;
- the payment is reversible, which means the processor can be compelled to identify you after the fact;
- the processor can be asked for that record by a party who would get nothing from asking us.
What we receive is unchanged: a notification that an invoice was paid. We do not store your name, card number, or billing address, and no card data touches our servers — the payment happens on the processor's own page. But your identity now exists in a record that links to your subscription, held by someone else. We cannot delete it and cannot promise anything about it.
If that matters to you, pay in Bitcoin instead. Be clear about what that does and does not buy you: we learn no name, no email and no billing address, and there is no account with a processor linking you to this subscription. But Bitcoin is pseudonymous, not anonymous. Every payment sits on a public chain permanently, and if the coins reached you through an exchange that verified your identity, that trail exists no matter what we do. We issue a fresh address for every invoice, which stops your payments being trivially linked to each other here; it does nothing about where the coins came from. Cards exist as an option because some people would rather have a VPN bought with a card than no VPN at all — that is a legitimate choice, and it should be made knowingly.
4b. The /surf visitor proxy
/surf is a free page reader on this website. It is not the VPN, and it does not carry the VPN’s guarantees. Treat it as a separate service that happens to live on the same domain.
While you use it, our proxy server necessarily handles:
- the URL you asked for, in order to fetch it;
- your IP address, because you are making an HTTP request to us;
- a
ztv_viewscookie counting pages viewed, so the banner knows when to mention the trial. It holds a number and nothing else.
What we do with it: nothing beyond serving the page. Requested URLs are not written to disk, and the proxy service runs with its request log switched off. That is an operational choice we can change, not a mathematical guarantee — unlike the VPN data path, where the exit node genuinely cannot associate traffic with an account. If you need the strong property, use the VPN, not the proxy.
What the site you visit sees: our egress address, shared with every other proxy visitor, and no cookies, referrer or credentials from you. It does not see your IP.
What your ISP sees: that you connected to 0trustvpn.com. It does not see which page you read through the proxy, because that is inside TLS to us.
The proxy covers one browser tab. Everything else on your device continues to use your normal connection.
4c. Free trials
A trial account is created without payment, email, or any identifier. To stop bulk automated signups, your browser solves a proof-of-work puzzle; we store the puzzle’s random nonce so the same solved puzzle cannot be redeemed twice. The nonce is generated by us and is not derived from anything about you or your device.
A trial account holds exactly what a paid account holds: a hash of the token, an expiry date, and the public keys of devices you register. Paying later converts the same account; it does not create a linked record.
4d. DNS while you are connected
Your device is told to use 10.64.0.1 for DNS — an address
that exists only inside the tunnel, on the exit node carrying your traffic.
That is deliberate: if your device kept using your ISP’s resolver, every
site you visited would be visible to them in plaintext no matter how good the
tunnel was.
The resolver on the node does not log queries. It holds a short in-memory cache and nothing on disk; the query-logging option is switched off, and turning it on would contradict this page and our audit pack.
What it cannot do is answer by itself. Anything it cannot serve from cache goes to Quad9, and it goes there over DNS-over-TLS — encrypted, and authenticated against Quad9’s certificate, so the node knows it is talking to Quad9 and nobody in between can read the question. That matters because the alternative is what most of this industry still does: the tunnel protects your half of the path and then the exit node broadcasts every hostname you asked for, in plaintext, to its own hosting provider and everyone else along the way. If the encrypted connection cannot be made, the lookup fails. It does not quietly retry in the clear.
Quad9 itself still sees the queries — it is the one answering them. It has its own no-logging policy, which we do not control and cannot audit for you. What it sees comes from the node’s address, mixed in with every other customer on that node, so it cannot tell which of you asked. What changes with DNS-over-TLS is that Quad9 is now the only party that sees it.
Operators running their own deployment can point this at a different upstream, or at a resolver they run themselves. If you would rather not rely on any of that, set your own DNS in the client’s WireGuard config; the tunnel carries it either way.
4e. IPv6
Your tunnel always claims all of IPv6 as well as all of IPv4. That is what stops v6 traffic taking a route around us on a dual-stack network, which is one of the most common ways a VPN silently fails to cover everything.
Whether v6 is carried depends on the exit node you land on. Where that node has working IPv6, you are given a v6 address inside the tunnel and v6 traffic is masqueraded out of the node exactly as v4 is — a site sees the node’s address, not yours, and not a prefix unique to you. We deliberately do not hand out a per-customer IPv6 prefix: a stable prefix of your own would follow you between sites and networks, which is precisely the identifier this product exists to avoid.
Where the exit has no IPv6, you get no v6 address and v6 traffic is dropped
inside the tunnel. IPv6-only sites will not load on that connection. We would
rather break those than let the traffic out around us; 0trust
status shows which of the two you have.
5. We use no third-party trackers
Our website serves no advertising, no analytics, and no third-party scripts. Your browser contacts no external origin at all: the typefaces used to come from Google Fonts and are now served from this site, so no other company is told which of our pages you opened. Our content delivery network is the one exception, and §5a says exactly what it sees. We do not use cookies for tracking. The single piece of client-side state is your account token, which never leaves your device except as a hash sent to authenticate API requests.
We do count how the business is doing, and it is worth being exact about what that is: our operations dashboard counts rows we already hold — how many accounts exist, how many started as a trial, how many of those later paid, how many invoices were created and how many settled. Those are the records we keep in order to give you what you paid for, and counting them adds nothing to them. What we cannot tell you, because we do not have it, is how many people visited this page, which one they arrived from, or what they clicked. There is no script and no identifier anywhere on this site that could answer that, and we would rather not be able to answer it than install one.
5a. Our content delivery network
This website is served through Cloudflare, and being precise about that matters more here than the convenience is worth glossing over. Cloudflare is a content delivery network: your browser connects to a Cloudflare server near you rather than to ours, and Cloudflare opens a second connection to our origin. That means the encryption between you and this page ends at Cloudflare, not at us. They can see every request they carry, in clear, and they see your real IP address because they are the ones you connected to.
What that covers, honestly: which pages you read on this site, when, and from what address. Cloudflare is a United States company, and a US company can be compelled by US process. We chose it anyway because the alternative — a single origin server absorbing traffic and denial-of-service attempts directly — is a worse outage risk for a service people rely on to get online, and because what it carries is a public marketing site. You are entitled to disagree with that trade, which is why it is written here in as many words rather than left in a subprocessor list.
What it does not cover, and this is the part that matters. Your VPN traffic never touches Cloudflare. The tunnel runs from your device to a mesh node in Zurich, Reykjavik or Bucharest over WireGuard, and Cloudflare is not in that path at any point — it fronts the website, not the network. Reading this page and using the VPN are two different connections to two different places.
Whether Cloudflare also sees your account token depends on one
deployment choice, so here is how to tell rather than taking our word for
it. If api.0trustvpn.com resolves to an address that is not
Cloudflare's, the control plane is reached directly and your token never
crosses them. If the API is served from this same proxied hostname, then
Cloudflare does carry your token on every authenticated request, because
it carries the whole request. Run dig api.0trustvpn.com and
compare against Cloudflare's
published ranges; our audit pack documents the same check, and
scripts/audit-verify.sh reports which of the two this
deployment is doing.
We keep no logs at the origin beyond the two-day anonymised access log described above. Cloudflare keeps its own logs under its own policy, on its own schedule, and we cannot make a promise on their behalf — so we do not.
6. Legal requests & the warrant canary
Our structural defense against legal compulsion is that we don't hold the data most requests seek — there is nothing to hand over. Where a valid legal order in one of our jurisdictions compels us to act, we will comply with the law while disclosing as little as the law requires, and we will never voluntarily provide data we are not legally compelled to provide.
We publish a warrant canary, PGP-signed and re-signed weekly. If it stops being updated, treat its absence as a signal. We cannot lawfully promise the canary will always be accurate; that is precisely why it is structured as a canary rather than a promise.
7. Server seizure
Our mesh nodes are RAM-only ephemeral instances: their disk is a RAM-backed filesystem, swap is disabled, and WireGuard keys regenerate on every reboot. A physically seized node contains its base operating system image and nothing operationally relevant about customers. The control plane stores account tokens only as SHA-256 hashes.
8. Data retention & deletion
Web access logs: 2 days, then deleted automatically. Application error logs: 7 days. Account records: until your subscription expires, plus the 30-day refund window, after which an automated sweeper deletes the account row and everything attached to it — devices, invoices, notices. You can hasten deletion by simply not renewing; there is no account to "close", because there is no identity attached to it to close.
If you hold your token, we can act on a request; if you do not, we cannot. This paragraph used to say flatly that we could not perform a per-user export or deletion on request, and that was not right. The token IS the identifier: presented with it we can find exactly one account and delete it, and we will, the day you ask. What we cannot do is act for someone who has lost their token, because there is no name, address or email on the account to match them to — and a recovery flow that worked would be a way for anyone else to take the account. Section 12 sets out the rights this gives you and how to use them.
9. Children
The service is not directed at anyone under 18. We collect no information that would let us identify a user's age, and we do not knowingly provide service to minors.
10. Changes to this policy
Material changes will be announced in the warrant canary and reflected in the version number above. Because we have no way to email you (we don't have your email), the canary and this page are the canonical notice channel. Continued use after a change constitutes acceptance.
11. Independent verification
Don't take our word for any of this. The
audit pack documents every claim with the verification
commands that confirm it, and ships a script
(scripts/audit-verify.sh) that an independent auditor — or you,
if you self-host — can run against a live server to check that what we say
matches what the server does.
12. Your rights, and how to use them
Swiss law (FADP art. 25) and, if you are in the EU or UK, the GDPR (art. 15–21) give you rights over personal data about you: to see it, correct it, have it deleted, and take it with you. This section says how each one works here, including where anonymity cuts against you.
Access is self-service, and it is complete. Everything the control plane holds that relates to your account is readable by you, right now, with your token — there is no request to file and nobody to wait for:
$ 0trust status # plan, expiry, device cap $ 0trust devices # every device key on the account $ 0trust notices # anything we have sent you
That is the whole of it. Section 2 lists the fields and section 8 says how long each survives. There is no profile behind the token, no second table keyed to you, and nothing we could add to that output if you asked us to export it by email — which is why we would send you back to these commands rather than answer with a file.
Deletion is self-service too.
0trust remove <pubkey> deletes a device immediately.
Stopping paying deletes the account: it expires, and the sweeper erases the
row and everything hanging off it 30 days later (section 8). If you want it
gone sooner, email us from anywhere with your account token and we will
delete it that day. The token is the proof — we have nothing else to
check you against.
Where anonymity costs you something. We cannot identify you, so we cannot honour a request from someone who has lost their token. There is no name, address or email on the account to match you to, and a password-reset flow that worked would be a way for anyone else to take your account. If you lose the token, the data stays until it expires on its own. We would rather tell you that plainly than pretend to a recovery process we deliberately did not build.
Correction and portability have little to work on here. The only fields you can change are the ones you set — a device's label — and there is nothing to port to another provider but an expiry date. We mention them because the law does, not to pad the list.
Complaints. If you think we have handled your data wrongly, tell us first at 0trustvpn@proton.me. You can also complain to the Swiss Federal Data Protection and Information Commissioner (FDPIC), or to the supervisory authority where you live if you are in the EU, EEA or UK. You do not need our permission and you do not have to come to us first.
13. If we are breached
A privacy service that will not say what happens when it fails is not worth much. If we discover that customer data has been exposed:
- we notify the FDPIC as soon as we can, and any EU supervisory authority that applies, within the deadlines the law sets;
- we publish what happened on this site and in the warrant canary — those are the only channels we have, because we do not have your email address;
- we say what was exposed, when, and what we did, without waiting until the investigation is tidy.
What is at stake is smaller than at most services, and deliberately so. There is no email list to leak, no payment identity, no browsing history and no connection log — sections 3 and 7 set out what an attacker who took the whole control plane would actually get, and section 7 covers a seized node separately. That is the point of collecting so little: it bounds the worst day.