One reason for that is explained well in a comment on the article.
Note that as with the Windows version, the protocol is HTTP, not HTTPS – because captive portals completely break TLS, but plaintext HTTP will result in a clean redirect to the portal, allowing the network service to detect the presence of the portal and to bring up a browser window to let the user authenticate.
Yeah, and there's also no guarantee the computer's certificates are even up to date (eg. first time you connect a PC after a fresh install off older media)
Also no guarantee the computer's clock is set ballpark accurately (which TLS requires), which can be relevant if Windows is checking for Internet connectivity before (for example) using NTP to update the computer's clock.
This is why (until very recently) Windows updates are distributed over HTTP - the only benefit of TLS is real-time error checking (and only because there are stateful HTTP proxies that can mangle files).
The whole point is to determine if you have full internet access, so you want to make sure that an HTTP request returns the data you're expecting. You may be able to get DNS responses but not have full internet access, like when on a public wifi that redirects all requests to a login page.
I mean really, what does it mean to you, or to Windows, that I have "full" access to the Internet?
For me personally, I only visit a few walled gardens, so as long as I had my Google, my Wikipedia, and my work-related sites, I wouldn't miss 99.99% of the Internet anyway.
But what if your ISP blocks a whole bunch of ports? What if Adware has taken over 33% of your DNS space? What if you're behind a Great Firewall of <Dictatorship>? What if there's some sort of Balkanization or segmentation of your side of the 'net and you can't reach a lot of stuff? What if Cloudflare's down again?
Yes, "full" internet access is a hard to define term and this simple test doesn't cover all possible cases. But it will work in probably 99.99% of cases and honestly I think that's good enough. If it doesn't work you end up with a little "no internet connection" icon in your taskbar and that's about it. You can still use the connection, so I don't think it's a big deal that this test isn't 100% accurate. It's still more useful to the majority of users to have a slightly inaccurate test than to have no test at all.
Unless you know what the DNS request is "supposed to return", you can't know that just getting any DNS response indicates that you have full Internet connectivity.
Sorry, you were imagining the use of a TXT record (I assume) and that would work better than an A record inquiry that I was considering.
It still wouldn’t find http filtering, but it would work better than I initially gave it credit. (I still doubt it would give a contextually correct answer for an airplane wifi connection [where DNS May very well work but few other services do if not paid].)
Mindless routers (which are frighteningly many) that cache the results and won't show the true state of upstream connection, which is an important thing. There are a lot less transparent HTTP proxies that wouldn't respect no-store than mindless routers trying their best to cache results.
You've got it exactly. This is also part of Windows captive portal detection, which makes what you say even more important. HTTPS would actually be a step backwards here.
I realized a while back that msftconnecttest.com is the domain it uses to check online status, and is the domain it checks in the background that gets redirected to wifi captive portals and pulls up. Any time I have an issue with a captive portal, I use that domain and the redirect works, because I know any other URL with end up with a certificate issue and I won’t be able to get to the portal.
