Re: [Captive-portals] time-based walled gardens

[Erik Kline <[e-mail]>]

On Thu, 26 Jul 2018 at 00:43, Kyle Larose <[e-mail]> wrote:
>
> Hi David,
>
> [snip]
>
> On 25 July 2018 at 08:59, David Bird <dbird=[e-mail]> wrote:
>>
>> Hi Mark,
>>
>>>
>>> > What is concerning with the API and direction of the WG, is that we are defining a new form of captivity … “self enforced”. Which will lead to the UEs doing probing to “confirm” the API captivity matches the Network captivity. Networks with API captivity can even be put on top of previously Open WiFi networks (that have no Network captivity). This is new - even if the UE allows the user to ignore the API captivity.
>>> >
>>> > Having written the problem statement, what are your thoughts on the direction today?
>>>
>>> I have lots of questions about how it's going to play out, but at first glance it looks interesting -- if only because it provides a way for some portals to be less intrusive on the network. For non-financial cases (e.g., T&Cs, ads), it *might* be enough to deploy a captive portal without any blocking. One could argue that it might encourage increased deployment, but *if* it works out, the less intrusive nature might balance that out.
>>>
>>
>> Networking putting the "API captivity" on networks without any real network captive portal might sound like an improvement, but I think it will not play out that way...
>>
>> For starters, not all networks *can* do that (legal requirements, etc). And, as networks do deploy it on open networks, users (and UEs) will just be trained to ignore it - "skip the portal" button. However, the user/UE will also experience networks that have network captivity even after skipping the "API captivity"... and we are back to where we started... probing, https redirecting, and UEs guessing.
>>
>>
>
>
> I just want to confirm: you're saying that nobody would actually deploy a bogus API on a network without real captivity because people would simply ignore it, and that this then leads to an arms race with legitimate portals? I'm not sure how the API would facilitate a "skip the captivity" button. As currently phrased, it's simply there to tell you when you are captive so that you may visit the portal.
>
> If the API says you're captive, then the UE would suggest you visit the portal. If you weren't actually captive, I guess you could skip doing so, but wouldn't the UE consider the network broken and not actually try allow traffic through? Would that be a problem (i.e. would it just fall back to probes)?
>
> I imagine the workflow of a user would be along the lines of:
>
> UE says an open network is available
> User associates with network
> UE discovers captive API on network
> UE does not update routes to go through network
> UE tells the user that the network is captive, and that they should visit the portal
> Option 1: User goes to portal
>
> User accesses the portal. possibly reads the text, and clicks accept
> API indicates that the user has access, so UE updates its routes to go through that network
>
> OR Option 2: User ignores portal:
>
> User ignores the portal. UE does not update routes
> User fails to do anything with network, and either finds a new one, or actually goes to the portal
>
>
> Now, the UE *could* just let the user through in #7, or give the option to the user to use the network anyway (is this what you're suggesting leads to the arms race?), but is that likely?
>
> Note that there is one possible flaw here in #6, what if the API always returns "disallowed"? I think that the user would just not use the network. Sure, the network has had one or two hits at its portal from that user, but is that any different than a portal which does the same thing today?

(co-chair hat off)

I think a reasonable assumption on the part of the UE would be: if the
API exists && it's telling me I'm captive, then assume successful
probes are successful for some /other/ reason than the portal being
generally open.  As a result: do not switch to this network
automatically (manual action by the user or this network being the
/only/ network connection available to the device could change this,
of course).