Gecko vs Goanna for Thunderbird Independence

ISHIKAWA,chiaki ishikawa at
Tue Apr 18 03:29:57 UTC 2017

On 2017/04/17 23:13, Tanstaafl wrote:
> On 4/17/2017, 10:03:13 AM, Gervase Markham <gerv at> wrote:
>> On 13/04/17 23:11, Ben Bucksch wrote:
>>> there were no less than 250 known critical *1 security holes and 600
>>> memory corruption bugs that might be exploitable. One critical security
>>> is already a very serious risk.
>> How many of those are exploitable if JS is switched off?
>> I am not saying the cost of forking is zero but we need to acknowledge
>> that Thunderbird exposes a much-reduced attack surface compared to a web
>> browser.
> I said/suggested something very similar in a prior thread about this.
> 1. Disable full web browsing capability in TB (does anyone really use it
> for web browsing?), and limit the browser functionality/component to
> just rendering HTML emails and internal pages (ie, Help pages, Addons
> pages, etc),

At least on PC with enough screen area, we could even delegate the HTML 
e-mail rendering toan external browser process: then TB does not have to 
grok HTML at all.
(Sure the external browser needs to understand the restriction about
the origin of the HTML source file, etc. Tricky, but the situation is 
much better than trying to handle HTML inside a mailer.)
"TB doe not have to grok HTML at all": of course, if GUI for future TB 
is built using HTML, that would be another story.

I still see a value in the classic "UNIX philosophy" in which sharp but 
narrow scope tools are combined to do something useful for us.

> 2. If a critical vulnerability affecting Gecko is issued, assess its
> impact on TB, and if one exists, determine if it is easier to port the
> fix, or just disable the vulnerable function (and the impact that would
> cause).

Eliminating or throwing away a function is rather difficult in today's 
source hierarchy IMHO.
We need to re-organize the M-C source files anyway if we go in this 

> 3. There may come time that we might have to disable 'Original HTML'
> support completely - ie, only support 'Simple HTML' - although I'm not
> sure how effective that would be at limiting security potential risks.
> In a worst worst case scenario, it could even come to disabling HTML
> rendering completely by default, and issue a big fat warning if the user
> decides to enable it.
> I know these are not ideal or even 'good' solutions, but I'd prefer
> these to just killing TB and walking away.

Rendering HTML mail in an external browser is something I would prefer 
to do instead of carrying all the HTML baggage inside TB.

Sure there would be overhead when we switch to HTML e-mail, but
having the both processes (TB and external browser and maybe a glue 
code) is not such a pig in terms of performance on today's hardware 
platform. (And people can accept the switching to HTML from plain text 
vice versa. Rendering of HTML e-mail INSIDE web browser, etc. is 
something that needs careful tuning, or running down the list of message 
headers is also that needs speed IMHO, but hopefully we can get away 
from HTML there, too.)

> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list