Multi-process, or: the drawbacks nobody ever talks about.

[Moonchild]

Apologies in advance if this goes over anyone's head. It's very technical, although I'll try to make it as understandable as possible for everyone.

I want to write a little bit about multi-process browsers, and specifically highlighting some of the drawbacks with it that nobody who promotes these things ever wants to talk about. Why? Because I'm tired of having the same discussions with people again and again about this, and why I'm against multi-process browsers.

First things first: any more complex program will use a technique called "multi-threading"; this is an integral part of any OO or class-based program which allows many computing tasks to safely run in parallel. These threads within a program can run on single or multiple CPUs, depending on how things are designed and compiled (so don't confuse "CPU threads" with "program threads", please).
To make all this run smooth and without issues, any threads that are relying on asynchronicity will be using so-called "mutexes" that lock data objects so they can't be modified, released from memory, or have other disastrous actions performed on them while a procedure is run on them.

So, there's a solid, and reliable framework to use here that allows efficient processing of multiple tasks simultaneously, all within a single process.

Now, enter the realm of multi-process browsing, which for the sake of not having to type as much, I'll also refer to by Mozilla's term "electrolysis", abbreviated to e10s.
When you use e10s, of course there are some great advantages that I'm sure everyone is already sick of hearing, like the potential for more graceful recovery from crashes or keeping the UI more responsive regardless of what terrible blob of JavaScript is run on a website. So, I'm not going to talk about that, as you'll be able to find many articles praising it into heaven on the net already. No, what I want to talk about is how this, in practice, actually works, and why it is in many respects slower, more dangerous to use, and a lot more resource intensive than using a single multi-threaded process.

Inter-process communication

To make anything possible in a multi-process browser, you need what is called inter-process communication (IPC), a method to get program instructions from one process to another through a messaging system. For example, if you press the "reload" button in an e10s browser, you are interacting with the "main process" (that runs the user interface). This click will have to be converted to a message, that has to be sent to the web content process. When the web content process receives this message, it will perform the reload of the page, sending status messages back to the main process as the page is loading; first to confirm that the command was received, then more as the status of page loads changes. Because it is a messaging system, everything, without exception, has to be done asynchronously -- this means processes end up waiting for other processes most of the time. Multi-tasking operating systems tend to be rather efficient in this type of communication, but even milliseconds quickly add up if you're dealing with thousands of messages being sent back and forth, causing a noticeable sluggishness to the browser that can even be more pronounced than any delay you experience from downloading assets of web pages from the net.

Process restrictions and IPC

One of the advantages touted for multi-process browsing is that it is "more secure" because web content processes (that load potentially dangerous content) can run with restricted rights. This restriction also inherently causes the need for a lot of data to be passed through IPC to the main process. After all: if you want to cache web content, which is an integral part of any browser, you can't do that from a restricted content process that doesn't have rights to write to the file system. Any data that has to be cached by the browser will have to be downloaded by the content process, packaged as a payload in a message, sent asynchronously to the main process, which can then cache this content. Similarly, just loading a page will involve the content process checking with the main process if what is being downloaded is in the cache or not, generating many more messages to be sent back and forth for each asset in the web pages. As you can see some of the very basic features of a web browser become very complex with an enormous amount of overhead.

As for the security of a single-process browser: although it's potentially simpler to just off-load security restrictions to the operating system, properly-designed single-process browsers are just as secure, if not more so (because they actively keep tabs on restrictions instead of passively letting someone else handle it). Separating browser content from the application code of a browser is an essential mechanism that all browsers (and any document viewer, really) use. In Mozilla-land, it's a little more complicated because both content and the application use the same technologies, and more of this active separation is needed to not have web page scripting access UI scripts. Even so, properly designed content containers and so-called x-ray vision (read more about that here) are an effective method to keep things neatly separated.

Off-loading security to others also means you have no control over it. If there's a vulnerability in IPC's communication or operating system sandboxing, then there's nothing you can do about it and you'll have to rely on the O.S. vendors to fix it before the vulnerability is mitigated.

Web standards and multi-process aren't always compatible

It doesn't end there, though. By design, a good number of web standards are synchronous. This isn't a problem when dealing with single-process applications, because the application has full control over the sequence of steps performed to achieve a synchronous task. Because everything in e10s must, by design, be asynchronous, this causes problems. Take setting cookies for example as a very basic process every single browser has; this is such a significant problem that web standards even make special mention of it:

The cookie attribute's getter and setter synchronously access shared state. Since there is no locking mechanism, other browsing contexts in a multiprocess user agent can modify cookies while scripts are running. A site could, for instance, try to read a cookie, increment its value, then write it back out, using the new value of the cookie as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.

This example is only a problem in multi-process, because 2 content processes can easily read the same state,and then write the same changed state back to the shared cookie storage in the main process. In a single-process browser this isn't a problem, because getting and setting cookies is synchronous (one task, one result).
In other words, many parts of web standards don't specify mutexes or locking mechanisms because they would not be needed if the browser itself wouldn't be forced to use asynchronous calls for everything (even things that are, by design, of a synchronous nature).

Resource usage

Of course there is the additional issue of resource usage: for every browser process in use, another copy of the parsing, layout and rendering engine has to be loaded and used, or web content processed would not be able to display their pages. This will quickly inflate the number of graphics resources, memory and processing used to load the same content in an e10s browser compared to a single-process browser. There may even be contention between processes for the same resources in the case of heavy use, e.g. video memory.

---

I may add more to this later, but these are the main concerns I keep having to explain to people.

[Thehandyman1957]

Thank you for this explanation of how multi-process works.
Your explanation of the IPC is especially Intriguing.

I understand the lock down and the need for some intermediate immunized communication separating the main process from the other processes
and it seems like a very messy and cumbersome way to do things.

This reminds me of someone who originally could just take what was given to him and make decisions on the fly, knowing what was good and bad
and keeping things organized. To having to call central command for every single thing he see's and does and having to wait inline for everybody
else communicating to central command while changes take place in front of him in real time that makes him have to again alter what he would have sent
to central command and again wait inline.

Or, it's like living in real time but having all decisions getting decided by someone else you can only communicate with by phone that places you on a numbered hold
for every single question while things keep changing in front of you.

I looked up the word asynchronous as I did not fully understand the difference.

adjective
1.
not occurring at the same time.
2.
(of a computer or other electrical machine) having each operation started only after the preceding operation is completed.
3.
Computers, Telecommunications. of or relating to operation without the use of fixed time intervals (opposed to synchronous ).

So anyway, hopefully I didn't butcher your explanation too much but it really did help me understand a whole lot better.
I have followed most of the threads that talked about this but never really understood it that well.

[Moonchild]

Asynchronicity in computer programming is the occurrence of events independently of the main program flow and ways to deal with such events.
Synchronous events are so-called "blocking", in that the data they access cannot be used by other processes. A simple Function call -> processing of data -> return.
Asynchronous events are "non-blocking" meaning the main event loop of the program can continue ("things changing in front of you") while the called function does its thing. This immediately causes some dangerous pitfalls of data changing while things are processed. One side you already indicated and you're correct: By the time the function call returns its result, what is coming back may no longer be relevant for the main loop, and the result has to be discarded in favor of a new request (which may have already been launched). The other side is that the main loop may manipulate, or worse, remove the data that the called function is supposed to process, while it's being processed.

Then there's the issue of things that are synchronous by design (need to be performed in sequence, e.g. because the next process needs the result of the one before it) but if that needs to be handed off asynchronously then you'll get delays:
Start -> process A -> process B -> process C -> done
becomes
Start -> request A -> wait for completion -> receive & process result -> request B -> wait for completion -> receive & process result ->request C -> wait for completion -> receive & process result -> done
In a browser, there's plenty of these kinds of processes going on; both internally and on the websites visited.

[Thehandyman1957]

Ok, so what kind of things can happen when the main loop manipulates or removes data that the called function is supposed to process?

In a browser, there's plenty of these kinds of processes going on; both internally and on the websites visited.

I'm assuming all browsers do this correct?

So the main issue with E10's is what you mention above correct?

[Moonchild]

I've sent you a PM to try and explain a few of the dangers of asynchronous processing.

The main issue with e10s isn't a single thing; it's why I wrote my initial post touching on a few of the more obvious downsides. It's not limited to that, though.

[GrayFace]

As for the security of a single-process browser: although it's potentially simpler to just off-load security restrictions to the operating system, properly-designed single-process browsers are just as secure, if not more so (because they actively keep tabs on restrictions instead of passively letting someone else handle it).

This is incorrect. Only process restrictions (low integrity mode) provide a layer of protection against vulnerabilities like buffer overflows - instead of just finding a buffer overflow or similar vulnerability the attacker would also have to find a vulnerability in process communication or other way to break out of Low Integrity mode in order to infect the system.
That's not to say added IPC doesn't add new places for potential vulnerability.

Off-loading security to others also means you have no control over it.

No-one is forced to remove program-level security measures when going multi-process.

When it comes to FireFox, changes related to e10s are probably to blame for FF 49+ being very slow (with all my extensions, of course) even if e10s is disabled.

[Moonchild]

Only process restrictions (low integrity mode) provide a layer of protection against vulnerabilities like buffer overflows - instead of just finding a buffer overflow or similar vulnerability the attacker would also have to find a vulnerability in process communication or other way to break out of Low Integrity mode in order to infect the system.
That's not to say added IPC doesn't add new places for potential vulnerability.

I'm sorry but it's not that simple. Just because a process runs in low integrity mode doesn't mean that you're magically protected against buffer overflow scenarios. Also, buffer overflows are a lot harder to exploit, than, say, use-after-free, which is a much larger danger with asynchronous processing that gets introduced everywhere in multi-process browsing; UAF can also easily pass through the inter-process communication layer by exploiting a UAF scenario in the "master" process, and then your restricted process does absolutely 0. That's not even thinking about IPC components themselves which have bugs.

The additional danger I'm indicating is that, by passing security handling off to a process container, assumptions are made that certain types of vulnerabilities no longer occur; safeguards are regularly removed because they are either deemed unnecessary or because they would interfere with IPC, or because they would not work in async. Exploiting them may become less than trivial, but not impossible. Trivial exploits are also not something we see these days anymore because most programs have extensive code review and analysis to catch the blatant mistakes, so you can't really use that as a criterion. If e10s was a magic wand to protect from any and all sec vulnerabilities imposed by content, then why has there been a significant increase in sec bugs lately? You'd have expected that to drop sharply if the security benefits are as solid as you seem to think.

Let's just say that with my access to the various sec bugs as e10s developed, I've seen my share of bugs that would never occur in single-process mode, and in general have a higher severity.

[bawldiggle]

So frustrating.

While I don't appreciate the intricacies I definitely understand the dynamics of the e10 problems

I used to write addins (in dreaded VBA) for AutoCad (for fun and profit) ... then MS dumped VBA (still available Office 2010)
Also spent 2 years writing an addin for Excel with 64 features, (pre-ribbon) ... I just couldn't face a rewrite (2,560 items that held it all together).
Add to that ... Excel 2003 was sooo unstable.
I wrote another addin that rewrote bloated addins as fresh files with a bloat reduction of up to 40%, then MS pulled the plug on VBA

Yes VBA is/was a monster ... I fully understand your frustration

Thank you for exposing your frustration with those of us who are interested in the topic and care about your well being