*** Regarding V8 usage in browser for Proxy Autoconfig (PAC): *** My goal is to do all the work necessary to get V8-PAC resolving working in the browser process first.
This gives us feature parity with how things function today, where we load winhttp.dll in the browser process and execute PAC in-process. So security-wise we should be no worse off (unless we believe V8 to be inherently less secure than WinHTTP). ------ Moving resolving OOP could be tackled as a second iteration when integrating into chrome, since the work is at least a superset of what I am doing now. That said, I am not convinced that an OOP design is actually worthwhile. It adds extra complexity, slows down the network fetch critical path, and is doubtful how much it helps users. --- Security: --- Adam compared OOP-PAC to "decoding favicons in the renderer for security". I think this comparison is too generous. favicons and PAC are inherently different: favicons are downloaded without user intervention, whereas PAC scripts are priviledged code that users must explicitly run (at least in theory). The logic goes something like: * To exploit V8 you must be running an evil PAC script. * If you are running an evil PAC script, you are already screwed. Say you got duped (or scewed by WPAD) into running an evil PAC script: The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! All they really need to do is substitute the next EXE you download with the code they want to execute, and voila. In light of this clear and present danger, the remote possibility that they are able to punch out of V8 and into your browser process seems of little consequence. --- Performance: --- As far as performance goes, PAC evaluation needs to happen on every network request; it is on our request critical path. At the very least, this involves one additional IPC round trip (from the browser, to the unpriviledged process). TODO: anyone know what the average IPC roundtrip cost is, so I can quantify this as a percent overhead? The reason I said "at least", is that PAC scripts themselves have access to javascript bindings which may not be runnable in the unprivledged process. For example "dnsResolve()" and "myIpAddress()" may not be runnable from a sandboxed PAC-resolver process. So you could imagine proxying these back to the browser for evaluation. Assuming you have a poorly written PAC script, we could wind up pingponging back and forth on every network request. --- Conclusion: --- So yeah, I was planning on discussing all this formally in a design document when tackling the integration part into chromium (so far all my work is in net/ and has no impact on chromium). I will try to ramp up that timeline and get a discussion thread started. But my take is the choice on whether to do OOP V8-PAC is best evaluated along the non-security axis. - Do we not want the dependency so linux can be 64-bit process - Do we want to avoid heap fragmentation by isolating to process - Do we want to give better resource accounting for PAC authors Cheers. On Tue, Feb 17, 2009 at 11:30 AM, Adam Barth <[email protected]> wrote: > > It's a reasonable size attack surface that we don't need. It's > analogous to our decoding favicons in the renderer for security. > > Adam > > > On Tue, Feb 17, 2009 at 10:17 AM, Darin Fisher <[email protected]> wrote: >> That sounds like a lot of overhead and a lot of costly plumbing to me. Is >> it really beneficial? >> -Darin >> >> >> >> On Tue, Feb 17, 2009 at 3:07 AM, Dean McNamee <[email protected]> wrote: >>> >>> Is it not possible to process PAC in a renderer? >>> >>> On Tue, Feb 17, 2009 at 5:02 AM, Darin Fisher <[email protected]> wrote: >>> > We use V8 in the browser process to run the JS shell, from which it is >>> > possible to type V8 debugger commands. You can telnet to this shell >>> > (after >>> > running chrome with a special command line switch) or open up the "JS >>> > debugger" UI. >>> > >>> > We will also soon be using V8 in the browser process to execute PAC >>> > scripts >>> > in the network library. (eroman is working on that.) >>> > >>> > -Darin >>> > >>> > >>> > On Mon, Feb 16, 2009 at 5:47 AM, Dean McNamee <[email protected]> >>> > wrote: >>> >> >>> >> I thought the js debugger was out of process (or trying to be)? >>> >> >>> >> On Mon, Feb 16, 2009 at 1:29 PM, Marc-Antoine Ruel >>> >> <[email protected]> >>> >> wrote: >>> >> > the js debugger >>> >> > >>> >> > On Mon, Feb 16, 2009 at 5:53 AM, Dean McNamee <[email protected]> >>> >> > wrote: >>> >> >> >>> >> >> What for? >>> >> >> >>> >> >> On Mon, Feb 16, 2009 at 12:18 AM, Erik Kay <[email protected]> >>> >> >> wrote: >>> >> >>> >>> >> >>> v8 is already in the browser process. >>> >> >>> >>> >> >>> Erik >>> >> >>> >>> >> >>> >>> >> >>> On Sun, Feb 15, 2009 at 1:46 PM, Evan Martin <[email protected]> >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> Does this mean we'll have v8 in the browser process? >>> >> >>>> >>> >> >>>> We had idly chatted about running a 64-bit browser process to fix >>> >> >>>> the >>> >> >>>> library hell on Linux. It shouldn't block you either way -- I'm >>> >> >>>> just >>> >> >>>> curious. >>> >> >>>> >>> >> >>>> On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman <[email protected]> >>> >> >>>> wrote: >>> >> >>>>> >>> >> >>>>> I'm trying to commit a change >>> >> >>>>> (http://codereview.chromium.org/19737/diff/1440/1448 ) which adds >>> >> >>>>> a >>> >> >>>>> base class for unit tests that exercise JavaScript. It uses v8.h, >>> >> >>>>> which is disallowed by DEPS. What is the right way to do this? >>> >> >>>>> >>> >> >>>>> - a >>> >> >>>>> >>> >> >>>>> > >>> >> >>>>> >>> >> >>>> >>> >> >>>> > >>> >> >>>> >>> >> >>> >>> >> >>> > >>> >> >>> >>> >> >> >>> >> >> >> >>> >> >> >>> >> > >>> >> >>> >> >> >>> > >>> > >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
