On Thu, Apr 6, 2017 at 1:40 AM, Dave Dolson <[email protected]> wrote:
I’d like to hear from browser vendors as to why the browser gets sandboxed when interacting with a captive portal.
In the case of Chrome, it's a technical limitation. The browser just doesn't support using a network that is not the system default network, and that is required to log into a captive portal without disrupting all other Internet access on the device (e.g., email sync, incoming chat messages, etc.).
The necessary work is both infrastructure (per-network socket pools, per-network DNS requests, per-network change events, etc.) and UI - e.g., how to denote in the UI that a particular tab is tied to a particular network.
Android provides an API that a multinetwork-aware app can use to offer to log in to captive portals instead of the system default app. In order for that to work the app must have the ability to display web pages on a network that is not the system default network. IIRC there was some interest from Firefox to implement this API, but I'm not sure whether they ever did.
Because as we’ve heard, portals try to defeat captive portal detection to get the “real” browser: cookies, video player, etc.
As regards the captive portal login app on Android: other than cookies, which are technically impossible except by lifting the technical limitation above, since they are in the Chrome app which has its own cookie store in its own directory, what issues do you see?