User:Dmose:JS-in-Tb notes

When quickstubbing went into Gecko, this meant that CAPS no longer provided the security that it previously had for neutering JavaScript in Thunderbird messages. Rather than exposing our beta users to undue risk without understanding the consequences, we temporarily turned off JavaScript entirely (see bug 453928 and bug 453943). bug 374577 contains information that might also be relevant, as does the first post in this thread. The remaining posts in that thread are somewhat relevant, but don't bring much to the table that hasn't been covered elsewhere.

In early November, a bunch of folks, some of whom I'm probably forgetting, including Standard8, dveditz, jst, sicking, mrbkap, bienvenu, bz, davida, and me met to figure out what to do. We ultimately came to a number of conclusions:

1. we could live with prefs (mostly defaulted to off) that folks who were tolerant of high degrees of risk could turn on, similar to the way codebase principal support works.
2. support javascript in web-content pointed to by feeds was likely an important use case, and one that we would ideally default to on, because:
   1. more and more blogs are embedding JS-based web widgetry of various sorts
   2. we could display that content in a browser-like context, which is well understood and supported by Gecko for handling JS with appropriate risk-mitigation features
   3. feeds need to be explicitly opted into, which makes their risk profile very slightly safer than sources of arbitrary messages (though very much not risk-free, as philor has pointed out)
3. we should turn off JS/XBL in the compose window entirely
4. we should notice when the user flips any of the prefs to on, and at the very least point them to some web-content describing what risks they were taking
5. we should audit that forwarding messages disables or strips any script

After that, I spent a bunch of time hacking, and came up with the patches in bug 374577, which are reviewed and need a bit more cleanup. There is one patch for mozilla-central, and one for comm-central, but there are really three pieces of functionality:

1. adds code to nsMsgContentPolicy so that docshells loading message URLs turn off JS at the start of the load
2. once the message load is sufficiently far along, a preference is checked to see if JS should be allowed for messages that were "first seen" in a specific context (one of nntp, mail, feed-summary, feed-summarized-page) and, if so, reenabled
3. removes the special-casing of mailnews from nsScriptSecurityManager, since the above two hunks obviate the need for it. Note that unlike before, loads that aren't message URLs now allow JS by default. This is important for extensions that want to integrate with the web in interesting ways (eg displaying web pages in iframes).