> 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.
Captive-portals mailing list