[Standards] Securely converting a 1:1 chat into a MUC
steve.kille at isode.com
Wed Dec 21 07:03:17 UTC 2016
This is covered in MIX 5.5.3 and 5.5.4, along with MIX invitations. This is succinct, but I believe addresses what is needed.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Sent: 20 December 2016 18:19
> To: standards at xmpp.org
> Subject: [Standards] Securely converting a 1:1 chat into a MUC
> a modern XMPP messenger needs to provide a seamless way to create a
> "privte" group, either by inviting a bunch of folks or by upgrading a
> 1:1 chat into a conference.
> XEP-0045 §7.9 explicitly defines this use case as follows:
> | Now the first person decides to include a third person in the
> | discussion, so she does the following:
> | 1. Creates a new multi-user chatroom
> | 2. Sends history of the one-to-one chat to the room (this is purely
> | discretionary; however, because it might cause information leakage,
> | the client ought to warn the user before doing so)
> | 3. Sends an invitation to the second person and the third person,
> | including a <continue/> element (optionally including a 'thread'
> | attribute).
> Unfortunately, all of these points are flawed, or as an xsf@ regular wrote "a
> bit of a pain to implement sanely".
> #1 omits precise instructions on how to make a non-public invite-only MUC.
> It mentions §10.1.2 "Creating an Instant Room", but there it is only described
> how to send back an empty form; the actual parameters for an "instant
> room" are never defined.
> #2 breaks message attribution in the history (for plain-text messages, and it
> also violates the other user's privacy) and wreaks havoc if any kind of
> encryption is in place.
> #3 is using mediated invitations which can not be securely attributed to the
> initiating user. While a direct invitation (§7.8.1) can be checked for an
> according presence subscription from the sending JID, a mediated invitation
> might contain "the bare JID, full JID, or occupant JID of the inviter", making it
> essentially useless.
> Existing implementations don't speak a common language here, and many
> are susceptible to auto-join-on-invite, leading to exposure of presence or
> other sensitive information.
> I'd like to see a coherent UX and protocol specification for how a client
> should convert a 1:1 chat into a MUC, which kind of messages should be sent
> in this use case and how a client should react to such invitations without
> leaking sensitive information.
> Maybe somebody could write it down here or extend the page at
> Then we could improve the UX of XMPP a bit more.
More information about the Standards