Policy in a decentralized network world

The Berkman Center at Harvard asked me for a synopsis on technical and social problems of emergency planning (via ad hoc mesh) and community wireless that could be addressed through a policy initiative – I’m reposting the blurb here:

Public Safety and Emergency Planning (with Ad Hoc Mesh networking):

Technically, it is problematic to install mesh-enabling software on users’ phones, devices and laptops to create mobile ad hoc networks – difficulties include ease in gaining “root” access to devices, violating warranties, incompatibilities between mesh protocols and ease of installation/use for non-tech users. Battery life and CPU cycle consumption are also major factors when routing other users’ traffic through the mesh, while bandwidth optimization (to minimize the number of hops) through ad hoc backbones is still theoretical.

From a socio-technical perspective, mesh networks increase in reliability as the number of users increases. Until a critical mass of meshed devices is within range, the network is unreliable or non-existent. Easily deployable or pre-installed relay nodes between well populated areas could help quality of service. Another difficulty is ensuring that users have access to or have already installed mesh technology on their devices, before a loss of centralized communication services (through natural disasters, political uprisings, etc.). Otherwise, the technology will not be able to satisfy unforeseeable, immediate needs.

There are a few ways to incentivize the enabling of mesh on devices before a communication shutdown. It could be as simple as creating a culture of latent sharing, in the way that donor stickers work on driver’s licenses. This creates a social capital of readiness and awareness, if the user is able to subtly show off their installed mesh software, or “donor card.”

Mesh software could also be active in hyper-local exchange and communication between networked users. Skill-based task assignment and user roles in communal, technical and social areas mimics self-assembly/swarm theory in the ad hoc assembly of decentralized infrastructure. Creating a culture of readiness, willingness and ritualization (meetings/events) could help to spread awareness to additional user groups. An intrinsic, skill-based currency (such as Mozilla’s Open Badge project), combined with an extrinsic participatory currency may help to drive this forward.

Another approach is to appeal to phone manufacturers directly to enable a standardized emergency system, which is what the developer behind Auto-Bahn, an Android (and soon iPhone) P2P messaging system is trying to do by expanding the use of Bluetooth and WiFi during emergencies (not clear if it includes mesh networking). http://hackerdemia.com/

Community Wireless Networking and Policy:

In “From Face-Block to Facebook or the Other Way Around?” Apostol, et al. call on urban planning to “encourage the creation of [Wireless Network Communities],” due to the “capability [of WNCs] to increase social capital” and “inclusiveness.” They could be “active[ly] operat[ed] through policy implementation and city sponsorship.” (pg. 10)

There’s a history of success and failure in the introduction of wireless networking into communities. Municipal and grassroots based wireless networks have thrived in particular settings, originating from and their ability to address local economic, geographic and cultural conditions. A multi-faceted approach to policy, based on these granular conditions, could be considered when working on the community level.

In “Divining a Digital Future,” Dourish and Bell note that formal mechanisms regulating infrastructures have impact on everything from appropriate forms and formats of content, pricing, decisions about component parts and standards, data traffic speeds, and backhaul rates.” They propose that “[t]acit forms of regulation might include family choices about service providers and device placement within the home, religious proscriptions about device types and usages, and the placement of infrastructural nodes [in a spacial/social boundary context].”

Two hundred years ago, British colonial forces made a treaty with the Maori, the indigenous people of New Zealand, to secure their “lands, villages…and treasures”. These treasures included “material and non-material…sacred places,” which allowed the Maori nation to claim a legal share of the newly erected 3G wireless radio waves traversing their lands. Dourish and Bell question how deployed infrastructure and the spaces they inhabit are understood by users/groups (and when scaling up). They ask: “Who should participate in this discussion? Whose opinions and experiences are relevant? How might such individuals and institutions be included in both conversations about deployment and regulation?” (pg. 106-107)

The first standardization of mesh networking on a protocol level has been seen through IEEE 802.11s (ratified July 2011), with the first device to use an earlier draft standard being the One Laptop Per Child project. Other hardware is now beginning to support this protocol natively (Ubiquiti Networks NanoStations and Bullets through their AirOS firmware). There is critique of its usefulness amongst the OLSR, BATMAN, and other mesh protocol communities, but it is a first step toward a standard that device manufacturers can start calibrating, optimizing and building software for.

Policy considerations in my current work:

With the Red Hook Initiative, we’re engaging network growth on the community level, through awareness meetings and workshops – infrastructural difficulties will surely arise when working with the NYC parks department to bring connectivity to the local park, and when attempting to install network nodes on the rooftops of NYC-owned housing projects (which make up a majority of the community).

I’m also working with the New America Foundation’s mesh firmware (openWRT + OLSR/ROBIN) called Commotion Wireless, which is an attempt to create a easy-to-deploy, standardized mesh topology. When implementing this technology in Red Hook, it will be interesting to see how easily it is adopted, rejected or modified to fit with their needs – is it then best practice to allow modification? Will separate networks be able to connect directly to each other if they aren’t using the same interface? Another issue to note is the problem of outdated firmware on individual devices in homes – are specialists deployed to homes to re-flash the firmware, or is their a semi-annual ritual to bring devices to a central location to be updated?

Additionally, the ability to start seeding Internet through this mesh (with multiple gateways) will be an issue, as the community will need to either strike a deal with the local ISP (Time Warner) for a business quality connection and make sure not to violate their terms of service, or attempt to purchase a fiber connection directly from Tier 1 or 2 providers (if at all possible).

One last point, which has been a problem for all wireless network communities. Bandwidth regulation and throttling is an issue that effects all users, as the concept of sharing connectivity is somewhat amorphous. It’s an unwritten phenomenon that as soon as a network is created, it is immediately bogged down by the mass download of pornographic video (seen in communities around the world, according to Village Telco developers) and other large packet volume. The Île Sans Fil network created a standardized software called WiFi Dog that streamlined the traffic shaping and authentication for community wireless, which is now used by some networks globally. I am currently using WiFi Dog as a captive portal (splash page) in Red Hook, but will eventually allow community self-regulation of bandwidth –but is this the best option? There is also the problem of “malicious nodes” on these kinds of networks, which could compromise security, committing cyber crimes, or causing general disruption – is a standard policy needed to deal with these users? What is the best practice?

Aside from Red Hook, my other focus is on developing an engaging user experience in a software interface that brings value to mesh networking outside of internet connectivity (to ensure mesh exists on devices before communication shutdowns). I’m relying on technology that already exists on most devices: zeroconference (used by Bonjour & Avahi) – this allows automatic, decentralized discovery of other devices on the same local network, which is very important for ad hoc setups. When a device enters a network, they could automatically find similar people or groups and start communicating directly. There is room for policy here, in addressing privacy issues with broadcasting identity across a network, and in ensuring standard zeroconf protocol exist across all devices (while OSX and Linux have it pre-installed, Windows and some smart phones do not).