[Standards] XEP-0394: too weak to replace XEP-0071

Jonas Wielicki jonas at wielicki.name
Fri Mar 16 09:18:23 UTC 2018


On Freitag, 16. März 2018 09:56:59 CET Kozlov Konstantin wrote:
> 16.03.2018, 11:31, "Ненахов Андрей" <andrew.nenakhov at redsolution.ru>:
> 
> btw, I'm new here, what were the reasons for deprecating XEP-0071 ?
> It's a new tradition here: deprecate XEP not because it is bad, but because
> there is a lot of bad implementations around. And a lot of bad
> implementations of XHTML-IM just because using XHTML allows lazy developers
> to use existing HTML parsewrs and engines instead of coding their own XHTML
> parser. That sounds at least strangs, but that's the way it goes nowadays
> in XMPP council.

So, believe me that I can understand your frustration. In the discussion last 
october (you’ll find it in the archives there, or see [0]), I was on the "no 
way we’re going to deprecate XHTML-IM in favour of a hack like '393" side, 
too. I have been convinced by the reasons I’m going to repeat, once more, 
below. Please, please refrain from throwing accusations around that people are 
doing things lightheartedly, especially since this whole discussion was dozens 
of mails and weeks long [1]. Also, you’re discrediting hard work and 
investment of time from volunteers here, which I find not so cool. Thank you 
for your consideration.


XHTML-IM is notoriously hard to get right. It includes two massively complex 
languages in the processing flow: CSS (even though only property values) and 
XHTML.

XHTML itself can possibly (I gave up on trying that) be sanitized with some 
XSL rules, aside from issues like phishing based on using different @href 
values than the text suggests.

CSS requires to write a proper LR1 (I think, regular expressions at least 
won’t suffice) parser for the software to understand the properties and 
sanitze them accordingly. Different XHTML rendering engines might have 
different security properties regarding CSS in @style. Apparently, for example 
in Internet Explorer, it was possible to execute Javascript solely with the 
background property. See [2] and [3] for examples.

So unless we want to force clients to implement iframe-like isolation for each 
individual message or very complex sanitization rules, we have to step away 
from what XHTML-IM was. Iframe-like isolation has its own usability issues. 
Sanitization is complex, and will be messed up by clients. Incidentally, for 
the same reason why we’re avoiding markdown and such in <body/>: Because 
putting structured content (like CSS properties) in an unstructured text field 
leads to complexity leads to security issues.


Also, note that it has been repeatedly said that the deprecation of XHTML-IM 
does NOT mean that the use of XHTML is banned in XMPP. Somebody needs to work 
out the security considerations and make a new proposal for the embedding of 
XHTML if they really want that. I for one will play with '394 and see if we 
can make this a decent replacement for 99.99% of the use-cases (where I see 
'393 only as a replacement for 99% of the use-cases).


kind regards,
Jonas


   [0]: https://github.com/xsf/xeps/pull/594#issuecomment-369839060

        I posted this one also to the mailing list, but I’m too lazy to find
        it in the archives. sorry.

   [1]: Really, the discussion felt like months, but in fact I think it was 
        only two weeks in which the whole XSF + community didn’t discuss
        anything *but* the deprecation of XHTML-IM.
   [2]: https://security.stackexchange.com/questions/54055/xss-with-style-attribute-background-image
   [3]: http://www.thespanner.co.uk/2007/11/26/ultimate-xss-css-injection/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180316/7d00bdeb/attachment.sig>


More information about the Standards mailing list