Wifi networks with captive portals ("Before we let you connect, you have to agree to our terms of use" pages; I'd prefer the term "wifi splash screens" but use "captive portals" for consistency) are a terrible thing, network-wise: They announce a default route that is by default out of service, and they mangle your DNS requests to point to their entry web server; as a result, they mess with your browser tabs, confuse update managers and may require you to turn off DNSSEC.
On the other hand, even if some jurisdictions become more wifi friendly (or not?), the legal requirement will stay around for some time -- operators of wifi access points will, under certain conditions, stay forced to make their users acknowledge some terms before they may route their traffic into the internet.
We should try to find a solution that satisfies both the technical requirements ("don't mess with my traffic") and the legal ones ("you have to establish a contract").
The first offender in the course of a typical captive portal setup is the DHCP server; it announces a route to the internet it does not really provide at that time; whatever we do, it happens before that is sent.
Fortunately, DHCP is extensible. Assuming a DHCP option "Terms of use" (ToU), a DHCP dialog could look like that:
Server: OFFER with ToU set to a HTTP URL (eg. http://192.168.0.1/terms), indicating only a route to the server indicated in ToU, and optionally indicating a DNS server if required to resolve the HTTP URL.
Routing stays blocked for that client; reaching the ToU page should be allowed in all cases anyway. If DNS is used, the DNS server (which for the classical setup already distinguishes between "accepted" and "new" clients to either pass on requests or inject fake answers to 192.168.0.1) needs to put the client into a new "negotiation-pending" mode in which it refuses to answer any requests but for the ToU server.
REQUEST and ACK happen as usual, the client has no route to the internet.
While some negotiation could happen before that, it would involve traffic from an interface that is not yet actually configured, making implementation complicated.
Client: GET http://192.168.0.1/terms, interpret it and ask the user whether those terms should be accepted.
Client: RELEASE the current address and DISCOVER again with ToU set to a
URI inicating that the ToU are accepted (eg.
http://192.168.0.1/terms?accept=yes or
Server: OFFER with ToU set to the HTTP URL as before, indicating a default route and a DNS server.
By the time the server offers the route, its routing must be configured to actually forward packages, and the DNS server must regularly forward client requests.
REQUEST and ACK happen a usual, the client now has full connectivity.
If the requirements happen to be so strict that periodic re-confirmation is required, that can be covered with lease times. Before the client sends its REQUEST for lease renewal, it evaluates the ToU from the offer again. If it has changed, or if it indicates a different outcome based on the elapsed time, the lease renewal REQUEST sent afterwards needs to indicate the new confirmation URI in the ToU field or, failing to do so, might receive a NAK.
The response to the request to the server's ToU URL needs to indicate
More detailed functionality, like logging in with room number, access codes from a bill or classical username / password credentials could be transferred in that process as well, even though WPA Enterprise would often be the more sane approach. Still, this allows businesses that previously chose to operate a captive portal based wifi to do that in a more technically sane manner.
Independent of how the contract is indicated, the accepting URI can be any of the following:
An HTTP URL on the server, as would be produced by a GET form, for example (eg. http://192.168.0.1/terms?accept=yes)
Such a URL, but with a version indicator to make sure the client was not using an outdated version of the ToU (eg. http://192.168.0.1/terms/2014-02-01?accept=yes)
A hash URI that was calculated from the ToU version that was shown to the
client, calculated on the server (eg.
As for the HTTP response, this could be (not mutually exclusive):
A plain or HTML formatted text, indicating the confirmation URI in a link header with rel=accept.
The client agent will display it, offer an accept button triggering the next step and a cancel button to disconnect from the wifi.
An HTML formatted text with a "I accept" hyperlink with rel=accept, or a form (not sure if rel= works out there).
The client agent will display it, intercept clicks to the accepting link, and proceed.
An RDF document indicating the terms in an arbitrarily abstract fashion.
The client agent will attempt to derive whether the user has issued a matching generic statement of acceptance, and ask if required.
Can a DNS server indicate that it is temporarily unwilling to resolve a request, and if yes, how?
Might it be easier to do the whole accepting process over HTTP? (no ToU=URL in the re-discovery, just POSTing following the indication of the offer URL and hoping that after that's done, the next DISCOVER will yield something more useful)
Do we need a way for the access point to indicate whether the client needs to ask for re-confirmation? Of course, the access point can modify the terms frequently, thus always prompting for reconfirmation, but do we need a more benign way of doing so?
Do we need to take legal prerequisites of forming a contract into account? Classical captive portals are just HTTP as well (which has no guaranteed rendition, and no guarantee that it's the actual user pressing the button either).
Splash screens sometimes offer additional information, like how much bandwidth has been consumed (or, in limited situation, how much is left). Can we establish channels for such information via the DHCP solution, or is that better handled via DNS-SD? (If yes, a formalization of the complete mechanism might recommend a way of integrating with DNS-SD.)
If a method for tacking metadata onto an established wifi connection, something like a favicon could be interesting to some wifi operators and useful for visual navigation in wifi lists to users.
This whole draft was only thought through in the IPv4 area. IPv6's router advertisements might not be suited for this, but DHCPv6 might work.
Security: The devised scheme is no more secure than the current captive portal solution -- I am not aware of anything that keeps clients from spoofing MAC and/or IP addresses (whichever the access point's policy is bound to), apart from the fact that it's easier to just click the button.
Power users: Annoyed by issues caused by captive portals.
Normal users: Annoyed by issues caused by captive portals, might not get the connection.
Client-side developers: Will probably take up a working solution, provided it does not interfere with / break anything. Might even be glad for it to exist, as normal users might blame their software over the access point.
Free software access point developers (OpenWRT & co): Probably already cringe because their users need captive portal features, will probably accept enhancements if they don't affect performance.
Commercial access point vendors: Might be reluctant, and will listen to their customers (see below).
Wifi operators who care for their users (Freifunk, libraries): Might be concerned about whether they still observe the legal requirements with such a solution, but will probably use what's easiest for their users. Will probably take what free firmwares provide, and might even ask their commercial vendors for support of the solution.
Those operators might be interested in providing their ToU in a way a client can generically accept it (eg. by using an agreed-upon text whose metadata allows the client agent to use the user's confirmation across different access point operators, provided such a text/metadata combination satisfies the requirements in the respective jurisdiction).
Wifi operators who offer that because they are expected to / to lure customers (large vendors of burgers, coffe, etc): Use their portal to convey advertisement, and are possibly interested in customer turnover rates or in avoiding non-customers use their service.
They have no natural incentive to provide a technically sound solution (and thus don't provide an incentive to the commercial access point vendors), as long as they are allowed to advertise even a technically broken wifi as "Free Wi-Fi" or "Free internet access" (which they are unless great changes happen in customer protection / unfair competition / net neutrality laws).
Power user complaints ("Your wifi is breaking my DNSSEC") would most likely go unheard, but if wifi clients started to indicate broken situations more agressively, chances complaints are heard are better.
(Wording that would be challenging -- while technically someone is MITM'ing DNS communication, indicating that the device is under attack by the wifi would be misleading. Having a yellow triangle showing on the wifi radar, saying "The access point is indicating full internet access, but only providing limited connectivity", ideally only if some services are actually affected, should get the message across better.)
Availability of connection metadata (eg. favicon) could provide an additional incentive. (Note that such a thing might easily work with independent solutions just as well, but if tacked onto the solution to making captive portals do the right thing, clients might refuse to display the coffee shop's logo overlaid with the wifi symbol).
Note that this is more a theoretical thing (see "incubator status" below).
Add support for one wide-spread DHCP client. (Server side, in first stages of testing, can be handled with generic option field values). The client only needs the ability to indicate the offered ToU URL to its caller.
Add support for a network management agent. (This could be network-manager, wicd, or a wrapper around the DHCP client that pretends to be the DHCP client towards network-manager).
This component will need a fair deal of control over an HTTP rendering agent, depending on the choice of URL content and open questions. Especially, this will need to be fairly "tall" in the stack, as it talks to both the DHCP client at system level and the end user at graphical.
Find a free implementation of captive portals, and add support for the protocol.
By that time, the whole setup can be presented in a video demonstration, and virtual machines can be provided that ease development and integration on both sides. This should get power users and free wifi operators interested.
Get the basic patches accepted upstream in the DHCP client and the captive portal implementation.
Get into contact with network managing agents (network-manager, Android, whatever Windows and Apple use) to see how support could be aded there.
This step probably takes long enogh for the low level support (above) to trickle into releases.
Lobby for adoption in increasingly difficult environments (starting with libraries, ending at restaurant chains) with progressing spread of client implementations.
This is currently just an idea with some scribbling attached, neither a plan nor a concrete proposal -- that's why it resides in my idea incubator.
I'd be happy to participate in doing and promoting this if there is significant interest in the topic (as expressed by other people actively participating, or by people funding such an undertaking), but apart from that won't do much more on this than updating ideas and gathering links, information and feedback here.
Those sites or statements need to be reviewed for possibly enhancing this idea:
--chrysn 2015-03-08
This page is part of chrysn's public personal idea incubator; go up for its other entries, or read about the idea of having an idea incubator for more information on what this is.