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. For normal extensions where images are always just rendered in HTML, we don't need to do anything special with the images. They'll always be read and rendered in the renderer. The issue with images is with themes, since they're displayed by the browser process. I'm not sure I followed your flow with this. At install time, you ship decoded images over to the browser process so it can display them. Does it need to re-encode the images itself for storage to disk? Or is it going to need to ask the renderer to decode each time? 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. I think the max was actually 10M. Perhaps we'd need to implement it as a streaming API. Isn't that kind of logic already in place for audio/video? > 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? Perhaps the renderer could just have read access to the zip file, and then pass the files it's unpacking one-by-one up to the browser. If the zip has any single large files, that gets expensive though. 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. > There have been other cases people have brought up where the work being requested wasn't associated with a renderer (PAC parsing for example). With the extension example, I think it could be associated with a renderer, but in some cases, we'd be opening up a new one (say you double click on a crx file). Erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
