@kirby
It's a price to pay for proper encryption that works with multiple sessions🤷
XMPP crowd was making fun of Matrix for this, but that is just how Double Ratchet works — now it got implemented in popular XMPP clients and it turned out that it's even worse than it was in Matrix and before that it "just worked" simply because nothing was encrypted.
@kirby
Leaking presence to the servers of participants of a multi-user room that I'm in is the thing I'm the least concerned about TBH, XMPP doesn't do it because the rooms aren't distributed and only exist on the server they were created on. A lot of people do not seem to understand this: XMPP doesn't have a more secure implementation of the feature — it simply doesn't have this feature at all.
@dcc
@kirby @dcc
And I believe they have even fixed it now, it is possible to prevent interacting with the sessions that you haven't personally authorized, but you have to enable it for each room and for every session of yours individually — far from perfect solution, could've been better, probably this way to prevent breaking compatibility.
@dcc
I get it, a lot of people had a warm and fuzzy feeling about XMPP because they were seeing these key exchange failure messages in Matrix client, but not in XMPP client and that made them assume that XMPP somehow just magically works — now that OMEMO is getting adopted, we can see that it's the same or worse — due to inconsistent client implementations.
@kirby
@romin @dcc @kirby
Yep, valid point! Same as different implementations might have deficiencies of their own — what I meant is that they are based on the same Double Ratchet.
Beside the point, OMEMO spec is pretty vague about multi-user rooms: https://xmpp.org/extensions/xep-0384.html#group-chats it refers to a MUC-related XEP that doesn't mention OMEMO or ratchets at all.
As opposed to megolm spec which is rather thorough: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md
