zlacker

I disagree. We were living in the period of easy middleware (this was before HTTPS rollout), and it generally sucked -- there were supercookies, ads injection, general app breakage when you get a captive portal page instead of expected RPC response.

The middleware should require effort to install, and it should be obvious when it is active. Otherwise, companies which have no business MITM'ing the traffic -- such as ISPs and free wifi providers -- will start to do it just because it's so simple.

For example, Google may require MDM app on the Android devices which is used to access corporate data. This app ensures that the device has the right policy (screen lock, encryption) and I think it may also check for malware apps. This is how it should be -- if you need corporate control over devices, install special application on it, it will be more efficient and it will do more.

>>theamk+(OP)
And that's why the browser is at fault - they could have designed it to be more permissive or more secure, depending on the role. They decided instead on a one-size approach, once too permissive, now too restrictive.

As a regular user, I can't just use a captive portal to get free wifi, because any site I go to has HTTPS, so they all break and I can't accept the god damn HTTP accept page unless I can conjure up a valid domain that has no HTTPS like I'm Svengali. Now all the OSes have special checks to see if there's a captive portal because the browsers couldn't be troubled to build a function for it, even though it would improve their security and usability at the same time.

Captive portals are not the enemy. Shitty UX and a bad attitude toward the needs of real users is. Locking browsers/protocols down more is just doubling down on this mentality.

>>peterw+au
Captive portal authentication functionality has no business being part of a browser anyway. Why should I have to start a browser to make my non-browser client application connect to my non-HTTP server?. A captive portal is a special case of rich network-level authentication, which belongs in the operating system. Also, 802.11u is specifically designed to help create uniformity in this area.

>>peterw+au
Yes, captive portals are the enemy. They break an important assumption: requests either succeed and return correct data, or fail and return an error.

Were you writing a forum post? It was lost because it got submitted to captive portal. Were you in dynamic app? It crashed because it got HTML instead of JSON. Does you page reload ads in the i-frames? Your page position and page itself is now lost, and you are in captive portal page. Did you have a native app which did HTTP requests and cached them? Congrats, you have invalid data in your cache now.

And I have seen captive portals which were broken. How about you get redirected to login page every time you go to your favorite website, because the redirect page got cached somehow?

Good riddance. Yes, the browsers should include better captive portal support like android does, possibly triggered by the SSL certificate mismatch errors, but even the current situation when I have to type "aaa.com" by hand all the time is great.