Speech.is: Usability Engineering ≠ Design

Usability is a process, not a product. Assessing the quality and competency of a usability engineer requires evaluating not just the final interface but the process that went into making the interface. This piece tries to demonstrate the difference between design and usability engineering.

Usability Engineering

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.

Usability Failings

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.

Prior Solutions

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.

JavaScript DNS & Speech.is

The challenge I set myself was to create a solution with the following characteristics:

  1. No installation – it had to work on a vanilla web browser.
  2. Scalable to handle the entire .bit domain.
  3. Legally protected from the destination website content.
  4. Secure and private for casual reading.

When I first started on the project, it was assumed by myself and the Namecoin developers that achieving no installation and any one of the other 3 requirements was impossible.  After 6 months of iterating on prototypes, hounding pro bono legal counsel, and digging into JavaScript, I accomplished goals 1-4 in addition to finding a way to make censorship of the site unconstitutional in the United States.

The simplest explanation is that I re-implemented parts of the browser using JavaScript.  The interface was similar to that of the proxy server, example.bit.io (note that we are still looking for funding to aquire a bit.* web address).   It, too, would fetch example.bit but it did so using JavaScript on the client’s browser.  There are some caveats (a more full technical explanation is in the info box below) but the end result is a user experience that is 100% transparent, scales well, and is legally immune from prosecution in the US.

JavaScript DNS Technical Details

Instead of a browser plugin installed by the user, the user visits a page such as example.bit.io (we’re still looking for a good URL).  The server delivers JavaScript to the user’s browser then the user’s browser extracts the destination site from the URL.  The browser then fetches the DNS information from the Namecoin blockchain, and loads the destination site into an iFrame.   Using HTML5 APIs, the underlying website syncs the URL, favicon, page title, and history information with the top level page.

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.


Speech.is and the JavaScript DNS system powering it broke new ground.  It uses browser technologies that were not available just a few years prior.  Some capabilities are only partially operational, but it currently achieves every requirement set out at the beginning of the project.   The situation will only improve as new browser technologies come online.


What interface could you judge this project by?  You should recognize this as a trick question: the interface is no different than that of a standard web browser and any evaluation would just be an evaluation of Firefox, Chrome, or Internet Explorer.  In terms of usability, the underlying websites are at the very least browse-able, if not 100% identical to browsing without JavaScript DNS (see JavaScript DNS Technical Details above).


JavaScript DNS websites such as Speech.is can scale to handle as many page views as can any of the top 5 most visited domains (Google.com, Facebook.com, Yahoo.com, etc.), and for approximately a hundred dollars per month.  This is because the main site only delivers a static website which contains a small amount of JavaScript before the browsers can directly fetch content from the destination website.


Because pages are loaded directly by the client, the server hosting Speech.is and any other JavaScript DNS site cannot be held legally liable for the content.  Thanks to the #example.bit trick (see Technical Details of Anti-Censorship Features above) the server and the network operators can be made blind to the destination website.  Any attempt at forcing such a site to selectively censor specific .bit sites would be equivalent to forcing Firefox or Chrome to censor websites as well.


Speech.is and any other JavaScript DNS site cannot examine the content of the destination website.  Additionally, the destination website can control which JavaScript DNS sites are allowed to even display the site content.  This is a remarkable improvement over proxy servers, which must process the destination website address, the content of the destination site, and remove the encryption of the destination website.  It would be trivial for browser vendors to allow the underlying website to inspect Speech.is or any other JavaScript DNS site for code that would enable it to redirect the user to a phishing site (see JavaScript DNS Technical Details above).

Leave a Reply