[Standards] UPDATED: XEP-0313 (Message Archive Management)
me at thijsalkema.de
Wed Jan 20 18:36:58 UTC 2016
> On 20 jan. 2016, at 19:16, Daniel Gultsch <daniel at gultsch.de> wrote:
> while I see the general need for the added x Element in forwarded muc messages. (I think i brought this up myself once in an earlier thread.) This is missing a 'Security Consideration' that servers must remove the x element if a users sends it. (In case the server is storing the entire stanza and not just the Content of the body element.) Otherwise users can very easily spoof messages as being from a different sender.
> However the main problem is that even if the server removes those elements as a client I still can't trust them because I don't know whether the server has added the element or a malicious user.
> I was always meaning to spark a conversation about server injecting elements into stanzas that don't originate from them. (ejabberd for example is already injecting the stanza-id (which don't get me wrong is a good thing in theory.) The problem is not to sanitize those stanzas on the server side the problem is that i don't know as a client.
> I don't have a good solution to this yet and this should definitely go into a different thread by maybe something about a special attribute for example 'by' that indicates who injected that tag and a general rule to remove all elements that have the attribute by with my entity - or something.
I sent a proposal for that back in June , but that didn't receive a lot of
responses, just Kev noting that namespaced attributes aren't very common in
There are alternatives to using a namespaced attribute, but I fear those won't
be backwards compatible. Unless there are implementations out there that have
major problems working with namespaced attributes, I don't think we should
avoid them just for being rare.
 = http://mail.jabber.org/pipermail/standards/2015-June/029847.html
 = http://mail.jabber.org/pipermail/standards/2015-October/030514.html
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards