On Wed, Jul 29, 2009 at 5:55 AM, Robert Shield wrote:
> Really nice doc! An attempt at potentially helpful comments follows:
>
> Regarding the class naming in the Out of process design, the convention
> I've seen most often is to have FooHost classes run in the browser with Foo
> classes in child
Really nice doc! An attempt at potentially helpful comments follows:
Regarding the class naming in the Out of process design, the convention I've
seen most often is to have FooHost classes run in the browser with Foo
classes in child processes.
Proxy resolver process / crashes - the document ment
Updated the names with some feedback from Darin:
ProxyResolverV8::JSBindings --> ProxyResolverJSBindings
OOPProxyResolverV8 --> IPCProxyResolver
OOPProxyResolverV8Host --> IPCProxyResolverHost
So the names are less V8 specific (could drop in a JSC backend on the
proxy resolver process-side if yo
On Thu, Jul 30, 2009 at 4:20 PM, Eric Roman wrote:
>> Regarding the class naming in the Out of process design, the convention I've
>> seen most often is to have FooHost classes run in the browser with Foo
>> classes
>> in child processes.
>
> Yeah, I always get confused on which endpoint should b
On Thu, Jul 30, 2009 at 4:20 PM, Eric Roman wrote:
> Thanks all for the feedback.
> Responses are inline, and an updated design document has been posted.
>
> @robertshield:
>
> > Regarding the class naming in the Out of process design, the convention
> I've
> > seen most often is to have FooHost
Thanks all for the feedback.
Responses are inline, and an updated design document has been posted.
@robertshield:
> Regarding the class naming in the Out of process design, the convention I've
> seen most often is to have FooHost classes run in the browser with Foo classes
> in child processes.
On Wed, Jul 29, 2009 at 1:42 PM, Linus Upson wrote:
> Sorry. The point of my sandbox the browser suggestion wasn't to increase
> robustness in the case of failure. It was only to limit the damage an
> exploit might cause. The browser process is complicated enough that it is
> hard to secure. A sm
The plug-in sandbox is too weak to be robust, see the other thread about it.
As long as it has access to HWNDs, it's very easy to break out of it.
On Wed, Jul 29, 2009 at 10:43 AM, Adam Barth wrote:
>
> I wonder if we could use something like the plug-in sandbox for the
> main browser process i
Sorry. The point of my sandbox the browser suggestion wasn't to increase
robustness in the case of failure. It was only to limit the damage an
exploit might cause. The browser process is complicated enough that it is
hard to secure. A small broker would be easier to understand and make
resistant to
On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson wrote:
> I realize this is not a small request, but it would be better if we could
> move to a model where the browser was sandboxed and talked to a much simpler
> process to carry out trusted operations on its behalf.
While I like the general goal o
I wonder if we could use something like the plug-in sandbox for the
main browser process in the intermediate term. That way the browser
could still have HWNDs and the like.
Adam
On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson wrote:
> I realize this is not a small request, but it would be better
I realize this is not a small request, but it would be better if we could
move to a model where the browser was sandboxed and talked to a much simpler
process to carry out trusted operations on its behalf.
Linus
On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman wrote:
>
> Here is a design document fo
As an aside, favicons are handled in the renderer, sandboxed. The renderer
decodes them and reencodes them as PNG to ensure that they're safe before
handing them off to the browser process. Trace the ViewMsg_DownloadFavIcon,
ViewHostMsg_UpdateFavIconURL, and ViewHostMsg_DidDownloadFavIcon messages
On Wed, Jul 29, 2009 at 11:52 AM, Mike Pinkerton wrote:
> Don't we farm out a separate process for favicon decoding? And for
> theme image decoding as well?
There are two things done by the utility process. Unpacking of themes (not
just images but the unzipping of the packages, parsing of the JS
Don't we farm out a separate process for favicon decoding? And for
theme image decoding as well?
On Wed, Jul 29, 2009 at 11:44 AM, Jeremy Orlow wrote:
> Are there other things currently done in the browser process that'd be nice
> to do in a sandboxed utility process like this? Is there any work
Are there other things currently done in the browser process that'd be nice
to do in a sandboxed utility process like this? Is there any work that the
browser farms out to renderer processes that might be cleaner to do in a
utility process?
If so, I'd propose making the design for this new process
16 matches
Mail list logo
