+paul

Pie-in-sky-idea: Move captive portal detection into a library shared between Chrome and Android.

I've put a fair bit of work into the Android captive portal detection over the last few years.  A very brief summary of changes, and discussion of some recently implemented improvements in Android captive portal detection can be found here:
https://docs.google.com/a/google.com/document/d/15qsrhatF8jjkYJVS1S3GKgA1ir3x0_x66fvg-FbXbCo/edit?usp=sharing

Given the sometimes substantially different abilities between Chrome and Android, and the cross-platform issues of Chrome, that does seem like much more administrative and coding work. For example, if Android wanted to support DHCP options, that's simply not viable for Windows code. You would either need to introduce additional abstractions to hide that cross-platform detail, or you'd need to support a variety of compile flags or some sort.

Not saying I disagree, just suggesting it may be non-trivial work that could impair velocity.

I totally agree that it's probably infeasible to share code, that's why I said "pie-in-the-sky-idea".  I was more offering to share the lessons we've learned from Android's captive portal detection.  Similar to Chrome, Android had at least four captive portal detectors, but I think we managed to get rid of all but the main one now.

At the very least if this isn't a real issue we should have improved documentation on each of these URLs. Let's mark this issue as Available.

Any advice from captive portal experts is appreciated. I imagine if there's consensus on the "right way" to do this, we could probably mark this issue as Good-First-Bug.

Using *.google.com domains is potentially problematic/cause for real issues, since HSTS on that domain, and eventually subdomains, may prevent the captive portal logic from working.

This will require coordination - on the client side, to harmonize URLs, but also on the server-side, to ensure the appropriate endpoint is selected that will allow it to function as intended: an HTTP URL to generate 204 responses to ensure services work.

Adding some Chrome OS wifi folks as FYI. 

Broken captive portal detection (cannot get past captive portal) leads to non-working wifi on Chrome OS. Happy to provide examples of broken URLs if that is relevant to this bug (we might be seeing #c7). 

Following Paul's comment (#2), while sharing code is pie-in-the-sky, there's room to integrate the captive portal detection and handling logic between Android and Chrome better. Tal is thinking about this space, so I've cc'd her.

https://crrev.com/a7581d86 exposed the result of the Android's captive portal check to Chrome. So, that makes it slightly simpler for net and its consumers in Chrome to query the result of the Android's captive portal check.

Note: I think the more pressing matter is quite simple, but requires the coordination of client and server teams: What URL to use for the captive portal check. We should not be using a bunch of different URLs, especially those that may be affected by HSTS in the future.

That should be the first-order priority, IMO.

I agree. Didn't mean to derail your issue.

When they were enabling HSTS on google domains, captive portal detection came up, and I think they weren't enabling HSTS on www.gstatic.com.

Refreshed during triage.