The captive portal economy: how hotel WiFi sign-in pages became both a security vector and a hidden ad channel

TL;DR

Hotel WiFi captive portals have quietly become both a security attack surface (HTTP-only pages, DNS hijacking, rogue networks) and a programmatic ad channel collecting first-party data. Most VPN clients fail at the handoff. KeepSolid built a Captive Portal Network Checker into VPN Unlimited to detect and reconnect automatically.

Last month I checked into a hotel for a conference. Open laptop. Click WiFi. Hotel network. The familiar splash screen appears: enter your room number, your last name, accept the terms. Standard.

What’s no longer standard is what’s running behind that splash screen.

The captive portal, that login page you see before you can actually use a hotel or airport WiFi, has quietly evolved into two parallel industries at once. One is a security attack surface. The other is a programmatic advertising channel worth real money. They share infrastructure. Most travelers don’t see either side of this clearly. Most VPN providers don’t either.

The technical reality

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

A captive portal works by intercepting HTTP requests from your device before you’ve authenticated to the network. You can’t bypass it the way you’d bypass anything else, the network itself forces every request through a redirect until you complete whatever ritual the portal demands. Enter a room number. Accept terms. Sometimes pay. Sometimes watch a fifteen-second video ad. Sometimes hand over an email address that gets sold downstream to a marketing platform.

This works because your device has to make an unencrypted HTTP request to a known test URL just to detect whether internet access is real. Apple uses captive apple com. Microsoft uses www msftconnecttest com. Google uses connectivitycheck gstatic com. The OS is essentially asking the network «am I really online?», and the captive portal answers by intercepting that probe and redirecting to its splash page. It’s designed protocol behavior, not a bug.

It’s also why your VPN can’t help you here. By the time you’ve launched a VPN client, the OS-level connectivity test has already revealed your device and triggered the portal redirect. The VPN can’t connect because the network won’t let it through until you’ve authenticated to the portal. So you turn off the VPN. Click through the splash. Forget to turn the VPN back on. Browse the rest of your trip exposed.

This is the gap we chased when we built captive portal handling into VPN Unlimited. Most VPN clients still don’t close it cleanly.

What’s running on that captive portal isn’t always what you think.

Most large hotel chains don’t operate their own WiFi infrastructure. They contract with companies like Boingo, Aptilo Networks, or Cloud4Wi. These are real businesses with real products and reasonable security defaults. But the rollout quality varies dramatically across properties, and a chain-wide brand standard doesn’t always extend to the captive portal implementation in a specific franchised property in a specific country.

The security failures fall into a few categories. The most common is HTTP-only portals, the splash page itself doesn’t enforce TLS, so the credentials you enter (room number, last name, sometimes credit card details for premium tiers) traverse the local network in clear text. The second is DNS hijacking, the captive portal forces all your DNS queries through their resolver, which gives the portal operator visibility into every domain you query for the duration of your session, regardless of what your device thinks its DNS settings are. The third, less common but well documented at security conferences, is the actively malicious portal, a rogue device impersonating the hotel network, serving its own splash, harvesting whatever credentials the user types in before connecting them to the real network so they never notice anything was wrong.

You don’t need to be in a high-risk environment for any of this to happen. You need to be in a hotel.

The ad channel side

Here’s the part most travelers don’t think about: that splash page is also a piece of premium ad inventory.

The market for «WiFi marketing platforms» is a real and growing category. Companies in this segment, Cloud4Wi is one of the more visible ones, pitch their products to hotels, airports, retailers, and stadiums as a way to monetize the seconds and minutes guests spend at the captive portal. The general pitch in this segment goes something like this: every guest who connects to your WiFi is a captive audience for a fifteen-second video ad, a quick survey, an email capture, or a sponsored offer. The venue collects first-party data. Depending on how the platform is configured and what partner relationships are in place, that data can be shared with marketing networks or used for downstream retargeting after the guest leaves.

The economics work for the venue. WiFi is otherwise pure cost. Adding a programmatic ad layer turns it into a marginal revenue stream, especially in high-traffic locations. The economics work for the advertisers too, because the audience is unusually well-targeted (you know they’re at this airport, this hotel, this specific venue) and predictably attention-paying (they literally cannot do anything else online until they accept the portal).

None of this is illegal. It’s also not always disclosed in a way the average traveler would notice. The «accept terms» button you click in a hurry often bundles in consent to marketing communications, data sharing with the WiFi operator’s partner network, and sometimes location tracking for the duration of your stay. Most people don’t read the terms. The portals are designed under the assumption that they won’t.

Where the two industries collide

The thing I find interesting about this convergence is that the same captive portal infrastructure that’s being commercialized for advertising is also the structural security weak point. The portal operator has visibility into your device, your domain queries, often your authentication credentials. They also have a commercial incentive to keep you on the portal longer (more impressions) and to identify you across sessions (better profile for the data sale).

For a security-aware traveler, the captive portal is both a friction point, the thing that breaks your VPN, and a privacy leak, the thing that profiles you while your VPN is off. These are not separate problems. They’re the same problem viewed from two angles, and they were both created by the same underlying design choice: that the OS has to talk to the local network in clear text before it can establish a secure connection.

What we built, and why it took longer than it should have

At KeepSolid we eventually shipped a feature in VPN Unlimited specifically to close this loop. We called it the Captive Portal Network Checker. The basic idea is straightforward. When the client detects that it’s behind a captive portal, instead of failing silently or forcing the user to manually disable the VPN, the app surfaces the portal, lets the user complete whatever authentication the network requires, then reconnects the VPN automatically. The user never has to remember to re-enable protection. The window of exposure shrinks from «the rest of the trip» to «the seconds it takes to clear the portal.»

The detection itself is straightforward: the client watches for the specific HTTP redirect patterns that captive portals use, distinguishes them from other connection failures, and surfaces the right UX at the right moment. The reconnection back is the more interesting half. When the VPN comes back online after the portal, it doesn’t just default to whichever protocol the user happens to have selected, it goes back to Optimal Mode, the auto-selector that picks the best protocol and server for the conditions it’s seeing right now. On a hotel network that’s filtering standard transports, that often means switching to KeepSolid Wise or VLESS rather than the WireGuard that would have failed to connect a minute earlier. The behavior is the same on Windows, macOS, Linux, iOS, Android, and through the browser extensions. The captive portal is a cross-platform problem; the fix has to be too.

I’ll be honest about why this shipped later than it should have. The captive portal problem doesn’t surface in standard product metrics. Users blame «the WiFi» or «the VPN is broken.» They don’t articulate it as a feature gap. It surfaces in support tickets one at a time, never aggregating into a clear signal that’s visible from the dashboard. We only prioritized it once enough of our own team had hit the problem personally on business trips that it became impossible to ignore.

I think this is the most honest thing I can say about a lot of security product development. The features that matter most for users in adverse conditions are often the ones that don’t generate clear demand signals in normal conditions. You build them because you’ve been there, not because the funnel told you to.

What this means for the rest of the category

For travelers, the practical advice is unchanged from any other security piece. Use a VPN. Use it consistently. Be skeptical of network names. Skim the captive portal terms even when it’s tedious.

What I think deserves more attention is the systemic part. The captive portal is a design artifact from an earlier era of internet infrastructure, when authentication-before-encryption was the only thing that worked. We have kept the architecture, and over the last decade two industries have bolted themselves on top of it, security exposure on one side, programmatic advertising on the other. The VPN industry’s response has mostly been to treat captive portals as user error rather than as a structural problem to solve at the client layer.

That should change. The captive portal isn’t going away, it remains the only practical way to authenticate guests onto a shared WiFi network at scale. But the experience around it can be designed better. Detection should be automatic. The VPN client should know when to step aside and when to step back in. The user shouldn’t have to think about it.

What we shipped is one approach. There will be others. What shouldn’t continue is treating the captive portal as something users have to work around, when in fact it’s the single most consistent point at which their devices are most exposed and least informed.

Vasyl Ivanov is the founder and CEO of KeepSolid, the company behind VPN Unlimited , where he has spent thirteen years building privacy and security products that serve more than 60 million users worldwide. VPN Unlimited ships across Windows, macOS, Linux, iOS, Android and browser extensions, with a multi-protocol stack that includes KeepSolid Wise, VLESS, and Hysteria2 alongside the standard WireGuard, OpenVPN and IKEv2 transports.