jww/estark/mkwst: Can you help triage?

+meacer who's working on improving the Chrome captive portal detection integration with the SSL interstitial

I don't understand why the addition of HSTS prevents the captive portal detection from working; could you explain more, jkarlin?

Also +jschuh with whom I was just talking about this. He explained that it's not that HSTS break the captive portal detection, it's just that navigating to http://google.com to get the captive portal login page no longer works.

I just noticed this RFC: https://tools.ietf.org/html/rfc7710

I realize that supporting it is a long play, because captive portal providers will need to update. And ideally it would be built into the OS, not the browser. However, it seems like it's more the right solution.

In the case of SSL-only captive portals, I don't think we should be doing anything (Sorry, but if your login screen only supports SSL with a self-signed cert....No, just no).

Currently, if we run into an SSL page with a self-signed cert, we'll do a captive portal probe, and pop up a tab at the login page.  We'll only do that if the captive portal's login page itself allows for HTTP - allowing an SSL hijack just because we thing we're talking to a captive portal seems a really bad idea.

Oh, and we only do that on desktop, not mobile.  The logic predates the full Anroid merge, and uses classes that don't exist on Anroid (Or didn't, at the time).  Also, popping up a new tab is a lot more disruptive on mobile.

So the Android bit in comment #6 is important. I often wind up in a captive portal while on my phone and we provide zero guidance to the user on how to proceed. I made this bug because a user filed a bug about this happening to them in  Issue 633217 . Can we make the Android code at least as good as desktop?

And is there anything we can/should do to improve the experience?

Might want to talk to some UI guys about that.  I think bringing the browser flow (Which itself isn't great) over to Android would be a mistake in this case, because of how drastically different the UI is.

There is a custom interstitial for captive portals on desktop. We (security-ux) are planning to enable this interstitial on mobile too, and that might require enabling captive portal detection on mobile. The custom interstitial relies on the detection of a captive portal in a 3 second window, so is not fully accurate. I'm working to improve its accuracy at  https://crbug.com/640835 .

On desktop, the captive portal interstitial opens a new tab, but as mmenke pointed out this might not be a good idea to do on mobile. It should probably open the system captive portal dialog instead.

I noticed we don't have a bug for this so I filed  https://crbug.com/642993 .

I really need a net-internals log (for ChromeOS) and/or an Android bug report (for Android) to diagnose what's going on here.  I totally understand the pain of trying to pick non-HSTS URLs to find the captive portal login page.  I personally use foo.com :)

I'm requesting logs to investigate further because normally captive portals should be detected and handled by the OS.  In Android we'll use URLs that aren't HSTSed.  In ChromeOS I think Matt's captive portal detection should fire when either SSL is back-holed or the captive portal gives back self-signed cert responses to https://google.com (as he said in comment #5).

meacer@ is working on this issue (improving captive portal detection and UI) separately. I'm not sure what bug he's using for his work though -- meacer, can you move from WaI -> Dupe and add the bug to the dupe? Thanks.

The umbrella bug is bug 335933 so merging there.

 Issue 318525  has been merged into this issue.

 Issue 709528  has been merged into this issue.