4 ms·

Federation would make me almost instantly recommend it for a handful of cases, but in the meantime they have a lot of catching up to do in the privacy departmen

Federation would make me almost instantly recommend it for a handful of cases, but in the meantime they have a lot of catching up to do in the privacy department. Behold, the two five year old tickets requesting that they stop passing notification text to Apple/Google cloud messaging: https://github.com/zulip/zulip/issues/6954 https://github.com/zulip/zulip/issues/6954 https://github.com/zulip/zulip-mobile/issues/1190 https://github.com/zulip/zulip-mobile/issues/1190 For those who don't know: if you have an app and want to send a notification to a user, you use Apple or Google push notification services. In both cases, the notification is plaintext but transmitted via encrypted channel to Apple or Google, then transmitted via encrypted channel to the user's phone. But in each case, the push messaging provider gets to see the messaging text. So companies that give a shit about your privacy send a token instead, that says "hey, wake up, something happened, fetch a notification." Apple likely doesn't do anything with the notification text, but it's a given Google datamines the hell out of it. They also still don't have any form of e2ee. Here's another five year old ticket requesting end to end encrypted chat, where a bunch of people say "here's a long list of apps that support e2ee" and Zulip devs go "gosh golly how do they handle keys? Math is hard." https://github.com/zulip/zulip/issues/6096 https://github.com/zulip/zulip/issues/6096

stavros 4y ago
This is extremely disingenuous. There are tons of usability issues when you have E2EE, to the point where you'd basically have to redesign Zulip and it wouldn't work the same way (e.g. how do you add a colleague to a chat channel and have them see old messages that they don't have keys for?). I'm going to assume good faith in your comment, but I'm really having a hard time doing it, and I'm one of the people who worked for SilentCircle! Another one of those people currently works for Zulip (hey Austin!). TL;DR: It would take a ton of effort and would basically require a pivot of the business model. Yet you present it as if it's some afterthought that can be tacked on, completely ignoring the fact that all none of their competitors (Slack, Teams, etc) support E2EE.
- noizejoy 4y ago
  Since you’ve been in the field, and have thought about it a lot more than me: isn’t privacy inversely proportional to the size of group who’s in on the secret? And that’s not even a technology issue. And therefore demanding E2EE for groupware might seem almost nonsensical, since wide proliferation of access keys makes the whole secret room subject to increasing likelihood of accidental or malicious compromise - ending up more privacy theatre than actual privacy? e.g. if there are 1000 different individual keys to access a conversation, how private is that conversation really?
  - stavros 4y ago
    That makes sense in people terms, but in cryptography terms you treat some people as trusted, and some as untrusted. The goal of E2EE is to keep the two groups entirely separate. However, this does make sense when you consider your attack model. When thousands of people know a secret, maybe forward secrecy isn't worth the trouble, and you can simply have one master key that people share between them (to prevent the server from reading any of the communications). There are tons of issues even then, though. For example, you can't send an email notification to someone and show them the content of the message that mentions them (because you don't know it), plus how do you even know they were mentioned? There are probably hundreds of small issues like that, and the fact that the server knows nothing leads you to push most of the functionality to the clients themselves, which leads to more problems.
    - skjoldr 4y ago
      If I want my messages to stay away from the public Internet, why would I even want to receive message content over unencrypted email? That makes no sense. Receiving notifications while I am not even logged in also makes little sense because I obviously did not consent to them. And having optional E2EE lets you choose which kinds of messages you don't mind leaking.
- skjoldr 4y ago
  Wait a second, Element has had working optional private and group E2EE for a while, why can't Zulip?
e40 4y ago
I wondered why Signal notifications just say "you have a message".
- throwaway92394 4y ago
  That's a setting you can configure. You can also choose whether it shows the sender's name. There's reasons unrelated to this for why you want to not show the message/sender - namely devices like a desktop you might be screensharing from or if you're concerned about someone seeing it over your shoulder. I almost leaked a message just taking a screenshot because I didn't notice the notification immediately so I keep it disabled.
tabbott 4y ago
Howdy and thanks for sharing that these issues are important to you! The push notifications issue is important to me. I'm the one who opened #6954 five years ago, when we were first implementing mobile push notifications, and I've encouraged contributors to pick it up a number of times over the years. I appreciate your bringing attention to this -- it will likely make it easier for me to get folks excited about working on this mostly invisible improvement. https://news.ycombinator.com/item?id=31573940 https://news.ycombinator.com/item?id=31573940 elsewhere in today's thread has a bit more technical context for those who are curious. As a bit of side comment, I think how long ago an issue was opened is not what makes it important. About 250/1650 of our open issues are at least 5 years old, and while some old issues are quite important, many of them are still open precisely because they are not important. So while I agree that #6954 is important, my view is that would still be the case if it had been added to the issue tracker yesterday. I'll post a separate comment about end-to-end encryption of conversations, since that's a complex topic. (I lead the Zulip project)
- 0des 4y ago
  This response says everything I need to know, thanks.
- hardwaresofton 4y ago
  Stealing this moment -- love and appreciate the tireless work Tim. Zulip's a truly amazing piece of software.
doomrobo 4y ago
Woah there at least let's acknowledge that e2ee is a BIG ask and would concretely hurt usability. A secure e2e messenger should pass the "mud puddle test" [0] meaning if you drop your devices in a mud puddle and then slip in said puddle and crack yourself on the head, you should be locked out of all your accounts. Do you want a Zulip where account recovery is impossible by design? Or where conversation history is unavailable to new users [1]? You might say "well let people opt in if they want e2e" but that's not helpful either. If even 1 user in a group is not opted in then the entire group has the same security level. [0] https://blog.cryptographyengineering.com/2012/04/05/icloud-who-holds-key/ https://blog.cryptographyengineering.com/2012/04/05/icloud-w... [1] This must be the case unless you invent a p2p system for users to bring a new user up to date on the group. And even then people could voluntarily lie about past messages. There are neat ways around all this but the point is that this system is very complicated and doesn't currently exist in practice.

stavros 4y ago

This is extremely disingenuous. There are tons of usability issues when you have E2EE, to the point where you'd basically have to redesign Zulip and it wouldn't work the same way (e.g. how do you add a colleague to a chat channel and have them see old messages that they don't have keys for?). I'm going to assume good faith in your comment, but I'm really having a hard time doing it, and I'm one of the people who worked for SilentCircle! Another one of those people currently works for Zulip (hey Austin!). TL;DR: It would take a ton of effort and would basically require a pivot of the business model. Yet you present it as if it's some afterthought that can be tacked on, completely ignoring the fact that all none of their competitors (Slack, Teams, etc) support E2EE.

noizejoy 4y ago
Since you’ve been in the field, and have thought about it a lot more than me: isn’t privacy inversely proportional to the size of group who’s in on the secret? And that’s not even a technology issue. And therefore demanding E2EE for groupware might seem almost nonsensical, since wide proliferation of access keys makes the whole secret room subject to increasing likelihood of accidental or malicious compromise - ending up more privacy theatre than actual privacy? e.g. if there are 1000 different individual keys to access a conversation, how private is that conversation really?
- stavros 4y ago
  That makes sense in people terms, but in cryptography terms you treat some people as trusted, and some as untrusted. The goal of E2EE is to keep the two groups entirely separate. However, this does make sense when you consider your attack model. When thousands of people know a secret, maybe forward secrecy isn't worth the trouble, and you can simply have one master key that people share between them (to prevent the server from reading any of the communications). There are tons of issues even then, though. For example, you can't send an email notification to someone and show them the content of the message that mentions them (because you don't know it), plus how do you even know they were mentioned? There are probably hundreds of small issues like that, and the fact that the server knows nothing leads you to push most of the functionality to the clients themselves, which leads to more problems.
  - skjoldr 4y ago
    If I want my messages to stay away from the public Internet, why would I even want to receive message content over unencrypted email? That makes no sense. Receiving notifications while I am not even logged in also makes little sense because I obviously did not consent to them. And having optional E2EE lets you choose which kinds of messages you don't mind leaking.
skjoldr 4y ago
Wait a second, Element has had working optional private and group E2EE for a while, why can't Zulip?

e40 4y ago

I wondered why Signal notifications just say "you have a message".

throwaway92394 4y ago
That's a setting you can configure. You can also choose whether it shows the sender's name. There's reasons unrelated to this for why you want to not show the message/sender - namely devices like a desktop you might be screensharing from or if you're concerned about someone seeing it over your shoulder. I almost leaked a message just taking a screenshot because I didn't notice the notification immediately so I keep it disabled.

tabbott 4y ago

Howdy and thanks for sharing that these issues are important to you! The push notifications issue is important to me. I'm the one who opened #6954 five years ago, when we were first implementing mobile push notifications, and I've encouraged contributors to pick it up a number of times over the years. I appreciate your bringing attention to this -- it will likely make it easier for me to get folks excited about working on this mostly invisible improvement. https://news.ycombinator.com/item?id=31573940 https://news.ycombinator.com/item?id=31573940 elsewhere in today's thread has a bit more technical context for those who are curious. As a bit of side comment, I think how long ago an issue was opened is not what makes it important. About 250/1650 of our open issues are at least 5 years old, and while some old issues are quite important, many of them are still open precisely because they are not important. So while I agree that #6954 is important, my view is that would still be the case if it had been added to the issue tracker yesterday. I'll post a separate comment about end-to-end encryption of conversations, since that's a complex topic. (I lead the Zulip project)

0des 4y ago
This response says everything I need to know, thanks.
hardwaresofton 4y ago
Stealing this moment -- love and appreciate the tireless work Tim. Zulip's a truly amazing piece of software.

doomrobo 4y ago

Woah there at least let's acknowledge that e2ee is a BIG ask and would concretely hurt usability. A secure e2e messenger should pass the "mud puddle test" [0] meaning if you drop your devices in a mud puddle and then slip in said puddle and crack yourself on the head, you should be locked out of all your accounts. Do you want a Zulip where account recovery is impossible by design? Or where conversation history is unavailable to new users [1]? You might say "well let people opt in if they want e2e" but that's not helpful either. If even 1 user in a group is not opted in then the entire group has the same security level. [0] https://blog.cryptographyengineering.com/2012/04/05/icloud-who-holds-key/ https://blog.cryptographyengineering.com/2012/04/05/icloud-w... [1] This must be the case unless you invent a p2p system for users to bring a new user up to date on the group. And even then people could voluntarily lie about past messages. There are neat ways around all this but the point is that this system is very complicated and doesn't currently exist in practice.