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

2013-01-22 Thread Sergio Villar Senin
En 21/01/13 23:07, Maciej Stachowiak escribiu:
 
 On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote:
 
 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.
 
 Thanks, Adam. It's fine to pick up the conversation later, and we're 
 certainly open to iterating beyond what we do first.
 
 We're also happy to meet with anyone interested in this topic to discuss in 
 person, or to document more of our design decisions in writing if the 
 community would find that helpful. 

That'd be awesome, at least an overview document that could help people
to understand the whole picture and the main advantages/drawbacks of the
selected design.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-22 Thread Maciej Stachowiak

On Jan 22, 2013, at 12:17 AM, Sergio Villar Senin svil...@igalia.com wrote:

 En 21/01/13 23:07, Maciej Stachowiak escribiu:
 
 On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote:
 
 Thanks, Adam. It's fine to pick up the conversation later, and we're 
 certainly open to iterating beyond what we do first.
 
 We're also happy to meet with anyone interested in this topic to discuss in 
 person, or to document more of our design decisions in writing if the 
 community would find that helpful. 
 
 That'd be awesome, at least an overview document that could help people
 to understand the whole picture and the main advantages/drawbacks of the
 selected design.

What topics are you interested in? I could probably write decent explanations 
of:

- NetworkProcess: tradeoffs for making it a process vs a thread in the UI 
process
- Load interception for proxying - ResourceHandle vs. ResourceLoader layer, 
pros and cons for each
- What code runs inside the network process, exactly?

Any other topics folks would be interested in?

Cheers,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-22 Thread Sergio Villar Senin
En 22/01/13 09:52, Maciej Stachowiak escribiu:
 That'd be awesome, at least an overview document that could help people
 to understand the whole picture and the main advantages/drawbacks of the
 selected design.
 
 What topics are you interested in? I could probably write decent explanations 
 of:
 
 - NetworkProcess: tradeoffs for making it a process vs a thread in the UI 
 process
 - Load interception for proxying - ResourceHandle vs. ResourceLoader layer, 
 pros and cons for each
 - What code runs inside the network process, exactly?
 
 Any other topics folks would be interested in?

Those are pretty interesting topics that you both (you and Adam I mean)
touched in this thread, but actual information was mixed with personal
opinions I think so it'd be nice to have it in separate docs.

Regarding any other additional topics, what about a discussion about how
sandboxing is supported by the design (also part of the thread)?

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-21 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 aba...@webkit.org wrote:
 On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote:


 On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote:

 On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@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 

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

2013-01-21 Thread Maciej Stachowiak

On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote:

 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.

Thanks, Adam. It's fine to pick up the conversation later, and we're certainly 
open to iterating beyond what we do first.

We're also happy to meet with anyone interested in this topic to discuss in 
person, or to document more of our design decisions in writing if the community 
would find that helpful. 

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-20 Thread Adam Barth
On Wed, Jan 16, 2013 at 11:33 PM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 12, 2013, at 1:14 AM, Adam Barth aba...@webkit.org wrote:
 On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote:

 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.

 I don't know.  As I wrote above, I haven't really thought through the
 consequences of that design choice.  My point was just that the design
 wasn't discussed with the community at all.

 The NetworkProcess and its nature as a process have been mentioned before. At 
 the time, no one expressed an opinion about the matter or pressed for an 
 alternative, and it seems you have not (yet) done so either. If you have an 
 interest in discussing it yourself, I at least would be happy to discuss it. 
 If, for example, you would like to ask questions about it, advocate for a 
 different design, argue that it's important for WK2 and Cr architectures to 
 be consistent in this regard, present the Chromium team's reasons for 
 choosing a thread, or anything else, then I would gladly engage in such 
 discussion.

 Indeed, if anyone has a substantive point to make, I'll concede the foul of 
 insufficient prior discussion. If no one does, then it doesn't seem very 
 valuable to debate the meta-point.

The point isn't to concede the foul.  As discussed in the rest of
this thread, the current design of the NetworkProcess might be a good
design on Mac OS X, but it doesn't work well on other platforms.  To
the extent that the impact of its design is limited to WebKit2, I
don't really care.  The consequence, however, is that Chromium is
unlikely to want to share any abstractions or mechanisms whose design
follows from that design decision.

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

 I'm surprised that the Mac OS X sandboxing mechanisms are
 sophisticated enough to provide a meaningful sandbox for the
 NetworkProcess.  That's certainly not possible on other platforms
 (e.g., Windows).  The reference monitor we use in Chromium for network
 requests contains a great deal of web-specific details that are
 necessary to prevent, for example, an attacker from stealing
 confidential information (such as tax returns) stored in the user's
 file system.

 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.

 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?

 Issue (a) is already a problem with the CachedResource approach with
 the sandbox we use today.  Network requests that don't get intercepted
 will not work on Windows because code running inside the sandbox we
 use on Windows cannot talk to the network.

 Our long-term goal is to make all WebCore loads go through 
 ResourceLoader/CachedResource, and have nothing hit ResourceHandle directly. 
 I agree with you that this is not the case today. I take it from your 
 response that you don't think it is fundamentally impossible or overly 
 complex to make this happen. And it seems like attaining this goal would have 
 a number of advantages regardless of the interposition layer of choice, such 
 as making all loads, even obscure ones, correctly respect 
 ResourceLoader-level concepts such as ApplicationCache and WebArchives.

Even while we've been having this discussion, more patches have landed
that don't follow this design.  For example, a patch landed that
shoehorned an interception point into FrameLoader.

Given that your team appears to be prioritizing schedule over
implementing this feature in an architecturally sound way, I don't
think we'll be able to work together on this topic.  As I've written
before, on Windows and other platforms, we don't have the fallback
option of issuing network requests from the web process.  Maybe in the
long-term when you're done refactoring all network loading paths to
flow though ResourceLoader, we might be able to reconsider.  In the
mean time, the code that your team is landing does not work in a
secure way on non-Mac platforms.

I will note, however, that if instead you simply chose 

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

2013-01-20 Thread Oliver Hunt
 
 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.

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.

--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-20 Thread Adam Barth
On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@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?

 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.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-20 Thread Maciej Stachowiak

On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote:

 On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@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


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-20 Thread Adam Barth
On Sun, Jan 20, 2013 at 1:54 PM, Maciej Stachowiak m...@apple.com wrote:


 On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote:

 On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-16 Thread Maciej Stachowiak

Hi Adam,

You raise a number of interesting points which I'll try to address.

On Jan 12, 2013, at 1:14 AM, Adam Barth aba...@webkit.org wrote:

 On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote:
 
 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.
 
 I don't know.  As I wrote above, I haven't really thought through the
 consequences of that design choice.  My point was just that the design
 wasn't discussed with the community at all.

The NetworkProcess and its nature as a process have been mentioned before. At 
the time, no one expressed an opinion about the matter or pressed for an 
alternative, and it seems you have not (yet) done so either. If you have an 
interest in discussing it yourself, I at least would be happy to discuss it. 
If, for example, you would like to ask questions about it, advocate for a 
different design, argue that it's important for WK2 and Cr architectures to be 
consistent in this regard, present the Chromium team's reasons for choosing a 
thread, or anything else, then I would gladly engage in such discussion.

Indeed, if anyone has a substantive point to make, I'll concede the foul of 
insufficient prior discussion. If no one does, then it doesn't seem very 
valuable to debate the meta-point.


 (One reason for our particular choice, FYI, is so that we can give the 
 NetworkProcess a tighter sandbox profile than the Safari UI process).
 
 I'm surprised that the Mac OS X sandboxing mechanisms are
 sophisticated enough to provide a meaningful sandbox for the
 NetworkProcess.  That's certainly not possible on other platforms
 (e.g., Windows).  The reference monitor we use in Chromium for network
 requests contains a great deal of web-specific details that are
 necessary to prevent, for example, an attacker from stealing
 confidential information (such as tax returns) stored in the user's
 file system.

I take your word for it that it's not possible on Windows.

I believe that the NetworkProcess can feasibly be denied the following 
privileges via Mac OS X sandboxing mechanisms, whereas none of these can 
feasibly be denied to the UI process:

- Access to the window server
- Access to the pasteboard server
- Access to arbitrary local files in the filesystem

I'm going to guess you are the most skeptical about whether the third can be 
done in a meaningful way. If you would like to get deep into the details of how 
it might be done, then I'd sincerely love to have your expert review, but it 
might be something that we should discuss outside this thread.

However, to give you a quick overview: Mac OS X sandboxing mechanisms allow 
fine-grained control over the file access for a process. The sandbox profile's 
rules can allow or deny access to any section of the filesystem. There is also 
a way to dynamically grant temporary access to a given file or portion of the 
filesystem from a more privileged process. Deny rules can also take precedence 
over extensions. Thus, at minimum, it is straightforward to achieve the 
following:

(1) When the user has not explicitly opened any local files, the NetworkProcess 
can only access its assigned whitelist of files (including such things as cache 
and cookies directories, for instance).
(2) For the duration of the user having an explicitly chosen local document 
open, the NetworkProcess can be temporarily granted access to the whole 
filesystem excepting sensitive blacklisted areas.

(2) is obviously suboptimal, since social engineering attacks could be used to 
trick a user into opening a local file, but it does prevent drive-by attacks. 
But it's possible to do better with more work. Let me throw out two rough 
strawman designs. Let's presume for both of these that local files are opened 
in separate WebProcesses from any remote webpages. There are at least two 
approaches to avoiding giving the NetworkProcess the run of the filesystem even 
temporarily. One is to grant the extension the local file WebProcesses, and 
have them load files directly rather than via proxy. Another is to have a 
FileAccessProcess or the like which only handles file: URLs but otherwise works 
like the NetworkProcess, and only WebProcesses serving a local file document 
would be given a handle to it. There might be other even more clever ways but I 
hope this suffices for an existence proof.

Again, we could dig more into the details, but I think that would merit a 
separate discussion (perhaps off of webkit-dev).

For these reasons, I am reasonably confident that a separate process for 
networking can be made to have better security properties on Mac OS X (and 
platforms with similarly sophisticated sandboxing mechanisms) than a thread 
inside the UI process. And these better properties are intrinsically tied to 
being a 

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

2013-01-12 Thread Maciej Stachowiak

On Jan 11, 2013, at 2:53 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-12 Thread Adam Barth
On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 11, 2013, at 2:53 PM, Adam Barth aba...@webkit.org wrote:
 On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@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.

I don't know.  As I wrote above, I haven't really thought through the
consequences of that design choice.  My point was just that the design
wasn't discussed with the community at all.

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

I'm surprised that the Mac OS X sandboxing mechanisms are
sophisticated enough to provide a meaningful sandbox for the
NetworkProcess.  That's certainly not possible on other platforms
(e.g., Windows).  The reference monitor we use in Chromium for network
requests contains a great deal of web-specific details that are
necessary to prevent, for example, an attacker from stealing
confidential information (such as tax returns) stored in the user's
file system.

 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 

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

2013-01-11 Thread Maciej Stachowiak

On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:

 
 If you're actually planning to make a significant complexity-imposing 
 architectural change for performance reasons, without any way to test 
 whether it delivers the claimed performance benefits, or how it compares to 
 less complex approaches, then why should any rational person agree with that 
 approach? When attempting to improve performance, the burden of proof is on 
 the person proposing the performance improvement, not on others to create a 
 test to figure out if the performance improvement works. It's not valid to 
 respond to a request for performance testing info with the equivalent of 
 patches welcome.
 
 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.

What I know is controversial, and I believe merits further follow-up 
discussion, is the choice of where proxying of networking to an outside process 
should hook in - whether at the ResourceHandle layer (as Chromium does it), or 
at the CachedResource layer, as WebKit2 is doing it. That choice involves 
hypotheses about both performance and appropriate architecture. I feel that the 
WebKit2 folks have not provided sufficient public data to fully justify the 
choice of where to hook things in, and I will encourage things to do so. On the 
other hand, Chromium folks historically did not really provide a lot of data or 
justification for why the ResourceHandle was the right place. Rather, it was 
presented as a constraint and a must-have for merging back to the WebKit 
repository.

Long term, it is obviously somewhat regrettable if we end up diverging on this 
point, and therefore having two different insertion points for proxying, as 
that makes WebKit overall more complex. 

I think your whitepaper on the topic was a good start on outlining some of the 
pros and cons. I commented on it a bit in email and via the comment system, but 
discussion died down (probably due to vacations and then the holidays).

Here it is for reference of others: 
https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1

In addition to my previous comments, I believe some topic not yet fully covered 
by your whitepaper are:
- Hooking in proxying at the ResourceHandle layer may require threading 
information through ResourceHandle that it logically should not need to know 
(if one thinks of it as a an abstraction on top of a low-level networking API), 
such as association with a specific frame/page, or 
- How to connect loading mechanisms that bypass ResourceHandle or otherwise 
bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs 
(currently implemented as a magic ResourceHandle subclass), etc. The two 
approaches have different architectural implications for this type of feature. 
I am not sure offhand which approach is cleaner or whether one way or the other 
has more pragmatic benefits.

I'll add also that it seems possible in principle to make all WebCore loading 
go through the CachedResource layer, jut as it's possible to have it all go 
through the ResourceHandle layer, and it's likely beneficial to do so though 
the benefits in cases of more marginal load types may be small.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-01-11 Thread Adam Barth
On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote:
 On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
 If you're actually planning to make a significant complexity-imposing 
 architectural change for performance reasons, without any way to test 
 whether it delivers the claimed performance benefits, or how it compares to 
 less complex approaches, then why should any rational person agree with 
 that approach? When attempting to improve performance, the burden of proof 
 is on the person proposing the performance improvement, not on others to 
 create a test to figure out if the performance improvement works. It's not 
 valid to respond to a request for performance testing info with the 
 equivalent of patches welcome.

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

 What I know is controversial, and I believe merits further follow-up 
 discussion, is the choice of where proxying of networking to an outside 
 process should hook in - whether at the ResourceHandle layer (as Chromium 
 does it), or at the CachedResource layer, as WebKit2 is doing it. That choice 
 involves hypotheses about both performance and appropriate architecture. I 
 feel that the WebKit2 folks have not provided sufficient public data to fully 
 justify the choice of where to hook things in, and I will encourage things to 
 do so. On the other hand, Chromium folks historically did not really provide 
 a lot of data or justification for why the ResourceHandle was the right 
 place. Rather, it was presented as a constraint and a must-have for merging 
 back to the WebKit repository.

To me, that's seems like a pretty revisionist version of history.  At
the time Chromium landed, it wasn't at all practical to hook in at the
cached resource layer because many (most?) loading codepaths bypassed
the memory cache.  It's only because of Nat's work to unify the loader
code paths that it's even possible today.  As Brady found, it wasn't
even possible when he started out because main resources didn't flow
through the memory cache until this past month.

 Long term, it is obviously somewhat regrettable if we end up diverging on 
 this point, and therefore having two different insertion points for proxying, 
 as that makes WebKit overall more complex.

Agreed.

 I think your whitepaper on the topic was a good start on outlining some of 
 the pros and cons. I commented on it a bit in email and via the comment 
 system, but discussion died down (probably due to vacations and then the 
 holidays).

 Here it is for reference of others: 
 https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1

 In addition to my previous comments, I believe some topic not yet fully 
 covered by your whitepaper are:
 - Hooking in proxying at the ResourceHandle layer may require threading 
 information through ResourceHandle that it logically should not need to know 
 (if one thinks of it as a an abstraction on top of a low-level networking 
 API), such as association with a specific frame/page, or
 - How to connect loading mechanisms that bypass ResourceHandle or otherwise 
 bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs 
 (currently implemented as a magic ResourceHandle subclass), etc. The two 
 approaches have different architectural implications for this type of 
 feature. I am not sure offhand which approach is cleaner or whether one way 
 or the other has more pragmatic benefits.

 I'll add also that it seems possible in principle to make all WebCore loading 
 go through the CachedResource layer, jut as it's possible