[Standards] XEP-0394: too weak to replace XEP-0071
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 ), 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 . 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 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
background property. See  and  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).
I posted this one also to the mailing list, but I’m too lazy to find
it in the archives. sorry.
: 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards