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
