[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
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). 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
> 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,
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).
: 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!.
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