moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Address security concersn in Converting a 1:1 Conversation to a Channel

Browse Source
This commit is contained in:
Steve Kille 2018-01-02 10:34:45 +00:00
parent 592da7960e
commit c650d1881f
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
xep-0369.xml
View File

@ -50,6 +50,7 @@
Allow servers to limit retract time frame,
Clarify that private messages must not be groupchat,
Creating Channel Clarification,
Address security concerns on Converting a 1:1 Conversation to a Channel,
</p></remark>
</revision> <revision>
@ -2154,7 +2155,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<p>
It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared in the MUC using &xep0297;. A body SHOULD NOT be used in the outer message.
This will generally be done by the user creating the channel before the other user is invited, but MAY be sent by either the user creating the channel or the 1:1 chat partner at any time subsequently.
Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a member of the MUC forwarding a message to the channel and MUST NOT be treated as history sharing.
</p>
<example caption="Forwarding a message to create History" ><![CDATA[
<message from='hag66@shakespeare.example/UUID-a1j/7533'
@ -2173,6 +2174,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</forwarded>
</message>
]]></example>
<p>
There are a number of security considerations with use of MUC history. There may be sensitive information in the 1:1 MUC history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the MUC has potential to inject history messages which were not part of the history. It is recommended that the second user joining the MUC to validate that the messages match the history and to take appropriate action if they do not.
</p>
</section3>
<section3 topic='Destroying a Channel' anchor='usecase-admin-destroy'>
@ -2759,6 +2763,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
MIX provides flexible access control options, which MUST be used in a manner appropriate to the security requirements of MIX users and services.
</p>
<p>
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
</p>
</section1>