Isn't the core problem here that some clients "do not send the
xhtml-in extension"? Shouldn't the answer be have these other clients
patched to fix their code? To hack around this seems like it will
only encourage others to not follow standards. Why bother including
the proper extensions if the other clients will just deal with it?
Then we risk getting into a race-to-the-bottom where any software
which enforces the standards is seen as inferior (e.g. PDF viewers).
No, the core problem is that the OTR specification itself does not
specify whether the content of a message includes HTML or not and does
not include a mechanism to tell the remote client whether or not the
message includes HTML. Different clients have (legitimately and
entirely within the spec) decided differently here, and until the spec
is corrected, incompatibilities will continue. The OTR spec isn't
great, but it's what we have right now. Not handling HTML in messages
reasonably is non-compliant behavior.
I've heard of serious security vulnerabilities because of content
sniffing was introduced, which is why most browsers don't do it
anymore. IE still does, but I'd argue that is not a good thing.
Hi! I'm a security engineer who's worked in the industry for a decade
-- so you know where this is coming from -- and while yes, content
sniffing has caused vulnerabilities in some cases, it's simply not a
concern here. Jitsi already has to deal with receiving and rendering
HTML in messages from untrusted remote sources. Rendering HTML here
does not increase the system's attack surface. The vulnerabilities that
from places where js was absolutely not expected to be coming, such as
image files. The vulnerabilities it caused were mostly XSS in sites
that allowed image upload. Jitsi should never execute js regardless of
context, so this simply isn't an issue.
Between wanting to encourage that people follow standards and security
concerns (and I could imagine the content sniffing feature scope
creeping to include more risky things), I am against content sniffing.
Standard correctness requires handling HTML in OTR messages.
Content sniffing will not increase the attack surface of the system.
There is no reason to do any other content sniffing that I know of.
thing I'd ask is that there be a way to disable it at run time.
Perhaps some option buried deep in the preferences?
Having a checkbox to disable it seems entirely reasonable; see my
On 2015.09.03 18.30, Adam wrote:
Ideas are my favorite toys.