Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

["James Wood" <[e-mail]>]

Hi

First of all, great progress appears to have been made with 7710 and
capport/icmp-unreach. Good job!

As a global WiFi provider I would like add our thoughts on the discussions
to date along with my personal views of the problems/challenges we face with
captive portals today. I'm hoping I can contribute to this WG by expressing
views from the 'other side', and why captive portals are still important to
WiFi operators.

Most providers including ourselves require a portal to be displayed for a
number of reasons. Many have already been covered but to confirm, some
countries require (legally) to capture certain information (such as a valid
mobile/cell number to validate it's a real person/device), or accept
T&C's/Privacy policies in respect of the country the hostpot is located.
Other reasons are for advertising, providing seamless logins (i.e. we know
the MAC of the device so we can bypass the portal page and instead present a
welcome back page). But, the real reason most providers insist on a user
going through a portal is to understand who is using their free wifi. There
has to be some payback to the operator/customer and data capture is this.
They may not use the data to market, but just look at how many people
connect and at what times of day etc, or they may send promotional emails to
users who login etc.

So, captive portals are great as a way to onboard and capture some details.

That said, we face daily challenges with captive portals. To name a few:

1. Security. Nobody prefers to join an open network, but most end up doing
because that's the way it is. The hype around Hotspot 2.0 came and went as
that was never really deisgned to help captive portals but rather for
seamless, non-interaction from the user. As a portal provider, we don't want
that, we want to show a portal even if it's just a 'welcome back, you're now
online' message.

2. More devices/browers/web servers are defaulting to checking/redirecting
to a HTTPs URL. As you know, when in a captive portal/walled garden state,
this will cause a problem because you can't intercept a HTTPs request
(rightly so!) to a captive portal page without a browser/certificate
warning. This breaks everything from the end user perspective.

3. Built-in OS captive popups provide limited browser
functionality/cookies/etc. When trying to offer login options like Facebook,
it can really affect the user experience when cookies are not permitted or
other features disabled. The behaviour is also different per device. In
Android 5.0+, the captive portal window immediately dissappears when the
user is authenticated. This is a pain for us as we want to display a "you
are now online" page, or redirect the user to a landing page with
information etc.

4. Walled garden. It's a nightmare having to manage lists of domains/IP's
across all the different vendors kit out there. For example to offer a
social login through Facebook we need to allow certain domains like
facebook.com, akamaihd.net and connect.facebook.net etc. This is all static
lists inside an AP/controller, and would be a nightmare to update should
Facebook change the URLs they send authentication requests throught etc. How
about some way to dynamicly pass back a list of domains as part of the DHCP
option or some other way to allow the operator to set the required domains
at time of connection? Or, how about, as part of the capport API, we are
able to send a list of domains back to the AP, so if someone chooses
Facebook, we open the Facebook domains for that MAC for a few minutes to
allow them to login.

Other thoughts...

I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it
describes the example URL that could be returned as part of the captive
portal URL: https://wifi.domain.com/portal?icmp_session=10&policy_class=100.
However, what about the other traditional parameters that a captive portal
redirect injects? As a minimum, we need the ap_mac, client_mac and login_url
to which we post the login request back to (traditional captive portal login
request). Without such parameters, we cannot identify the venue/ap/client
and provide the relevant portal splash page and user specific options. I may
have misunderstood this?

Does anyone here see Hotspot 2.0 (release 2 or further in particular) and
OSU as the answer? I don't think I do. It just doesn't seem to help us as a
provider but instead tries to be around getting the user online as quickly
and without any interaction. Providers are all for making it easy for users
to on board, but they need to get something out of it to make it pay. 

I am more than willing to take any questions and offer as much insight as I
can.

Thanks

James