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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
