What happened to hiring an architect?
disasterlistmanager at gmail.com
Fri Dec 16 20:49:09 UTC 2016
On 12/16/2016 12:28 PM, Jim <squibblyflabbetydoo at gmail.com> wrote:
> On Fri, Dec 16, 2016 at 10:47 AM, Disaster Master
> <disasterlistmanager at gmail.com <mailto:disasterlistmanager at gmail.com>>
> If the 'browser' 'feature' in TB is removed, and only basic HTML
> email rendering is allowed (lock it down I say), what, exactly,
> are these mysterious risks?
> Generally, use-after-free allowing an attacker to execute arbitrary
> code. This happens more often with JS, but every part of Gecko is
> potentially vulnerable, and unlike websites, email gets *pushed* to
> you, making it more likely that even safe email habits can result in a
> breach. (To be fair, there's a similar problem with ad networks on the
> web, since they're the primary vector for malware when browsing.)
Well, like I said, I was thinking (hoping?) there would be some way to
mitigate these vectors by simply only allowing only a minimal subset of
the HTML rendering capabilities to peek through. Enough to render an
HTML reasonably well (simple bullet lists, tables, font settings, etc),
but block useless and/or potentially harmful things (like JS - who needs
that in an email, really?).
Maybe something like NoScript for TB, but built in, with no way to
disable it, but a well managed whitelist for things that are known to
not be vulnerable/harmful.
I was thinking it should be possible to render simply bullet lists, font
settings, etc, in a reasonably secure fashion, shouldn't it?
I know, more of my blissful ignorance showing here probably...
> About the only saving grace for Postbox (and Thunderbird, really) is
> that there aren't that many users compared to web browsers, so broad
> attacks don't make as much sense.
It helps, but I've never been a fan of security through obscurity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning