Servo: Embeddable Browser Engine
blogs.s-osg.org
blogs.s-osg.org
1 - https://github.com/servo/servo/blob/master/ports/cef/core.rs...
It's hard to say about single-process mode; it'll stay maintained as long as someone's willing to do the maintenance. There isn't anything that's inherently multiprocess about the architecture (for example, there are basically no global variables anywhere in Servo), in any case, so I don't imagine it'll be hard to keep it running. I don't want to make any promises, though.
In the Chromium Multi-process Architecture design document[0] the benefits boil down to security and stability. While memory safety doesn't guarantee secure logic, it obviates a large class of bugs that a multi-process architecture is designed to counteract. While memory safety doesn't prevent deadlocks, it does completely prevent data race conditions.
[0]: https://www.chromium.org/developers/design-documents/multi-p...
Remember that the goal of Servo is not just to be as safe as modern engines, but to be far safer (while also being twice as fast!).
A worthy goal! However, I'm still concerned. If the project is sufficiently secure without multi-process, adding layers only increases the surface area for attack vectors. Sandboxing not only increases the surface area of your (now) multiple processes, but also introduces the OS layer as an arbiter of communication between them, which we can safely assume does not have memory safety guarantees (though is probably quite hardened).
Of course, the developers would not claim that Servo is "sufficiently secure" right now, especially since (as brson mentioned) it still includes C & C++ source. My point is, sandboxing can be a huge win in terms of security, especially for now; but any complex feature has tradeoffs and the efficacy of those tradeoffs may not continue to hold through the future and should remain open to consideration.
I also don't understand "If the project is sufficiently secure without multi-process, adding layers only increases the surface area". The point of layers is that each one needs to be breached in order to craft a full exploit. If one layer is sufficiently secure without multi-process then in the worst case your defense-in-depth is merely redundant, regardless of the attack surface of the remaining layers (though obviously "sufficiently secure" is fairly impossible to prove).
Windows support is still a while away. You can help out[1], though!
Update: There is paper[1] describing layout parallelization with 80x performance increases. However, I'm not sure it works on constraint-based layouts, such as GSS[2].
[1] https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper....
> Ras Bodik’s group at the University of California Berkeley worked on a parallel browsing project (funded in part by Mozilla Research) that focused on improving the parallelism of layout. Instead of our approach to parallel layout, which focuses on multiple parallel tree traversals, they modeled a subset of CSS using attribute grammars. They showed significant speedups with their system over a reimplementation of Safari’s algorithms, but we have not used this approach due to questions of whether it is possible to use attribute grammars to both accurately model the web as it is implemented today and to support new features as they are added. Servo uses a very similar CSS selector matching algorithm to theirs.
EDIT: for those wanting context, WebKit started its life as fork of the KDE project's KHTML, and has gone on to supplant it. Having KDE ditch WebKit for Servo (no doubt with Safari and Chromium still using WebKit-based renderers) would be an strange state of affairs.
If Servo continues to thrive, I'd be more surprised if no one attempts this.
The current state of browser engine embedding in Qt/KDE also isn't too rosy. Qt switched from wrapping WebKit to wrapping Blink, and the new wrapper is currently very skimpy on extension points, making it hard or impossible to put e.g. KDE's I/O stack (HTTP, SSL, cookies, etc.) between the renderer and the web. That's a level of integration both KHTML and the WebKit KPart did allow, so things have currently regressed a fair bit. I'm not familiar with the CEF API, but it might actually allow more than Qt WebEngine (currently) does.
Is this clear? The multi-core rendering surely can't be used for every page.
[0] http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...
[1] https://github.com/servo/servo/pull/4969
[2] http://blog.servo.org/2015/04/02/twis-29/ (scroll down)
[3] http://events.linuxfoundation.org/sites/events/files/slides/...
I always lamented that you can't make a command-line, programmable tool that is a fully robust implementation of the web. It would be very cool if this could enable it.
Why MPL again.
MPLv2 is a weak (file-scoped) copyleft that avoids some of the provisions in (L)GPL that drive corporate lawyers raving mad, it's explicitly compatible with (L)GPLv2+ thus avoiding balkanization, and it does have a modern patent grant clause like ALv2/(L)GPLv3.