Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01

From: "Cohen-Rose, Adam" <[email-masked]>
Date: Mon, 4 Apr 2016 16:26:24 +0000

Hi there,

Thank you for the comprehensive problem statement and I hope you have a
good discussion tomorrow in Buenos Aires.

A brief introduction: I work at The Cloud, part of Sky UK, where we run
over 20,000 public Wi-Fi hotspots in the UK.

We spend a large amount of time trying to give our customers a good
experience when getting online, accessing from mainly mobile phones and
tablets, so we definitely welcome moves towards standardising device
behaviour.

Some stats that might help with context: around 50% of the requests to our
captive portal come from non-browser apps; also we see over 500 million
HTTPS requests per week from unauthenticated users and this is only
growing as sites move to HTTPS.

The move to HTTPS does provide us with difficulty -- when devices don¹t
open a captive portal browser but offer a search bar that goes to an HTTPS
site, the end user is sometimes left with an empty page and no indication
of how to connect.

At The Cloud we come across similar situations to those described by Lukas
at Asteas/IACBOX -- our captive portal pages are there to authenticate,
inform and sometimes to pay, but also to capture customer information
(such as whether they consent to be contacted by our venue partners).

We operate both open and secured SSIDs, but since we are not a mobile
operator there is not yet any simple way for us to offer the secured SSID
to walk-up customers. One option that might be worth bearing in mind is
some mechanism to prompt customers to switch from the open SSID to the
alternative secured SSID in the same location.

I¹m very happy to contribute towards an industry survey and will keep
following the discussion in the mailing list.

Best wishes,

Adam

--

Adam Cohen-Rose
The Cloud (A Sky UK Ltd company)

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2016 14:43:14 -0400

> alternative secured SSID in the same location.

So, a URL-scheme that could contain a pointer to the other SSID.

    > following the discussion in the mailing list.

I'm super-happy to have you on the list.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Apr 2016 17:42:21 -0300

> So, a URL-scheme that could contain a pointer to the other SSID.

You mean something I could put on my webpage that, if clicked, would
cause a device to connect to the identified SSID?  That might be less
than good.  I thought that Adam was talking about plain ol' text, but
maybe he can confirm.

> I'm super-happy to have you on the list.

Likewise.  It's good to have this sort of perspective.

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Tue, 5 Apr 2016 14:49:29 +0000

On Comcast’s open wifi deployment we make our best attempt to upgrade
security upon authentication on our captive portal page.  After a
successful login,  we have unique flows for each operating system that
deliver secure profiles to the client for installation.  This is very hard
to maintain and QA test as the operating systems’ sandbox gets more strict
on each iteration.    I do not know if its this is a problem we need to
address immediately but it s something we need to think about as we
transition into secure phy layers.

-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone  215.286.7283
Cell  215.609.2691

On 4/4/16, 5:42 PM, "Martin Thomson" <[email-masked]> wrote:

>_______________________________________________
>Captive-portals mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/captive-portals