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
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!