On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell <k...@chromium.org> wrote:
> (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. > On Windows, the most common way for people to launch with arguments is to add them to a short cut. The risk is that they'd do this to their main shortcut and then forget about 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. > _New_ users will stop specifying it, but I doubt people will be regularly checking the wiki page. > > 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. > We definitely know this is true, and I think it's even safe to assume this will be true for other features in the future that only work with the sandbox off initially. The problem is the time before this is true. As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. The solution to this is either the annoying/scary UI can't be disabled/clicked-through/etc (like a red and white striped theme that can't be overridden) or to pop up a modal dialog or info bar periodically (it could even be once an hour or even day) in addition to popping it up initially. In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said Also, when thinking about options 1 and 2 above (changing the appearance of Chrome) I can't help but think of someone pitching WebGL (which currently doesn't work in the sandbox) to their development team and the audience asking 'why is your browser all red?'. Answer: 'Oh, I have to turn off all the security in Chrome to get the demo to work'... :) I respectfully disagree. I think it's an opportunity to make it clear that the browser is normally running at a higher level of security than any other and that we're _temporarily_ making Chromium on par with any other browser. At the end of the day, Chromium will have these features within a sandboxed environment. Other browsers won't. This point could be very powerful if presented well. J -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
