On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman <[email protected]> wrote:
> > Right now, we are unpacking extensions in the browser process. This > basically consists of unzipping the package into a directory structure > and parsing a JSON manifest. > > Both of these things feel like things we should not be doing in the > browser. Additionally, extensions can contains PNG images that will be > used in the browser process, for example, for themes. Decoding these > images also shouldn't be done in the browser process. > > I'm looking for advice on how best to sandbox all of this. > > > Here are my current thoughts: > > To me, the conceptually simplest solution would be to do all of the > unpacking in whichever renderer happened to be the one that the user > clicked "Install" in. In the case of autoupdate, we'd use the > extension's own process, which are also just renderers. > > The browser would tell the renderer about the zip file that needed to > be unpacked, and the renderer would unzip it, parse it, and decode > images into bitmaps, which would all be shipped back to the browser. > > The immediate practical problem with this approach is that the zip > library we use works in terms of files, not memory. This could be > changed, but I am not sure how good an idea that is since packages > could be large. Average Firefox extensions are ~300k, but we are > planning for a max of 1M. > > Maybe the renderers could be allowed to have a temporary directory > they are allowed to do work in? The browser could put the zip file > there and they could be unpacked in place? We've talked about this for a bunch of different reasons, and always pushed back. But maybe the gears team was going to do that anyway? I'm not sure what we decided at the end. Either way, can you modify your zip library to take a file handle instead of a filename? If so, we have everything you need to pass a file handle across processes, or even better, a memory map file. Nicolas > > Another orthogonal idea I have heard kicked around is a separate > "utility" process. This seems like it would have the same problems > with how to get the data in and out, though, and I don't see why > bother having a new process when we already have a renderer we could > use. > > Looking forward to your brilliant ideas, > > - a > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
