I like the straightforward explanation this site provides. That said, I tend to use http://example.com to trigger captive portals because it's an IANA reserved domain [1] that other people can't register. This gives me confidence to browse to it without fear that the domain could lapse in the future and get taken over (e.g. in a watering hole attack). [1]: https://www.iana.org/domains/reserved
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 witho…
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.