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.