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

On Jan 11, 2013, at 2:53 PM, Adam Barth <abarth at webkit.org> wrote:

> On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jan 11, 2013, at 12:21 AM, Adam Barth <abarth at webkit.org> wrote:
>>> 
>>> Is that really the case?  If so, I'm surprised that the patches for
>>> the shared memory cache and the NetworkProcess landed.  I raised
>>> similar questions to the ones you're raising now, but the folks
>>> purposing those changes basically ignored me and landed their patches
>>> anyway.
>> 
>> NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial.
> 
> I don't want delve too deeply into this issue because it's primarily a
> WebKit2 concern.  However, I'll note that in Chromium, networking is
> just a thread in the UIProcess rather than a separate process.  I
> haven't really thought though the consequences of that design choice.
> My point is more that folks just started landing patches for the
> NetworkProcess without discussing the design with the community.
> That's fine if you're not interested feedback from the community, but
> I've also heard repeated requests to share more code between Chromium
> and WebKit2.  If you don't seek feedback on your designs, it's
> unlikely that you'll happen to design something that Chromium will be
> able to adopt in the future.  Put another way, I don't think it's
> reasonable to simultaneously design WebKit2 without community feedback
> and also to complain when Chromium doesn't adopt WebKit2 (in part or
> in whole).

Do you think thread in the UI process vs. completely separate process is a topic worth discussing? It seems like the WebCore layer is unaffected by the difference, and in fact the impact of Chromium's choice is not even visible in the WebKit repository afaict.

 (One reason for our particular choice, FYI, is so that we can give the NetworkProcess a tighter sandbox profile than the Safari UI process).


[...snip...]
> 

> 
> The main point I was trying to make in the document is that hooking in
> at the CachedResource layer has worse security properties than hooking
> in at the ResourceHandle layer.  I understand that Safari and Chromium
> have different goals when it comes to security, which I believe is the
> main reason you're even willing to consider hooking in at the
> CachedResource layer.
> 
> In particular, Chromium needs to be able to run in a strong sandbox on
> Windows XP.  Unlike Mac OS X, Windows XP does not have a particularly
> sensible sandboxing mechanism, mostly because the OS mechanisms that
> we use in Chromium were not intended to be used for sandboxing by the
> designers of XP.  As a consequence, any network requests that we fail
> to hook will simply fail (or more likely just crash).  For that
> reason, we need complete interposition, which means we need to hook
> into WebCore at a layer like ResourceHandle that has actually has
> complete interposition.
> 
> Moreover, we've enjoyed the security benefits of complete
> interposition for a while now and have raised our security goals,
> namely we're interested in achieving software fault isolation based
> API integrity.  As far as I can tell, the approach WebKit2 has taken
> to out-of-proces networking is not compatible with software fault
> isolation based API integrity.  Now, I understand if that sounds very
> futuristic to you given the current security posture of the apple-mac
> port, but if you're serious about working on a common design, you need
> to be willing to accept design goals and constraints beyond those that
> affect the apple-mac port.  As long as you minimize or ignore those
> constraints, it's unlikely that the folks who have those goals and
> constraints will be interested in adopting your designs.


I'm certainly not blowing off your use case. But I would like to understand how it impacts the design.

Can you explain why the WebKit2 approach to out-of-process networking is incompatible with software fault isolation based API integrity, whereas interposing at the ResourceHandle layer is? Is it (a) because some loads don't go through the CachedResource layer currently, (b) because there are some loads you think it is fundamentally impossible (or at least unduly challenging) to send through the CachedResource layer, or (c) some other reason?

Regards,
Maciej