[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] time-based walled gardens
Hi David,
> On 22 Jul 2018, at 6:27 am, David Bird <[email protected]> wrote:
>
> Hi Mark,
>
> I was reminded of this thread, as I believe some of the points continue to be on topic.
>
> Networks, particularly public access networks, already do, and will continue to do, all sorts of things we might find questionable - on several levels. We have some questions because the network infrastructure itself has no way to be transparent about the things it does today. It will silently (or at least ideally transparently) hijack HTTP(S). It will silently drop packets not in the walled garden. It will rate-limit packets without indication. With captive portals, that guesswork has led to probing, having to hijack HTTPS (because the UE will not understand a Drop), and other usability problems.
>
> We can remove this UE guesswork by defining how networks *should* implement these enforcement functions, with the proper transparency for the UE to no longer need to guess. This will actually help make the operator more accountable for their enforcement function behavior.
I agree, but realise there's a flip side to this -- by standardising and making these functions explicit, we are encouraging their use, both tacitly (standardisation == approval) and by making the functionality more reliable (when implementations support those well-defined cowpaths). That effectively encourages they deployment of those enforcement functions.
The ever-so-careful line we need to walk in this work, I think, is to balance the amount of damage caused by the deployment of these mechanisms, while not encouraging an increase in their deployment by making them more viable. Of course, that's a judgement call, but if we didn't have those, standards would be much quicker...
> By addressing the core issue of ‘signaling captivity’ at the network layer, we are just annotating (e.g. with ICMP feedback) what is already happening in the network, in real-time, transparently (as in full-disclosure). This, in of itself, does not add new captive portal capabilities - only better information for the UE to provide better user experiences.
As per above, I'd dispute the "only" -- there may not be new capabilities, but making existing capabilities work more reliably, predictably and with the "air cover" of standards will change their deployment patterns.
In other words, the implicit goal of most interoperability work is to encourage increased deployment. We try to make HTTP more interoperable so that it's easier for more people to use, so they use it more, so that we enjoy the increased network effects of its use. I don't think increasing deployment of captive portals is a good goal. Others may disagree, for various reasons, of course.
I do think that where a captive portal is deployed, making it less painful is a good goal. Hopefully we can all agree on that.
> 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.
Hope that helps,
>
>
>
> 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.
>
> 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.
>
> 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/