Home // About // Previous // Next

Burnrchat. A design sprint for an anonymous messaging app.

Some time ago I participated in a design sprint, organised by the Innovation Lab of AVG in Amsterdam. Initially, the idea was to design a clear and easy to understand mechanism to securely exchange keys for secure communication. In the end we designed and sketched the implementation of a privacy friendly and fully anonymous messaging app called 'Burnrchat'.

We agreed beforehand that everything we would produce during the design sprint would be open source and in the public domain. That is one of the reasons I am writing this blog.

The result

Burnrchat allows users to connect to each other by 'bumping' their phones. This will exchange cryptographic keys that will allow them later to connect and communicate with each other securely. Each bump creates a new set of keys, which makes each connection independent of any other connection. As a result no group of people can determine whether you are connected to all of them. This is one way in which Burnrchat protects the social graph.

One way to exchange such keys is through a Diffie Hellman key exchange (watch this video for a very intuitive explanation of the idea!) using sound as the medium to transport the binary data. Apps like Chirp do this to transmit photos, contacts, etc. Using sound ensures that only a device really close by can connect, adding to the security of the scheme. If so desired users could crosscheck fingerprints to verify the connection was indeed established correctly (and not with an eavesdropper close by).

The result of a bump is a connection that initially contains an empty conversation. Right after the bump you can choose a emoticon to label the connection, to remember who this connection connects you to. We specifically designed the app in such a way that there is no default profile picture or nickname that I can send to you so you can remember who I am. This would contradict the requirement that each connection is independent of all my other connections. With such a default, people would easily be able to tell that I am connected to all of them.

Burnrchat also supports group communication (albeit in a limited way, see below). To create a group, bumps are 'viral' for a brief period in time. If one of us bumps with someone else after we bumped within that timeframe, we all belong to the same group. People can only communicate 'point-to-point' with people they directly bumped with, though.

(Note: during the design sprint we focused on physical proximity to establish a connection. Our user panels showed that all people interviewed found this a severe limitation: the app could not be used for most/all of their messaging needs. But in fact, a virtual bump is easily realised by generating random pairing codes that are valid for a brief period of time, and that can be sent to the person you want to connect to through other means: email, SMS, social network, etc. Clearly this auxiliary channel is not anonymous, and therefore invalidates the anonymity guarantees that Burnrchat itself provides. But here it offers a convenience, and the anonymity wasn't there in the first place because the people already connect over the non-anonymous channel.)

Use cases

The design sprint also identified a few promising use cases.

The first one involves journalists that may want to stay in touch with (anonymous) contacts and informants in hostile environments, like civil war zones, or in countries with limited protection to journalists (or informants). If you don't even need a phone number to connect to each other, loss or theft of your phone means your contacts cannot be traced (as would be the case if their phone numbers would be in your address book). This is relevant, as the following quote from the recent Freedom on the Net 2014 report shows.

The increased use of “social engineering”—essentially tricking users into revealing information—and account hijacking has reinforced the idea that one’s own digital security often depends on the actions and judgment of those in one’s broader social or professional network.

The second use case involved dating. When you meet someone at a party, or in a club, the only way to stay in touch at this moment is by exchanging mobile phone numbers to connect on WhatsApp and the like. Now if the person you connect with turns out not to be so nice after all, you have a problem. Even if you delete the contact from WhatsApp, he (typically a he...) will still be able to stalk you using your phone number. With Burnrchat, you no longer run this risk. Women interviewed during the user trials all loved this feature. Apparently boys can be very persistent in asking for their phone number. And can even become nasty when the girls refuse. As one of the interviewed women said: "finally a graceful way to refuse a guy to give him my phone number!".

The third use case involved anonymous groups, like Alcoholics Anonymous, or on-the-spur-of-the-moment protests (like last year's Hong Kong protests). This use case is much less clear cut. First of all (as discussed in a bit more detail below) group communication is hard to do right and sometimes counter intuitive (especially in an anonymous setting). Secondly, the threats involved in things like protest marches are poorly understood but do involve spies, undercover agents and other insider threats. Something the app itself cannot easily defend against.

A final interesting use case that we discovered a week after the design sprint is related to health care. Increasingly health workers, social workers, etc. use messaging apps to stay in touch with their clients. One requirement for the person providing the care is to be able to disconnect a client when he stops caring for a client. Or to be able to only be reachable for clients when on duty. Something clients can easily circumvent if they know the mobile phone of the health care worker.

Group chat

The first use case we came up with was the Alcoholics Anonymous one, so we were initially spending quite some time on thinking about group chat, and how that should work in an anonymous setting. To make this intuitive and easy to use turns out to be hard, for several reasons.

• How to establish a group? Should all people in the group bump with each other? This is a lot of work per user, but provides a lot of control. But what if someone forgets to bump one other person? Should forming of the group then be canceled?
• Should groups be formed transitively instead? Such that anyone in a group can add someone else to the group by bumping with that person. That may be undesirable because people may end up in a group with other people they do not want to be associated with. Clearly the transitivity needs to be limited, e.g. only allowing it within the confines of a single physical location, or only allowing 'viral bumps for a brief period of time (what we eventually settled for)
• Are groups static or dynamic? Given the arguments above, adding people to a group later may be undesirable. What about removing people from a group? Who decides this? Can one person remove someone, or do you need a majority vote?
• Should members of a group be able to communicate privately with any single member of a group, or not? This was a hotly debated issue. On the hand it feels unnatural to have to connect separately to certain group members only because you want to send them a message but the app does not allow you to select that person from within the group. On the other hand, people may be comfortable joining a group of people that are relatively unknown to them, knowing that any message sent is received by all people in the group. This creates some pressure to behave, which means people have to be less worried to be stalked by individual members.
• How should a group chat be implemented? Using point to point links among all members? How to guarantee causal order delivery of messages to all members of the group in that case?
• How do communication patterns generated by group chat influence the anonymity guarantees that application originally sought to provide?

At some point I had the feeling a proper study of these issues could easily lead to an entire scientific article for a conference like Symposium On Usable Privacy and Security (SOUPS)...

Implementing the system securely

Interestingly enough, the whole design sprint also delivered a serious new scientific result (that I am currently busy to write up and to scrutinize in detail). We realised the app would only be useful if it could be implemented in such a way that it protects not only the content of the conversations but also the metadata. In other words that no party involved would be able to link or trace users. On the other hand, the only viable approach (and the one taken by almost all other messaging apps) to realistically implement this service in practice is to have a central server relaying (and temporarily storing) messages in transit. The scientific breakthrough was that this could indeed be done, as sketched in the following figure.

Closing

The design sprint resulted in a new kind of privacy friendly messaging app. One that allows you to connect, without revealing a long term identifier like your mobile phone number or your email address. Burnrchat. No strings attached.

It was a very worthwhile experience. I learned a lot about how real companies design real products. And I saw the added value a scientist like me could play in such a process. I would like to thank AVG for hosting me. And Carolien, Jessica, Jeroen and Maurice for the very nice and fruitful collaboration.

And I look forward to doing something like this again, in the near future.

P.S.: About the name. It somehow came up, and stuck. Personally I don't really like it, but according to Maurice research has shown that spending too much time to find the perfect name and/or logo (if there is even such a thing as a universally understood perfect in this domain) is not worth the effort...