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

Hi David,

[snip]

On 25 July 2018 at 08:59, David Bird <[email protected]> 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?

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals