← Back to context

Comment by tabbott

16 days ago

Most consumers don't know the difference between "encryption" and "end-to-end encryption".

Zulip uses standard TLS encryption, where the messages are encrypted in transit, but the server has access to the messages.

The server having access to the messages is extremely useful for many key features. Access control policies. Search. Markdown rendering that can make guarantees to clients about its behavior. Mobile notifications for mentions. And many more. There's options for all of these problems, but it's /hard/ and you end up having a lot of risk of nasty bugs where "all the message history become unreadable" and a lot of performance issues.

This is why why end-to-end encrypted messenger apps like Signal are extremely minimal with basically no chat features, and can take a while to load long conversations ... there's a lot of expensive cryptography happening in the background. AFAIK it's not realistic to use the Signal protocol with the volume of messages people do in high-traffic Discord or Zulip communities.

Some other E2EE chat systems have more features but fail to actually provide end-to-end security. (For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read, or the server is still in charge of metadata like channel membership ... so a malicious server could just add a fake user to every channel).

You get almost all of the security benefits of these "E2EE" chat systems by having a trusted person self-host the server, and setting a message retention policy if you want messages in certain channels to be automatically be deleted after a period of time.

Our vision for Zulip is not billions of people on our Cloud service. People should own their own communities, not corporations. And in that world, usually the person who runs the community can be trusted to host it.

> where the messages are encrypted in transit, but the server has access to the messages.

So the easiest and most useless kind. There were 1000s succesful db leaks for 1 successful mitm. Last time I heard of one, I did it myself on WEP. Https everywhere trend is super annoying for me because all it does for me is make my life difficult when I want to save time and transfer by setting up local caching proxy for myself.

> the volume of messages people do in high-traffic Discord or Zulip communities.

Why do people recieve volume of messages that's too expensive for their device to decipher? Are they gonna read them all?

Decryption should happen as needed. Before render. Before building local search index.

And what's up with notifications? Can't background process of my local app notify me?

> metadata like channel membership ... so a malicious server could just add a fake user to every channel

If you post to a channel anyone can join it's by definition public message regardless of any encryption. So no encryption needed.

> For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read.

We should have an abstraction that is a socket that encrypts outgoing packets with my private key and deceypts incoming with provided public key.

Such chat apps should have only the right to use such sockets but not general ones.