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

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

So, here's a few thoughts:

I suggest to add a requirements section. The reasons why other methods suck (Sec. 2) would be a good start, but I suspect there will be additional requirements once a bigger audience looks at this.
I suggest to add an example scenario, such as: Jean goes into a coffee
shop. She signals her agreement to the usage terms and fires up her VPN.
After an hour, the session expires, and she needs to click "agree" again.
When we add such a scenario, we will most likely recognize that the DHCP
option is not sufficient for what we need, even for a basic CP. The
document currently even does not define how applications (the browser,
other browsers, a mail client, VPN client etc.) can detect that the CP
is now "open", let alone reliably detect when it has "closed" again. We
should not rely on the legacy detection methods for this, or we will
never get rid of them.

On 03/29/2015 07:31 PM, Mark Nottingham wrote:
Hi everybody,

Thanks to those that came to the Bar BoF in Dallas. Feel free to introduce yourselves here.

I think the strongest outcome there was the interest in the draft for a new DHCP option:
IIRC Joel said he was considering sponsoring this document; it would be great to get feedback from OS vendors if they haven't seen it yet.

Hotspot 2.0 <https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0> has been brought up by a few people as well. AFAICT, it's focused on "roaming" use cases — e.g., allowing mobile carriers to offer wifi services seamlessly. That's interesting, but AIUI not applicable to *many* use cases where captive portals are used.


The wiki we've been using to keep state is here:
Feel free to edit, and if it gets unwieldily, we can consider moving it out of that space.


Mark Nottingham   https://www.mnot.net/

Captive-portals mailing list
[email protected]