Privacy Has a Postcode: Testing VPN Website Cookie Choices Across 3 Locations

The same VPN website offered a direct decline-all button in Germany, a settings-panel route in California, and no consent controls in our Kenyan homepage observation. Fresh-session refusal tests also showed why a saved “off” setting, a cookie jar, and network silence are three different things.

This one-day study covers five sampled websites, with usable fresh-session homepage observations for four. It reports what our browser observed, without ranking VPN services or drawing legal conclusions.

The question behind the test

A VPN company’s homepage is often the first place a prospective customer encounters its approach to privacy. Before downloading an app or opening an account, visitors may already be asked to accept cookies, open a settings panel, or acknowledge a notice.

We wanted to examine a concrete question: does the same VPN website offer the same cookie choices when the visitor’s connection appears to come from Germany, California, or Kenya—and what can we observe after choosing refusal?

This is a study of public marketing websites. It does not test VPN traffic logging, encryption, app security, or what a provider does inside a customer account. For the separate question of what a VPN records, see our guide to VPN logging policies.

Why we ran a second round

Our first pass covered five websites across three connections, with roughly ten seconds of observation per page. It used a browser that retained earlier visits. On Surfshark, Germany produced “Accept all,” “Decline all,” and “Cookie preferences,” while California produced “OK, understood” and “Privacy controls.” A second comparison, performed in the reverse location order, reproduced those two interfaces.

That was an interesting lead, but retained browser state could affect both notices and stored cookies. We therefore added a separate round with isolated browser contexts, longer observation windows, explicit choices where available, and a reload after refusal. The two rounds remain separate datasets.

The first notice offered different routes to refusal

Fresh sessions reproduced the Germany–California difference on Surfshark. In Germany, “Decline all” appeared on the initial notice alongside “Accept all.” In California, the initial notice instead offered “OK, understood” and “Privacy controls.” Opening Privacy controls revealed an explicit decline-all choice.

That is a concrete difference in the path a visitor must take: one click from the German notice, two from the California notice in our measured visits. It does not mean California lacked a refusal option.

On the native Kenyan connection, the fresh Surfshark homepage observation exposed neither the consent notice nor a settings button. Its saved rendered text included a Cookie policy link, but no corresponding privacy-controls text. We therefore recorded refusal and acceptance as unavailable on that sampled homepage, rather than trying to manufacture a choice. This does not establish that controls are never available to Kenyan visitors.

Refusal changed the settings, but did not silence all requests

On Surfshark, we selected the explicit “Decline all” button, observed for sixty seconds, and reloaded. In Germany, the notice stayed closed through the reload. Separate confirmations in Germany and California then reopened the panel after refusal and reload: both optional switches—Analytical and Marketing—showed off. An earlier extra German confirmation failed to locate the decline button within its bounded wait; that failure is retained and is not counted as a successful replication.

Network activity continued. The German refused visit recorded six POST requests to behaviour.surfshark.events/com.surfshark/engagement in its sixty-second comparison window. The California refused visit also recorded requests to that endpoint, as well as hosts including bat.bing.com and bzr.openai.com. We report those as observed destinations, without assigning every request a purpose.

The reload checks matter here. In both locations, the reloaded refused page again requested the engagement endpoint and paths including /fpomup/gs/ccm/collect on surfshark.com. The California reload did not reproduce every external host observed immediately after the original refusal. Those are different phases and should not be combined into a single claim about continued activity.

The evidence therefore supports a narrower finding than “refusal failed”: the interface saved an off state in the California confirmation, while storage and some browser-visible requests remained. We did not capture the query values or request bodies needed to establish the contents and consent semantics of those requests. Scripts loaded before the click can also contribute activity immediately afterward.

To separate a refusal interface from actual transmission, compare our privacy-request form investigation with the later VPN, NetShield and browser-blocker study. Their samples and collection windows differ from this pilot. For implementation guidance, see cookie consent testing and implementation.

Cookies are a separate measurement

In the first pass, the German Surfshark visits ended their sixty-second windows with seven cookie entries untouched, eight after refusal, and twenty-two after explicit acceptance. California ended with twenty-two untouched and twenty-three after either explicit refusal or acceptance. Each condition used a separate fresh context, so these are observations from separate visits, not a before-and-after deletion experiment on one cookie jar.

Counts include cookies with the same name on different domains. They are not counts of trackers, and more cookies do not automatically mean a worse privacy outcome. In particular, remembering a refusal can itself require storage. Our browser cookies guide explains the storage categories behind these counts. The names and domains—not cookie values—are retained in the private evidence.

First-pass cookie entries present at the end of each untouched sixty-second comparison window, following the initial checkpoint. NordVPN returned a security challenge in all three fresh-session groups; those pages are excluded, not treated as zero-cookie homepages.

Mullvad, IVPN and Proton did not expose consent controls in these homepage visits, so we did not run artificial acceptance/refusal conditions for them. IVPN’s entries had _pk_ names, consistent with its disclosed Matomo setup. Proton’s four entries included the same cookie name on two domains. These facts describe this page and window, not the complete tracking behavior of either provider.

The first pass contains twenty measured attempts: sixteen complete visits and four exclusions. The exclusions are NordVPN’s three challenges and one California Surfshark visit that was blank at the initial checkpoint while resources were still loading. A single retry with a bounded render wait succeeded; the failed attempt remains in the dataset. Exploratory and supplementary UI checks are outside that denominator.

Second pass: what a same-day repeat changed

The second pass contained 19 measured attempts and 16 complete visits. NordVPN again presented a security challenge in each connection group. Surfshark again offered a direct decline button in Germany, a Privacy controls route in California, and no consent controls in the sampled Kenyan homepage visit. Separate confirmations again showed Analytical and Marketing off after refusal and reload.

The cookie counts were not identical in every condition. California’s refused session ended with 11 entries rather than the first pass’s 23. Its pre-choice, final and post-reload counts were 10, 11 and 12; the corresponding first-pass counts were 11, 23 and 24. The untreated Kenyan Surfshark visit ended with 22 rather than 23. Its first-pass endpoint list included a test_cookie entry absent from the second-pass endpoint list.

California refusal: two observed endpoint counts

Same-day sessions, explicit Decline all, sixty-second comparison windows. Counts include retained and consent-related cookies.

First pass23

Second pass — same-day repeat11

Surfshark cookie entries at the comparison endpoint, by separate fresh session.

Connection	Condition	First pass	Second pass (same day)
Germany	untouched	7	7
Germany	refused	8	8
Germany	accepted	22	22
California	untouched	22	22
California	refused	23	11
California	accepted	23	23

Untouched endpoint counts: eleven of twelve usable pairs matched. NordVPN is excluded in both passes.

Connection	Homepage	First pass	Second pass (same day)
Germany	Mullvad	0	0
Germany	IVPN	2	2
Germany	Proton VPN	4	4
Germany	Surfshark	7	7
Germany	NordVPN	Excluded	Excluded
California	Mullvad	0	0
California	IVPN	2	2
California	Proton VPN	4	4
California	Surfshark	22	22
California	NordVPN	Excluded	Excluded
Kenya	Mullvad	0	0
Kenya	IVPN	2	2
Kenya	Proton VPN	4	4
Kenya	Surfshark	23	22
Kenya	NordVPN	Excluded	Excluded

The second California refused visit recorded fourteen request starts in its comparison phase: seven to behaviour.surfshark.events, four to www.google.com, one to googleads.g.doubleclick.net, and two to surfshark.com. The German refused visit again recorded six POST requests to the engagement endpoint. Destinations and timing do not establish request contents or consent semantics.

Matching cookie counts also hid early loading differences on other homepages. Mullvad made additional connection-check requests without setting cookies, while IVPN and Proton reached their earlier endpoint counts after different initial checkpoints. These findings support reporting individual visits, not treating a single count as a provider-wide rule.

The second pass used the same browser and routing setup, with the bounded extra render wait applied consistently. That wait was introduced during the first pass after its blank California page. Both passes retained the fixed connection order and shared infrastructure, so they do not isolate a geographic cause or establish consistency across days.

View reviewed second-pass screenshots

Read the second-pass research report, download its dataset, or inspect the comparison data. All 293 original evidence files were checked against their saved checksums; none were overwritten.

Every second-pass attempt — same-day repeat

This ledger preserves all 19 attempts in this pass. The first pass includes the unsuccessful California Surfshark visit and its successful retry. “Unavailable” means there is no completed comparison window for that attempt. Request counts describe page activity, including ordinary assets; they are not tracker counts. Reload traffic is a separate phase.

Fresh-session extension, October 13, 2026. Cookie counts include duplicate names on different domains.

Connection / provider	Condition	Result	Window (s)	Cookies before / after	Requests initial / comparison	Reload cookies / requests
Germany IVPN	untouched	Complete	60.044	0 / 2	25 / 2	Not applicable
Germany Mullvad	untouched	Complete	60.053	0 / 0	75 / 13	Not applicable
Germany NordVPN	untouched	Challenge	Unavailable	1 / —	8 / —	Not applicable
Germany Proton VPN	untouched	Complete	60.048	2 / 4	61 / 129	Not applicable
Germany Surfshark	accepted	Complete	60.059	4 / 22	41 / 54	Not applicable
Germany Surfshark	refused	Complete	60.040	5 / 8	56 / 7	9 / 57
Germany Surfshark	untouched	Complete	60.064	5 / 7	47 / 12	Not applicable
Kenya IVPN	untouched	Complete	60.043	0 / 2	25 / 2	Not applicable
Kenya Mullvad	untouched	Complete	60.059	0 / 0	87 / 1	Not applicable
Kenya NordVPN	untouched	Challenge	Unavailable	1 / —	18 / —	Not applicable
Kenya Proton VPN	untouched	Complete	60.054	4 / 4	182 / 0	Not applicable
Kenya Surfshark	untouched	Complete	60.058	23 / 22	89 / 6	Not applicable
California IVPN	untouched	Complete	60.034	2 / 2	27 / 0	Not applicable
California Mullvad	untouched	Complete	60.047	0 / 0	79 / 9	Not applicable
California NordVPN	untouched	Challenge	Unavailable	1 / —	6 / —	Not applicable
California Proton VPN	untouched	Complete	60.061	3 / 4	160 / 30	Not applicable
California Surfshark	accepted	Complete	60.055	6 / 23	55 / 31	Not applicable
California Surfshark	refused	Complete	60.061	10 / 11	66 / 14	12 / 60
California Surfshark	untouched	Complete	60.051	6 / 22	48 / 40	Not applicable

The initial interval includes navigation, rendering and any choice-panel interaction before the sixty-second comparison window. It is not a standardized sixty-second pre-consent interval. Exact timestamps, hosts, failures and response statuses are in the downloadable dataset.

How we measured

The sample consists of the public homepages of Mullvad, IVPN, Proton VPN, NordVPN, and Surfshark. It is a deliberately small sample, not a representative survey of the VPN industry.

The setup record notes Proton’s malware-only NetShield default and no selected optional ad/tracker filtering; default protection differences remain a potential network confound. The two VPN-routed groups use a Proton VPN subscription supplied for this project. Proton VPN is also one of the sampled websites; the routing service and the website measurement are separate parts of the setup.

The extension uses local Google Chrome 155.0.8059.39 controlled through Playwright. Every measured visit starts in a new, non-persistent browser context with no imported cookies or site storage. We hold language at English, timezone at UTC, and viewport at 1280 × 800. We disable the HTTP cache for the measured page. The browser runs headless; automation and browser defaults can affect the experience a site serves.

We record an initial checkpoint at least ten seconds after navigation begins. For an untouched visit, we then observe for sixty seconds without making a consent choice. For refusal or acceptance, the sixty-second window follows the completed choice. A refused session also gets a reload and another observation of at least ten seconds. Navigation delays and actual timings are recorded, rather than assuming every page loads instantly. For your own routing checks, use our VPN testing checklist.

Each visit saves cookie metadata, local and session storage key names, visible interface controls, screenshots, and network request/response/failure metadata. We remove cookie values, URL queries, headers and request bodies from the saved network evidence. Our local validation page supplies a known redirect, a fetch request, two cookies and a storage entry; we also check that a second context starts without the first context’s state.

Where a complete untouched visit exposes no consent interface, we mark acceptance and refusal unavailable. We do not invent a refusal by dismissing a notice, and we do not treat a generic “OK” as an explicit accept-all choice. Security challenges are exclusions, not successful homepage observations.

A location label was not enough

The German and California groups use Proton VPN WireGuard connections. The Kenyan group uses the local ISP connection. These are different network types, which introduces a confound: a website may react to a VPN address or its reputation as well as its apparent location.

During the earlier pilot, Proton’s Nairobi-labelled Smart Routing endpoint produced conflicting country results. NordVPN’s IP checker reported Kenya; Surfshark’s reported France. We excluded that endpoint from the Kenyan comparison and used the native connection after both checkers reported Kenya.

For the extension, we check location again around each group. NordVPN’s checker was challenged in the separate browser. Germany and California used Surfshark plus IPinfo as usable checks. The Kenyan start check used Surfshark plus IPWHOIS after IPinfo supplied no country field. Failed and empty responses are unavailable, not agreement. Agreement between services increases confidence in the apparent location; it does not establish that their underlying databases are independent or that the endpoint is physically located there.

What the evidence can establish

The interface is directly observable: we can document the labels presented, the choices made, and what the settings show afterward. Cookies and requests provide another layer of evidence, but require more care.

An advertising-associated cookie name is a lead for investigation, not proof of what was transmitted in a particular request. A request to a tag manager does not identify every tag it might execute. First-party hosting does not make a request harmless, and a third-party request is not automatically advertising.

Likewise, a cookie that remains after refusal is not, by itself, proof that the site continues to use it. NordVPN’s cookie policy expressly distinguishes retained cookies from receiving information from them after a change of choice. We therefore report storage and observed network activity separately.

Nor does a request after refusal automatically establish that a consent choice was ignored. Google’s consent-mode documentation describes an advanced implementation that can send measurements without cookies when storage consent is denied. We have not established whether any particular observed request uses that implementation. Identifying its consent state and contents would require a separate, carefully scoped inspection; our evidence deliberately excludes request bodies and query values.

Provider disclosures also matter. IVPN describes self-hosted Matomo analytics, Proton describes its own analytics tools, Mullvad describes necessary website cookies, and Surfshark describes necessary, analytic, marketing and affiliate categories. Those statements help interpret observations; they do not substitute for measuring a particular visit. Website owners can compare this distinction with our cookie consent implementation guide.

Limits readers should keep in view

This is a one-day pilot with a single measurement setup and two same-day passes. Each pass has one complete visit per available condition; these are not independent calendar-day replications. Visits share connection infrastructure and browser software, even though their cookie and site-storage contexts are isolated. The fixed visit order leaves time and order effects unresolved.

We do not inspect account areas, complete purchases, test every page, send an automated privacy signal, or measure mobile browsers. Sixty seconds cannot establish what happens over days, across return visits, or inside a provider’s systems. Captured requests establish browser-visible activity within the observation window, not the complete server-side handling of the data.

The Germany–California comparison can show an association with the connection used. It cannot isolate geography from IP reputation, experiments, delivery infrastructure, or other site behavior. It also cannot establish that a law caused a particular design or that an observed implementation violates a law.

Reproduction and supporting material

The accompanying summary dataset, extension protocol, collector, and summary generator describe and implement the measurements. The earlier pilot report preserves the original observations and exclusions. Screenshots in this article have been reviewed for disclosure; raw evidence remains private.

The next study should repeat the available conditions across days and additional networks, inspect consent signals and selected request contents with appropriate redaction, and test other browsers. That would help resolve the questions this pilot cannot: how consistent the interfaces are, what the remaining requests communicate, and whether the behavior changes beyond this short window.

Affiliate disclosure: This article contains Proton VPN affiliate links. FreePolicyTools may earn a commission if you purchase through them. These offers are separate from the research findings and do not constitute a comparative product test or change the study’s methods, results or limitations.