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 attack. Linus
On Wed, Jul 29, 2009 at 1:40 PM, Erik Kay <[email protected]> wrote: > On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson <[email protected]> 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 of what you're proposing, the downside of > this approach is that if there's a crash, you lose the browser process. If > we still wind up storing much of the state of the browser in this main > process, then we lose a lot of state and potentially cause much of the > browser to become unusable (I'm assuming that the whole browser wouldn't > crash since the 'microkernel' would likely keep everything running). When > one of these utility process crashes, we only lose that operation. > > Erik > > > >> Linus >> >> >> On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman <[email protected]> wrote: >> >>> >>> Here is a design document for http://crbug.com/11746 >>> >>> >>> http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac >>> >>> Feedback welcome. >>> >>> >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
