Now I guess you could set up some kind of broker system and have like a different encryption key per channel or per conversation or something, which would at least mean some hacker has to get both the archived chats as well as the keys. This would make stealing chat histories more complicated, but not less possible.
Now with iMessage in iCloud, I do not know how the E2E encryption is done.
It isn't done. Apple holds the master keys. The trust is that the iCloud server is not compromised.
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
https://pxlnv.com/linklog/improving-imessage-encryption/
> During an interview with Apple blogger and Daring Fireball’s owner John Gruber, Federighi said that the company has figured out a way to do syncing while still remaining unable to read your iMessages.
We're still at a point in time where 99% of communities are ready to make exactly 0 compromise for privacy over usability. Slack is catering to the 99%.
If one definition includes "the server(s)" then I'm positive it does at least on their Enterprise product, which notably last time I looked was the only one that could be considered HIPAA-compliant, aka "no your two - site medical practice can't use Slack to chat between the sites and coordinate anything involving patients."
I guess there's also the problem of how to let a new joiner view previous messages. Can that be done with e2e encryption?
512 GB
> How about on your phone?
256 GB
> I guess there's also the problem of how to let a new joiner view previous messages. Can that be done with e2e encryption?
Of course. Share the key with a new joiner. Probably should be an option for admin, whether he wants to share (share the key) or does not want to share (generate new key and use it since that moment, old clients still remember old keys and can decrypt things).
Granted, I don't know much about encryption, end-to-end messaging, or otherwise, but it seems like a Very Hard Problem to solve for something like Slack.
Yes, shared among participants.
> it seems like a Very Hard Problem to solve for something like Slack.
There are plenty of messengers with E2E encryption and group chats with working search. Sure, it's not a straightforward task and server-side handling of search and other functions makes everything much easier, but I don't think that it's impossible task.
Though I'm not sure if demand is big enough. I would think that just self-hosting slack would be preferable for many organizations.
Honest question - how does this work across thousands of employees, some of which are almost guaranteed to be bad-actors at one point? Or is that just not a problem that's trying to be solved? What are the impacts if someone leaks that?
> There are plenty of messengers with E2E encryption and group chats with working search.
I don't know - are they on the (user) scale of Slack? How many people can you add to a group in WhatsApp or iMessage? (I honestly don't know, but I would suspect Slack lets you have more people in a 'group' than them).
Again, I have only a very cursory knowledge of how iMessage does E2E encryption. Obviously Slack would need to choose a different approach, but I wouldn't look at other messaging apps for examples.
- https://github.com/matrix-org/matrix-search
- https://github.com/vector-im/riot-web/issues/2548