[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Feedback requested: Charter text.
On Tue, Jun 30, 2015 at 2:10 AM, Martin Thomson
<[email protected]> wrote:
> On 23 June 2015 at 11:26, Warren Kumari <[email protected]> wrote:
>> We would like to get a discussion going on some *strawman* charter text.
> I realize that this might be a little controversial, but I really
> don't like the term "captive portal".
> I think that a valuable product
> of this working group would be a thing that accomplishes the goal that
> captive portals set out to achieve, without the MitM.
Yup. +1 <aol>me too</aol>
I'd like to stick with the term "captive portal" for now, simply because:
A: that is the name on the BoF / what people think of this as and
B: the terms still seems to make sense to me -- even if there is no
MitM, users will still be 'captive' (imprisoned or confined) until
they convince the network that they need to get out. The 'portal' bit
I cannot really justify, other than the game
(https://en.wikipedia.org/wiki/Portal_(video_game)), which has someone
who want something (cake and grief counseling) but is being thwarted
by technology :-)
> Currently, this charter bemoans the current status where MitM is the
> only real option, but does not set out to create a situation that is
> materially different. I'd like to see it say something more
> definitive about this. (And no, I'm not in denial; I expect that
> networks will continue to MitM, but we'll never be rid of the beast
> until we have a viable alternative).
Hmmm... I hadn't intended the charter to be so whiney about the
I wanted the charter text to be longer than just:
The Captive Portal (CAPPORT) Working Group will define
a standard mechanism for clients to
interact with Captive Portals, including how to discover and connect,
and how to communicate with it to obtain status information
such as remaining access time, purchased bandwith class, etc.
This working group will seek participation and input from browser /
operating system vendors, captive portal developers and operators.
One of the known challenges is that some captive portal operators may
not want to use a standard interaction protocol, preferring to perform
more intrusive interception and interactions. We are hoping that the
benefits to CP standardization outlined here are sufficient to not
only encourage input from CP developers and operators, but also aid in
We are (probably) asking for the formation of a WG, and I wanted
charter text that explains a bit more about what the issues are, and
explains more about what we will be doing. Perhaps the above is long
enough? Does it need some more text / background? Any proposed text
> I understand that the aim is to solicit human input as a prerequisite
> of authorizing network access. A secondary goal is to provide
> programmatic access to status information, primarily time remaining,
> in support of knowing how to get back to the first part.
> Those goals could be (minimally) achieved by discovering two pieces of
> - the time remaining on the network
> - where to direct human eyeballs if a change to this time is desired
Yup. I think the fact that there *is* a widget that blocks access
until it is satisfied is also needed. This is very similar, but subtly
different to your first bullet....
> There is some additional information that could be interesting later, perhaps:
> - programmatic access to login/logoff functions (useful if time-based
> charging is involved)
Yup. This will also be needed for devices that have no UI.
> - information about network paths that are not gated (though I'm
> struggling a little to justify this, it's a common enough feature, we
> might like to support it, noting that this is usually discovered via a
> portal page, which could be sufficient).
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair