A root cause of the so-called 'arms race' around captive portal detection that I'm trying to highlight is that it will always continue for as long as UEs treat captive portal networks specifically different than they do public access networks generally, you will have incentive to exploit that difference in behavior in the public access industry.On Fri, Apr 7, 2017 at 6:52 AM, David Bird <[email protected]> wrote:On Fri, Apr 7, 2017 at 6:36 AM, Erik Kline <[email protected]> wrote:I think the client should, ideally do:- Use the network for all connections (why ask permission when forgiveness is cheap).Not gonna happen. Mobile clients do a ton of work to enable "make before break". There is no such thing as forgiveness from users who can't get Facebook updates, Twitter notifications, nor email while their device is held hostage because it switched to Wi-Fi and tore down mobile before checking for a captive portal.But, it DOES happen when you connect to Open SSID without captive portal (or when the venue evaded your detection). Maybe the captive portal networks wants to offer these services in their walled garden... and it is likely the user would be happy about that (provided they selected the network on purpose).If you had ICMP giving you real-time feedback, you could more accurately (and quickly) detect what connections will work and which will not on the network. QUIC will help in maintaining session continuity as connections are pinned to different interfaces.This may also address your question elsewhere about browsers and "sandboxing". I suspect the sandboxing to which you're referring is about cookie isolation (primarily), but there's a kind of "network sanboxing" that is applied as well to ensure the browser uses a self-consistent networking configuration.Cookie isolation on secure websites doesn't really help the user any...
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature