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

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


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? Also, is there any link between the CP DHCP options and the DHCP lease time?

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. 

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


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).

[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.

Captive-portals mailing list
[email protected]