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

From: David Bird <[email-masked]>
Date: Sun, 22 Jul 2018 06:27:33 -0700

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. 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.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?*

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

>
> > On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jul 2018 11:36:08 -0700

Hi David,

> On 22 Jul 2018, at 6:27 am, David Bird <[email-masked]> 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,

> > 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).
> 
> 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,
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 25 Jul 2018 09:09:36 +0200 (CEST)

On Tue, 24 Jul 2018, Mark Nottingham wrote:

> 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 IETF has tried to resist things historically, and from what I can 
tell, the track record is mixed. Captive portals are not going away 
anytime soon, so the only thing we can do is to make them work as well and 
invisibly to the user as possible.

There are lots of things I do not like in the world, 20 line legal 
disclaimers in the email footer, captive portals, 60 page EULAs etc. Yet, 
10+ years on, they're still with us, and no sign of going away.

So I support their standardisation and integration into devices, so that 
they're as trouble-less to the end user as possible. Today it's a mess, 
but it's a mess that's not going away because we try to keep it a mess by 
not creating better solutions.

Also, again, I'd like to re-iterate that captive is related to PvD, in 
that it's a property of the network that can/will change. So Capport 
should look into not only solving the capport problem, but try to hook 
into (and help enhance) other use-cases as well, that are in related 
solution space.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Bird <[email-masked]>
Date: Wed, 25 Jul 2018 05:59:53 -0700

Hi Mark,

On Tue, Jul 24, 2018 at 11:36 AM Mark Nottingham <[email-masked]> wrote:
[snip]

> 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...
>
>
Well, I'd argue that the functions being performed - Redirect, Drop,
rate-limit, etc. (per flow) are all done today already. Sure, we unlock,
perhaps, new 'features', but only because user interaction problems are
solved (which is the same goal of the API).

>
> > 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
> 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.
>
>
It sounds like you want to intentionally keep captive portals broken, at
least enough, to discourage their use... (isn't that exactly what we have
today?) But, many network do *not* have a choice - say, if local laws
require certain things.

>
> > 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.
> >
> 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.

---

From: Kyle Larose <[email-masked]>
Date: Wed, 25 Jul 2018 11:43:36 -0400

Hi David,

[snip]

On 25 July 2018 at 08:59, David Bird <dbird=[email-masked]>
wrote:

> 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...
>

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.

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

I imagine the workflow of a user would be along the lines of:

   1. UE says an open network is available
   2. User associates with network
   3. UE discovers captive API on network
   4. UE does not update routes to go through network
   5. UE tells the user that the network is captive, and that they should
   visit the portal
   6. 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
   7. 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

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?

---

From: David Bird <[email-masked]>
Date: Wed, 25 Jul 2018 12:26:21 -0700

Hi Kyle,

> 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.

> traffic through? Would that be a problem (i.e. would it just fall back to

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...

>    3. UE discovers captive API on network
Discovers by the API only ? (assuming yes...)

>
>    1. UE does not update routes to go through network
>    2. 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..."

>
>    1. Option 1: User goes to portal
>       - API indicates that the user has access, so UE updates its routes
>       to go through that network
>    2. OR Option 2: User ignores portal:
>       - 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. "