Not sure the following is entirely clear or complete,
but I tried to capture the concerns from the meeting
and the ensuing discussion.

Hope it helps.

Arlo



Attentive Otter Plan
====================
 
Goal
----
 
  Add instant-messaging to the Tor browser bundle in order to provide a secure
  communication tool which supports the free flow of information online.
 
Overview
--------
 
  Instantbird [1] is a cross-platform IM client based on Mozilla's XULRunner.
  The following presents the necessary steps to turn Instantbird into the
  future Tor Messenger.
 
A Way Forward
-------------
 
  1. Remove libpurple dependence
 
  This is a trivial amount of work and changes to the build to support it would
  be accepted upstream. They are already considering moving libpurple, and the
  added protocols it supports, to an add-on for reasons of licensing/code
  quality. JS implementations of the following protocols exist: XMPP, Google
  Talk, Facebook, IRC, Twitter, with Yahoo landing soon and AIM/ICQ started but
  further away. 
 
  2. OTR support
 
  Instantbird currently lacks support for OTR. Two pieces are needed here: a
  suitable OTR implementation, and an interface between the client and that
  library (essentially, the role that pidgin-otr plays).
 
  To get started, for the OTR library, a js-ctypes wrapper of libotr should be
  used in conjunction with the message observer API. Code [2] from a few years 
  ago towards this end has been written but probably needs to be dusted off and
  extended. An effort is underway at Mozilla to implement OTR in JS using NSS,
  which could be dropped in as a replacement. A patch has been submitted [3]
  but it looks far from complete, so I wouldn't expect it anytime soon. When
  asked, they said it won't be ready for *a while*. Should the NSS
  implementation fail to materialize entirely, they would still be willing to take the
  ctypes wrapper and libotr, as it doesn't present any licensing issues. In his
  analysis, Mike suggested converting the ctypes wrapper to an XPCOM
  wrapper but it's unclear why that's preferable.

  The front-end side seems like a larger undertaking. This involves not only
  the interaction with the message observer API but handling the quirks in the
  various protocols (think /me in IRC), authentication including SMP, and
  importing and storing long-term keys. Sukhe estimated at least a month of
  development time and expressed an interest in being the one to undertake it.
 
  On the bright side, the Instantbird team seems eager for OTR support and this 
  work will most likely be upstreamed.
 
  3. Disable logging
 
  An add-on may be required to ensure certain desirable configurations, like
  logging disable by default. A difference in goals between UX for the
  average user and the TIMBB user may force us to maintain these changes.
 
  4. Tor controller
 
  Tor Launcher will be used as the controller. Sukhe has already reported
  having this working.
  
  Using only JS protocol implementations means all traffic goes through
  nsIChannels, making proxy support fairly easy to verify. For DNS,
  network.proxy.socks_remote_dns should be set. DNS SRV should not be an issue
  seeing as how it isn't supported by Mozilla [4]. Should test for other
  UDP traffic leaks.
 
  5. Messaging window
 
  Jail it to type=content. Preferably everything is displayed in plaintext,
  with HTML disabled or at least sanitized with an XSS filter [5]. Disable JS
  and other features. Make use of all the preferences from TorBirdy.
 
  6. Installer and updates
 
  Leverage the work that's already being done on Mozilla's updater for the TBB.
 
  7. Deterministic builds
 
  Deterministic builds for the TBB was a major undertaking. I can't imagine
  this case being any different, less the experience and groundwork already
  laid.
 
  8. Sandboxing
 
  Come up with a practical, cross-platform way to sandbox the application.
  I don't have an answer here. Maybe you do.
 
  9. Audit
 
  - Instantbird's render attack surface (content window, XSS filter, etc.)
  - Crypto in NSS and how JS uses it
  - Interface between the UI and OTR
  - Proxy by-pass
  - And more ...
 
  10. Translations
 
  Instantbird is available in 14 languages, including French and Spanish.
  However, none are RTL and we want to support Arabic and Farsi. Messaging
  should already work for RTL languagues though, they've fixed a few bugs
  to ensure it, and reflecting the UI is reported to not be a ton of work.
  They are definitely willing to accept patches here.
 
  11. Other considerations
 
  - Disable Instantbird's built-in auto-updater and crash reporter
  - For sure OTR on by default, but maybe disallow any non-OTR comm. entirely
  - CA verification: TOFU mode? Pin popular domains?
  - Disable older TLS/SSL suites
  - Consider the interaction between all three Tor bundles (FF, TB, IM). Tor
    Launcher could attempt to authenticate and read settings from an already
    running control port.
  - Choose a different default profile folder (to avoid picking up plugins
    and other unsafe settings)
 
References
----------
 
[1] http://instantbird.com/
[2] https://gitorious.org/fireotr/fireotr
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c20
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=14328
[5] https://mxr.mozilla.org/comm-beta/source/chat/modules/imContentSink.jsm