(Resending from chromium.org)
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher <da...@chromium.org> wrote:
> After reading the WebGL blog post today, and following the link to the wiki,
> it struck me as fairly *bad* that we are telling people to disable the
> sandbox. A good number of folks are going to disable the sandbox and forget
> that they had ever done so.
I don't follow. The --no-sandbox command line argument only takes
effect for the current invocation of the browser. Most people launch
Chrome or Chromium from its icon, which will not have that argument
associated with it.
> Once we can support WebGL in the sandbox, what will we do? It would be nice
> if we could somehow restore the sandbox automatically. But renaming
> --no-sandbox doesn't seem like a great choice, and it isn't a scalable
> solution for other things like this that come up in the future.
We will just remove the --no-sandbox option from that wiki page, and
people testing WebGL will eventually stop specifying it.
> Perhaps --enable-webgl should instead implicitly disable the sandbox today
> so that "tomorrow," when WebGL just works, folks won't have to change any
> command line options to restore sandbox functionality. I can see a counter
> argument that people should have to explicitly opt-in to disabling the
> sandbox, but I'm not sure that out-weighs the cost of having a good number
> of dev channel users running *permanently* without the sandbox.
> Was this idea considered? Any other ideas?
I considered this but rejected it because it might lull people into a
false sense of security -- thinking that they had "just" enabled WebGL
but were actually browsing without the sandbox.
The best solution is to get the GPU process in place on all platforms,
at which point WebGL can be run inside the sandbox; this is a high
priority for me and others.
-Ken
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
