Well, the question comes down to this: Can we trust running small amounts of
WebCore in the browser process.
Historically, the answer to running WebCore in the browser has been a
resounding no. Can you please explain what you think has changed since such
decisions were made (or why it's time to revisit such decisions)?
My _feeling_ is that it would be OK with a security review, and my feeling
is that a security review is possible since the code is fairly isolated, but
that's just my opinion. I don't have anything terribly solid to back it up.
J
On Tue, Apr 28, 2009 at 5:46 PM, Michael Nordman <micha...@chromium.org>wrote:
> On Tue, Apr 28, 2009 at 5:38 PM, Jeremy Orlow <jor...@chromium.org> wrote:
> > On Tue, Apr 28, 2009 at 5:27 PM, Michael Nordman <micha...@google.com>
> > wrote:
> >>
> >> > In some sense we do have separate process in which to run sandboxed
> >> > 'backend' code relevant to multiple renders if the need arises... the
> >> > worker process.
> >
> > The way you stated this is a bit odd, but on the surface I guess this
> could
> > be solved via special "shared workers" that ran WebKit code instead of
> > javascript. That said, this means a lot of extra processes (for now,
> shared
> > workers are each in their own process), this blocks localStorage on that,
> > and actually makes the design more complicated. This might be worth
> > exploring at some point, but not now.
>
> Let me re-iterate my main point... i dont think we need to sandbox the
> localstorage or appcache backend code, so we should be able to run
> that directly in the browser process.
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
