[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]

Some folks have pointed out to me off thread that I'm coming off as
angry and harsh.  I would like to apologize for my tone.

My goal here is not to obstruct or block your progress on the
NetworkProcess.  My goal is to end up with a common design that we can
share between WebKit2 and Chromium or at least have a common way of
interfacing with WebCore.  My concern is that I don't believe that the
current path the NetworkProcess is taking leads to a common design or
interface.

Anyway, it's probably best to continue this conversation another time.
 We can certainly iterate on the approach once you all are feeling
less schedule pressure.

Adam


On Sun, Jan 20, 2013 at 11:44 PM, Adam Barth <abarth at webkit.org> wrote:
> 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
>