Subject: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires.

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Feb 2016 17:46:21 +0000

Hi all,

Just to let you all know / remind you that CAPPORT will be holding it's
first official WG meeting at IETF95.

We are in the process of organizing the agenda - one of the things which we
heard from you at the BoFs is that you would like something like a "survey
of the industry" (e.g motivation for deploying a CP) and a more complete
understanding of why captive portal operators do things like defeating /
whitelisting the captive portal probes.

Mark Nottingham is already working on a "problem statement" type draft with
outlines some of this, but we'd like more viewpoints/ discussions.
His initial submission is here: "Before You Log In, Here's A Brief Message
>From Our Sponsors!" - draft-nottingham-capport-problem (
https://datatracker.ietf.org/doc/draft-nottingham-capport-problem/)

So, if you develop and / or operate a CP, we'd really like to hear from you
- we give priority agenda time to drafts which have had online discussion,
but may be willing to also have more of a discussion type presentation.

Martin and Warren.
----

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Feb 2016 10:24:50 +1100

> On 16 Feb 2016, at 4:46 AM, Warren Kumari <[email-masked]> wrote:
> 
> Mark Nottingham is already working on a "problem statement" type draft with outlines some of this, but we'd like more viewpoints/ discussions.

Please!

> His initial submission is here: "Before You Log In, Here's A Brief Message From Our Sponsors!" - draft-nottingham-capport-problem (https://datatracker.ietf.org/doc/draft-nottingham-capport-problem/)

... and that's really just a regurgitation of what we previously put together at <https://github.com/httpwg/wiki/wiki/Captive-Portals>.  If people have suggestions, corrections, pull requests, etc. I'm all ears.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Roscoe, Alexander" <[email-masked]>
Date: Mon, 15 Feb 2016 23:41:06 +0000

I like the idea of Github, I know its more than just for code but I hope
we produce running code that we can check in :)
-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone  215.286.7283
Cell  215.609.2691

On 2/15/16, 6:24 PM, "Mark Nottingham" <[email-masked]> wrote:

>> Mark Nottingham is already working on a "problem statement" type draft
>>with outlines some of this, but we'd like more viewpoints/ discussions.
>
>Please!
>
>> His initial submission is here: "Before You Log In, Here's A Brief
>>Message From Our Sponsors!" - draft-nottingham-capport-problem
>>(https://datatracker.ietf.org/doc/draft-nottingham-capport-problem/)
>
>... and that's really just a regurgitation of what we previously put
>together at <https://github.com/httpwg/wiki/wiki/Captive-Portals>.  If
>people have suggestions, corrections, pull requests, etc. I'm all ears.
>
>Cheers,
>
>
>
>--
>_______________________________________________
>Captive-portals mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 16 Feb 2016 13:15:07 +0200

OK, so here's two minor comments:

  * Your markdown-to-RFC tool misses out on asterisks that are being
    used for bold text, and remain in the TXT version (Sec. 3).
  * In Sec. 2.1, we need to use the word "consent". Captive portals not
    only present information, but require user interaction to indicate
    the user's acceptance of terms of service.

Thanks,
     Yaron

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Feb 2016 12:30:06 +0100

Actually, the markdown-to-RFCXML tool works fine (as you can see in the
HTML generated from this: https://mnot.github.io/I-D/capport-problem/),
it's just that TXT doesn't have bold, so XML2RFC marks the bold text
asterisks :-)  [I happen to think that this is a distraction that needs
to be switched off in XML2RFC.]

Grüße, Carsten

Yaron Sheffer wrote:
> Your markdown-to-RFC tool misses out on asterisks that are being used
> for bold text, and remain in the TXT version (Sec. 3).

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 16 Feb 2016 13:41:31 +0200

I agree about removing (or not including) the asterisks. Adding the 
tools team.

Thanks,
     Yaron

---

From: Caciano Machado <[email-masked]>
Date: Tue, 16 Feb 2016 12:17:12 -0200

I think it is important to write in subsection 2.1 why would I need a
captive portal for authentication instead of more secure solutions, like
802.1x. Despite the reason is implicit in the text

   "In all of these cases, using a Web browser is attractive, because it
   gives the network the ability to tailor the user's interface and
   experience, as well as the ability to integrate third-party payment,
   advertising, authentication and other services."

, I consider it is better to be explicit about some examples of needs that
dot1x does not take into account, because it is a widely deployed solution
that many people consider the right way to do things.

Caciano

On Tue, Feb 16, 2016 at 9:41 AM, Yaron Sheffer <[email-masked]>
wrote:

> I agree about removing (or not including) the asterisks. Adding the tools
> team.
>
> Thanks,
>     Yaron
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Feb 2016 09:22:24 -0500

cWarren Kumari <[email-masked]> wrote:
    > We are in the process of organizing the agenda - one of the things
    > which we heard from you at the BoFs is that you would like something
    > like a "survey of the industry" (e.g motivation for deploying a CP) and
    > a more complete understanding of why captive portal operators do things
    > like defeating / whitelisting the captive portal probes.

Sure...

    > (https://datatracker.ietf.org/doc/draft-nottingham-capport-problem/)

A good read, where are we going with this document?

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Feb 2016 14:53:55 +0000

> A good read, where are we going with this document?

Potentially no where -- it may or may not get published as an RFC, but
whatever the case, I've found it it be really helpful to have some thing
like a problem statement document to make sure that everyone (newcomers and
long time WG participants) are all working on the same page.

It it really helpful to have a document like this as an introduction to new
people wanting to contribute, and for old-timers to be able to refer back
to to make sure that what we are building actually solves a: a real problem
and b: the right problem(s). It's very easy to get sidetracked and diving
down rabbit holes solving interesting, but unrelated problems...

So, it's not necessarily "where we are going with this document", but more
"where will this eventually lead us?"...

W

---

From: David Illsley <[email-masked]>
Date: Tue, 16 Feb 2016 16:44:19 +0000

+1 on the consent point. I'm aware of a number of organisations which
believe that they need user consent to carry out necessary security
monitoring of their networks. That provides a justification for
portal-avoidance-avoidance features in captive portal systems.

On Tue, Feb 16, 2016 at 11:15 AM, Yaron Sheffer <[email-masked]>
wrote:

>    - Your markdown-to-RFC tool misses out on asterisks that are being
>    - In Sec. 2.1, we need to use the word "consent". Captive portals not
>    only present information, but require user interaction to indicate the
>    user's acceptance of terms of service.
>
> Thanks,
>     Yaron
>
> On 16 Feb 2016, at 4:46 AM, Warren Kumari <[email-masked]> <[email-masked]> wrote:
>
> ... and that's really just a regurgitation of what we previously put together at <https://github.com/httpwg/wiki/wiki/Captive-Portals> <https://github.com/httpwg/wiki/wiki/Captive-Portals>.  If people have suggestions, corrections, pull requests, etc. I'm all ears.
>
> Cheers,
>
>
>
> --
> Captive-portals mailing [email-masked]://www.ietf.org/mailman/listinfo/captive-portals
>
>
>

---

From: David Illsley <[email-masked]>
Date: Tue, 16 Feb 2016 16:59:32 +0000

I'm interested in the Sandboxing point in section 4. I understand these to
be designed as a pro-user security feature. In general I don't trust random
network devices in hotels so I'll use a VPN. That leaves me open to malware
attacks from the captive portal [1]. Deciding to put captive portals into a
more-restrictive-than-usual sandbox then seems reasonable to me.

Can you explain the problems caused by sandboxing (I don't think I've ever
experienced them)?
David

[1] http://www.wired.com/2014/11/darkhotel-malware/

On Mon, Feb 15, 2016 at 11:24 PM, Mark Nottingham <[email-masked]> wrote:

> Message From Our Sponsors!" - draft-nottingham-capport-problem (

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Feb 2016 14:21:30 -0500

> people have suggestions, corrections, pull requests, etc. I'm all ears.

I feel that the DNS poisioning "inconvenience" is understated.

Particularly on portal timeout, if your next DNS request involves a site that
would be HTTPS, most users are screwed, and in "reboot computer" state.

I have been trying to contact captive portal owners in my local area.
Many smaller entities have done something in-house, but the incumbent telco's
"DataValet" division has very widespread deployment.

It would be very nice if we could cause some phone calls to occur behind the scenes.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Feb 2016 14:26:32 -0500

Warren Kumari <[email-masked]> wrote:
    mcr>     A good read, where are we going with this document?

    > whatever the case, I've found it it be really helpful to have some
    > thing like a problem statement document to make sure that everyone
    > (newcomers and long time WG participants) are all working on the same
    > page.

Yes.  I'd like to ask that we consider is step one of outreach, and that we
consider making 7-12 slides to explain captive portal risks to:
  1) marketing people.
  2) end-users
  3) computer programmers (not necessarily network people)

I'm thinking of something that could be done as a quick talk at another
conference, such as a pycon or XYZ User Group.  Or maybe a Youtube video a la
Minute Physics.

I'll probably take a cut at this, but it will only help if we it looks good,
and I'm not in that category.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Feb 2016 19:55:12 +0000

>   3) computer programmers (not necessarily network people)
Yup. One of the things that we've heard from multiple people is that they'd
like a "survey of the industry" -a better understanding why operators
deploy captive portals and also defeat the captive portal probes.  We've
heard a number of motivations for deploying a CP.
These include:
regulatory,
AUP / legal protection,
payment,
advertising (eyeballs / "watch my 30 second ad video" / "Like me on
Facebook for access"),
only allowing employees / some other class).

We've also heard a number of reasons for defeating the probe - mainly "In
order to show my ad I need a fully featured browser" or "In order to have
people like me on Facebook their browser needs access to their cookies".

But, most of these have been anecdotal, mentioned in passing -- we'd
appreciate it if someone wold be willing to take this on as a document.

It would be great if the slide deck also asked marketing, end-users,
operators, implementors, computer programmers, etc to participate and
contribute to this document / discussions....

> conference, such as a pycon or XYZ User Group.  Or maybe a Youtube video a
Yup, as above.

> and I'm not in that category.

Having seen many IETF presentations, I suspect that most of us fall into
that camp. :-)
W

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Feb 2016 10:51:40 +1100

Hi,

> On 16 Feb 2016, at 10:15 PM, Yaron Sheffer <[email-masked]> wrote:
> In Sec. 2.1, we need to use the word "consent". Captive portals not only present information, but require user interaction to indicate the user's acceptance of terms of service.

Makes sense. I'm wondering whether that should be another sentence under "information", or a separate point -- thoughts?

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Feb 2016 10:53:48 +1100

> On 17 Feb 2016, at 3:59 AM, David Illsley <[email-masked]> wrote:
> 
> I'm interested in the Sandboxing point in section 4. I understand these to be designed as a pro-user security feature. In general I don't trust random network devices in hotels so I'll use a VPN. That leaves me open to malware attacks from the captive portal [1]. Deciding to put captive portals into a more-restrictive-than-usual sandbox then seems reasonable to me.
> 
> Can you explain the problems caused by sandboxing (I don't think I've ever experienced them)?

AIUI, some captive portals want access to the users' normal cookies; e.g., to log into Facebook to authenticate the user (yeah, I know...). Also, I understand that some captive portal sandboxes don't allow some browser features like video playback, and some captive portals feel that they need this functionality. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Feb 2016 11:14:49 +1100

> On 17 Feb 2016, at 1:53 AM, Warren Kumari <[email-masked]> wrote:
> 
> So, it's not necessarily "where we are going with this document", but more "where will this eventually lead us?"...

+1; if we decide it's useful to publish as an RFC, that's great (and we can do editorial work to make it appropriate for that). 

In the meantime, I'm much more interested in helping the WG in its discussions than having something that's perfectly communicating What's Wrong With Captive Portals to a broader audience.

Cheers,

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Feb 2016 06:51:31 +0200

> On 17 Feb 2016, at 1:53 AM, Mark Nottingham <[email-masked]> wrote:
> 
> 

Not to mention the cool feature regular browsers have of remembering your passwords and helpfully filling them out in forms for you so you don’t have to type them out on your itsy bitsy phone keyboard.

Yoav

---

From: David Illsley <[email-masked]>
Date: Wed, 17 Feb 2016 08:08:11 +0000

On Wed, Feb 17, 2016 at 4:51 AM, Yoav Nir <[email-masked]> wrote:

> >> I'm interested in the Sandboxing point in section 4. I understand these
> to be designed as a pro-user security feature. In general I don't trust
> random network devices in hotels so I'll use a VPN. That leaves me open to
> malware attacks from the captive portal [1]. Deciding to put captive
> portals into a more-restrictive-than-usual sandbox then seems reasonable to
> me.
> >>
> > AIUI, some captive portals want access to the users' normal cookies;
> e.g., to log into Facebook to authenticate the user (yeah, I know...).
> Also, I understand that some captive portal sandboxes don't allow some
> browser features like video playback, and some captive portals feel that
> they need this functionality.
>

Video playback in the captive portal. Oh dear. Next they'll be saying they
need WebRTC.

>
> Not to mention the cool feature regular browsers have of remembering your
> passwords and helpfully filling them out in forms for you so you don’t have
> to type them out on your itsy bitsy phone keyboard.

 Yeah. That's one I've been bitten by, and I think that capability should
be added to the sandboxed browsers.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Feb 2016 19:16:05 +1100

> On 17 Feb 2016, at 7:08 PM, David Illsley <[email-masked]> wrote:
> 
> Video playback in the captive portal. Oh dear. Next they'll be saying they need WebRTC.

But of course; they need to see your face and your badge before allowing you access to the network. It's the latest in Enterprise Security.

>  Yeah. That's one I've been bitten by, and I think that capability should be added to the sandboxed browsers.

If we want to go there, we're really talking about defining a profile of the Web stack. That's not a trivial thing, and of course we'd need active involvement from the people who write the captive portal detection code.

Cheers,

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 17 Feb 2016 23:23:15 +0200

Hi,
> Makes sense. I'm wondering whether that should be another sentence under "information", or a separate point -- thoughts?
Technically both are the same: user reads text, user presses a button. 
So it's OK to bundle "consent" under "information".

Thanks,
     Yaron

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 18 Feb 2016 10:29:41 +1100

Thanks. See:
  https://github.com/mnot/I-D/commit/3edaa4961093f7e

> On 18 Feb 2016, at 8:23 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi,
> Technically both are the same: user reads text, user presses a button. So it's OK to bundle "consent" under "information".
> 
> Thanks,
>    Yaron