<div dir="auto"><div>Joshua,<div dir="auto"><br></div><div dir="auto">I think your understanding of the security enhancement of electrolysis are incorrect.</div><div dir="auto"><br></div><div dir="auto">Jailing/sandboxing processes adds significant security for the end user.</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 28, 2016 2:12 PM, "Joshua Cranmer ­čÉž" <<a href="mailto:pidgeot18@gmail.com">pidgeot18@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 12/22/2016 11:56 AM, Disaster Master wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
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)?<br>
</blockquote>
<br></div>
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).<br>
<br>
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.<div class="quoted-text"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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".<br>
<br>
<a href="https://medium.com/mozilla-tech/a-quantum-leap-for-the-web-a3b7174b3c12" rel="noreferrer" target="_blank">https://medium.com/mozilla-tec<wbr>h/a-quantum-leap-for-the-web-<wbr>a3b7174b3c12</a><br>
<br>
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.<br>
<br>
<a href="https://wiki.mozilla.org/Quantum" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Quant<wbr>um</a><br>
<br>
This is a little confusing to me, so if I messed any of that up, please correct me.<br>
</blockquote>
<br></div>
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 interactions.<div class="quoted-text"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br></div>
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>.<font color="#888888"><br>
<br>
-- <br>
Joshua Cranmer<br>
Thunderbird and DXR developer<br>
Source code arch├Žologist<br>
<br>
______________________________<wbr>_________________<br>
tb-planning mailing list<br>
<a href="mailto:tb-planning@mozilla.org" target="_blank">tb-planning@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/tb-planning" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/tb-planning</a><br>
</font></blockquote></div><br></div></div></div>