[webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

Maciej Stachowiak mjs at apple.com
Sun Jan 20 13:54:40 PST 2013

On Jan 20, 2013, at 1:44 PM, Adam Barth <abarth at webkit.org> wrote:

> On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt <oliver at apple.com> wrote:
>>>> I take your word for it that it's not possible on Windows.
>>> Given that Chromium has many users on Windows (and other non-Mac
>>> platforms), you should now understand why this design does not fit
>>> well with Chromium's design constraints.
>> But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions.
> The reason discussed earlier in this thread is because they have
> implications for how the loader works in WebCore.  In particular,
> folks working on the NetworkProcess have been shoehorning it into
> WebCore by adding numerous #ifdefs throughout WebCore.  Are you
> offerring to implement the NetworkProcess without adding a bunch of
> WebKit2-specific #ifdefs to WebCore?

The choice of load interception point is completely orthogonal to the decision to make the network process is a process or a thread.

>> One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance.  Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however.
> According to Maciej, one of the motivations for having a
> NetworkProcess is that it can be sandboxed more tightly on Mac OS X.
> Unfortunately, the NetworkProcess, as currently designed, cannot be
> sandboxed on other platforms, such as Windows.  That's why the current
> design is not a good fit for other platforms.
> To be clear, I think it's fine if you want to use a Mac OS X-centric
> design for WebKit2.  However, you shouldn't be surprised later when
> other ports that run on more platforms don't want to adopt your
> designs.  Moreover, if sometime in the future, I want to implement a
> Chromium-centric design that involves adding a bunch of #ifdefs to
> WebCore, I expect that you won't mind not having input either.

As I understand it, here's the payoff matrix for how much sandboxing of networking code you get, if you take the process vs thread decision in isolation:

                                   |       Mac             |       Windows
Networking in dedicated process    | fs can be sandboxed   | no meaningful sandbox
Networking in thread in UI process | no meaningful sandbox | no meaningful sandbox

Just to be absolutely clear, are you saying that the Chromium project sees the second row as a better payoff? In other words, you'd consider it bad to make Mac security better in a way that can't be applied to Windows, even if it makes Windows security no worse?

I really hope that I'm just misunderstanding what you are saying.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130120/fe5f580d/attachment.html>

More information about the webkit-dev mailing list