Very interesting.
Definitely we would need a way to give more resources to the renderer
after the process has been locked down. In windows we also have the
fonts issue but we do a neat trick to get them working. That is to say
that we should try hard to use the most restrictive setting ('pure
computation').
Mike, do you wan't to cross reference the windows sandbox with the mac
preliminary stuff. I would be good for somebody that lands in one to
go see the other even if the mac is just preliminary thoughts.
-cpu
On Nov 10, 5:28 pm, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Very interesting!
>
> > As a result, this shouldn't impose any additional requirements or
>
> drastically alter our IPC designs.
>
> I'd actually be surprised if this didn't have a bearing on our IPC choice.
> Afterall, the Windows IPC deals in DuplicateHandle, which is all about
> exposing new resources to the restricted process. It sounds like
> seatbelt could maybe get in the way of some mechanisms used to accomplish
> similar sharing of system resources. Perhaps the Mach ports based approach
> to IPC avoids many of those issues?
>
> -Darin
>
> On Mon, Nov 10, 2008 at 1:11 PM, Mike Pinkerton <[EMAIL PROTECTED]>wrote:
>
>
>
> > Here's a rough-cut starting point for the sandboxing on OS X. Brief,
> > yes, but with only 1 API point that does pretty much everything we
> > need with few obvious restrictions, I'm not sure what more to say...
>
> > Feedback welcome.
>
> >http://sites.google.com/a/chromium.org/dev/developers/design-document...
>
> > --
> > Mike Pinkerton
> > Mac Weenie
> > [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
