I'm actually curious how anyone not a geek gets on Wifi at many coffee shops etc. Many captive portals don't seem to do anything and chrome just says "can't connect" or "cert bad". I used to go to test.com, now I go to foo.com. But I'm geek. What do all the non-geeks do?

Most operating systems have started detecting captive portals and presenting a notification. All of the modern consumer ones (OS X, Windows, Android, iOS) appear to have this detection. (I don't use it so not sure how well it works, though.)

I used to stay a lot at a hotel that would "helpfully" exempt a good number of domains from the captive browser, including whatever macs and androids use to detect connectivity...

There should really be a standard for dealing with this, like a flag on DHCP saying "O HAI you need to login here", and providing a REST endpoint that will tell the OS the status of the connection at any given time.

As if such a standard would help for these WiFi providers that explicitly take steps to avoid captive portal detection?

Surely it's not in their interest to avoid captive portal detection, anyway? After all, it helps them advertise their product!

Bugs will happen, but it's a very simply operation, they simply load an HTTP URL that has an expected response (Google's is just a 204 No Content) and check if it matches.

Chromebook does as well. Works great.

1. Complain that the internet isn't working. 2. Talk to friendly geek who explains going to non Secure site forces pop-up 3. Forget that this work around applied in all cafe and not just the one were problem solved. Goto 1.

This was my immediate first thought too. A lot of subway stations got WiFi in NYC and for the one directly underneath my office I always had to load Google first to get the login portal to load. Any other websites I visit (including this one) just displayed a HSTS error instead.

You can use http://example.com operated by the IANA, which is accessible though http and https.

Since an auto-upgrade to https would break a considerable number of examples, and there's no compelling business need on their part to promote https-only, it's much more likely to stay available through http than just about any other website run by commercial interests.

example.com just seems to point to localhost for me. Weird...

Possibly you have a config somewhere that has example.com in it... Could try example.org instead?

Same thing there. Oddly enough, `dig @8.8.8.8 example.com` seems to work. No mention of it in /etc/hosts. Guess my ISP must be up to some shenanigans. :/

With mine I get:

    Host example.com not found: 5(REFUSED)

http://http.rip will always be http only; it's the domain I use for this purpose.

Very nice, I didn't know there was a dedicated site for "I need just HTTP" purposes. Thanks for the tidbit!

Actually, there is https on the site, at least with a self-signed cert.

https://http.rip/

You can use the addresses that Google and Apple products use to detect captive portals.

Google uses http://connectivitycheck.gstatic.com/generate_204. Apple uses http://captive.apple.com/hotspot-detect.html and http://www.apple.com/library/test/success.html.

I was pretty sure that my Android Version uses google.com for the 204 generation. Without further updates, that would break.

Probably not; google.com will still reply on HTTP, it's just that if you have a browser that visits the HTTPS page, it'll record a rule to never visit the HTTP version. I doubt the code doing captive portal detection supports HSTS at all, so most likely it'll still work just fine.

But that would be exactly the use case here; browse google manually and then hsts kicks in from then on. Later, I get a captive portal wifi and it uses http://www.google.com/generate_204 and whoops, no request sent and no way for the wifi to redirect me to their login portal.

Both happens in chrome hence the same browser context.

Ah, right; I was thinking about the detection mechanism (which probably doesn't use Chrome), not the redirection.

Right, the detection mechanism is part of the OS, not the browser.

https://developer.android.com/reference/android/net/Connecti...

We must thanks the wifi alliance for not having solved this problem in 15 years while they were busy releasing broken crypto implementations.

Instead, it looks like the IETF will be the one solving it. https://datatracker.ietf.org/wg/capport/documents/

Yeah. The wifi alliance track record is so bad that it's a real pity they run one of the most important protocols we have today. They are decades late on most required innovations, and when they try to design something, it's just so severely broken that requires many iterations to get to a decent status. Miracast is another example of being late and failing at producing something decent.

I use xkcd.com for this. Short safe domain, no HSTS.

I use an old and otherwise unused vanity domain hosted on a private server for this.

I usually type in a random url, like askdjajrj.com

I use cnn.com. I know they support neither ipv6 nor https, and they don't trigger firewalls.

I use cnn.com too because the name is short and easy to type on my phone. Hopefully they won't switch to HTTPS any time soon. :)

Only works if you don't use your own DNS.

...which only works if UDP traffic on port 53 isn't blanket-rerouted.

I use the biggest newspaper website in the country I am from since they don't have any TLS at all yet.