Some people have been thinking about creating a standard to distinguish between the two so that captive portals won't have to do a MITM attack (that browsers currently correctly defend against). One idea might be to have a different protocol through which the captive portal can indicate its presence and declare itself as a captive portal, entirely or almost entirely outside of the HTTP or HTTPS session.
Getting the UI right is pretty challenging, though. It's not even completely clear what getting it right would mean. Even if the user clearly understands that they're interacting with some network operator rather than, say, Gmail or their organizational webmail server, the user still has no way to know whether the portal they're talking to is actually operated by the operator of the network that they think they're connecting to!
Chrome does this already by sending a hidden request to http://www.gstatic.com/generate_204 and displaying the page in a new tab if the request is intercepted.
I've wondered this too. Doesn't DHCP support extensible options? Couldn't you just send an option that said, "hey, crappy portal welcome site at {URL}"? It'd be fixed to a particular webpage (so, you can't use another protocol), but that's the state of things today.
It seems like there are only two things captive-portals are "for", though: accepting EULAs, and presenting a login form for the proxy. Both of these could be better if built into browser/OS chrome.
Comments
There's no functional difference between craptive portals and a MITM attack, so this definitely seems like a feature...
Some people have been thinking about creating a standard to distinguish between the two so that captive portals won't have to do a MITM attack (that browsers currently correctly defend against). One idea might be to have a different protocol through which the captive portal can indicate its presence and declare itself as a captive portal, entirely or almost entirely outside of the HTTP or HTTPS session.
Getting the UI right is pretty challenging, though. It's not even completely clear what getting it right would mean. Even if the user clearly understands that they're interacting with some network operator rather than, say, Gmail or their organizational webmail server, the user still has no way to know whether the portal they're talking to is actually operated by the operator of the network that they think they're connecting to!
Chrome does this already by sending a hidden request to http://www.gstatic.com/generate_204 and displaying the page in a new tab if the request is intercepted.
(More detail at http://www.chromium.org/chromium-os/chromiumos-design-docs/n...)
I've wondered this too. Doesn't DHCP support extensible options? Couldn't you just send an option that said, "hey, crappy portal welcome site at {URL}"? It'd be fixed to a particular webpage (so, you can't use another protocol), but that's the state of things today.
It seems like there are only two things captive-portals are "for", though: accepting EULAs, and presenting a login form for the proxy. Both of these could be better if built into browser/OS chrome.