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

[David Bird <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *On
> Behalf Of *David Bird
> *Sent:* Tuesday, April 4, 2017 5:35 PM
> *To:* Christian Saunders
>
> *Cc:* [e-mail]
> *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 <
> [e-mail]> 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 <[e-mail]> 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:[e-mail]] *On
> Behalf Of *David Bird
> *Sent:* Tuesday, April 04, 2017 3:52 PM
> *To:* Mikael Abrahamsson
> *Cc:* [e-mail]
> *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 <[e-mail]>
> 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: [e-mail]
>
>
>
>
>
>
>
> _______________________________________________
>
> Captive-portals mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>