about truetheory.org

There is a story to tell about this site, and as there is no recorded history of it yet, I figure here’s as good a place as any to document it.

During my time at UC Berkeley, I studied Mechanical Engineering while serving in several different roles with the residence hall IT support organization Residential Computing. Most of my time with ResComp was devoted to network security, but thanks to a blue-chip team of IT heavyweights including Christopher Cowart, Rune Stromsness, Dennis Mojado, and Erik Klavon, I also got a good taste of systems and applications security and administration.

The former three of these dear friends of mine, along with Minh Tran, Benjamin Lee, Robert Taylor and Daniel Chen worked together at the umbrella organization for ResComp during the Summer of 2007, and eventually became the founding members of this Cooperative. It was on one of those beautiful summer evenings in the SF Bay Area that blee, ccowart and I were discussing a shared point of hatred: Google.

Why do we hate Google? Because they provide free services, both well designed and implemented, but at the same time are siphoning privacy away from information like stored e-mail, web searches, and legal file trafficking by logging and parsing all information that is coming from the user. In particular, it is the harvesting of e-mails that made the three of us most uneasy (you have probably seen this practice before: on Gmail, have you ever noticed that those advertisements seem to be tailored to you?). However, most users are perfectly fine with trading the convenience and availability of these free services for just a little bit of their privacy. We three were not, and we all shared our separate dreams of having our own mail servers, even though we knew that it would just be too expensive.

“What about using a VPS?” one of my coworkers, Jeremy Weinstein asked. In short, these solutions generally load a user on to an already-overburdened server with a bunch of tiny, oversubscribed “virtual” machines working on the same hardware. Not only that, but my colleagues use encryption tools like GnuPG and SSHKeys which store private keys unencrypted in memory, because back when these features were innovated RAM was considered a “safe place” to store information. However, knowing that a machine administrator can always access it in software or a random passerby can access it in hardware, my friends and I had reason to fear moving all of our precious privacy-granting tools onto a machine that we do not own.

“Fine, you should all just pitch in and get your own server,” jeremydw told us. Sounds like a great plan, but something was wrong with even that, too; who would have access to the primary administrator account? With access to it, one could still override all of our many methods of ensuring privacy and authenticity by grabbing our encryption keys. It’s not that we don’t trust each other as friends to not steal each others’ identities… it’s that we don’t trust each others’ absolute judgment in deciding who or what to trust. When three people have access to the administrator account, that means we have just expanded the largest security hole in computing by a factor of three.

Then, ccowart suggested what would become the guiding principle for our model. We can use the VPS infrastructure, except limit the amount of users so it’s not oversubscribed and break the password into pieces so no one person could take administrative actions (e.g. capture passwords). Instead, we would re-write the authentication subroutines in UNIX to require a quorum of members to agree to gaining privileged access. The idea caught like wildfire. That night, ccowart and I met at Jupiter with our colleague and friend mht to gauge his interest; he was intrigued and wanted to start work immediately (but was a little too tipsy to do so after our discussion).

The dredge of daily life and school started fast; ccowart got a full-time job with RSSP-IT, I was busy applying for graduate fellowships and Ph.D. programs, and everyone had their own business to tend to. We still talked about the project from almost a purely academic standpoint for months. Come Spring, the hope had all but faded that we would actually come together and pull it off– until blee found a server on Dell’s outlet site for super cheap that matched our proposed specifications. That evening, we bought the server and were committed monetarily.

After a very long search for colocation providers and several proposed methods of decorum and Constitution, we have ended up with EGI Hosting in Fremont, at a Hurricane Electric facility. Our server is a Dell 2950, with dual Quad-Core Intel Xeon E5410 Hapertown 2.33GHz processors, 16GB RAM, and over 500GB of storage space in a RAID5 array with one hot spare. Each of the Cooperative members has been afforded three virtual machines, with an equal share of resources formed into pools by VMware Virtual Infrastructure ESX. And among everything else, we each have no explicitly greater access to each others’ servers, staying true to the founding principles of our group.