The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to do anything at all. I don't know any other projects that do what NaCl does, so regardless of whether Google should switch to pure NaCl for sandboxing, if they did, it would be innovation, not scrapping an antiquated technology.
As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.
The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.
In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.
> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is.
That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day.
Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.
> I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here.
It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team.
I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is.
A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app.
One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
It would be pretty ironic if Apple were actually annoyed that Chrome was developed in secret considering they forked KHTML and developed it into Safari & WebKit in secret in essentially the same way.
Firefox uses a sandbox process for plugins like Flash. Mozilla implemented per-tab processes, a project called Electrolysis, but it would break many popular add-ons. Firefox OS is able to use process isolation, through, because it doesn't need to support legacy add-ons.
Really? I haven't heard a single thing about Electrolysis in a long time, except I remember reading somewhere recently that it was abandoned. I'm happy to hear that Firefox OS is using it; still, keeping legacy add-ons working seems like a bad reason to stop pursuing such an important security feature on the desktop.
I was employed at Mozilla when the pronouncement to "suspend" work on Electrolysis came from on high.
I think addons are a small part of the picture.
The big deal is there are only so many Firefox developers, and Electrolysis was turning into a real sinkhole of time with no end in sight. There were a lot better ways to make Firefox a better browser in the meantime, and those things are being done.
Firefox on Android used to use Electrolysis until it switched to the current Java front-end. And FirefoxOS is using it for sure: process per app, so that apps can be easily killed in low-memory conditions.
As for "legacy add-ons", that would be "every single add-on". Not to mention that the desktop Firefox UI itself would have to be heavily rewritten as well. The judgement, as mcpherinm says, was that the cost was too high for the possible gains. I agree that process isolation is good for security, but there are various other security mitigation strategies that can be used that had a higher bang for the buck at the time.
Yup, I think some people don't realize why processes exist and what they're here for. It just looks like a concept that we've been using for a long time so, "it must be too old and be replaced", without understanding _how_ it works and _why_ it's there.
There's no way that "resource-intensive and unpredictably timed context switches" account for 100-200ms on modern hardware. With modern multi-core/cpu boxes I think a typical time for a context switch is on the order of 10 microseconds, and that doesn't take into account in things like CPU affinity. (It's still going to depend on a lot on OS and hardware. For example: new i7 vs old core architecture)
If there's actually high costs, it shouldn't be due to a "antiquated" multi-process architecture, but other things like marshalling data to and from the JS engine.
I don't know about these claims — just because most OS research is now 20+ years old doesn't mean that a result, process isolation, is antiquated. You likely use a very modern operating system with process time-sharing (1964) using virtual memory (1950s/1960s) and so many other results of OS research from 30+ years ago…
This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.
As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.