On Freitag, 16. März 2018 09:56:59 CET Kozlov Konstantin wrote: > 16.03.2018, 11:31, "Ненахов Андрей" <[email protected]>: > > 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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
