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

[Adam Barth]

On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

I'm not sure that's the case.  The choices are coupled because the choice
of interception point determines what code is in the web process and what
code is outside the web process.  The more loader code that's outside the
web process, the more desirable it is to sandbox that code, which pushes
the design towards running the code in a sandboxable environment, like a
process.


> 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?
>

As I wrote before, you're drawing a false dichotomy.  "Networking" is not
a monolithic blob of code.  The question isn't how best to sandbox a
particular blob of code you've chosen to put in the NetworkProcess.  The
question is how best to factor the loader across multiple processes so that
the risky parts of the code can be sandboxed well on various platforms.
 You've chosen a Mac OS X centric design that lets you sandbox that code
but that ignores the constraints that other platforms face in sandboxing.

Since you asked for clarity, my answer to your specific question is that I
reject it's premise.


> 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?
>

Again, you've returned to your false dichotomy.  Instead of assuming that
we've already chosen a Mac OS X centric design that screws Windows, I think
we should choose a design that balances the contraints of all the platforms
we care about.

IMHO, this thread had gone on too long without any tangible results.  The
code that your team is landing just plain doesn't work on other platforms.
 Even if you follow though on your "long-term" ResourceLoader-based design
(which I'll note is *not* what you're actually implementing---see the
recent hacks to FrameLoader.cpp), you'll get a design that might work well
on Mac OS X but that won't have good security properties on other
platforms, such as Windows.  As a result, the Chromium port is unlikely to
adopt the design in the future.

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