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

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



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