JaaS: the Team that Builds Jitsi Can Now Also Run it for You! Start now

The pitfalls of end-to-end encryption

Over the past couple of years we have been experimenting with the notion of end-to-end encryption. While we have put a substantial amount of work into Jitsi’s e2ee support, we have also seen a growing number of misconceptions with regard to what guarantees e2ee does and doesn’t provide. We’d like to start by clearing those out.

In December 2020 Jitsi founder Emil Ivov gave a talk at the WebRTC Kranky Geek event that explained the issue in detail. For those of you interested in the issue, the talk is worth a listen

If you don’t have the time then here is the gist. The end-to-end encryption model refers to solutions where the endpoints in a communication session will encrypt data in a way that would make the data in accessible to the infrastructure that it traverses. In the case of e-mail, for example, Mozilla Thunderbird may use PGP, to make sure that an e-mail service provider, such as GMail, will not be able to access the content of one’s e-mail messages. One of the core presuppositions in this model is that the thing that performs the actual encryption (e.g., Mozilla Thunderbird) is not under the control of the entity that provides the infrastructure (e.g., Google). If this presupposition is not present then end-to-end encryption becomes rather meaningless. In other words, let’s imagine that the GMail JavaScript client was responsible for end-to-end encryption user messages. Since Google is the entity responsible for the development of both the GMail client and the GMail service, then we would be in a situation where Google is responsible for hiding data from Google. Seems like an issue, doesn’t it?

Of course, it is entirely legitimate for a company to provide guarantees that it would never attempt to access user data, but if such guarantees were acceptable then end-to-end encryption wouldn’t be necessary in the first place.

Well, for better or worse, this is the situation that we are in today. In this day and age, most of the popular meeting tools out there have their clients and servers built or distributed by the same entities.

Does this mean e2ee  for modern meetings is useless?

Usefulness is in the eye of the beholder. One could always say that a meeting infrastructure involves a multitude of components and the ones that transport media (in Jitsi’s case this is Jitsi Videobridge), are not the ones responsible for managing e2ee. Let’s say, for example, that an attacker was to compromise a Jitsi Videobridge that is hosting e2ee encrypted meetings, without getting access to the components that serve the meeting client, or the components that participate in negotiating it. Then, even though that attacker may be able to disrupt meetings,  e2ee would prevent them from eavesdropping. If that sort of protection is meaningful to you, then Jitsi’s e2ee support would help.

If however, you are concerned that the entity providing you with Jitsi meetings might eavesdrop on your conversations, then e2ee would not help and you are much better off deploying your own Jitsi instance.

Hope this makes sense,

Love the Jitsi team!