Database of login procedures of all the gatewayed free hotspots

For various reasons, a wide variety of otherwise free wifi hotspots require you to go through a login screen. (This is also common of course with for-pay hotspots where you must enter an account or room number.)

These login screens sometimes exist to control how many people access the hotspot. Sometimes they are just there to make sure the user knows who is providing the hotspot so as to be thankful. Often they are there to get you to click agreement to a set of terms and conditions for use (which most people just ignore but click on anyway.) Whatever reason they are there, they create problems. For example, they block non-browser oriented devices, like wifi phones, from using the hotspots. They also interfere with non-browser applications that want to use the network before the user has gone through the procedure with the browser.

Since we’re not going to make them go away, can we improve things? There have been suggestions in the past for standardizing the login protocols, so that devices like wifi phones can still get in, as long as there is no typing or little typing. One could even standardize delivery of a short message or logo from the hotspot provider so you know who has provided the free service. Clicking agreement to terms remains a problem on such issues. I don’t know how far those efforts have gotten, but I hope they do well.

Until then however, it might make sense to build a giant database of hotspots along with information on how to log into them. In most cases it involves doing a web fetch and then posting a form with a box checked and possibly some text in a box. There are really only so many different classes of login system. The database could map from SSIDs (for non-default SSIDs) or even MAC addresses. Laptops could easily store a large MAC based database, while phones and PDAs would have more trouble. However there are techniques, using hash tables and bitmaps designed for spell checking, which can compress these tables, since false hits on unknowns are not a problem.

Better still would be a way to “fingerprint” the login pages, since again there are only so many basic types. Then just store a set of scripts to calculate the fingerprints and scripts to fill out the forms.

When a laptop user — anywhere — using this system encountered a hotspot whose login page did not match any fingerprint (or which matched but failed to login) the software could capture the attempted session and fire off an E-mail (to be sent later, when connected) to the people maintaining the scripts. This team, perhaps paid, perhaps volunteer, could quickly develop scripts so that the next person to use that hotspot gets automatic login. Of course this doesn’t help at a new conference hotspot where all the conference goers can’t update their lists until they get on, but that’s only the first time.

Now one problem is that these scripts would automate the checking of “I agree to the terms” buttons. And that does raise some interesting issues. First, over whether the user truly agreed. Next, over whether the script provider is liable for violations. And third, whether the hotspot owners will feel the need to make their login unscriptable (for example using CAPTCHAs or worse) to prevent people doing auto-logon. I mean they tried to make it hard to log on for some reason, we suppose.

Standardization would help here. Perhaps somebody could draw up a contract with the basic terms found in almost all these terms of service (no spam, prohibitions on various illegal uses) and users could agree to that (on behalf of all hotspots) and they would be satisfied. The scripts could be programmed to be able to extract the terms and offer the user the chance to see them. On a wifi phone, the phone could extract the terms and E-mail them to the phone’s owner (the phone would be configured with that E-mail) over SMTP over TLS (don’t want to reveal the E-mail address to sniffers) so the user has a copy and can at least review them later.

Of course, not having hotspot owners afraid of liability would be nice, too.

Some Balkanized versions in place

You don't mention anything in the marketplace, so you may not be aware of Devicescape, Whisher, and WeFi. Devicescape is commercially oriented, using a Web site hosted account to manage your hotspot logins, and a lightweight embedded app that uses tunneled DNS to retrieve (encrypted) authentication information from their servers. They have logic that allows logins via gateway pages, too, by having the device send the right sequence of HTTP to accept the agreement.

Whisher uses an encrypted database of keys stored in a client (Mac, Windows, Linux) that lets you log into "buddy" networks as well as public hotspots that have chosen to use Whisher to distribute their key. The key is centrally managed by the owner; distributed into the clients by download.

WeFi is a public grassroots Wi-Fi hotspot mapping project.

Tie a few of these together, and you have something close to what you want.

Not islands

Islands where the access point/login system has to do something special are a step along the road, but what I am talking about is a tool for the laptop (or other device) that logs me into an AP without the AP taking measures to allow automated login.

After all, if an AP wants easy login, there's a really easy way to do that. :-)

Whisher seems very similar to FON, which I was already familiar with. Saw WeFi at Supernova but learned very little about it, it's not clear that they are automating login.

Devicescape, however, which I did not know about, seems to be pretty close to what I was talking about, in a commercial form. They seem to be using a trick I would not have thought to be reliable -- sneaking information through fake DNS queries before you are logged in. I would have though most gateways blocked such traffic (redirecting the DNS to themselves with 0 TTL) but perhaps they don't.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options