Can FreedomBox be an alternative to commercial home routers?

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

Recent actions by network hardware behemoth Cisco have irked a number of people who feel that the company is not respecting its customers' privacy. In response, members of the FreedomBox project have begun discussing whether the freedom-protecting device could adequately serve as a home router replacement. Such a move would mark a slight shift in focus for the project, but it may enable FreedomBox to offer the best alternative for those concerned over remote spying and other privacy threats.

Cisco raised the ire of online privacy advocates in June when it rolled out "Cisco Cloud Connect," a cloud-based configuration and management system for recent Linksys WiFi routers. The terms of service specifically state that Cisco may record users' Internet history (among several other types of information the service will track). In addition, the new cloud-based service was deployed to existing consumers' devices without their prior notice or consent. Device owners were first made aware of the change when they attempted to log in to their routers' web administration interfaces and could not — with a message instructing them to go register for the new cloud service instead.

Bloomberg reported on a response from Cisco's home networking chief, who said that the company was "absolutely not tracking Internet history, nor do we intend to" and chalked the issue up to "unclear" wording. Cisco has subsequently altered the wording in question, which now says that "usage" information is only associated with a randomly-generated ID number controlled by the device owner. The new wording also explains how consumers (including those whose devices have already been "upgraded" to the new cloud service) can opt-out of the service and revert to the old administration interface — by calling a Cisco telephone support number.

But that may not be enough to mollify privacy advocates. After all, court orders, warrants, or other means could force Cisco to reveal its stored information to other parties, at which point device owners have to trust that the randomly-generated ID is truly untraceable. Admittedly, the ISP has access to the same information, but replicating it elsewhere still makes one more vulnerable, not less. Add to that the fact that Cisco reserves the right to unilaterally modify its terms of service whenever it feels like it, and giving someone else control over one's router may not sound like a good trade-off just for the convenience of managing it through The Cloud.

Whither FreedomBox?

That chain of events led Sean Alexandre to write to the FreedomBox discussion list and ask whether or not serving as a home gateway router should be a target for the first stable FreedomBox release:

I remember from Eben's original talk on FreedomBox he described it as something people would use to replace their home wireless routers. They go to the store to buy a new wireless router, and buy a FreedomBox instead of a WeSpyOnYouBox.

FreedomBox, of course, is an effort to develop a "personal server" image that delivers secure, privacy-respecting software for common applications like email, social networking, and media delivery. Eben Moglen kickstarted the project in 2010, and the initial target hardware was so-called "plug computers." Thus, Alexandre's proposal does represent a shift in emphasis: although some routing tasks (such as firewalling) have been discussed, serving as a router-replacement or wireless access point has not been prominent on the development roadmap.

But replacing a WiFi router would be a useful, well-defined use case, he suggested, and allow the project to roll a usable release "sooner rather than later." Later releases of the software could add additional functionality. The practical problem, he said, was whether or not FreedomBox's Debian base could be made to run on home wireless router hardware with the features most consumers expect.

Alexandre's router-first concept would give FreedomBox an attainable goal, which would benefit the project. After all, despite its clout and technical prowess, the project is still a considerable ways from delivering the end goal of a plug-and-play email and cloud-computing experience with GnuPG-hardened encryption — not because the project isn't up to the challenge, but because of the sheer size of that challenge. FreedomBox developers are hard at work on a number of difficult problems, such as enabling two firewall-protected boxes to locate each other and establish a connection (the project's solution piggybacks on the Tor network). Rolling a routing-centric release would raise the project's profile while permitting development to continue.

The software angle

The FreedomBox distribution is intended to run on a range of hardware, and the project elected to build it on top of Debian in order to provide broad compatibility (among other goals). Clearly Debian itself is more than capable of serving as a NAT gateway, router, and firewall. But there are other considerations that might make building a router-centric FreedomBox release more difficult.

For starters, network configuration for a plug-and-play box needs to be straightforward, and ideally provide a working "first run" experience. Even the aftermarket router firmware projects (such as OpenWRT) struggle to make configuration simple, and FreedomBox strives to eventually enable the user to configure all sorts of additional services — some of which require tasks like key generation. The project has yet to select a configuration system; OpenWRT's Unified Configuration Interface (UCI) seems like a natural choice for the router use-case, but it may not extend easily to FreedomBox's other applications.

A separate issue, raised on the list by Jonathan Wilkes, is whether ISPs will allow users to bring their own routers. Some service providers rent wireless routers to customers, others supply their own devices (which do NAT and firewalling) that are combination units with DSL or cable modem functionality built in to a wireless router. In both cases, the area of concern is that the ISP requires that their device be the one doing NAT. A double-NAT configuration might be possible, but would not be simple to configure or troubleshoot. As Wilkes put it, such a departure from the plug-and-play server concept is more complicated from a user's point of view:

I think from the user perspective, plugging in a FB _behind_ what their ISP already has installed is way easier to set up and immediately start using, but less powerful (I'm thinking of the setup discussed recently where it's basically piggybacking over Tor make connections). Of course replacing one's router with a FB-- if there isn't a double-NAT-- opens up many more possibilities for what you can do with it. Maybe the best of both worlds would be to make the UI for the easy solution (i.e., FB behind the router), at least initially. Even though it's less power for the non-techie user, it's less potential frustration. (A FB that the user can't get working certainly won't improve their privacy.)

In the ensuing discussion, the big unknown remained that no one has adequate data on which ISPs (or what percentage of all ISP users) face such restrictions. But then again, ISP restrictions are not a new problem for FreedomBox; the project has always been interested in running its own services, which inherently involves making incoming connections accessible from the outside — and which many ISPs frown upon.

The hardware angle

The other challenge to deploying FreedomBox on a home router is the availability of suitable hardware at an affordable price point. For the plug-and-play server design, there are a number of inexpensive plug computer options already known to the project. But few of them offer multiple network interfaces, which is a necessity for routers.

On the other hand, the aftermarket router firmware community typically must maintain multiple builds targeted at individual products, in order to cope with peculiarities of design (such as the vendor changing the internal flash memory without changing the model number) and with binary-blob drivers. Consequently, getting Debian to run on a commercially-available router is likely to prove difficult. Alexandre noted that Debian already runs on some Linksys routers, but with major caveats: "The wireless driver is a binary kernel module (first problem), and it needs a 2.4 kernel (second problem.)"

A third possibility he discusses is ALIX boards, which are low-power x86 devices available in several configurations, including some with multiple network interfaces. There is an active Debian port to the ALIX, although Alexandre admitted he was unsure if it was free of binary-only drivers.

The proposed router-centric milestone release is still an ongoing discussion topic at FreedomBox. As the Cisco incident reveals, there is clearly a need for a privacy-and-freedom-respecting router. OpenWRT and similar projects are decent options for those comfortable flashing the firmware and voiding their warranty, but those projects can never provide an out-of-the-box experience. Taking on that challenge may be too far afield for FreedomBox, though. It is at least feature-creep, which is generally taken to be a bad thing. But it may be a more attainable target, in which case it could do a lot to attract new talent to the FreedomBox project, which would be a win in the long run.