Why your sign-in is a number, not an email

The account you don't need is a 128-bit number, issued by a machine that structurally cannot open your tunnel. Here is why both of those have to be true together.

Most apps ask for an email address before they ask what you actually came for. ForestVPN asks for neither an email nor a password — open it, press connect. If you want one subscription on more than one device, you get a 32-character number instead, shown once, and that is the entire sign-in system.

That is not a style choice. It is what is left after two requirements collide, and the interesting part is which one wins.

Where sign-in usually lives

A "Sign in with Apple" or "Sign in with Google" button is a redirect to somebody else's domain — appleid.apple.com, accounts.google.com, a *.auth0.com tenant. On a phone with an open path to those hosts, that redirect is invisible plumbing.

We can't assume that path is open, because part of this product's job is to keep working on networks that only let a device reach a short, fixed list of hosts. Our own relay proxy's entire security model is that list — three names, api., sess. and catalog.fvpn.net, matched exactly. Widening it to admit a CDN-fronted identity provider means admitting a provider whose same CDN fronts a large slice of the internet, which turns a narrow relay into a general-purpose one. And on iOS specifically, the sign-in web view for a third-party identity provider runs out of process — an app-level proxy setting has no way to reach into it and route it through anything we operate. The redirect fails in exactly the place it most needs to work.

So the number is not the friendly option we picked instead of the familiar one. It is the option that still works under the constraint that mattered more.

The other half: nobody who has the number can see your traffic

Say the account number a different way: it is a credential minted by a service that runs on Cloudflare Workers — request-scoped execution, no long-lived process, no raw socket, a per-isolate memory ceiling in double-digit megabytes. None of that is a limitation we route around. It's the reason that service can be trusted to hold your entitlement at all:

no raw UDP or TCP sockets
no long-lived process — execution is request-scoped
128 MB per isolate
a few MB, compressed, is the entire deployable

A machine built like that cannot terminate a stateful UDP tunnel — not "not yet," structurally. So the servers that actually carry your traffic are a separate fleet, on separate infrastructure, and the two sides meet through exactly one thing: a ticket. Your device asks the Workers side for one and gets back a value that is signed but unread — the signature is produced over a number the signer never sees, so the ticket you present later cannot be traced back to the request that minted it. It proves which tier bought it. It does not say which device, and it does not say you.

That is what makes the account number boring in the way it needs to be. There is no column in this system that holds the account number next to an exit server or an address you connected from — not "we choose not to look," the column does not exist, and a build check fails if one is added. There is one narrower, deliberate exception, and it is about the device, not the number: while a ticket is live, a row names your device's key hash next to a hash of the session it belongs to, which is what lets a spent ticket be charged against your allowance and a revoked device be cut off mid-session. That row is deleted within about a day of the session ending, sooner if it settles quickly, and it has no field for an exit or an address — device and session, nothing else. If you've linked a device to an account, that link is how far the reach goes; the account number itself never touches a session row. The service that does see your traffic never learns the number in the first place.

What it costs, said rather than hidden

None of this is free. The number is shown once and stored nowhere on our side; lose it with no device still attached to it, and there is nothing to recover it with, because there is nothing else that identifies you to recover it against. Linking a device to an account is one-way — there is no unlink, for the same reason there is no password reset: undoing either needs a way to prove the request came from the account's real owner, and the entire design point was to never collect anything that could prove that.

That is a real trade, not a footnote, and we would rather you know it going in than find out at the moment it matters.