Privacy policy

Digital Services LLC operates ForestVPN. This policy covers the ForestVPN apps for iPhone, iPad, Mac and Apple TV, for Android phones and tablets, and for Android TV, the desktop apps for Windows and Linux, the Linux command-line client and the router app, the servers that carry your traffic, and this website.

Our commitment

ForestVPN does not sell, use, or disclose to any third party the data described in this policy, for any purpose, other than as strictly necessary to operate the service — that is, Apple or Google for payment, and the infrastructure providers listed below, each acting solely as a processor on our instructions and under contract. We do not run advertising, we do not profile you, and we do not share anything with data brokers, analytics vendors or attribution networks. There are none in the app. One exception is not a processor of ours: when your network’s DNS fails or our servers cannot be reached at the addresses it gave, the app may ask a public DNS resolver (Cloudflare, Google or Quad9) for the address of our own servers, and that resolver sees your IP address under its own privacy policy. See what happens when you connect.

The app contains no analytics SDK, no attribution SDK and no advertising identifier, on any platform. On Apple platforms this is stated in the app’s privacy manifest, which declares no tracking and no tracking domains. It declares ten data types. Nine are marked as linked to your identity: a user identifier, a device identifier (a pseudonym that is joined to your account whenever you attach one), purchase history, coarse location, customer support content, other user content, diagnostic data, performance data and other usage data. One, product interaction, is not linked: the support assistant counts which screen it was opened from, whether you chose to share diagnostics and whether its answer fixed the problem, with no device or account tag. Apple’s form takes one answer per data type, so diagnostic data and coarse location are marked linked because the report you choose to send and the credential-issuance counters are, even though route reports are not. Nine types are used for app functionality, and eight are also used for our own counters described under analytics. On Android the app never requests the advertising ID and adds no analytics, attribution or crash-reporting SDK of its own. The one third-party library that reaches Google is the Google Play Billing Library, which Google requires for in-app purchases and which operates under Google’s own privacy policy.

What we never have

• Your browsing. There is no field anywhere in our systems for the sites you visit, the names you look up, or the addresses you connect to. Not a short retention period — no such column exists.
• Your identity. There is no email address, no password, no phone number and no name. An account, if you create one, is a 128-bit random number. The accounts table has no contact field of any kind.
• Your card. Payment happens at Apple or Google, or — if you buy on the web — at the processor you choose: Stripe, CloudPayments or NOWPayments. Apple gives us a signed receipt and a device-derived token; for a Google Play purchase, we verify the purchase token the app forwards us — alongside a device-derived token attached to the purchase — directly against Google’s own servers, never taking the app’s word for it alone. A web purchase gives us a one-time reference number we generate ourselves, never your card. Either way we never see a card number, and for a crypto payment the processor is the only party that sees anything at all. See paying by card or crypto.
• Extra permissions on Android. The app asks for two things at runtime: the system’s own VPN-connection consent dialog, and, on Android 13 and later, permission to show notifications — asked once, the first time you connect, never at cold launch — covering the ongoing connection status, warnings when your data allowance runs low or ends, and connection problems. It does not ask for your location or your contacts. Two further permissions it declares stay entirely on the device and are never sent to us: reading the installed-app list, for the split-tunnelling screen that excludes chosen apps from the tunnel, and the system’s fingerprint, face or screen-lock prompt, to gate revealing your own account number on-screen.

What lives on your device

A machine key

On first launch the app generates a key pair that stays on the device: in the system keychain on Apple platforms; on Android, in the app’s private storage, encrypted with a key held in the Android Keystore. It is marked so it never leaves that device — not to your other devices, not to iCloud, and on Android not into any backup or device-transfer copy either. It is not an advertising identifier and it is not shared with anyone. We store a hash of its public half, which is how a device is recognised across launches.

On Apple platforms it is permanent. It is never rotated, and it survives deleting the app. Reinstalling there does not give you a new identity — the reinstalled app presents the same key and is recognised as the same device. This is deliberate: it is what stops one device claiming an unlimited number of free allowances, and it means uninstalling is not a reset there, which you should know before you install. On Android the key does not survive uninstalling the app or clearing its storage. A reinstall generates a new key and is registered as a new device, and the old device record stays on our side, orphaned, under the retention set out in the table below. The app also replaces its key once, in place, if our servers ever report the old one unknown.

A session key

Each ticket carries its own session key, generated on the device when the ticket is issued, before any connection is attempted. It is kept, encrypted, in the platform’s own local storage — the system keychain on Apple platforms, the app’s private storage on Android — until the ticket is used or expires, and a spare ticket minted for the same connection may share the key of the one it backs up. It never leaves the device except as its public half.

Accounts, subscriptions and allowances

One service issues connection credentials and keeps the records a subscription needs. It holds:

The ticket binding row above is the one exception, and it is stated here rather than left off the table: while it exists it names both your device and the session it belongs to, which is what lets a settled session be charged against your allowance and a revoked device be cut off mid-session. It is deleted automatically, not by request — an hour after the session it names settles, or when the ticket itself expires unused, whichever comes first. None of these records, including that one, contains an exit server, the address you connected from, or anywhere you went: the issuing service never learns any of those. They exist only at the separate service described in [what happens when you connect](#session), which has no way to look up who you are. The diagnostic report row above is held at a third, separate service too — an unsigned upload the issuing service never sees and cannot join to a device.

The credential itself

To connect, your device asks this service for a ticket. The ticket is blind-signed: the signature is produced over a value we never see, so the ticket you present at connect time cannot be recognised as the one issued to you. It carries exactly two facts — which tier signed it and which fortnight’s key was used — and nothing else. The issuing service never learns a location, an exit, a session, or whether a tunnel ever came up.

Paying by card or crypto

Apple or Google bills every subscription bought in the app, and we never see a card number. On Apple platforms, Apple sends us a signed receipt and a device-derived token. On Android, before checkout our servers give the app a token derived from the device key; the app attaches it to the purchase as Google Play’s obfuscated account id, and Google returns it whenever we verify the purchase, so the subscription can be matched to the device that bought it — it carries no name, email or card. The app also forwards the purchase token and product id Google Play hands it to our servers, which verify the purchase directly against Google’s own API rather than trusting the app; Google separately pushes us a Real-Time Developer Notification when a subscription changes, which we treat as a prompt to re-verify with Google, never as proof on its own. A subscription can also be bought on the web, through a card processor — Stripe or CloudPayments — or a crypto processor, NOWPayments, and that path is different enough to describe on its own.

When you check out on the web, we mint a one-time reference number ourselves and hand that to the processor — never your account number. Under this policy the account number is a credential; putting it in a payment processor's dashboard, webhook payloads or support tooling would be publishing a password. The reference expires within the hour and, held on its own, opens nothing.

What we keep from a web purchase: which processor billed it, that processor's own subscription id, the tier, the date it is paid until, and whether it has been cancelled or revoked. What we never receive and never store: your name, your email, your billing address, your card fingerprint, or — for a crypto payment — anything about you at all. The code that writes a payment row has no field that could hold any of those; adding one would be a visible, reviewed change to a file everyone building a payment rail has to touch, not something a bug could do quietly.

Stated as plainly as we can: a records request served on us produces a tier and a paid-until date. The same request served on the payment processor produces a person and a card. That is deliberate. It is the trade of paying on the web instead of through Apple or Google, and it is also why we would rather this data sit with a company built to hold it than sit with us as well.

Cancelling an app-store subscription happens in the store's own settings: Settings → Apple ID → Subscriptions on Apple platforms, or the Subscriptions screen in the Google Play Store app on Android. A card subscription is cancelled through the processor's own customer portal, which authenticates you by the email it holds — not by us, since we hold none. A crypto payment buys a fixed term and simply expires; there is nothing to cancel.

If you lose your account number after a web purchase, support can ask the processor to refund you, but cannot restore access — there is no email or password on our side to prove the purchase was yours. A crypto payment cannot be refunded at all. We would rather you read both of those sentences before paying than after.

What happens when you connect

A separate service accepts the ticket and opens the session. It sees the address you are connecting from, the location you chose and your one-time session key, and it holds a session record containing the tier, the epoch, that session key, the exit, your tunnel addresses, an expiry and a byte budget. The record deletes itself when the session expires. Your source address is never written into it.

This service has no database binding at all. It has no handle by which an account or a device could be reached, so a bug on the connect path cannot write your identity into a session record — there is nothing to write it with. A build job named the privacy seam holds fails the build if that binding is ever added. This is the one privacy property here that does not depend on us behaving well.

Before connecting, the app needs the addresses of our own servers. It asks your network’s DNS first. When that fails, is slow to answer or returns a wrong answer, has done so before on the same network, or our servers cannot be reached at the addresses it gave, the app may also ask Cloudflare (1.1.1.1), Google (8.8.8.8) or Quad9 (9.9.9.9) over encrypted DNS, alongside your network’s DNS rather than instead of it, for the addresses of our own servers only, never for a site you visit. Each of these operators has other public addresses the app may use. On a network whose DNS answers promptly and correctly and where our servers can be reached at those addresses, none of them is asked. Each one it asks learns the IP address the question comes from, the time, and that this device looked up one of our server names — nothing else: no account number, no session credential, nothing you browse. We send them nothing beyond the lookup, and each applies its own privacy policy to what it receives. If we ever let the app ask another DNS provider, we will name it here before it does.

Carrying your connection through a CDN

On some networks, our own servers are blocked or slowed down by address or by name. When that happens, the app may automatically use a content delivery network (CDN) instead of connecting to us directly. There are two such routes: on Pro and Premium plans, it may relay your encrypted tunnel through the CDN instead of connecting to our server directly; and for its own requests to our control services, such as the signed server list and session tickets, it may use the CDN as well. Today Bunny.net can carry either route, while Gcore may carry only the app's own requests to our control services, not the tunnel; Fastly is wired up the same way and may carry this traffic in the future. This is automatic and used only when your connection needs it. It never changes what we collect about you: the CDN only relays bytes, the same way it relays any ordinary website's traffic, and it cannot read your account number or your session credential.

A CDN relaying your connection is set up to reach one specific server of ours — an exit server for the tunnel, a relay server for requests to our control services — and while your connection passes through it, it does see the IP address you are connecting from, the hostname of our relay endpoint, the time and timing of your traffic, and a coarse read of the connection — your rough location and a fingerprint of how your device makes a TLS connection, the kind of signal any HTTPS relay can compute — the same as it would relaying any other encrypted website. It does not see what is inside: WireGuard encrypts the tunnel end to end between your device and our exit server, requests to our control services are encrypted between the app and our relay server, and the CDN carries both without opening them, so it never learns which of our services a request is for. Our own servers discard that coarse read on arrival and never store it; what differs by provider, below, is whether the CDN itself keeps a record joining your IP address to the server it relayed you to.

• Bunny.net carries this traffic today. We turn its request logging off on our zones, so Bunny does not keep a record joining your IP address to the server you reached.
• Gcore may carry only the app's own requests to our control services, not the tunnel, and will not carry the tunnel unless we first say so here. Unlike Bunny, Gcore's logging cannot be turned off on our account: it keeps the IP address you connect from, the hostname the request was addressed to and the time for 3 days, and anyone holding a token on that account can read it. Gcore also passes your IP address on to our server in a request header, which our server discards on arrival and never stores. We are disclosing this rather than hiding it, and we will stop relying on Gcore for this, or turn it off, the day Gcore lets us.
• Fastly does not carry any of our traffic yet. If it starts to, we will describe here what it can see, the same as for the other two, before it carries anything.

None of these three can read your account number or a login credential, and none is given a way to tie the connection it relays back to who you are on our side. To decide whether a network needs the CDN, the app keeps a small note on your device for each network it has connected from, filed under a hashed name for that network: whether the CDN was needed there, the day it last learned that, and the public location names that worked. It never holds an address, a server or a network name in the clear, and it is left out of any diagnostic report you send us. The app only contacts the CDN on a network where connecting to our server directly has failed, now or within the last day. To keep the Premium route affordable, we count per device and calendar month how many bytes went through it. We never record which server, when, or from where.

Exit servers

Exit servers boot from memory. There is no disk to write to, state is wiped on every reboot, and there are no logging code paths in the software that runs them.

While a session is up, an exit necessarily handles the address you connect from — it terminates the tunnel — along with a session key it will never see again and the traffic itself. It does not record any of it. What it reports back is aggregate, delayed and rounded: bytes per peer per period, never per connection or per destination.

To keep the servers hosted, an exit may rate-limit or refuse abusive traffic patterns locally, using only what is in memory on that server and keyed on the network the traffic came from, never on a subscriber. There is no record of abuse that outlives a session, because keeping one would mean resolving a session to a person.

Sharing a device or an exit

If you invite someone to use one of your exits, they go online through your connection the way any guest on your network would: websites, games and your internet provider see their traffic as coming from your connection, and you appear to them as the person using it. If you invite someone to reach one device only, they can reach that device and nothing else on your network.

Traffic between your devices, and a guest's traffic through a share, is end-to-end encrypted. When a direct connection isn't possible, it passes through a ForestVPN relay that can't read it and keeps no record of which devices talk to each other. On networks that block us, it may also pass through a content delivery network, which sees only that encrypted data is flowing, the way it already does for the rest of ForestVPN's traffic (see “Carrying your connection through a CDN”, above).

There is no record of who did what. ForestVPN keeps no log of what a guest does through a share, so neither the host nor we can show who did something.

A share is stored as two random mesh identifiers and a small amount of state — who it is for, what it allows, and when it ends — never a log of use. Ending a share deletes it after 30 days. Cloudflare, our hosting provider, can still recover it for up to 30 more days after that, for its own disaster-recovery purposes.

Analytics

We keep operational counters: how many credentials were issued and refused, connection outcomes and timings, byte totals, and per-server aggregates, daily counts of new devices, new accounts, paying customers and subscription changes, and support-assistant counters (topic, entry point, whether diagnostics were shared, whether the answer helped), none of which carries a device, an account or any text. They are written to an analytics store that nothing in the request path reads back.

Two things about it should be said plainly.

• The rows about credential issuance and settlement carry a pseudonymous per-device tag — a keyed hash of your device key hash, not the hash itself — along with a country code and a network operator number. That is personal data under the GDPR, not anonymous data.
• Retention is 90 days and cannot be changed, and there is no deletion API. We cannot delete an individual’s analytics rows on request; we can only wait for them to expire. Rotating the key that makes the tag orphans future rows from past ones; it does not remove the past ones, and it does not retract a correlation made while the old key was in use.

No row carries a subject and an exit server together. The datasets that carry a device tag do not carry a server, and the datasets that carry a server do not carry a subject. Route reports are aggregates that carry no device tag, and they are published to our dashboards only for days with at least 10 devices.

This website runs no analytics at all. It sets two functional cookies and nothing else: fvpn_locale remembers your language for a year, and fvpn_theme (value light or dark) remembers a theme you picked, for a year. fvpn_theme is set only when you choose Light or Dark in the header, and choosing System deletes it. Neither identifies you, and only this site reads them. It loads no third-party scripts, embeds nothing, and self-hosts its fonts.

Who else processes it

Each of these acts on our instructions, under contract, and is bound to protect the data to at least the standard set out here. The public DNS resolvers are the exception: they act under their own privacy policies, not ours.

Cloudflare

Hosts the control services, their databases and this website, terminates TLS for our domains, and stores the diagnostic report you can choose to send us, in a bucket keyed only to your support code and separate from any device record. Because TLS terminates there, Cloudflare is in a position to see the metadata of requests to our hostnames regardless of what our own code records. This is a real limit and we would rather state it than imply it away.

Nebius

Runs the language model behind the support assistant, in the EU, under a contract with zero data retention — it does not keep your conversation after answering and does not train on it. It never receives your account number, your IP address, or which servers you connect to. See support assistant.

Apple

Sells and bills every subscription bought in the app, and tells us that a subscription exists. Apple has its own privacy policy and its own relationship with you. We receive a signed receipt and a device-derived token, never a card number, name or email.

Google

Sells and bills every subscription bought in the Android app, and tells us that a subscription exists. Google has its own privacy policy and its own relationship with you. The app forwards a purchase token and product id to us, along with a device-derived token attached to the purchase as Google Play’s obfuscated account id; we verify all of it directly against Google’s own servers, and Google separately pushes us a Real-Time Developer Notification when a subscription changes — never a card number, name or email.

Stripe

Processes card payments for subscriptions bought on the web, and runs the customer portal where a card subscription is managed and cancelled. Stripe holds the buyer's name, email, billing address and card details — none of it reaches us.

CloudPayments

An alternative card processor for web purchases, offered where it serves buyers better than Stripe. Same boundary: it holds the payment identity, we hold a subscription row with no name attached to it.

NOWPayments

Processes cryptocurrency payments for web purchases. It is the payment method where even the processor holds the least about you — no card, no bank account — and, unlike the others, a crypto payment cannot be refunded. See paying by card or crypto.

Server providers

The companies that host our exit servers. They can see traffic volume at their own network edge, as any host can. They have no access to the servers’ memory or to your traffic.

Bunny.net

Relays the encrypted tunnel of a Pro or Premium connection, and the app’s own encrypted requests to our control services, when a network blocks our own servers, and only then. While it relays, it sees the IP address you connect from, the hostname of our relay endpoint and the time of the traffic, never what is inside, which of our services is reached, your account or your device key. Its request logging is turned off on our zones. See carrying your connection through a CDN.

Gcore

May relay only the app’s own encrypted requests to our control services, not the tunnel, when a network blocks our own servers, and only then. While it relays, it sees the IP address you connect from, the hostname of our relay endpoint and the time of the traffic, never what is inside, which of our services is reached, your account or your device key. Unlike Bunny.net, its logging cannot be turned off on our account: it keeps the IP address you connect from, the hostname the request was addressed to and the time for 3 days. See carrying your connection through a CDN.

AWS

Mirrors the signed server list, so a device that cannot reach our own domain can still fetch one. When a device falls back to this mirror, AWS sees the IP address it connects from and the time of that fetch — never your account, your device key, or which server you go on to use.

Public DNS resolvers

Cloudflare, Google and Quad9 run public DNS resolvers the app may ask, over encrypted DNS, for the addresses of our own servers when your network’s DNS fails, is slow or returns a wrong answer, or our servers cannot be reached at the addresses it gave. They are not our processors: each acts under its own privacy policy, not ours, and learns your IP address, the time and the server name looked up, never your account or what you browse. See what happens when you connect.

Retention

Retention is listed per record in the table above. In summary: session records last only as long as the session; ticket bindings — the one record with a device and a session on the same row — are deleted an hour after settlement or at the ticket's own expiry, never more than about 17 days out; support codes and diagnostic reports last 72 hours; daily usage rolls off after 31 days; analytics expire at 90 days and cannot be deleted early; device rows, account rows, subscription and billing records, monthly byte totals and the decision ledger are kept indefinitely, because a subscription dispute or a refused allowance has to be explainable later. This is retention for what we hold — a web purchase's receipt, dispute correspondence and card record live at the processor and follow its own retention policy, not this one.

Deletion, and what a request can actually reach

Email support@fvpn.net with a support code from the app — Account → Get help on Apple platforms; on Android, tap the connection status at the top of the app, then Health → Report a problem → Get a support code on a phone or tablet, or Connection details → Report a problem → Get a support code on Android TV. The code is the only way we can tell which device record is yours: we have no email address, username or account name to authenticate you by. Without it we cannot act on a request about a specific device.

Being exact about what that request reaches today:

• Daily usage rows can be removed, and expire after 31 days anyway.
• A device can be unlinked without deleting the account. A device can sign itself out from the Account page in the app, and any other device on the account can remove it, in the app or in the console at fvpn.net; the device keeps working on the Free plan. An account holds up to ten devices, a device that joined in the last 7 days cannot remove older devices, and a router can sign itself out but cannot remove other devices. Deleting the whole account is separate, below.
• In-app account deletion is available: Account → Delete account. It is permanent — it removes the account, reverts every device linked to it back to anonymous (each keeps whatever it separately bought), and cannot cancel account-owned subscriptions, which the store — Apple or Google — keeps billing until you cancel them yourself in its own subscription settings. It asks for the account's full number rather than trusting that you are signed in on a device, because every device on an account shares that authority equally and one of them should not be able to destroy it on the others' behalf. It only deletes an account: a device with no account attached has nothing here to delete.
• Analytics rows cannot be deleted at all and expire at 90 days.
• Monthly byte totals, billing records and the decision ledger are kept. The ledger is append-only on purpose: a record that can be quietly edited cannot settle a dispute.

You can stop all collection at any time by deleting the app and not connecting. Note that this does not remove the records above, and that the machine key survives deletion on Apple platforms — see what lives on your device.

If you are in the EU, the UK or California, you have rights of access, correction, deletion and portability over personal data we hold about you. A device key hash is pseudonymous personal data, not anonymous data, and we treat it as such. Where we cannot satisfy a request — the cases above — we will say which one applies and why, rather than claiming we cannot identify you.

What this does not protect against

One record links your device to a session, and through the device to your account if you have linked one. It is the ticket binding set out in accounts and subscriptions: it exists so the allowance can be metered and a revoked device cut off mid-session, and it is deleted an hour after that session settles. Nothing anywhere links either of them to an exit. We say it that way rather than claiming a separation we do not have — and these are the other limits, for the same reason:

• The service that issues credentials and the exit that carries your traffic each see your session key at different moments. Parties who were compelled together, or who colluded, could use that to rejoin a session end to end. We keep no record that would do it, and no single one of them can do it alone.
• If you use the devices page to send a router to a different exit, the location you chose is stored against that device — and so, if the device is linked to an account, against your account — until you choose another. It is what you asked for, never what we observed: the device's acknowledgement is a number echoed back, not a place.
• TLS for our domains terminates at Cloudflare, so metadata about requests to our hostnames exists there regardless of our own code.
• Your device key hash is stable, and pseudonymous analytics rows keyed to it live for 90 days.
• The set of people you are indistinguishable from is everyone holding a ticket signed by the same tier key in the same fortnight — not “all our users”. At launch that set is small. We would rather say so than describe an anonymity we do not have yet.

A VPN moves who can see your traffic. It does not make you anonymous, and this one does not claim to.

Children, changes and contact

The service is not directed at children under 13, and we do not knowingly collect data from them. We have no way to know a user’s age, because we collect nothing that would tell us.

If this policy changes materially, we will change the date at the top, describe what changed here, and show a notice in the apps that support one. Because there is no email address on file, we cannot notify you by mail.

16 October 2026: We added a section on sharing a device or an exit with someone: how a guest's traffic appears, what our relays can and cannot see, and what is kept about a share. See sharing a device or an exit.

4 October 2026: When your network’s DNS fails, is slow to answer or returns a wrong answer, or our servers cannot be reached at the addresses it gave, the app may also ask Cloudflare, Google or Quad9 over encrypted DNS for the addresses of our own servers; each one it asks learns your IP address, the time and that the device looked up one of our server names, and nothing else. See What happens when you connect.

4 October 2026: Gcore (gcore.com) now joins Bunny.net (bunny.net) as a CDN, and a CDN may now also relay the app’s own requests to our control services, not only the tunnel; Gcore may relay only those requests, not the tunnel. A CDN on either route may see your IP address, the hostname of our relay endpoint and the time, never the content or which of our services is reached. Gcore keeps your IP address, the hostname the request was addressed to and the time for 3 days; Bunny’s logging is turned off on our zones. See carrying your connection through a CDN.

10 October 2026: The apps can now send route reports — anonymous, aggregated network diagnostics, not linked to your identity or account. We added them to what our control services keep, and corrected our description of the Apple privacy manifest.

16 October 2026: Route reports from the phone apps now also describe which kind of road the VPN connection itself used (UDP, TCP, transit, carrier or mesh peer) and which shared access front or relay carried it, with a rough volume bucket. Still anonymous, aggregated and not linked to your identity or account. See what our control services keep. We also corrected the list of apps that send them: the macOS app does too.

Questions, requests or complaints: support@fvpn.net. The controller is Digital Services LLC.