TB, Electrolysis & Quantum

Benjamin Kerensa bkerensa at gmail.com
Wed Dec 28 22:32:33 UTC 2016


I think your understanding of the security enhancement of electrolysis are

Jailing/sandboxing processes adds significant security for the end user.

On Dec 28, 2016 2:12 PM, "Joshua Cranmer 🐧" <pidgeot18 at gmail.com> wrote:

On 12/22/2016 11:56 AM, Disaster Master wrote:

> Hi all,
> First, I was just reading an article on the new multi-process capabilities
> of Firefox vis a vis Electrolysis. Can anyone speak to the relationship of
> Electrolysis to TB? I'm guessing there is none (meaning, TB will never
> benefit from Electrolysis)?

The benefits of multiprocess are greatly oversold--in terms of security,
it's basically the equivalent of setting up a cubicle wall: it will stop a
few half-hearted passive attacks, but any serious code execution attack
pretty much has full access to your machine anyways. Its biggest benefit is
stability, which is to say, letting Flash crash and burn without killing
Firefox--and that portion was implemented all the way back in 3.6 (not
without controversy). If you hadn't noticed, it's taken several years for
the developers to get around to actually shipping out-of-process for web
content (which has been possible in theory since about Firefox 4 or so).

It's hard to see much benefit for multiprocess in TB, especially given that
HTML email tends to avoid features that truly stress the backend.

> Then I encountered an article about Firefox's upcoming replacement for
> Gecko, named Quantum, that, according to David Bryan, Head of Platform
> Engineering at Mozilla, is supposed to "start delivering major improvements
> to users by the end of 2017".
> https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12
> This was very interesting to me since I've never heard of Quantum. I had
> read about what I thought was another new engine being developed by Mozilla
> called Servo some time ago, but it had sounded like it was a long way off,
> and a little googling reveals that Quantum is apparently the official name
> of the new engine which is written (I think) in Rust, and uses the 'high
> performance components of Servo', so I guess 'Servo' is just the 'tech'
> behind it? Also, the expectation of Quantum being implemented *this year*
> is significant news (to me at least) too.
> https://wiki.mozilla.org/Quantum
> This is a little confusing to me, so if I messed any of that up, please
> correct me.

This feels like a layer of marketing blather combined with a pitch for new
contributors that's hiding what's really going on. If you read McCloskey's
blog post, you do get a better sense of what Quantum is. Basically, they're
trying to make rendering more multithreaded. It looks like there's also an
attempt to replace the CSS engine of Gecko (roughly the layout/ folder)
with Servo's CSS engine. This seems somewhat sketchy to me, given that the
Firefox frontend still uses XUL and XBL heavily--although looking at the
bug list, one of the blocking bugs is "implement XBL <stylesheet>". So it
looks like the next-gen replacement of Gecko will end up supporting XUL/XBL
after all. :-P Unclear is plans on how to deal with the XUL box model, XUL
trees, or XUL lists, the latter two having some complex layout/content

It sounds to me like Quantum, while being implemented incrementally, is
> really ultimately deprecating Gecko itself, not just a couple of components
> of it (XUL/XBL).

The key thing to recognize is that incremental changes require maintaining
most of the existing interface. It's certainly possible, if not probable,
that the exact API of, say, the HTML parser may change, breaking our
libmime. But, for the most part, the queries we make (e.g., convert this
DOM tree into an HTML string) aren't the kind of things that you're going
to lose in the API, although we may lose the finesse of some of the knobs,
breaking usually only rare, poorly-documented about:config options. As long
as we're basically using the same surface that the Firefox frontend is,
it's unlikely that any near-term, incremental change is going to break that
surface. For that reason, I'm less concerned that we're using XUL <tree>
than I am about, say, the fact that we're still using <RDF:datasource>.

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

tb-planning mailing list
tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161228/d80ced24/attachment-0001.html>

More information about the tb-planning mailing list