[chromium-dev] Re: [WebGL] Recommending --no-sandbox
(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
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
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
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
Yes, a periodic inforbar would be swell and fairly effective. in my opinion. ☆PhistucK On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow jor...@chromium.org wrote: 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 -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
The goal is to annoy you so you will try to stop passing these arguments. Don't we already have other infobars possibly showing at startup (e.g., restore tabs)? -darin On Fri, Dec 11, 2009 at 9:46 AM, Evan Martin e...@chromium.org wrote: I also like the infobar on start, especially if there's no way to say stop bugging me on it, so every time you start it will annoy you. I would like to bring back --single-process as well in that case. On Linux users are much more comfortable sending in stack traces etc. but trying to walk someone through getting a renderer subprocess crash into gdb is a pain; if I could say run 'gdb --args chrome --single-process it would save me a lot of time. On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher da...@chromium.org wrote: 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 phist...@chromium.org 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 jor...@chromium.org wrote: 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
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 9:56 AM, Darin Fisher da...@chromium.org wrote: The goal is to annoy you so you will try to stop passing these arguments. Don't we already have other infobars possibly showing at startup (e.g., restore tabs)? Yes. It looks a little silly -- you get two of them stacked -- but part of the point of this is that most users don't encounter it, it's only the ones doing things that we're trying to discourage. Since code speaks louder than words: http://codereview.chromium.org/490019 Screenshot: http://i.imgur.com/1mPST.png -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 1:57 AM, Jeremy Orlow jor...@chromium.org wrote: 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. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
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. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. I'd be happier if the dialog provided a single-button way to automatically remove the flag from the shortcut (otherwise it's just easier to hit 'OK' and put off manually editing it). -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher da...@chromium.org wrote: 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. I don't think this is a fair comparison. One is a normal usage of Chrome and the other is something we're actively trying to discourage. On the other hand, maybe some sort of periodic indicator for when you auto-update is a good idea 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. Even when they're using the flag because they want to use an experimental feature we should still remind them that the flag is dangerous and that they shouldn't be doing normal browsing with that window. Major +1 to glens idea in theory. But in practice, how would you pull that off? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
But, as I understand, some people do use it due to issues with the sandbox, real issues, system incompatibilities. That would be really unfair towards them. ☆PhistucK On Fri, Dec 11, 2009 at 20:43, Glen Murphy g...@chromium.org wrote: 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. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. I'd be happier if the dialog provided a single-button way to automatically remove the flag from the shortcut (otherwise it's just easier to hit 'OK' and put off manually editing it). -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 11:01 AM, PhistucK phist...@gmail.com wrote: But, as I understand, some people do use it due to issues with the sandbox, real issues, system incompatibilities. That would be really unfair towards them. Most issues should be fixable. We need to hear about problems the sandbox causes, and fix them. If people just disable the sandbox, we won't hear about them. If there is some issue that is not fixable, I would prefer those users not use Chrome than that they exist in the steady state of using it with the sandbox off. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 10:43 AM, Glen Murphy g...@chromium.org wrote: 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. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. How annoying? Since we already know that people habitually mash the default button, the dialog could say Running with --no-sandbox is dangerous. Can I keep the sandbox enabled?, then OK is the good thing, and Cancel/No is the bad thing. [BTW, I hope it's obvious that we might not want to be as annoying if we disable the sandbox as part of an experimental feature. A little annoying, but since experimental features correlate with browsers crashing, we should be careful not to alienate developers who are testing the experimental feature...] [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
[from right address] On Fri, Dec 11, 2009 at 11:37 AM, Steve VanDeBogart vand...@google.comwrote: On Fri, Dec 11, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote: [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] Instead of telling people to use --no-sandbox on the blog, we could tell them to use a new flag, --disable-sandbox-until MM/DD/. It could limit the maximum amount of time the sandbox was disabled, to say two weeks. After that, the sandbox would automatically be reenabled. There should still be some kind of notification that the user is running with the sandbox disabled, but people that ignore it or forget about it will get converted back to a secure configuration in a reasonable amount of time. -- Steve -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
And then an infobar would show up (only in the first time) and tell them they can be relieved since they are secure again? ;) Sounds like an appropriate Google joke. ☆PhistucK On Fri, Dec 11, 2009 at 21:40, Steve VanDeBogart vand...@chromium.orgwrote: [from right address] On Fri, Dec 11, 2009 at 11:37 AM, Steve VanDeBogart vand...@google.comwrote: On Fri, Dec 11, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote: [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] Instead of telling people to use --no-sandbox on the blog, we could tell them to use a new flag, --disable-sandbox-until MM/DD/. It could limit the maximum amount of time the sandbox was disabled, to say two weeks. After that, the sandbox would automatically be reenabled. There should still be some kind of notification that the user is running with the sandbox disabled, but people that ignore it or forget about it will get converted back to a secure configuration in a reasonable amount of time. -- Steve -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
