Gecko vs Goanna for Thunderbird Independence
ishikawa at yk.rim.or.jp
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 mozilla.org> 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
> 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
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 mozilla.org
More information about the tb-planning