I don't understand the argument for a periodic indicator. We don't have a periodic indicator telling the user when to restart their browser to pick up auto-updates. The only time it makes sense for the user to re-consider the command line options is when restarting because they might have been upgraded to a version that makes the --no-sandbox option unnecessary for their usage.
-Darin On Fri, Dec 11, 2009 at 3:02 AM, PhistucK <[email protected]> wrote: > Yes, a periodic inforbar would be swell and fairly effective. in my > opinion. > > ☆PhistucK > > > On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow <[email protected]> wrote: > >> On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell <[email protected]>wrote: >> >>> (Resending from chromium.org) >>> >>> On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher <[email protected]> >>> 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: [email protected] >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
