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

The browser sandboxing issue is slightly more complex... I too am hoping engineers working on such things participate in this discussion!

I've been told various reasons, from 'I don't remember', to 'others do it that way', and sometimes reasons why it serves to protect the user. The latter argument, I believe, is historic in that captive portal networks were (are?) viewed as 'hostile'. I don't think this argument really holds much weight because:

- It conflates captive portal to mean public access. Today, a captive portal doesn't have to mean public access (it can be a trusted network too). Also, an Open SSID network with no portal is just as hostile (if not more, in that they aren't even notifying you of their man-in-the-middle 'presence').

- The sandbox browser comes up because, we guess, the network is 'hostile' (even though the user *selected* this SSID in the case of it being Open), yet after the user interacts with the captive portal, the UE determines all the sudden that the network is not so hostile? To think that people today select an Open SSIDs and then freak out about a captive portal I think is out-dated.

If protecting the user, while also offering ease of use for legitimate captive portals, I will be idealistic and say:

- UE should classify networks as public vs. private, where an Open SSID is always automatically put into the public category. All non-secure browser connections get sandboxed, secure connections go ahead (let TLS do its thing). [This line item has nothing to do with captive portals.]

- If the UE detects capport, that it will at least check the URL from capport detection (following any redirects) to verify it is https:// before launching a user default browser (with or without a message somewhere indicating this site is a captive portal). If it makes the user feel better, non-https could be sandboxed, but not when secured.

- To prevent a network from getting a URL / website into your default browser cache (by hijacking and redirecting you there), the UE should present the user (even in the notification event) of the captive portal URL FQDN they are about to connect to -- it could even give a TLS indication and cert verification icon. (Of course, the clever attacker can still mess with you using DNS and hijacking connections later on, after capport detection, so...)

What is ironic is that this is sometimes called an 'arms race', when in fact both parties are just trying to make the user experience better or safer, yet neither are being successful. For Hotspots, they have website usability reasons to hate capport detection, yet increasingly they are having problems with user experiences around HTTPS. Engineers hate captive portal, they think they are broken, and think avoiding detection is further proof captive portals can't be trusted. Hotspot are largely broken for the user because of the combination of sandboxed browsers and OS capport detection being evaded.

A note about capport detection evasion: It is not always on purpose... As more hotspots do "social login" applications, they are opening up the walled garden surprisingly wide to get that to work...

On Wed, Apr 5, 2017 at 9:40 AM, Dave Dolson <[email protected]> wrote:

I’d like to hear from browser vendors as to why the browser gets sandboxed when interacting with a captive portal.

If one could trust the URL came from the local network (via DHCP), could restrictions be lifted?

If the URL were HTTPS, and certificates were valid (e.g., valid cert of Chicago OHare Airport), could restrictions be lifted?

Because as we’ve heard, portals try to defeat captive portal detection to get the “real” browser: cookies, video player, etc.

-Dave

From: Captive-portals [mailto:captive-portals-[email protected]] On Behalf Of David Bird
Sent: Tuesday, April 4, 2017 5:35 PM
To: Christian Saunders

Cc: [email protected]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"
Thanks Christian,

I wanted to high-light something you said:
On Tue, Apr 4, 2017 at 1:13 PM, Christian Saunders <[email protected]> wrote:

I agree that determining the operators intention for the portal isn't really worthwhile.

On the other hand, it is worth providing the operators with tools to enable as seamless an experience as possible.

This is exactly right... the (consistent) and seamless an experience as possible.

However, today this sometimes means tricking UE captive portal detection into not giving you the 'other' browser (sandboxed, incognito, or otherwise not the browser the user is already logged into sites with). For people who build fancy websites for Hotspots, you can imagine that is frustrating (to require users to login, every time, even when your site uses HTTPS and cookies are "safe").
Beyond this the operators will sink or swim on their own merits.

Cheers!

Christian
Shaw Communications Inc.

On 17-04-04 02:05 PM, David Bird wrote:
Attribution / advertising is a big motivator, at least in the US.

On Tue, Apr 4, 2017 at 1:00 PM, Kyle Larose <[email protected]> wrote:

I was sitting in a coffee shop on Saturday in Chicago, and decided to log in to their wifi. It was a captive portal that basically said something like “Hey, we’re giving you this service for free, because we’re [the coffee shop] awesome!”. To log in I just needed to click a button to continue.

The point here, I think, is that the coffee shop is providing this as a service to you, and wants you to know that. I’m not sure how much that is worth to them, but it’s an example of something that isn’t just ToS, and wasn’t terribly intrusive.

From: Captive-portals [mailto:captive-portals-[email protected]] On Behalf Of David Bird
Sent: Tuesday, April 04, 2017 3:52 PM
To: Mikael Abrahamsson
Cc: [email protected]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

My opinion is that guessing why venues put up a portal isn't always that useful. The point is, they have a reason. In some countries, there are legal requirements to display ToS. While we could try to implement ways around ToS type portals, are we helping the venue be more compliant? In all jurisdictions? (Some laws *require* the ToS is displayed *every time*).

For some locations, they may simply WANT to annoy you! (While also collecting per session fees from Boingo or iPass for the privileged of skipping that annoying portal.) More than likely, however, sites like the one you mentioned are just themselves concerned about liability and want that minimal amount of disclaimer...

As a user, you should either be willing to view the portal, pay for ease of use, or find another network...

David

On Tue, Apr 4, 2017 at 12:43 PM, Mikael Abrahamsson <[email protected]> wrote:

On Tue, 4 Apr 2017, David Bird wrote:

The one area I do see value in solving is how to get headless IoT devices on-line on capport networks.. But, in some ways, all we need their is a WISPr client in the device and an out-of-band way of configuring credentials into it. That can be solved with existing protocols and technologies.

I only have experience with captive portals as a user. When I travel the world, I have frequently seen captive portal pages that as far as I can see, offer nothing apart from a login page. It might have the hotel name in there, but that's it. So then I have to manually do something like find the piece of paper where my username/password is, and enter that. It seems to be only about authenticating me as actually being a resident of the hotel or whatever venue it is. Sometimes it seems to be there because there are legal requirements for tracking (they will write down a log of my room number and username on the paper in a ledger).

It's extremely cumbersome and as far as I can tell, it adds nothing for the WISP (at least nothing I can tell) by means of marketing or alike, it's only for assuring that people in the street can't just use the wifi.

Do you know the motivation for doing this in the context of your email? Is there added cost for them to automate the behavior, as in IPR or other licensing cost for them to use the automation tech that perhaps is already available in my mobile device?

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