Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <[e-mail]>]

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 <[e-mail]> wrote:

> On Fri, Apr 7, 2017 at 6:36 AM, Erik Kline <[e-mail]> 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...
>
>