One pitfall to keep in mind here: shill's portal detection is less robust than Chrome's. And I suspect that will always be the case.

If you ask cbentzel@, he'll probably tell you that captive portal detection is hard, and requires ongoing maintenance. One obvious limitation of shill's captive portal detection is that shill doesn't understand proxy-auto-configuration.

What that means is that if the network requires the client to use a proxy for web access, shill will probably misreport the network as a captive portal network, _even_ if the network has provided the client with the details of the proxy configuration. (See https://en.wikipedia.org/wiki/Proxy_auto-config)

One reason for this limitation is that handling proxy-auto-config would require shill to either embed a JavaScript engine, or IPC over to Chrome to resolve the portal-check URL.

But even if the team were to deal with the proxy case, I imagine it'll be an ongoing battle to make the portal check as robust as the one in Chrome.

The other thing we've been discussing is that Chrome can incorporate other knowledge into its algorithm:

 - Cert errors on HTTPS
 - Whether the cert errors fit the profile of known portals
 - Page load events (to figure out when to trigger a recheck)
 - Normal HTTP requests suddenly coming back with portal redirects when the portal session times out

Do we even need a Portal state in shill?  The only use case I could think of is if it factors into the service sort order, keeping LTE active when wifi is stuck in Portal state.

Thanks for the input. Then I think we shall not depend on shill portal state. Seems we shall not simplify chrome's portal detection, instead need to make it more robust, given the suggestions from Kevin.