16. November 2014

Under the Radar

I’ve been kicking around a new project lately, with valuable input from @sgentle. Under the Radar (UTR) is a chat application designed with user privacy in mind.

Like many of us, I’ve been disturbed by the recent developments in global surveillance. In short, I respect the need for law enforcement to be able to surveil humans in order to fight crime. I think, however, that the judiciary is a vital component of the system in ensuring that the apparatus does not overstep it’s bounds. The legislative and operational changes we’re seeing have removed the agency of the judiciary and that is what’s spurred me to action.

UTR is intended as a day-to-day chat application. This means it should be available on all major platforms and should be easy to use. It should protect user privacy at all times, both in the content of messages and their recipeints.

See Prior Art for why I’m writing a new tool and not using something that already exists.

These two goals are sometimes in direct conflict. A steering principle to inform these tradeoffs is that our primary goal is to guard against ‘dragnet’ style surveillance. UTR aims to stop your data and metadata being useful to attackers who are simply watching everything. It may not be possible for UTR as-designed to guard users against targeted individual inspection by sophisticated attackers. ie: If the NSA is interested enough in you that they’re going to install a keylogger on your devices, you need some more powerful magic.

For more detail on this, read about UTR’s architecture.

A key design consideration of UTR is that it should be simple. UTR does not aim to reinvent any cryptographic wheels, instead opting to use established techniques, proven libraries and well trodden paths. UTR also aims to be as small a codebase as possible. A review of the implementation should be a trivial exercise.

More about this in threats and tradeoffs.

UTR will provide a standard implementation of the client and a publicly available server. It should be trivial for users to build their own clients and build and host their own servers.

Read about the current UTR implementation details.

UTR should also have a way of supporting it’s costs. One of the best ways to ensure that UTR continues to be developed in the best interests of it’s users is to have it’s users support it financially.

This and other concerns are discussed in ecosystem.

16. November 2014

Under the Radar - Ecosystem

There are a number of neat things that the architecture and implementation enable.

It is trivial for a user to host their own ‘backend’ for UTR. All they need do is get a CouchDB instance. There are several free providers and setting up your own is simple. This is the case both for Identities and Conversations. The reference client implementation will aim to make it simple to use third-party endpoints.

Using PouchDB/CouchDB does wonders for the ability to write cross platform applications. For one, the API is open and well documented by Mozilla. PouchDB is also usable in the browser, in nodeJS (and node-webkit) and in Cordova across all major mobile platforms. I’ve been spending a lot of my day job lately writing applications that span OSX, Windows, iOS and Android while using largely the same codebase. Node-Webkit and Cordova are also good to go for Linux, Windows Phone, etc etc. This toolkit gives us a clear road to native apps on every major platform and a webapp for anyone else.

Using PouchDB for both the storage and transport layer also means there is vastly less code to write in the app itself. This neatly serves the goal of keeping the codebase small and simple to aid audits.

I intend all software I create in this endeavour to be FLOSS. Users will be free to build their own clients if they choose. I do intend, however, to support development and hosting of UTR via user contributions. There will be a donation apparatus, however there will also be built versions of the reference client in the various platform marketplaces that may have a reasonable cost associated with them. It will also be possible to seek payment for hosted Conversations. Users will be free to create databases, but at intervals a process can run checking for new databases and associating them with a bitcoin address. It can then post an (unencrypted) messages to the Conversation asking users to pay into the address, providing reminders, etc. These wallets can then be tapped for the agreed monthly fee in order to support the cost of running the Couch.

The default behaviour of the reference client is to use PouchDB to do a live replication on the remote. This keeps a long poll open and fetches any new documents as they’re available. This is fine, but will not work when the app is not active (looking at you, iOS) and is potentially problematic for battery life. Since the Conversations are publicly readable, however, providing push notifications becomes an orthogonal service. The user simply hands the Conversation URL to their Push Notification provider and asks to be notified when there is a new Message. I intend to provide one such service, but anybody who wishes to operate their own will be on a level playing field, regardless of which CouchDB provider is hosting the Conversation.

16. November 2014

Under the Radar - Architecture

These are the architectural tenets of UTR:

UTR assumes the platform on which it is being executed is trusted.

All messages are encrypted on the client. This encryption is maintained at-rest and in transit.

Messages can be safely stored by an intermediary in order to enable asynchronous delivery and multi-device synchronisation.

It is not obvious to an attacker who is corresponding with whom.

Clients work offline and synchronise their state when the network becomes available.

Push notifications can be utilised to ensure a good mobile experience.

The components of UTR are:


Users can create any number of Identities. An Identity is a database that contains a document with a public key.

When the user creates their Identity as a local PouchDB, they also provide a remote CouchDB instance to replicate to and from. This remote forms the user’s public Identity and they can share the URL describing it with people they wish to correspond with.


In order to start a Conversation with another user, you post an Invitation to their Identity database. This Invitation should be a JSON document describing the URL of the Conversation you are inviting them to, the Secret that is used to encrypt messages in that Conversation and (optionally) your Identity, a signature proving the veracity of your claim on your Identity and some text enticing the user to accept your Invitation. The document should be encrypted with the recipient’s public key such that they are the only ones able to read it.


A Conversation is a CouchDB database. Participants in the Conversation hold local copies which replicate with the public database. The Conversation contains Messages.


Messages are JSON documents that are encrypted with a Secret. The JSON documents contain a textual payload and some metadata describing who posted them, what time they were posted, etc.


Secrets are passwords of sufficient length and complexity that data encrypted with them is unfeasible for an attacker to break. They are automatically generated by clients and should never need to be remembered by humans. Now go read about how this is implemented.