By Nathan Willis
July 4, 2012
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.
(
Log in to post comments)