[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Starting to discuss Captive Portals

[ Top-post ]

David and I had a long chat off-line. I'm responding here as well
(with terse responses) to close the loop.

On Mon, Apr 20, 2015 at 7:34 PM, David Bird <[email protected]> wrote:
> Greetings,
> I was discussing similar topics with Warren and he suggested I join this
> group and introduce myself.
> I develop and maintain the open-source captive portal NAS software
> CoovaChilli, which forked the ChilliSpot project maybe 8 years ago. The
> software is used by many, many hotspots by providers big and small
> worldwide. At a minimum, I'm interested in testing and deploying "solutions"
> via chilli and can also perhaps provide insight from years of experience
> working with captive portal and public access networks.
> With respect to discovery of a status 'poll' page, for clients implementing
> this ID/RFC, why not give the client the polling URL instead of, or in
> combination with, the CP URL?

This document is intended to simply provide a hint to clients that
they are behind a CP, and how to reach the CP to authenticate.
At the moment there is not standard polling URL format -- I'm hoping
that we do something like form a CaptivePortal working group and
design a CP interaction protocol, which will include a polling format.

> Also, is there any link between the CP DHCP
> options and the DHCP lease time?

Nope - this is designed so that an operator can simply add this option
to their DHCP server, without having any changes on the CP itself.
I had initially misunderstood what this question meant -- I had
thought that David was asking if the time in the DHCP lease reflects
the (purchased) access time - it doesn't, because the DHCP server
doesn't know how much time the user will purchase...

> In the current ID, it says that a CP detection browser should use a
> "separate cookie store". This, in my opinion, is the reason for the "captive
> portal detection arms race" ... I think it should be stated that a CP using
> SSL (that verifies) should use the standard browser context and only HTTP
> should use the sandboxed version. This will help promote the use of SSL for
> captive portals and will make the user experience more standard across CP
> detection browsers.  This will mean it's also recommended that the CP URL
> uses a hostname, which seems to conflict with the suggestion in section 3
> that it should be an IP literal.

So, one of the sections that has proved to be problematic in the draft
is the whole "OSs should figure out themselves what to do with this
info. Here is an *example* of what they could do..." -- so, I'm moving
this to an Appendix, and will make it clearer that this is
non-normative, and just an example...

> Regarding polling a special URL from javascript, chilli has such a feature:
> http://coova.org/CoovaChilli/JSON

Excellent! Expect more mail soon on this topic...


> David
> On Mon, Apr 20, 2015 at 2:01 PM, Warren Kumari <[email protected]> wrote:
>> On Mon, Mar 30, 2015 at 11:26 PM, Yaron Sheffer <[email protected]>
>> wrote:
>> >> On 30 March 2015 at 15:14, Warren Kumari <[email protected]> wrote:
>> >>>
>> >>> I suspect that we are going to be spending a significant amount of our
>> >>> time with the tension between making the user's life better, and also
>> >>> trying to maximize the CP operator's desires.
>> >>
>> >>
>> >> Obviously, because the technical concerns aren't what is hard here.
>> >>
>> > We should specify behavior of both the CP and the client. Specifically,
>> > the
>> > client MUST display the CP's web page. And hope that most people obey
>> > the
>> > rules, otherwise we will get into another race between OS vendors and CP
>> > vendors.
>> Yup.  Many of the suggestions here (and in a thread in [email protected]) sound like
>> they are actually solving "the captive portal problem".... and while I
>> think that we really should solve the whole problem, I think whatever
>> we do design will benefit from the information that the client is
>> behind a CP, and where it is.
>> So, what I think makes the most sense is to press ahead with this
>> current document and also keep discussions going on a captive portal
>> interaction protocol (see below). If that sounds like a good plan,
>> then I will give the current document one last round of cleanup and
>> double checking and I will also clarify in the abstract and
>> introduction that it is not a full "solution" but rather a building
>> block (that can be used until come up with a final solution)[0]. Joel
>> (who is sponsoring this doc) sent me mail yesterday asking if it was
>> ready to be published -- I asked him to hold off because I wanted to
>> get your input.
>> >
>> > And this is my fantasy solution:
>> >
>> > /.well-known/captive/status - returns a basic status (CP open/closed),
>> > and
>> > optionally, an expiration time for this information, i.e. when you need
>> > to
>> > poll the status again.
>> >
>> > /.well-known/captive/refresh - returns null if no user action is needed
>> > (rare), or a URL the browser needs to display for the user to beg/pay
>> > for
>> > more time.
>> >
>> > The browser could detect these well-known URLs in order to notify the
>> > rest
>> > of the system, or we could wrap them in some fancy JavaScript.
>> >
>> > We should still use DHCP to return the address of the resource, so that
>> > the
>> > CP does not need to proxy all IP traffic (it can just drop it, hooray).
>> It seemed from the BoF that there may enough interest and input to
>> create a Working Group, problem statement (so we all know what we are
>> doing, not necessarily to publish), charter, etc.
>> Currently what I'm thinking a full solution would look like is:
>> 1: A client connects to the CP (after discovering it through probing,
>> or though the option in the above document).
>> 2: The CP page includes information letting the client know where to
>> poll for status (in case the web / status interface is not on the same
>> IP as the CP itself. If we did a ./well-known/ (like Yaron suggests
>> above) I think some other info that might be useful is:
>> status (connector or not), time_remaining, time_used, bandwidth/ tier,
>> URL_to_pay_again, etc.
>> 3: The client uses this to present a warning to the user that their
>> access is about to expire, and "helpfully" open a page before it does.
>> Implementing this protocol means that users are (IMO) more likely to
>> actually use the CP (and so give $$$ to the provider), and presenting
>> the "renew" page means that users pay again (and presumably also see
>> the content on the renew page again).
>> W
>> [0]: I suspect that getting to a full solution will take a number of
>> years - I'd personally like to have something that solves at least the
>> identification problem before that!.
>> >
>> > Thanks,
>> >         Yaron
>> --
>> 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
>> of pants.
>>    ---maf
>> _______________________________________________
>> Captive-portals mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/captive-portals

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
of pants.