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? 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 -~----------~----~----~----~------~----~------~--~---
