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

Hi Kyle,

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.

Not exactly...

- I believe networks *would* deploy the API on otherwise open network (and it sounds like some think that is a fine idea, even an intended use-case).

- Someone mentioned the UE when prompting the user about captivity learned from the API might have a "Connect anyway" option, which I made equivalent to "Skip portal" -- as would users should they come across the above mentioned networks.

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)?

That is exactly how I think this breaks in deployment...

- Users *will* encounter networks where there is only an API captive portal *suggesting* the portal. Users can still use anyway, without even bothering with a captive portal in some cases, and they learn to do so...

- However, other networks really do *require* captive portal (at the network layer)... the API would be helpful here, but the user might have already "skipped" that interaction opportunity...

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

Discovers by the API only ? (assuming yes...)

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

*Should* go to the portal? Or, else ? (they already selected the network, mind you...)

I think Tommy suggested that the dialog might have a "Connect anyway..."

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

I'm not sure there was agreement on the "User ignores portal" selection..

Tommy said (on the topic of API being used on otherwise Open network): "In this case, the user will see a landing page prompt when they join the network. That's the only "harm" in this scenario. Just like today when the user gets a prompt for a captive network, they can ignore it and stay on the network and continue to use it. "

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