Hi David,
I'm not arguing against helping improve the user experience of captive portals as they're commonly understood and currently deployed; I'm against expanding the definition of "captive portal" to give the network more control over communication *after the captive portal phase is done.*
Of course, networks already have significant power over what a user can and cannot do over them. Codifying this by standardising a way for networks to interpose themselves in subsequent communication, or pop up "helpful" information on the fly, or selectively refuse communication and offer replacement content -- all of which seem to be under discussion here -- is a pretty substantial expansion of that power, in practical terms.
It may be that that's the right thing to do, but it'd need to be informed by a wider discussion. This was *not* the scope of work that I understood when this WG was chartered.
WRT your question about "who is the IETF to define what is an appropriate business model access" -- this is a question that is being taken seriously in the IETF, as evidenced by tech plenary session in Chicago. It's clear that we don't solely determine the balance of these things on the Internet, but it's just as clear that we do have some role to play; I think it'd be pretty poor if we just abdicated any responsibility to end users and said "let the market sort it out, we just write specs." At the very least, I'd expect a discussion of the effect these changes might have upon the Internet and people's access to it.
Regards,
> On 11 Apr 2017, at 10:15 am, David Bird <[email protected]> wrote:
>
> 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
>
--
Mark Nottingham https://www.mnot.net/