Secure messaging window

Investigate Instantbird's whitelisting of HTML content and the related security issues that may arise out of this.

added component::archived/tor messenger priority::medium resolution::wontfix severity::normal status::closed type::task labels

Trac:
Cc: N/A to gk

Trac:
Parent: N/A to #14161 (closed)
Keywords: N/A deleted, TorMessengerPublic added

Trac:
Status: new to assigned
Owner: N/A to sukhbir

Messaging window is jailed to type=content and is additionally XSS filtered immediately prior to display.

We've further removed anchor tags from strict mode to resolve the ambiguity in #13618 (closed).

From gk's audit,

I looked at imContentSink.jsm/convbrowser.xml and studied the Instantbird audit done by Mozilla. Almost all issues mentioned in the audit got fixed; one is left which does not seem to bring a high-risk with it especially, as Tor Messenger is configured to use the least permissive rendering mode (which is further hardened)

ToDo:

• look closer at cleanupNode() and change history
• look at DOMParser mainly for making sure that no script etc. execution is happening prior to sanitization
• look closely at usage of TXTToHTML converter (used in convbrowser.xml, xmpp.js, xmpp-xml.jsm, ircUtils.jsm and imThemes.jsm)
• relevant bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=787984
• https://bugzilla.mozilla.org/show_bug.cgi?id=727216

Trac:
Parent: #14161 (closed) to N/A

Trac:
Keywords: SponsorO deleted, N/A added

Trac:
Keywords: TorMessengerPublic deleted, N/A added

Mike seems to be saying some things here, https://www.youtube.com/watch?v=DqBFez4v_2I&t=2114

Trac:
Cc: gk to gk, mikeperry
Sponsor: N/A to N/A
Severity: N/A to Normal

Oh, my comments there simply were that it would be strictly better if we knew the message content window had scripts disabled fully, rather than (or actually, in addition to) being XSS filtered.

I know there was some contention with the instantbird team over this, as they felt this would negatively impact UI, so my thought was that we could have a security slider here, too. So for example, look at all of the stuff that Coy.im disables: https://coy.im/about/. Rather than killing all of that up-front (which will negatively impact UX), it could be progressively disabled as security level is increased.

Thanks for clarifying (actually, I think you were being pretty clear to begin with, I'm just of the confused type).

A security slider seems apt. In #17480 (closed), Tails is asking for a less restrictive (linkified) content window. (Though maybe Tails, and the rest of the security conscious folks, have move on to CoyIM as it is ...)

Trac:
Reviewer: N/A to N/A
Owner: sukhbir to N/A

Trac:
Status: assigned to new

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

sad but true: https://blog.torproject.org/sunsetting-tor-messenger

luckily there are alternatives: https://blog.torproject.org/tor-heart-onion-messaging

.. and maybe someday

• https://cwtch.im (#27364)
• https://github.com/warner/magic-wormhole/issues/8

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed