Hacker News new | past | comments | ask | show | jobs | submit login

Neat! But no e2e encryption, so I'm going to have to stick with Matrix. Interested to see how this project progresses, though. Looks great, and active.



So, philosophically, as a former MIT cryptography grad student who spent a lot of time in Ron Rivest's office, I'm unwilling to offer a cryptographic guarantee like "E2E encryption" if it doesn't actually provide the security guarantees that any reasonable user would expect when they heard that phrase.

Zulip encrypts all content in transit using HTTPS, which protects against a pretty wide of potential attacks to the privacy of one's messages. We put a lot of effort into ensuring messages aren't sent to the wrong users (one surface-level detail here is that our backend codebase has ~97% test coverage; which becomes 100% for views, validation, and other security-sensitive code).

The big thing that these techniques don't protect against which E2E encryption is supposed to solve is a malicious/compromised server accessing message content. But I'm also not convinced there is a viable solution supporting desktop+web+mobile+terminal apps that can prevent a malicious/compromised server from getting access to message content.

Just to highlight one of the issues, if you're using a webapp, the server itself is what tells your browser what code to run. So, if the webapp can display decrypted message content in a browser, a hacked server can just deliver JS code that causes the browser to fetch every single message of history your browser client has access to and send them back to the server unencrypted. I've thought at times about whether a trusted browser extension could help, but I don't think it can. I imagine the various "E2E encrypted" apps address this issue by just not offering a webapp.

Even if one were willing to abandon having a webapp for this feature, the really hard problem with doing E2E encryption is key storage and distribution. What process do you need to use to move your secret key between different devices safely (or do you just lose access to your history when your phone dies)? How do new users who get added to a stream get the secret key for that stream? Maybe there's a Keybase integration that would solve this (I actually have exchanged a few emails with the Keybase team about this concept).


> Just to highlight one of the issues, if you're using a webapp, the server itself is what tells your browser what code to run. So, if the webapp can display decrypted message content in a browser, a hacked server can just deliver JS code that causes the browser to fetch every single message of history your browser client has access to and send them back to the server unencrypted.

If a native app is compromised, you are screwed all the same. I don't see how the delivery channel makes a difference -- the server serving the web client doesn't necessarily have to be the same one that's relaying the messages...


Well, theoretically, you could use a signed version of a native app from a distributor you trust (or build it yourself after inspecting the code, or whatever).


e2e encryption is an anti-feature for many. In places where an internal team chat is needed (i.e. companies), the ability to log and audit conversations is a requirement. I agree it might be nice if it was optional, as long as it can be disallowed globally by a server-side setting.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: