When I talk about usability, I tend to emphasize the engineering aspects of the discipline. While usability practitioners use methods from graphic design and cognitive psychology, the deliverables are radically different. Judging a UI by how it looks is like evaluating a piece of machinery based on the operating tolerance specifications. After all, mechanical engineers use mathematics to solve problems but the end result is not a mathematical proof. To evaluate the engineering used to create the machine, you must consider how well the final machine fulfills its purpose in addition to the processes behind its creation.
Tor & Bad Usability Engineering
In 2005, Tor (a censorship circumvention network) held a contest to create a new user interface. My own submission was rather simple, it included a browser window with a circle around it, signifying a sandboxed browser. I wrote that there should not be a separate interface for Tor and its proxy software – everything should come packaged as a browser.
However, my suggestion violated the very premise of such a contest: they wanted a new interface for their proxy and browser add-on. Five years later, the lead developer for browser integration wrote a blog post outlining the need to remove this interface.
“I think we should completely do away with the toggle model, as well as the entire idea of Torbutton as a separate piece of user-facing software, and rely solely on the Tor Browser Bundles, except perhaps with the addition of standalone Tor+Vidalia binaries for use by experts and relay operators.”
Building all of the proxy and routing functionality into Firefox may have been beyond Tor’s organizational capacity at the time. However, instead of recognizing this and incorporating it into their road map, they implemented an interface which they would later discard. The project wasted time and resources building documentation and support infrastructure to handle users who could not properly configure the software. But this was not just a waste of engineering resources: it degraded the safety of end users without the technical skills to properly secure their browser. Tor is a project that is used in extremely dangerous circumstances and it is not an understatement to say that their poor UI choices put the safety of their users at risk.
Namecoin is a very cool project that provides a decentralized system for registering domain names (such as example.com) using a new top level domain: .bit. Unlike traditional .com or .net websites, a .bit website can neither be forcibly taken over nor subverted by a government. The project is even working on creating an anonymous system for the purchase of the domains, so dissidents in places like China and Iran can run a website without fear of retribution.
To pull this off, Namecoin solved a decades old computer-science problem known as Zooko’s Triangle. At the time of Zooko’s Triangle’s conception it was considered to be the missing puzzle piece required for a secure, decentralized, and usable web. I grew-up online and followed the evolution of censorship on the web. Over the years, I watched as each anti-censorship system failed because it could not overcome Zooko’s Triangle. I was very excited when the Namecoin project was first announced in 2011: with Zooko’s triangle out of the way, I thought it would only be a matter of time until .bit domains became mainstream.
A couple of years later, during the summer of 2013, I checked in on the project only to find it in disrepair. Being a usability engineer, I zeroed in on the usability problems facing the project. Because Namecoin was an entirely new way of registering domains, none of the web browsers or operating systems supported it. The complicated process required to make a machine capable of visiting a .bit site meant that few could visit such sites. However, existing websites would not publish a link that won’t work with vanilla web browsers. To escape this chicken-and-egg adoption quagmire, Namecoin needed an interoperability solution that was secure, usable, and scalable.
One of the most frustrating parts of usability engineering is explaining to programmers that the most clever technical solutions are worthless if no-one can use them. Usability has a multiplier effect on adoption and zero multiplied by one thousand is still zero.
The previous method for interoperability with .bit websites was the use of a web proxy: a special webserver that doesn’t serve websites directly but fetches pages from other sites instead. A server capable of visiting .bit websites would be setup to handle requests from (for example) bit.io. If someone requested example.bit.io the server at bit.io would fetch example.bit and then serve it as if it were located at example.bit.io. While usable, there are three problems with this approach: security/privacy, cost, and legality.
The privacy and security of this process is fundamentally broken: the server can read and alter the content of example.bit. Indeed, it must strip off all encryption before serving up the page.
Proxies have very poor scaling characteristics as well: the proxy server must serve up webpages for every .bit website for free. The cost is 1:1 – every additional visit to every .bit website must be matched by the proxy server.
Finally, the proxy server can be held legally liable for the content it serves up – not a great legal situation for a system designed to serve up politically controversial material.
The challenge I set myself was to create a solution with the following characteristics:
- No installation – it had to work on a vanilla web browser.
- Scalable to handle the entire .bit domain.
- Legally protected from the destination website content.
- Secure and private for casual reading.
This requires some cooperation from the underlying website, but the UI degrades gracefully. We are currently providing the DNS information from our servers, as DNS is still a protected service under US law. Eventually, we will be able to create a Namecoin lite-client that can query the Namecoin network directly, removing our servers from the look-up process entirely.
While the top level page cannot directly access the content of the iFrame, it could redirect the user to a malicious page. However, this can be fixed by the browser vendors enabling iFramed sites to have read-only access to the site which is being framed. This would help to ensure the site’s contents are non-malicious. A two-step login process on the iFramed site (akin to the challenge-response iconography of bank logins) would prevent phishing attempts by the parent site. The iFramed site can also specify which sites are allowed to frame its content, giving them a degree of control over which sites they believe are trustworthy.
As a bonus, I discovered that I could prevent the destination website from ever being sent to the server, through use of a special # syntax. This led to the creation of Speech.is, a special address that would make the enforcement of nation-state internet blacklisting schemes unconstitutional. One part of this trick is technical: we can force a nation-state to chose between blacklisting all of the sites reachable through speech.is or none of them at all (see below). The other part of this trick is sociopolitical: politicians would be forced to justify blacklisting speech.is#wikileaks.bit. This places free speech rights front and center in debates usually dominated by file sharing and pornography.
Technical Details of Anti-Censorship Features
In a URL such as example.com#helloworld, anything after the # never leaves the browser. Full network-level anonymitization is not yet implemented, but that will only become necessary in countries with weak DNS-level censorship. While some countries already implement such protections, the main legal battleground is in the US. Research on browser-to-browser anonymous overlay networks is just beginning. We would prefer to wait until a solid network emerges rather than try to build one ourselves. A current lack of capacity does not mean it isn’t useful: if we can show that proposals for DNS-level blacklists are ultimately futile we can avoid the legal battle to begin with.