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

On Mon, Apr 10, 2017 at 4:46 PM, Mark Nottingham <[email protected]> wrote:

> On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson <[email protected]> wrote:
>
> CAPPORT doesn't have to just solve its own problems, perhaps it'd be good to try to come up with a slightly more generic solution and send it for review in INT-AREA for instance?

If I follow the discussion here and on the issues list correctly, I'm concerned.

My understanding when this WG was chartered was that we didn't really *like* captive portals, but people thought there was some benefit to at least making their operation smoother; we had lots of examples of interop problems and bad user outcomes in the discussion leading up to it. In that manner, the goal here AIUI is to codify current practice and incrementally improve it.

Indeed, there is a distinct bias against captive portals, of all forms. We all hate them, but we all still use them. (don't you?) I also hate paying taxes.

Often, venues don't want to use them either, but they need to for a variety of reasons, some legal (as in they are legally required to display something), but who are we to judge? Ideally, we get rid of http hijacking. But, there will always be legacy devices - for the foreseeable future, and you just can't say they aren't supported in public access (or not subject to restrictions), nor can a network trust a device to always do what it is told.

As I said in the BoF, even mitigating those problems might not lead to a great outcome, as it will encourage the deployment of more captive portals (as many networks are rolling them back, at least in my experience).

There is one use case defined in our charter:

"""
Some networks require interaction from users prior to authorizing
network access. Before that authorization is granted, network access
might be limited in some fashion. Frequently, this authorization process
requires human interaction to arrange for payment or to accept some
legal terms.
"""

Expanding the scope of this work to allow networks to further control their users' experience after authorisation to use the network (even if that is just giving a better user experience of that control) is not a small change. Allowing networks to interpose themselves in communication after authorisation is not a small change.

But, alas, networks are already doing this and people are using these networks (willfully, they can always pick another network). They just can't do it in very elegant ways and still implement their business model. Who is IETF to define what is an appropriate business model for public access, or any access? Yes, I think the UE can do more to protect users and take the front-seat in the user / provider expectation gap in public access -- which is, users want it, providers have it, and UEs are increasingly making it harder for both (for a couple of unrelated reasons).

I think we need to play both sides of the fence here, a little bit... captive portals are not ALL bad! Not all use-cases are evil. Yes, in public access you have evil twins and rogue APs, but I'd say, focus on making objective and secure end-to-end protocols... nobody said the Internet was a safe place.

(and we wonder why there isn't more industry activity in this WG?)

AFAICT addressing these use cases would require re-chartering, and that's something I would argue vigorously against. I'd like to hear a clear statement from the Chairs about what they think the scope of work is here.

Regards,

--
Mark Nottingham https://www.mnot.net/

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