How to communicate security expectations to users in an end-to-end encrypted chat app?

Question

I am developing a chat application that has end-to-end encryption, with no third party being able to eavesdrop on conversations. This is rather easy by simply deploying apps that people download and then use for chatting.

However, I also wish to give people an option to use a web client without installing anything. Obviously, this means that all the messages need to go through a web server, which could possibly eavesdrop on it. But if the provider is trusted not to eavesdrop, then it's still secure (The website uses HTTPS).

How should I inform users of the difference in security? The only thing I could think of is something like:

Note on security: Using the web client provides less security than using the downloaded application. If we somehow turn evil, then we could eavesdrop on conversations on the web client, but conversations using the downloaded client are safe even from us.

but this seems very confusing, and most users would probably laugh at the service "turning evil".

Answer 1

NB: This is an open research problem, and there are several people currently doing research on communicating the security provided by end-to-end encrypted chat applications. So there is no research coming to our rescue here, only design thinking.

Another note: there is no such thing as a security / usability trade-off. There's design principles, constraints related to security, and to that add poor designers and good designers.

You should communicate to your users the level of security they should expect. In this case, a visual approach is what I would recommend.

When you advertise / install / run the app, showing a visualisation of two people communicating over a secure channel (and possibly third-parties failing to pierce through the channel) could help users conceptualise that they are talking peer-to-peer and securely.

When people switch to the Web view, it should be prominently displayed this time that the messages transit through a server that is branded with your company's brand identity, and you should show that this server is able to read / intercept messages (depending on what your solution actually does).

Why visualisations? The idea is to rely on the human ability to process spatial concepts without rationalising them. By showing the boundaries between users, the branded server, and external parties, you can communicate the provided security effortlessly. See Dourish's 'Where the Action is: The Foundations of Embodied Interaction' for a (long) explanation of why this might ease your users' task of sense-making.

You should also clearly communicate the risks associated with signing up / exchanging identities on your system if any. It seems from your succinct presentation of your product that there are many aspects that have not been thought out at all.

As the task is daunting, I extremely strongly recommend hiring designers. Specifically, an interaction / service / information experience designer to take care of the presentation of the tool's benefits and limits and the general security interactions; and a graphic or motion designer to work on whatever security visualisations you might end up wanting.

Answer 2

People are trained to ignore text warnings. We've done a very good job of doing that over the past 30 years by providing largely opaque, hard to understand messages that assume the user has knowledge they don't. So nobody reads them because they've largely always provided useless information. No matter how well you construct the text, most people will ignore it to get to what they want to do.

People are much better at learning complex ideas through visualization than through text. Instead of throwing up a message that everyone will just ignore, on both UIs provide a visual representation of how the message is being transmitted unencrypted.

This is the best I can convey the idea in ascii:

client+++client

client++server-----cloud++client

And somehow represent that the path within (server cloud) has the potential for interception by adversaries.

Provide that on both UIs, so each person knows if the other is using a web client where.

I think Steve DL has a really great idea in hiring designers. Designers have a much better idea of how to communicate visual ideas.

The general idea here is that anything transmitted though your servers unencrypted should look at least a little risky. Client-Client communication should look far more safe.

Answer 3

I'm going to make the following assumption here: You're not implementing the end-to-end encryption in the web browser. You're sending cleartext messages to your web server which will then re-encrypt them for the recipient (it will act as a translating proxy).

In this context, you should do the following:

Place a clear warning about the fact that the web client, because of it's open nature, cannot implement end-to-end encryption and therefore shouldn't be used for really sensitive matter.

Send that warning as an easy to identify message to each party every time even one of them uses a web client.

That really should be enough. You might want to link to a web page explaining the possible issues with the web client (MITM, you "turning evil", etc.) for the technically minded but, for most users, they don't really need to know the details: state the issue, what they should be careful of and let them make their decision.

My reasoning is the following:

• For most communication, it simply does not matter.
• For sensitive communication, users have an option to use a more secure system. (note that they still have to trust you unless you also provide a source code version of your client and they have access to the expertise necessary to verify that source code)
• You cannot, yourself, figure out whether a given message is sensitive enough to require the strongest protection: only your users can do that.
• You have already made a tradeoff by allowing the use of a less secure channel.
• People are really bad about choosing when to trust someone and about thinking of the consequences of such choice (it's normal: we're more or less wired to chose usability over security).

So: you've decided that you will allow for two different security level, you know that you cannot decide which one should be use in each individual case.

Therefore, you have no choice: you must rely on the users to make that decision. Since you do not have technically educated users, you should place a warning that is easy to understand where you're sure they will see it. You cannot do anything more than that: people don't read long text, they don't understand complex technical discussions so you need to have a very simple warning with a clear explanation about what should be done (don't use the web client for really sensitive stuff).