Introducing gibson

Artwork by Mike Finch (CC BY 4.0)


As you may know, Emerald Onion systems run HardenedBSD. BSD systems in general, and HBSD in particular, provide numerous advantages to our team in operating secure and highly performant Tor relays. But BSD systems make up only a very small percentage of the Tor network. There are many similarities between BSD and Linux, with which many users may be more familiar, but the differences can be intimidating. We’re addressing this by launching gibson, a project to develop a suite of tools to address the needs of Tor service operators. The Tor network is more robust when it is diverse, and this is one way that we can encourage a more diverse Tor network and enhance our community.

It is important to say that while our initial focus is on BSD systems, our plan is to extend gibson to serve the Tor community regardless of platform. We’re starting with HBSD because it’s an obvious and natural choice for us; we believe in “dogfood“, and we want you to be assured that the code we share is used by our team in real deployments. In our mind it isn’t enough to make running Tor services easy, our tools must also help make services secure and reliable. At Emerald Onion, we do this by example.

What is gibson?

A generous description is that gibson is a no-dependency suite of cross-functional tools for creating and maintaining secure and robust Tor services. We currently support HardenedBSD systems, but plan to extend our support to FreeBSD, OpenBSD, and Linux in future releases.

We say that this is a generous description because we want our tools to take as light a touch as possible. To an experienced user, gibson may not appear to do much of anything at all. This is an intentional design decision. An experienced user might say, “Using gibson to do an update achieves the same outcome as just running these three commands I already know”. Truly, nothing would make us happier than this outcome. We want for everyone in the Tor community to be an expert of the tools that make the network operate, from Tor itself to the operating system, hardware, and everything in between. That said, we hope that experienced users will continue to use gibson, and that they will propose new solutions and new functionality.

The goal of gibson isn’t to make difficult Tor management tasks trivial. Rather, the goal of gibson is to make Tor management tasks consistent. We believe that secure systems are built around reproducible, auditable processes. Most of our maintenance is simple and mundane, but a small configuration error or a missed security patch could be catastrophic to the anonymity and security of Tor users. We want to eliminate possible sources of human error and to share our best practices with the community.

We also believe that users should be able to adopt gibson on existing systems without onerous effort, and should also be able to walk away from it whenever they wish without any lock-in. We want our tools to promote the adoption of correct processes and best practices. We also hope that they will be educational. Users new to BSD systems, new to Linux, and new to Tor should be able to look at our code and with minimal effort be able to understand what it does and why.

Finally, we say that gibson is cross-functional because our solution space is defined by the needs of a secure and robust Tor deployment. We do not seek to replace virtualization and jail tools (for instance, bhyve, virtualbox, ezjail, iocell, etc.). We do not seek to replace disk encryption tools (geli, LUKS, etc.). We’re not replacing any web servers, either (nginx, Apache, Caddy, etc.). What we are doing is providing tools to streamline the implementation of these other projects into a complete solution which addresses the needs of Tor administrators.

What does gibson do now?

Currently, gibson updates and controls Tor services running in HBSD jails. A simple and mundane task, but one that we want to make sure is done consistently during each of our maintenance windows. Our initial release of gibson is version 0.1, which is derived from a handful of scripts currently used in maintenance of Emerald Onion systems.

  • 0.0.1 Initial scripts used for EmeraldOnion system maintenance
  • 0.1.0 First version 0.0.1 scripts refactored into gibson: apply system and package updates in jails; start, stop, restart tor services in jails;

Where can I get gibson?

We’re working on getting gibson into the HardenedBSD ports repository, and it should land there shortly.  It will take a little more time for binary packages to become available for users who prefer to use pkg.

In the meantime, gibson is available at our GitHub, as is the files you need to sideload it as a port.  Detailed installation instructions are available there.

Roadmap (or: what will gibson do in the future?)

0.2 -> 0.5

  • Create and maintain template jail(s); clone templates into new jails and deploy tor services:
    • middle relays
    • exit relays
    • bridges
    • onion services (with nginix, initially)
  • Create and manage geli-encrypted ZFS pools
  • Initial creation of encrypted providers and pool members from specified devices
  • Replacement of devices due to failure or capacity expansion
  • Good ideas suggested (or implemented and submitted) by our community!

0.6 -> 0.9

  • Support for FreeBSD systems
  • Good ideas suggested (or implemented and submitted) by our community!


  • Support for Linux systems
  • Support for non-geli encrypted filesystems
  • Support for non-ZFS storage pools
  • Good ideas suggested (or implemented and submitted) by our community!

House Style

gibson is always written in all-lowercase.


The gibson logo was generously donated by Mike Finch and is licensed by Emerald Onion as Creative Commons Attribution 4.0 International.

OTF Concept Note

What is your idea?

Emerald Onion is a recently founded ISP/community non-profit organization based in Seattle seeded by a Tor Servers grant and personal donations. Our goal is to expand the privacy community by lowering the cost and learning curve for community organizations in the US to operate infrastructure.

Existing organizations in this space, Calyx and Riseup, have succeeded in rapidly becoming focal points for the community, but are inherently difficult to scale and are most effective in their local geographic communities. Thus, while Riseup has excelled at providing technical software, there is no easy path to establishing similar organizations. We want to change that!

In beginning the process of establishing ourselves, we have been documenting every step of the way. We are already running multiple unfiltered Tor exit nodes, and have both legally vetted abuse letters and educational material for law enforcement published. Now, we want to take this knowledge and export it to other communities. In particular, we want to focus on areas near Internet Exchange Points that are in at least 49 metro locations around the US, which can provide economical pricing and good connectivity for Internet traffic. We hope to spur wider deployment of Tor, onion services, and surrounding privacy technologies by helping other local groups follow our path.

Part of this mission is becoming a focal point for privacy operations work ourselves. Working with researchers at Berkeley, we are contributing to easier handling of abuse complaints. With academics in the Tor community, we are piloting new exit strategies to limit the impact of censorship. With the open source community, we are increasing platform diversity through the use and documentation of HardenedBSD as an alternative software stack. Our trajectory as an organization will include partnering with these organizations to improve usage and deployability, education of other network operators, and increasing our network presence and capacity.

What are your goals / long-term effects?

Our goal is that most major communities in the US have local organizations focused on operating privacy technology. Hackerspaces today are a mixed bag, and are often centered around physical rather than digital creation. Despite the presence of major IXPs, there are many urban centers today without community-driven organizations working to bolster privacy. We envision providing the groundwork and enthusiasm to support a network of ISPs around the country that can rectify this situation. Getting these entities in place will be important underlying infrastructure for future decentralized and federated networks to follow the model of Tor today.

Emerald Onion will directly evangelize operational best practices as it matures as a community organization and fits into the Seattle privacy community. To take advantage of Seattle’s position as one of the largest exchange points in the world, Emerald Onion will actively seek out peering agreements and aim to transit a significant amount of Tor traffic. Through our ISP operations, we hope for two primary longer term effects: First, that we are able to disseminate knowledge of peering agreements to make it significantly easier for other entities to understand how to enter into these negotiations. Second, that we can help Tor and other privacy enhancing networks gain capacity, reliability, and strategies for resilience to censorship. These technologies have focused on their software properties, but there are significant operational and networking challenges that need to be solved in tandem. We believe entities like Emerald Onion are the right complement to help privacy technologies succeed.

How will you do it?

Concretely, Emerald Onion will work to bring at least 10 new, independent, Privacy-focused ISPs into existence within the next 12 months. We will also speak in conferences, and use our existing communication pathways to advertise and publish our work. We will work to find other supporters and help them establish their own organizations. In addition, we will work to make shared support networks, like legal funds, peering databases, and abuse systems to be more accessible to these community groups.

Specifically, we will focus on the following areas of capacity:

  1. Funding and organizational stability strategies
  2. Nonprofit ISP incorporation setup and management
  3. Data center co-location setup and management
  4. ARIN registration and AS and IP scope management
  5. IP transit setup and management
  6. BGP setup and management
  7. Peering agreement setup and management
  8. Legal response setup and management

To stabilize ourselves as a focal point of the Seattle privacy community, Emerald Onion will continue to develop both its own sustainability model, and its infrastructure.

We expect to receive 501c3 status by the end of the year, and have already begun soliciting donations for our general operations. We have had initial success in approaching local members of the community to contribute the funds for one relay worth of cost in exchange for “naming rights” of that node. We believe direct community contributions can provide sustainability, and will complement this income stream with grant funding for growth.

We will also continue to increase our network presence to improve our fault tolerance and gain access to more network peers. Higher capacity will allow us to provide incubation for a larger range of privacy enhancing technologies.

Who is it for?

Emerald Onion is not just for the ~60 million monthly Tor users or the Seattle privacy community. We are not just a testing ground for encountering and solving operational issues in the deployment of privacy technologies. Emerald Onion is strategically developing as a model steward of privacy networks that is focused on quality and integrity. Our actions and relationships further legitimize Tor within communities that operate the backbones of the Internet and will help normalize the use of Tor for business-driven service providers.  We will continue to be an inspiration for community groups and other ethically-conscious ISPs alike.

Emerald Onion’s day-to-day work at present focuses on existing and new Tor router operators, who with the organizations that they create will immediately impact public perception. In Emerald Onion’s short existence, we have made direct, personal connections with at least 50 professional network administrators, datacenter operators, and Internet service providers. Imagine that happening in every major IXP community around the United States.

Emerald Onion has paid for professional legal services, and has already published our verified Legal FAQ and abuse complaint responses that are valid within the United States. Similarly, the organization is working with Academics to better understand the operational reality of abuse complaints, and to understand opportunities for making use of the IP space. These services benefit the larger privacy community both operationally, and as an incubator for projects.

What is the existing community?

The Tor relay community is already strong, but lacks strong US-based advocacy for growth. In Europe, has evolved into a grant-giving organization, which is able to provide advice and financial support to help new relays get started, but is not well positioned to support US-based relays. In Canada, Coldhak runs a valuable relay, but has not attempted to export its knowledge to external entities.

In the US, the largest relay presences come from and Calyx networks. Riseup is focused on services like email and VPNs in tandem with important education. This is valuable work, but does not extend to directly advocating for new groups to enter the ISP space. Calyx is supported through a cellular ISP model focusing on end-users but does not focus on supporting new relay operators.

Emerald Onion aims to fill this gap through direct advocacy to guide and support new relay operators and encourage the existence and creation of privacy supporting entities in a diverse set of IXPs around the country.

Complementary Efforts?

The Tor Project itself provides a basic level of support for new entities, particularly with technical support. In addition to a wide-reaching and engaging community, the presence of the Tor-relays mailing list provides a valuable community-wide support network between operators. The EFF has been a long-time supporter of the legal aspects of relay operation, and has helped with several legal papers supporting helping to establish the legal protections of Tor exit operation, along with providing counsel when new legal issues arise. It remains the case that new entities establishing Tor exit nodes in the US face thousands of dollars of legal fees to properly prepare themselves with the needed form letters for abuse and a tricky navigation of legal guidelines to establish themselves as legal entities with the authority to respond to complaints without fear of retribution.

Emerald Onion hopes to fill these gaps by making it easier for others by defining clear direction, freely published in the public domain, so that new operators don’t need to duplicate work that we’ve already performed. Building a shared legal defense fund and sharing how to navigate data center costs and contracts will allow groups to form with much less risk or uncertainty.

Why is it needed?

In building Emerald Onion so far, we have already found that many of the steps we are taking are undocumented, or rely on verbally communicated lore. That situation is not sustainable, and cannot scale or significantly improve the current state of the world.

More organizations are needed that focus on Internet privacy the same way hackerspaces have focused on hardware and technical development. Internet issues are inherently rooted in being part of the Internet and that barrier has so far been a high hurdle for community groups. We believe that this hurdle needs to be lower.

Without active development of these entities, we will continue to see even more centralization of the Internet and continued erosion of neutrality. Retaining a community presence in Internet operations is a key underlying infrastructure that we strongly believe has the potential to change the future development of the Internet.


Internet Exchange Points in the United States

Emerald Onion is researching IXPs in the U.S.A. in order to identify areas of priority as it concerns increasing global Tor network capacity by way of putting Tor routers directly on these highly interconnected networks. Putting Tor exit routers in IXPs, for example, may reduce network latency to end points. It may also reduce network hops, potentially minimizing the possibility of third-party surveillance. Emerald Onion envisions a future where the Tor network is composed of much larger and more stable network operators, globally.


  1. Are there any Tor routers connected to any United States-based IXPs? If so, which ones and who operates them?
  2. Is this IXP friendly to Tor?
  3. What is the organizational structure of this IXP? Such as corporate-run or community-driven, etc.
  4. What qualities of an IXP should impact how meaningful it would be for the Tor network?
    • Number of participants?
    • Access to specific participants?
    • Nonprofit?
    • Community driven?
    • Affordability?
    • Geolocation?
    • Prohibits network surveillance?

A top 20 list of cities to focus on for Tor development?

  1. Chicago, IL has at least 12 IXPs
  2. New York City, NY has at least 9 IXPs (and has Calyx Institute)
  3. Dallas, TX has at least 6 IXPs
  4. Los Angeles, CA has at least 6 IXPs
  5. Miami, FL has at least 6 IXPs
  6. Seattle, WA has at least 5 IXPs (and has Riseup and Emerald Onion)
  7. San Jose, CA has at least 5 IXPs
  8. Phoenix, AZ has at least 5 IXPs
  9. Ashburn, VA has at least 3 IXPs
  10. Reston, VA has at least 3 IXPs
  11. Boston, MA has at least 3 IXPs
  12. Atlanta, GA has at least 3 IXPs
  13. Portland, OR has at least 3 IXPs
  14. Honolulu, HI has at least 2 IXPs
  15. Denver, CO has at least 2 IXPs
  16. Vienna, VA has at least 2 IXPs
  17. Palo Alto, CA has at least 1 IXP
  18. Salt Lake City, UT has at least 1 IXP (and has XMission)
  19. Minneapolis, MN has at least 1 IXP
  20. Detroit, MI has at least 1 IXP

IXPs in the United States

Ashburn, VA

    1. Equinix Ashburn Exchange (Equinix Ashburn)
    2. LINX Northern Virginia (LINX)
    3. MAE East

Ashland, VA

    1. Richmond Virginia Internet Exchange (RVA-IX)

Atlanta, GA

    1. Digital Realty / Telx Internet Exchange (TIE)
    2. Equinix Internet Exchange Atlanta (Equinix Atlanta)
    3. Southeast Network Access Point (SNAP)

Austin, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

Billings, MT

    1. Yellowstone Regional Internet eXchange (YRIX)

Boston, MA

    1. Boston Internet Exchange
    2. Massachusetts eXchange Point (MXP)
    3. CoreSite – Any2 Boston

Buffalo, NY

    1. Buffalo Niagara International Internet Exchange (BNIIX)

Chicago, IL

    1. AMS-IX Chicago
    2. CyrusOne Internet Exchange (CyrusOne IX)
    3. Equinix Chicago Exchange (Equinix Chicago)
    4. Greater Chicago International Internet Exchange (GCIIX)
    5. United IX – Chicago (ChIX)
    6. CoreSite – Any2 Chicago
    7. MAE Central

Columbus, OH

    1. OhioIX

Dallas, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)
    2. DE-CIX, the Dallas Internet Exchange (DE-CIX Dallas)
    3. Digital Realty / Telx Internet Exchange (TIE)
    4. Equinix Dallas Exchange (Equinix Dallas)
    5. MAE Central
    6. Megaport MegaIX Dallas (MegaIX Dallas)

Denver, CO

    1. CoreSite – Any2 Denver
    2. Interconnection eXchange Denver (IX-Denver)

Detroit, MI

    1. Detroit Internet Exchange (DET-IX)

Duluth, NM

    1. Twin Ports Internet Exchange (TP-IX)

Gillette, WY

    1. BigHorn Fiber Internet Exchang (BFIX)

Hagåtña, Guam

    1. Guam Internet Exchange (GU-IX)

Honolulu, HI

    1. DRFortress Exchange (DRF IX)
    2. Hawaii Internet eXchange (HIX)

Houston, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

Indianapolis, IN

    1. Midwest Internet Exchange (MidWest-IX – Indy)

Jacksonville, FL

    1. Jacksonville Internet Exchange (JXIX)

Kansas City, MO

    1. Kansas City Internet eXchange (KCIX)

Los Angeles, CA

    1. CENIC International Internet eXchange (CIIX)
    2. Equinix Los Angeles Exchange (Equinix Los Angeles)
    3. Los Angeles International Internet eXchange (LAIIX)
    4. MAE West
    5. Pacific Wave Exchange in Los Angeles and Seattle (PacificWave)
    6. CoreSite – Any2 California

Madison, WI

    1. Madison Internet Exchange (MadIX)

Manassas, VA

    1. LINX Northern Virginia (LINX)

Medford, OR

    1. Southern Oregon Access Exchange (SOAX)

Miami, FL

    1. Equinix Internet Exchange Miami (Equinix Miami)
    2. MAE East
    3. Miami Internet Exchange (MiamiIX)
    4. NAP of the Americas (NOTA)
    5. The South Florida Internet Exchange (FL-IX)
    6. CoreSite – Any2 Miami

Milwaukee, WI

    1. The Milwaukee IX (MKE-IX)

Minneapolis, MN

    1. Midwest Internet Cooperative Exchange (MICE)

Moffett Field, CA

    1. NGIX West

Nashville, TN

    1. Nashville Internet Exchange (NashIX)

New York, NY

    1. AMS-IX New York (AMS-IX NY)
    2. Big Apple Peering Exchange (BigApe)
    3. Digital Realty / Telx Internet Exchange (TIE)
    4. Equinix Internet Exchange New York (Equinix New York)
    5. Free NYIIX Alternative (NYCX)
    6. New York, NY – (CoreSite – Any2 New York)
    7. DE-CIX, the New York / New Jersey Internet Exchange (DE-CIX New York)
    8. New York International Internet eXchange (NYIIX)
    9. MAE East

Omaha, NE

    1. Omaha Internet Exchange (OmahaIX)

Palo Alto, CA

    1. Equinix Internet Exchange Palo Alto (Equinix Palo Alto)

Philadelphia, PA

    1. Philadelphia Internet Exchange (PHILAIX)

Phoenix, AZ

    1. Arizona Internet Exchange (AZIX)
    2. Digital Realty / Telx Internet Exchange (TIE)
    3. Phoenix Internet Exchange, LLC (PHX-IX)
    4. Phoenix IX
    5. CyrusOne Internet Exchange (CyrusOne IX)

Portland, OR

    1. Central Oregon Internet eXchange (COIX)
    2. Northwest Access Exchange, Inc. (NWAX)
    3. Oregon Internet Exchange (OIX)

Reno, NV

    1. Tahoe Internet Exchange (TahoeIX)

Reston, VA

    1. LINX Northern Virginia (LINX)
    2. MAE East
    3. CoreSite – Any2 NorthEast

Saint George, UT

    1. Southern Utah Peering Regional Network (SUPRnet)

Salt Lake City, UT

    1. Salt Lake Internet Exchange (SLIX)

San Antonio, TX

    1. CyrusOne Internet Exchange (CyrusOne IX)

San Diego, CA

    1. San Diego NAP (SD-NAP)

San Francisco, CA

    1. San Francisco Internet Exchange (SFIX)
    2. San Francisco Metropolitan Internet Exchange (SFMIX)

San Jose, CA

    1. AMS-IX Bay Area (AMS-IX BA
    2. CoreSite – Any2 Northern California)
    3. Equinix San Jose / Bay Area Exchange (Equinix San Jose)
    4. NASA Ames Internet eXchange (AIX)
    5. MAE West

San Juan, Puerto Rico

    1. Internet Exchange of Puerto Rico (IX.PR)
    2. Puerto Rico Bridge Initiative (PRBI-IX)

Seattle, WA

    1. Megaport MegaIX Seattle (MegaIX Seattle)
    2. Pacific Wave Exchange in Los Angeles and Seattle (PacificWave)
    3. Seattle Internet Exchange (SIX)
    4. Seattle Internet Exchange (9000 MTU) (SIX Seattle (Jumbo))
    5. Seattle, WA Equinix Internet Exchange Seattle (Equinix Seattle)

Sterling, VA

    1. CyrusOne Internet Exchange (CyrusOne IX)

Tampa, FL

    1. Tampa Internet Exchange (TampaIX)
    2. Tampa Internet Exchange (TPAIX)

Tulsa, OK

    1. LiveAir Tulsa IX

Vienna, VA

  1. Equinix Internet Exchange Vienna, VA (Equinix Vienna (VA))
  2. MAE East