iOS (and macOS?) use http://captive.apple.com/

Yea I use this manually some times as well.

Great for low bandwidth tests Just displays clean “success”

Mozilla also has one that Firefox will use when detecting captive portals: http://detectportal.firefox.com/success.txt

I like neverssl.com, it's a nice basic text page.

Clean "Success" sssSsss

I read this in the voice of Cobra Commander

That means apple.com cannot be HSTS preloaded, which is too bad for security.

I've used this on Linux as well.

Agreed - I always use example.com as well.

Also worth noting that example.net, while not listed on the IANA page, is also reserved.

It's listed in rfc6761 which it references there.

https://datatracker.ietf.org/doc/html/rfc6761#section-6.5

> The domains "example.", "example.com.", "example.net.", "example.org." [...]

I also use example.com, and unfortunately https://example.com/ also works, so if you just type "example.com" in to your browser, you are likely to hit the https:// URL first and get an error. And you have to type the entire "http://example.com" out, or your browser's auto-complete will go for "https://example" first. And even when it's http://, a captive portal may redirect you to an internal https:// site without a valid cert. And sometimes it caches so you need to remember to Shift+Reload.

The most infuriating thing about technology is how it reminds me how incompetent we are as a species. Here we are, the global collective of Information Technology workers, captains of industry, cutting-edge entrepreneurs, and white beard pros, and we cannot make a god damn computer just connect to a coffee shop's network without jumping through a bunch of annoying hoops, like the whole system was constructed by an intern on summer break. (No offense to interns)

Simple answer: We can make it connect just fine, but we either need to give up on value extraction (i.e. "pay a fee to connect"), or on security.

Captive WiFi fundamentally relies on intercepting all Internet traffic to send you to the captive page. That's only possible with fake certificates, because you want to provide a response on behalf of the website the user wanted to go to. This wasn't originally part of "how the Internet works", because "pay as you go" just wasn't considered during the design.

But... we've solved that problem. rfc8910 does specify how you can use DHCP to work around that. Except, it doesn't work for legacy clients. So those will still be supported in existing setups anyways.

And since everybody's supporting legacy setups, the incentive for any single provider to even implement the new method is about zero.

The whole mess is a result of replacing the engine while flying the airplane, in an environment optimized for rent seeking behaviors. We can do the right thing, but we choose (collectively) not to spend the money.

I have always used http://http.rip

I'm not sure how example.com is better than any other domain in a coffee shop setting. Any DNS lookup can be made to resolve to any arbitrary IP address, so it would not matter if a domain is lapsed or even real.

It's a lot easier to simply register a domain like coffeeshopwifi.com if/when the owner abandons it and wait for the requests to pour in, than it would be to find the specific coffeeshop that your target frequents and then compromise their DNS servers.

It is not about compromising DNS servers at coffee shops.

If I go to a coffee shop, do any packets even have to go to coffeeshopwifi.com or example.com at all?

1. DHCP happens.

2. I type http://example.com, but I get 'Please click AGREE etc. for WiFi'. So far, this should all be internal to the local network.

3. I click on AGREE, but my browser actually goes to philzcoffee.com