Hackfest Report

Posted 2012-02-22

The FreedomBox Hackfest at Columbia University was a huge success. We hosted 25 people of diverse talents and interests. Some folks came to learn, acquire DreamPlugs and do a guided install of Bdale Garbee's FreedomMaker. Others took up parts of the (task list)[http://freedomboxfoundations.org]. We learned a lot about the boxes, ideas for routing, data modeling, and security concerns. Lots of people pitched in on the tasks list, and descriptions of that work are below. Most importantly, we had a lot of fun meeting each other and collaborating. If you are interested in any of it, please ask about it on the discussion list, especially if you want to help!

Huge thanks to everybody that participated. Many people came by just to learn about the FreedomBox, talk about their use cases and offer encouragement. That activity is very helpful, and we appreciated the fresh perspective.

We intend to do more hackfests, perhaps in more cities in the near future. This weekend was a great success in progress, bug squashing, design, and first-draft implementation of key FreedomBox infrastructure.

Thanks again to everybody and especially to Columbia University, Elizabeth Boylan, and ISOC-NY for logistical and material support.

Progress and Activities

• Nick Daly, Issac Wilder, Ian Sullivan and I fleshed out my earlier, nascent Port Santiago work (more about that below) and implemented some basic FreedomBox discovery and connection functionality. Nick and Issac also sketched out a DHT scheme (codenamed Neruda) for finding boxes. Nick and Issac each did presentations on the routing issue. Joly Macfie from ISOC-NY took video of those presentations and will get them online this week.

• Nick and Ian iterated hard on paired boxes (a dedicated, hard-coded, factory-set proxy server and client connection) as a way to roll out freedom to small numbers of people stuck behind national firewalls. We now have paired boxes that locate each other on the network and proxy for each other!

• Barbara Mack came to us with expertise in data model-ling, and she spent her time doing deep thinking on the person model and how it connects to the rest of the FreedomBox.

• BoxySean installed FreedomBox on a GuruPlug and updated the Wiki with details on how to do that more easily. There are a lot of GuruPlugs out there, and his work is a big help.

• BoxySean and Brian Newbold started work on configuring the FreedomBox as a wifi router and connecting that up to Plinth for UI. They identified some FreedomMaker bugs. BoxySean updated the list on those bugs and we've been following up on closing them.

• A team of people (most notably Marcus and Tyrone) from the FreedomTower project explored ways the FreedomBox can be added to their mobile internet stations to provide Free communication services to people connecting to the net via those stations.

• Sean O'Brien familiarized himself with Plinth and intends to contributing to the router front-end setup effort.

• David Garson dropped knowledge on configuration systems and virtual machines as test beds.

• I updated Plinth with a new template featuring some design work by Robert Martinez (about which I will say more in a separate update).

• I updated Plinth with a new template and chased down some bugs. Boxysean explored Plinth's bugs as well, albeit involuntarily. We'll have patches on those shortly.

Port Santiago

There is a problem we have been referring to as the "magic routing problem". It is the question of how two FreedomBoxes find each other on the internet and establish communication, even if one or both boxes are firewalled and neither is findable via DNS. We called it "magic routing" because we hadn't started to design the routing system and so we had to assume it happened by magic.

Our solution to this problem is to piggyback on the Tor network. Hidden services rely on Tor for routing and discoverability. The system works quite well and the Tor project does excellent work at maintaining that system and strengthening it against attack.

Nick Daly and Ian Sullivan built a simple server that listens on a local port and is reachable from the outside world by a Tor hidden service. It accepts authenticated queries and responds with information. For example, it can give your IP address to friends you trust.

To avoid burdening the Tor network and also to avoid the delays associated with using Tor, Port Santiago will allow two FreedomBoxes to decide on a faster (though less anonymous) method of communication. Subsequent communication will happen on that channel.

Right now, we are using Santiago to discover a FreedomBox's IP address for the creation of encrypted proxy tunnels. This will allow a FreedomBox to provide uncensored, unmonitored internet access to a friend who is stuck behind a national or corporate firewall.

Nick did the heavy lifting on this work with help from Ian Sullivan and in consultation with many of the Hackfest participants. Nick's documentation and code will be up on github soon.

Neruda

Port Santiago lets FreedomBoxes provide some basic information via a Tor hidden service, but users need a way to find out the onion addresses of their friend's services. The most obvious way to do this is with distributed hash tables (we also considered less obvious methods that piggyback on existing infrastructure, like bit.ly links). Issac and I planned out the DHT, how to access it, the data structures, and API. We are calling this system Neruda.

Neruda will allow users to take a GPG key and look up a user's Santiago onion address. Issac Wilder is speccing this out and coding it.

One benefit of reaching Santiago via a Tor onion address is that FreedomBoxes do not need to update Neruda very often. Even if your IP address changes, your onion address shouldn't. Updating your Neruda record is a rare event and it is acceptable to refresh Neruda's tables relatively infrequently. This might allow us to devote fewer resources to it.

Key Signing

FreedomBoxes are going to make a lot of use of GPG to authenticate identity and sometimes to encrypt data as well. To strengthen the web of trust, we did some key signing and also introduced some participants to gpg, generated keys and taught key management.