Any tldr? I have a very hard time getting through this, but as the founder of a Europe-based messaging company (https://talkjs.com), I wonder whether this is trouble.
En-to-end encryption is great but it also kills quite a number of use cases. For example, our group conversations couldn't be e2e encrypted because then users can't see the message history from before they joined it. In whatsapp this is indeed the case, but for our platform it is a core feature. Same for Slack, I suppose. Similarly, Slack search would be totally out of the door. (unless, again, you make it only search the stuff sent to you)
"The providers of electronic
communications services shall ensure that
there is sufficient protection in place
against unauthorised access or alterations
to the electronic communications data,
and that the confidentiality and safety of
the transmission are also guaranteed by
the nature of the means of transmission
used or by state-of-the-art end-to-end
encryption of the electronic
communications data. Furthermore, when
encryption of electronic communications
data is used, decryption, reverse
engineering or monitoring of such
communications shall be prohibited.
Member States shall not impose any
obligations on electronic communications
service providers that would result in the
weakening of the security and encryption
of their networks and services"
I interpret this as the following clauses:
* "sufficient protection in place against unauthorised access or alterations" [through]
* "guaranteed by the nature of the means of transmission used "
* "OR"
* "state-of-the-art end-to-end encryption of the electronic communications data"
I think ubiquitous end-to-end encryption is the inevitable future of 1:1 and group communication. The momentum is in that direction. In your case, supporting the browser as a platform rules it out right now, but hopefully that will change when browsers provide an environment for doing serious crypto, where the server can't just quietly push down some new JS that leaks messages back to itself.
I'm in the alpha stage of building an end-to-end encrypted social network (https://sharewithsup.com, invite code: eff, currently iPhone only). Under the hood, it establishes E2E group channels between friends and uses those for everything (posts, comments, photos, events, etc). History is relayed between friends and search uses a local index, but the UX is still similar to Facebook. My point is - in addition to namedropping my app - that it's possible to find ways to implement features that at first seem hard with E2E. Just not on the web, yet.
Couldn't group chats be encrypted with a shared key that is provided to the new user by whoever invites them to the chat? The messages would still be encrypted and decrypted only at the ends.
What about removing a user from chat? What if the shared key is leaked? How do you deliver the key to the new user? Who provisions new keys if a shared key is leaked? There are a variety of problems (all solvable/already solved, yes) with the shared secret strategy, and addressing them costs money and time.
So? There does not need to be a way to get rich quick. I don't see a problem with forcing chat providers to include proper end to end encryption as a matter of consumer protection. Because we all know that otherwise, security will not be part of the minimum viable product, and the consumer can't tell the difference.
(Obviously, the state of the art answer to your technical questions is the double ratchet algorithm.)
En-to-end encryption is great but it also kills quite a number of use cases. For example, our group conversations couldn't be e2e encrypted because then users can't see the message history from before they joined it. In whatsapp this is indeed the case, but for our platform it is a core feature. Same for Slack, I suppose. Similarly, Slack search would be totally out of the door. (unless, again, you make it only search the stuff sent to you)