<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 20, 2013, at 1:44 PM, Adam Barth <<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt <<a href="mailto:oliver@apple.com">oliver@apple.com</a>> wrote:<br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I take your word for it that it's not possible on Windows.<br></blockquote><br>Given that Chromium has many users on Windows (and other non-Mac<br>platforms), you should now understand why this design does not fit<br>well with Chromium's design constraints.<br></blockquote><br>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.<br></blockquote><br>The reason discussed earlier in this thread is because they have<br>implications for how the loader works in WebCore. In particular,<br>folks working on the NetworkProcess have been shoehorning it into<br>WebCore by adding numerous #ifdefs throughout WebCore. Are you<br>offerring to implement the NetworkProcess without adding a bunch of<br>WebKit2-specific #ifdefs to WebCore?<br></blockquote><div><br></div><div>The choice of load interception point is completely orthogonal to the decision to make the network process is a process or a thread.</div><br><blockquote type="cite"><br><blockquote type="cite">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.<br></blockquote><br>According to Maciej, one of the motivations for having a<br>NetworkProcess is that it can be sandboxed more tightly on Mac OS X.<br>Unfortunately, the NetworkProcess, as currently designed, cannot be<br>sandboxed on other platforms, such as Windows. That's why the current<br>design is not a good fit for other platforms.</blockquote><div><div><blockquote type="cite"><br>To be clear, I think it's fine if you want to use a Mac OS X-centric<br>design for WebKit2. However, you shouldn't be surprised later when<br>other ports that run on more platforms don't want to adopt your<br>designs. Moreover, if sometime in the future, I want to implement a<br>Chromium-centric design that involves adding a bunch of #ifdefs to<br>WebCore, I expect that you won't mind not having input either.<br></blockquote></div><br></div><div><div>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:</div><div><br></div><div><font face="Courier"> | Mac | Windows</font></div><div><font face="Courier">-------------</font><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">----</span></div><div><font face="Courier">Networking in dedicated process | fs can be sandboxed | no meaningful sandbox</font></div><div><font face="Courier">-------------</font><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">-------------</span><span style="font-family: Courier; ">----</span></div><div><font face="Courier">Networking in thread in UI process | no meaningful sandbox | no meaningful sandbox</font></div><div><br></div><div><br></div><div>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?</div></div><div><br></div><div>I really hope that I'm just misunderstanding what you are saying.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br></div></div></body></html>