[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.
Regards,
Maciej
-------------- 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