No logs, by construction. The kind of no-log I like.

What I never record

• The sites you visit and the content of your traffic.
• Your DNS queries.
• The times you connect.
• Your source IP address.
• Your per-user data consumption.

To carry your traffic, my servers process your IP address, your DNS queries and the state of your connections in memory, for the duration of the connection. After that, none of this is recorded. Not "anonymized", not "aggregated", not "kept for 30 days": not recorded at all, anywhere. DNS answers stay for a while in a cache shared by all the users of the server, with no link to who asked for them.

What I know about you

A public key and an expiry date: that is the core of your customer file. Around it, a few short-lived technical records (replay protection, token issuance, 7-day backups), all listed in the privacy policy. Only abuse reported on one of your ports can add anything to it, detailed below.

Your key is generated by the app, on your device, with no name, no email, no sign-up. When you open Warren, the server checks one thing only: does this key have time left? A copy of the subscriber database would give access to no identity, because it contains none.

What is stored, and why

Here is everything that exists on my side, or with our processors:

• A billing register (amounts, dates, VAT country, payment references), kept for 10 years: an accounting and tax obligation. It does not contain your key, and your name only if you ask for a named invoice.
• With the payment processor (Stripe for cards): the usual banking data of a purchase. It never crosses paths with your key: the payment credits a code, which your app later exchanges for time. That missing link is the plan.
• If you exercise your right of withdrawal: the payment reference and refund address you give me, and the status of the request, kept for 12 months after it is closed.

What about auto-renewal?

Auto-renewal is an option, off by default. It is driven by your app, not by my servers. The charge authorization lives encrypted on your device: between two payments, my database contains nothing saying you auto-renew. You leave exactly the same traces as someone buying again by hand every month.

This is a problem our friends the other VPNs had not solved. Mullvad removed subscriptions in 2022 because running them forced its server to keep the link between your payment and your account for the whole life of the subscription. IVPN and Proton offer them, but keep the billing mandate on their servers. Here in the warren, that link never exists server-side: it lives in your app, and it disappears when you turn it off.

The three levels of discretion remain:

• Cryptocurrency or voucher: no auto-renewal, since nothing links one purchase to the next.
• Bank card, with or without auto-renewal: Stripe sees a payment toward a random purchase reference, never your key. The link between a payment and the code it credits only exists for the refund window (20 days), then it is severed. Enabling auto-renewal adds nothing to what I store.
• Purchases through Apple or Google: the store is the merchant and sees your purchase; it never sees your Warren key, and the technical link is severed after the store refund window.

Servers without disks

The exit servers run on an immutable system image, entirely in RAM: the root filesystem is read-only, state lives in memory, a reboot erases everything. Even port-forwarding allocations live only in memory.

The tool that builds these machines is called alpineAnywhere. I developed it and published it as open source: you can verify exactly what is running.

The one exception: abuse reported on a port

There is one case where I add something to an account. When a third party reports abuse coming from a port that is still open, I close that port, and nobody can take it back for 48 hours. That is the moment, and the only moment, I can learn which account held it: your app presents an encrypted tag whenever it opens a port, and only my central server can read it. I then record a warning against that account if it already held the port at the time of the reported abuse. Whoever took the port afterwards gets nothing. Three warnings within 90 days and the account is revoked for 12 months.

Before a report, nothing links a port to an account, and I keep no list of the ports you opened. After a report, I write three things: the report case (server, port, protocol, category, source, dates, with no account identifier, kept for 12 months then anonymised), the warning (a pseudonymous identifier of your account, the case reference, the category and the day, kept for 90 days) and, at the third one, the revocation (your account identifier and its dates to the day, for as long as it lasts). When it ends, I delete it along with your expiry date: your account is back to a key with no time, as on day one, and the unused time was refunded to you pro rata at the revocation, under section 12 of the refund policy. No destination, no content, no IP address. You see every warning in the app, you can contest it by writing to abuse@warrenbrowse.com with the case reference, and a warning recorded in error is voided, and so is any revocation it caused.

This is the price of port forwarding. Mullvad and IVPN preferred to drop the feature in 2023 rather than link a port to an account even once. Respect. I chose to keep it and to tell you exactly what it 'costs'.

What if an authority comes asking?

An authority can demand what I hold, in the forms the law provides. For an account never reported, the core fits in two columns: a public key, an expiry date. A reported account adds its warnings and, if it came to that, its revocation. I cannot hand over a history I never recorded. I can, however, be required to assist, with my hosting providers, a targeted interception authorised by law.