Can a paid VPN authorize sessions without your account?
Unlinkable tokens can split the eligibility check from the session itself. What matters is the issuance and redemption design, not the label on the login.
Paying for a tunnel does not have to mean presenting the billing identity on every connection. A design can check eligibility once, hand the customer cryptographic tokens, and let the gateway accept a token later without seeing the account behind it. Whether that actually hides anything depends on the issuance and redemption choices, so treat it as a specification exercise with four sections rather than a feature you switch on.
Split the purchase step from the session step
The Privacy Pass architecture in RFC 9576 gives the vocabulary: a client, an attester, an issuer and an origin. The client proves some property to the issuer and receives tokens; later it presents one to the origin, which decides whether to serve it. Applied to a VPN, the property being attested could be a single unit of access.
Billing still sees whatever its own process needs, and nobody is claiming otherwise. The narrower goal is that the later redemption cannot be tied back to the purchase that produced the token. That is a specific, testable property, and it is the one worth writing down.
A random-looking bearer string does not provide it. If the issuer stores the value next to a customer record and the gateway can ask for that mapping, the two interactions are linked by database rather than by cryptography. The construction has to make the issuer unable to answer that question, and the deployment has to keep the issuer and the gateway from pooling their views.
Decide what one token authorizes
"One token buys access" answers almost nothing operationally. Is the unit a single connection, a time allowance, or a volume? Can a client that lost its response resume the same grant? What happens when a device reconnects during a network change? Those answers decide whether the design is usable, and each of them has a privacy consequence.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
Choose one deliberately and write the failure behaviour next to it. A client that retries with a fresh entitlement after a timeout consumes another unit, which is a billing surprise and a privacy signal at the same time.
Write the reuse and revocation policy
Revocation is where anonymous designs usually break their own promise. Cancelling a subscription and invalidating tokens already issued are different operations, and a gateway that quietly performs an account lookup to decide is no longer anonymous at that point.
Pick an expiry, an issuance limit and a revocation story that fit together. Then check the gateway's own records for fields that reintroduce the link you removed.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
That search lists log files containing token or account fields, which is the first place a careful design leaks in practice. A session record that stores the token value beside an account identifier defeats the whole construction, and it usually arrives through a debugging change nobody revisited.
Also define what the gateway keeps after a session ends. Duration, bytes and endpoint are useful for operations, and each of them is a piece of the puzzle an observer would like to have. Keep the retention period short and the field list short, then review both when a debugging change adds a column. Nobody notices a new log field until it has been there for a year.
State the claim, then the observations that remain
Write the privacy claim in one sentence with its assumptions: which party must be unable to link which contexts, and what happens if the issuer and the gateway compare notes. A design that survives that sentence is reviewable; one described only as "zero knowledge" is not.
Then list what stays visible regardless. Source addresses, connection times, packet sizes and the simple fact that a purchase happened shortly before the only new connection appeared are all outside the cryptography. A single customer buying one unit and connecting once is linkable by timing alone, and no token design changes that.
The honest result is a narrower account-to-usage link, not an invisible session. That is still worth building, as long as the documentation says so and the operational records match the claim.