An advantage of the utility process is that it's not tied to the lifetime of
the tab, so we don't have to deal with edge cases like when the user closes
a tab that's mid-installing an extension.
Ojan

On Fri, May 1, 2009 at 10:42 AM, Adam Barth <[email protected]> wrote:

>
> I think we should go with the utility process.  We've seen several
> examples where this would be a useful concept to have.
>
> As for the zip libraries, I seem to recall that we can marshal file
> handles into sandboxed processes, but I'm not an expert on this.
>
> Adam
>
>
> 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?
> >
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to