Mozilla filed a policy response to UK regulator Ofcom on May 15, 2026, arguing that VPNs are essential privacy and security infrastructure and should not be weakened by upcoming Online Safety Act enforcement. The submission came in response to consultations on how the UK should handle age verification, content filtering, and the technologies that let users bypass them.

For developers, this is not abstract policy theatre. VPNs sit underneath a surprising amount of daily work — secure connections to staging environments, geo-testing localized features, getting around overly aggressive corporate DNS, and protecting yourself from ISP-level monitoring that turns your browsing history into ad inventory. When a regulator considers "addressing" VPN use, the tools you reach for every day are part of the negotiation.

What Mozilla actually told UK regulators

Mozilla's submission makes three concrete points. First, VPNs are baseline security technology, not edge-case privacy theatre — they protect users on untrusted networks (cafe Wi-Fi, hotel networks, conference floors) by encrypting traffic between the device and the VPN provider. Second, VPNs are essential for journalists, activists, and people in abusive domestic situations who need their browsing to be unobservable by an ISP that can be subpoenaed or hacked. Third, treating VPNs as a circumvention tool to be neutered would set a precedent that other privacy tools (Tor, encrypted DNS, even HTTPS) could follow.

What Mozilla is not arguing is that platforms have no responsibility for harmful content. The submission accepts that the Online Safety Act has goals worth pursuing. The argument is narrower: regulators should not encourage technical measures that punish privacy tools, like fingerprinting VPN traffic, pressuring app stores to delist VPN clients, or requiring ISPs to throttle known VPN endpoints.

Mozilla itself runs Mozilla VPN, a paid product built on Mullvad's infrastructure. Its policy position is not disinterested — but its argument is also not new. It echoes positions from the EFF, Access Now, and the Internet Society over the past five years.

Why developers rely on VPNs more than they realize

A lot of dev work assumes a VPN is sitting somewhere in your stack:

• Remote work into private networks. WireGuard tunnels into staging, bastion hosts, internal admin panels. If your company runs Tailscale or Headscale, you are running a WireGuard mesh — a VPN by another name.
• Geo-testing. Verifying that your i18n actually serves the right currency, language, and tax rules from a German IP. Cypress and Playwright can fake locale headers, but they can't fake an IP. Without a VPN, you're either using a shaky CDN preview or asking a colleague to load the page.
• Bypassing local network filters. Corporate networks block GitHub Copilot endpoints, Anthropic, OpenAI, or worse — your own staging domain. A VPN gets you back to a clean route.
• ISP-level privacy. UK ISPs are required under the Investigatory Powers Act to retain a year of subscriber metadata. Even if you trust your government, you should not trust that data to stay where it was put. ISPs leak.
• Working from networks you don't control. Coworking spaces, conferences, train Wi-Fi. A VPN is the cheapest way to make "is this network safe?" a non-question.

The point is not that every developer needs an opinionated paranoid setup. The point is that if regulators make consumer VPNs harder to use, downstream tools you don't think of as "VPNs" — Tailscale, Cloudflare WARP, your company's Zscaler tunnel — get caught in the same net.

What changes if VPNs get regulated harder

The realistic scenarios are not "VPNs are banned." The realistic scenarios are friction.

App store delisting. Apple has previously removed VPN apps from regional App Stores under government pressure. The UK could request similar treatment for VPN clients that don't implement age-verification handoff. This makes consumer VPNs harder to install, even if they remain technically legal.

ISP-level fingerprinting. Deep packet inspection that classifies WireGuard or OpenVPN traffic as "VPN" and either throttles it, logs it, or surfaces it on a "concerning subscriber" dashboard. This is already done in some jurisdictions. It does not break VPNs, but it makes them slow and visible.

Provider-side compliance burden. Forcing VPN providers to log connection metadata or block specific destinations. The companies that resist (Mullvad, IVPN, Proton VPN) become legally adversarial in the UK. The ones that comply quietly become useless for the privacy use case.

If you maintain a product that depends on customer VPN use — a remote dev platform, a security training lab, anything that requires routing diversity — start tracking UK Ofcom consultations now. The public comment window is the only point when developer voices materially influence the outcome.

The third option is the one that bites developers fastest. If your company uses a UK-headquartered VPN provider for its workforce and that provider gets a logging order, your traffic history is suddenly auditable in a way it wasn't last quarter. You will not be told.

What to do this week

1. Audit your VPN stack. Know which providers you depend on, which jurisdictions they are headquartered in, and whether they have published a recent warrant canary or transparency report.
2. Self-host where it matters. A WireGuard server on a $5 VPS in a jurisdiction you trust is a one-evening project and removes the third-party-provider risk entirely. Tailscale, Headscale, and Netbird make this practical for teams.
3. Submit a public comment. If you operate in the UK, Ofcom's consultation pages are open. Three paragraphs from a working developer about why VPNs underpin your job carries more weight than another submission from a trade association, because regulators rarely hear from the people who use the tools.
4. Have a fallback. Pick a second VPN provider in a different jurisdiction. If your primary gets a compliance order overnight, you do not want to spend a day shopping.

The Mozilla submission is not going to single-handedly change UK policy. What it does is make the developer-relevant argument legible at the regulatory level, where most submissions come from telcos and trade associations. The more concrete the developer-facing examples are in the record, the harder it is for an eventual ruling to pretend VPNs are only used by torrenters and teenagers.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.