Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <dbird@google.com>]

I found a really good example of why a Hotspot operator would not want to share their walled garden configuration with visitors (unless they have to, e.g. you try to access the service). Or, at least a reason for them to NOT give you the full picture (e.g. lie).

I stumbled onto a configuration file, that I don't think was meant to be publicly available (so, I will not provide a link). It is the NAS walled garden configuration for several airports for a major hotspot services company. It reveals a lot about their partners and business model. I don't see why a venue would want to advertise this information, accurately anyway....

On Wed, Apr 5, 2017 at 1:02 PM, David Bird <dbird@google.com> wrote:

Thanks for your comments!

Re: "I can imagine, they would like to inform the user upfront of what they provide; not wait until the UE visits something outside of the walled garden."

I agree, but chances are VERY high that _something_ will trigger the Os capport detection to give the user a captive portal notification. If not, then the walled garden is so large that the UE (nor the user) should even care if there is a portal or not. (The user might like the fact that their phone is already doing software upgrades, maybe at a low rate limit, in the walled garden even while they are interacting with the captive portal).

I think the UE is foolish to take any such information from the API ... I am already writing my blog post entitled "How IETF standards are keeping your devices captive" :)

On Wed, Apr 5, 2017 at 12:25 PM, Vincent van Dam <VvanDam@sandvine.com> wrote:

I don’t think the API should contain anything that would move control towards the UE. I think the API at most should be informative; as a decoration on the information it could provide the user by either sending him to the capport url, or as additional information that was not included in the icmp message that triggered the API call. Authentication of the icmp message could also be a role for the API, but I think if this could be solved without the API but with icmp itself, it would be much better.

I expect if the API would be rich, and hint towards control, adoptation will be low, and could lead to half/buggy implemetations. Also, I expect, if the capport provider is trying to defeat the sandboxed browsers, which seems to be because they lack control (analytics/tracking/marketing requirements), I think it’s safe to assume that an API that potentially can go beyond the sandboxed browser limitations, would not be something commercial capport providers would appreciate.

Also, I have my doubts concerning legal issues as well; for e.g. accepting t&c’s, would the capport-provider rely on a UE implementation that would display & handle accepting this? What if there is a legal dispute, and the question arises if the user actually accepted the t&c’s; where would you start the investigation and the capport or at the UE implementation that did some magic t&c accepting implementation? Moving (or keeping) that journey inside a browser would leave the control at the capport-side.

With that in mind, and back to my first statement, I think the only decoration that makes sense is too facilitate devices that aren’t capable of displaying the capport itself, but maybe are capable of displaying some message on a small display (internet of things, maybe e.g. a internet radio appliance). But maybe this could be solved by supplying a reason in the icmp.

The sandboxed browser is something interesting. If the icmp would trigger, instead of the capport detection, and the result would be that the capport sandboxed browser is opened; how would that fit the (e.g. mobile) use case where the user hit is quota when he was watching youtube. Most of the discussions focus on joining the network, while in my opinion this is just one half of the capport scope. 

The ohare airport is interesting as well; if the icmp is the trigger, the capport might not be triggered immediately. I can imagine, they would like to inform the user upfront of what they provide; not wait until the UE visits something outside of the walled garden.

Would it make sense to hint the UE that the capport should not be opened in the sandbox browser, but should be opened in the default browser instead? Currently there is no formal means for the capport provider, other than give the correct responses on the magic urls. Though, I think if this option would exist, by default capport providers will choose to use the regular browser.

---

Van: Captive-portals [captive-portals-bounces@ietf.org] namens David Bird [dbird@google.com]
Verzonden: woensdag 5 april 2017 19:15
Aan: Dave Dolson
CC: captive-portals@ietf.org; Christian Saunders
Onderwerp: Re: [Captive-portals] Arguments against (any) Capport "API"

I agree with that... but, to be clear, it really is just an improvement on WISPr XML, and with WISPr XML already, not only used, but used to make money, the reasons for supporting this API MUST be inline with the venue/Operator needs. 'Automating login' (as a focus for the API) quickly becomes venue / regional / legal / vertical / application / access policy dependent.. Not to mention, I question the value for the user in making it super simple for their devices to auto-login into public access networks (without clear user intent). This seems irresponsible, on our part, when there are solutions out there already that do automate this login, but only after taking extra security measures (presumably, hotspot aggregators conceal your identity when roaming, and their Apps can do more things).

On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <ddolson@sandvine.com> wrote:

This is OK if you only need to serve devices with browsers and attentive humans.

The API offers possibilities for automation in the device by making a formal data model (vs. HTML).

 

 

From: Captive-portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

 

The currently proposed solution has 3 components:

1. The ICMP component is used to detect a captive network.

2. The DHCP component is used to discover the address of the Captive Portal.

3. The API is an information service with a standardized interface that allows discovery and potentially remediation of the requirements for network access.

The ICMP and DHCP components are sufficient to resolve the redirection and HTTPS issue.

I would consider the API as an optional component - it might create some user experience benefits if the device developers and network operators choose to use it.

The difficulty with the API is having a way of codifying all of the possible network access requirements.  I'm not sure this is reasonably possible.

Assuming that such a definition is possible, then there is some benefit to the common definition.

(It also strikes me that this definition would make a nice back end design for the Captive Portal itself.)

Cheers!

Christian

On 17-04-05 10:25 AM, David Bird wrote:

Edits in-line :)

 

On Wed, Apr 5, 2017 at 9:06 AM, David Bird <dbird@google.com> wrote:

A few more key benefits of the ICMP approach :

 

- Capport detection is made easier for the client, even when RFC 7710 (or any API) is NOT implemented (as long as the NAS is Capport compliant).

 

- "Signaling" can be done by different components (NAS, iptables, rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with a central service.

 

- In defining the RFC in how a NAS should handle blocking traffic for Capport compliant devices, we are also defining how the NAS should handle Legacy devices - which is, there is no difference - they both get ICMP Dest Unreach w/Capport extension) - which is helpful.