Running a wireless community using a captive portal

This document lists the different models for giving internet access using a captive portals (note also that a single community can implement multiple models). For now, it is mostly written to clarify terminology. It does not attempt to discuss how each model relates to sustainability, or the considerable variations in policy that can occur within each model (is the user time limited, bandwidth limited, etc.). Over time, this document will list how suitable wifidog is for every model, and what features are missing.

Models for determining who has access

Models with users

Open community

Users can signup freely (possibly providing some mandatory information, typically an email address). Examples:  http://www.ilesansfil.org/

Closed community

When access is to be provided to an existing community of users. Examples: university campus, users of a public library, etc.

Barter model

Users have to provide something in exchange of network access in a hotspot. Typically, bandwidth or access to their own hotspot. Example: Fon,  wifree

Paid subscription & WISP

Access is provided when the user subscribe to some monthly service. Residential access from a WISP, an option on their cellular plan, etc.

Models without users

Splash-only

No attempt to maintain unique users is made whatsoever. The community simply wants to maintain locative or non-locative portals. Example: NYC wireless

Free tokens tied to purchase

Model in which a customer is provided with a one time use password equivalent with some unrelated purchase in a commercial venue (meal, coffee, etc)

Password of the day

Providing users in a venue with a daily changing password, distributed non-electronically (usually written on a whiteboard). The idea is to force users to physically come to the venue to gain access.

Paid tokens

You buy access for a day or an hour using a credit card. Examples: Most typical commercial hotspot operators.

Prepaid time

Just like prepaid cellphone.

Open access point

Just plugging in an access point with no access control or portal!

Portal mechanics

The model chosen will mostly determine the portal mechanic. An ideal captive portal system has three distinct “pages” involved in the connection process.

Welcome page (usually a login page, user does not yet have network access)

Disclaimer page (must be accepted for access, between Welcome and portal page, must be accepted each time or only once)

Portal page (user has network access)

Note that some models can have no Welcome page (Splash-only), or no Portal page (the portal redirects to the page originally requested by the browser once login and disclaimer stages have been completed. Explicit support for Disclaimer page isn't part of wifidog yet. Even once it is, many groups may decide that implicit acceptance is enough (so they will simply put the disclaimer on the login page).