Re: [chromium-dev] [WebGL] Recommending --no-sandbox
On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote: On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com wrote: I just got back from vacation and would like to take action on this. I read through the thread, but I don't see any sort of consensus on what to do. Here are the options as I see them: 1) Modal dialog box. Bad for debugging, will probably just be clicked through by users, and not very good for users who leave the browser open for long stretches of time. I'd say it's not a good solution. I thought it was clear that this was the consensus best idea (see Darin's, Glen's, my posts for example). Glen didn't support it (only didn't object) and you and Darin were the only ones that supported it. A couple of us thought it was a bad idea. I don't see how this is anything close to a consensus. I don't see how it's bad for debugging (Viet-Trung's objection makes absolutely no sense to me),and we don't care about the edge case of users who both use --no-sandbox and never restart (this works well enough even for restarting once every several weeks, which takes care of practically everyone). Clicking through is enough of an annoyance to serve our purposes, and this is trivially simple to add (simpler by far than all other options including an infobar). 2) Info bar. This seems like one of the more popular options at the moment. This is a bad idea, we shouldn't do it. It's not as annoying as a modal dialog, it has problems with clashing with other infobars on start. Basically it's inferior to a modal dialog in every way. FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch that goes this route. 3) Add some other persistent UI like the incognito spy guy, an annoying theme (that overrides whatever you have selected), or something else. This seems like a pretty good option to me, but there hasn't been too much discussion around it. What type of UI would be the best? Is this a good option? No, we shouldn't do this. Way too much effort and code (think about making this work on three OSes and with custom themes), we just want something trivial. Themes are cross platform. Though I agree that this route may be more trouble than it's worth. 4) Add some warning to the new tab page. Once again, no one's really thought about this seriously. Any thoughts? Again, inferior to the other options. Doesn't work well for users who don't start with the NTP (or ones who never see it -- I don't, I don't use ctrl-t or the new tab button, I use middle-click and alt-enter). Fair enough. If you're planning to implement something, please implement the dialog. I'd like to hear what others think as well. -- 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] [WebGL] Recommending --no-sandbox
On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow jor...@google.com wrote: 2) Info bar. This seems like one of the more popular options at the moment. This is a bad idea, we shouldn't do it. It's not as annoying as a modal dialog, it has problems with clashing with other infobars on start. Basically it's inferior to a modal dialog in every way. FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch that goes this route. I would really appreciate being on this thread. I haven't seen this at all and I don't see why any mails relating to this need to be private. What is the rationale for being less annoying than a modal dialog, particularly in light of Glen's comments above (which I fully agree with)? Evan's screenshot is not in-your-face enough. Glen's idea of making the dialog actually confirm turning the flag off, instead of just being a notification, is also worth implementing. 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] [WebGL] Recommending --no-sandbox
I thought there were two separate issues here: 1.) The specific webgl switch. Darin suggested that it should imply --disable-sandbox until webgl works in the sandbox. This way, people don't have to add --disable-sandbox explicitly and will automatically be safe once webgl works in the sandbox. 2.) If / how --enable-sandbox should uglify the UI. Your list is missing this suggestion by vandebo: 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. (which could be in addition to the other stuff, if people think it's a good idea) On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow jor...@google.com wrote: On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote: On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com wrote: I just got back from vacation and would like to take action on this. I read through the thread, but I don't see any sort of consensus on what to do. Here are the options as I see them: 1) Modal dialog box. Bad for debugging, will probably just be clicked through by users, and not very good for users who leave the browser open for long stretches of time. I'd say it's not a good solution. I thought it was clear that this was the consensus best idea (see Darin's, Glen's, my posts for example). Glen didn't support it (only didn't object) and you and Darin were the only ones that supported it. A couple of us thought it was a bad idea. I don't see how this is anything close to a consensus. I don't see how it's bad for debugging (Viet-Trung's objection makes absolutely no sense to me),and we don't care about the edge case of users who both use --no-sandbox and never restart (this works well enough even for restarting once every several weeks, which takes care of practically everyone). Clicking through is enough of an annoyance to serve our purposes, and this is trivially simple to add (simpler by far than all other options including an infobar). 2) Info bar. This seems like one of the more popular options at the moment. This is a bad idea, we shouldn't do it. It's not as annoying as a modal dialog, it has problems with clashing with other infobars on start. Basically it's inferior to a modal dialog in every way. FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch that goes this route. 3) Add some other persistent UI like the incognito spy guy, an annoying theme (that overrides whatever you have selected), or something else. This seems like a pretty good option to me, but there hasn't been too much discussion around it. What type of UI would be the best? Is this a good option? No, we shouldn't do this. Way too much effort and code (think about making this work on three OSes and with custom themes), we just want something trivial. Themes are cross platform. Though I agree that this route may be more trouble than it's worth. 4) Add some warning to the new tab page. Once again, no one's really thought about this seriously. Any thoughts? Again, inferior to the other options. Doesn't work well for users who don't start with the NTP (or ones who never see it -- I don't, I don't use ctrl-t or the new tab button, I use middle-click and alt-enter). Fair enough. If you're planning to implement something, please implement the dialog. I'd like to hear what others think as well. -- 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] [WebGL] Recommending --no-sandbox
On Wed, Dec 30, 2009 at 4:15 PM, Nico Weber tha...@chromium.org wrote: I thought there were two separate issues here: 1.) The specific webgl switch. Darin suggested that it should imply --disable-sandbox until webgl works in the sandbox. This way, people don't have to add --disable-sandbox explicitly and will automatically be safe once webgl works in the sandbox. I agree that this is a separate issue and that doing this would probably be a good idea. 2.) If / how --enable-sandbox should uglify the UI. Your list is missing this suggestion by vandebo: 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. (which could be in addition to the other stuff, if people think it's a good idea) I definitely think this would need to be in addition to other (noisy) UI. Personally, I think having stuff like --enable-webgl implying disabling the sandbox is a better plan though since it's hard to predict when the feature will be complete and a user won't delete the --enable-webgl flag bug forget to delete the --disable-sandbox-until flag. On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow jor...@google.com wrote: On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote: On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com wrote: I just got back from vacation and would like to take action on this. I read through the thread, but I don't see any sort of consensus on what to do. Here are the options as I see them: 1) Modal dialog box. Bad for debugging, will probably just be clicked through by users, and not very good for users who leave the browser open for long stretches of time. I'd say it's not a good solution. I thought it was clear that this was the consensus best idea (see Darin's, Glen's, my posts for example). Glen didn't support it (only didn't object) and you and Darin were the only ones that supported it. A couple of us thought it was a bad idea. I don't see how this is anything close to a consensus. I don't see how it's bad for debugging (Viet-Trung's objection makes absolutely no sense to me),and we don't care about the edge case of users who both use --no-sandbox and never restart (this works well enough even for restarting once every several weeks, which takes care of practically everyone). Clicking through is enough of an annoyance to serve our purposes, and this is trivially simple to add (simpler by far than all other options including an infobar). 2) Info bar. This seems like one of the more popular options at the moment. This is a bad idea, we shouldn't do it. It's not as annoying as a modal dialog, it has problems with clashing with other infobars on start. Basically it's inferior to a modal dialog in every way. FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch that goes this route. 3) Add some other persistent UI like the incognito spy guy, an annoying theme (that overrides whatever you have selected), or something else. This seems like a pretty good option to me, but there hasn't been too much discussion around it. What type of UI would be the best? Is this a good option? No, we shouldn't do this. Way too much effort and code (think about making this work on three OSes and with custom themes), we just want something trivial. Themes are cross platform. Though I agree that this route may be more trouble than it's worth. 4) Add some warning to the new tab page. Once again, no one's really thought about this seriously. Any thoughts? Again, inferior to the other options. Doesn't work well for users who don't start with the NTP (or ones who never see it -- I don't, I don't use ctrl-t or the new tab button, I use middle-click and alt-enter). Fair enough. If you're planning to implement something, please implement the dialog. I'd like to hear what others think as well. -- 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] [WebGL] Recommending --no-sandbox
This is exactly what I was thinking. An infobar is the right choice in my opinion. Having a modal dialog on startup for those who use this switch regularly due to issues, should not be suddenly have a *really annoying* modal dialog every time they start their browser. An infobar, on the other hand, is informative enough to make people be aware that their are using it and a learn more link to how to turn it off (in case they were once instructed to do so for support purposes and did not turn it off since then) would be the best solution here. ☆PhistucK On Fri, Dec 11, 2009 at 07:49, Finnur Thorarinsson fin...@chromium.orgwrote: I wonder... should we show an infobar on startup when the sandbox is disabled? On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. 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. 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. 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? -Darin -- 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 -- 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] [WebGL] Recommending --no-sandbox
(adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] [WebGL] Recommending --no-sandbox
Alice's reply is below. I'm still convinced that Google Chrome shouldn't run without the sandbox, and if someone needs that, then they can use Chromium builds. We actually rarely ask users to turn off the sandbox and after we confirm that they can run it with the flag, we tell them do remove it immediately due to security vulnerabilities. The only problem is that after this point, it's hard for users to figure out what's preventing Google Chrome to run properly. We need to find an easier way or some sort of utility to do this. I agree that we need to make it obvious to the user that they shouldn't be running without sandbox but we need to give them a better way to figure out what's wrong so that they can continue to use it. -- Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations | 650.253.6827 | a...@google.com On Fri, Dec 11, 2009 at 11:48 AM, John Abd-El-Malek j...@chromium.orgwrote: (adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.orgwrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] [WebGL] Recommending --no-sandbox
We actually rarely ask users to turn off the sandbox and after we confirm that they can run it with the flag, we tell them do remove it immediately due to security vulnerabilities. The only problem is that after this point, it's hard for users to figure out what's preventing Google Chrome to run properly. We need to find an easier way or some sort of utility to do this. I agree that we need to make it obvious to the user that they shouldn't be running without sandbox but we need to give them a better way to figure out what's wrong so that they can continue to use it. On Fri, Dec 11, 2009 at 11:48 AM, John Abd-El-Malek j...@chromium.orgwrote: (adding Alice) Alice: do you have a rough estimate for how often we ask users to turn off the sandbox when debugging problems? Thanks On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.orgwrote: I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I understand the argument, but do we really end up using this for end-users in debugging problems? Given how many Chrome users we have, my impression is we've fixed any issues with the sandbox long ago. I don't feel that strongly about disabling --no-sandbox, but I'd like to be more convinced of the arguments against it :) I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations | 650.253.6827 | a...@google.com This email and the information it contains are confidential and may be privileged. If you have received this email in error please notify me immediately. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and, therefore, Google does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. If you suspect the message may have been intercepted or amended please contact me. -- 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote: Perhaps --enable-webgl should instead implicitly disable the sandbox today I think this is better than having users manually disable it. They'll be running without a sandbox either way, but this (a) makes the enabling process less error-prone and (b) makes it more likely the sandbox will get turned back on eventually. 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] [WebGL] Recommending --no-sandbox
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. 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. 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? From a past thread on the subject: On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow jor...@google.com wrote: For the record, I'm very against publicly telling people to turn off the sandbox if you want to check out this really cool feature. Somewhat related: Maybe we need to do something really scary looking when the Sanbox is disabled to impress upon users running that way that they're in a very dangerous state. It could actually be useful to developers too; I've run without sandbox before and been very confused why things were working when they shouldn't be. I still think this is the right solution. -- 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow jor...@google.com wrote: 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. 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. 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? From a past thread on the subject: On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow jor...@google.com wrote: For the record, I'm very against publicly telling people to turn off the sandbox if you want to check out this really cool feature. Somewhat related: Maybe we need to do something really scary looking when the Sanbox is disabled to impress upon users running that way that they're in a very dangerous state. It could actually be useful to developers too; I've run without sandbox before and been very confused why things were working when they shouldn't be. I still think this is the right solution. Oh, and I filed this: http://code.google.com/p/chromium/issues/detail?id=24411 To be clear, I think this is the right solution because 1) some people might have already disabled the sandbox and forgotten about it and 2) in that interterm period, some people will just leave the flag on and they'll be insecure. I do agree that your suggestion is better than the status quo tho. And it's something we could do immediately. Of course, by the time the next dev channel build is out there (and thus we can change the instructions) it seems as though most of the damage will have already been done. 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] [WebGL] Recommending --no-sandbox
We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. 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. 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. 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? -Darin -- 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] [WebGL] Recommending --no-sandbox
I wonder... should we show an infobar on startup when the sandbox is disabled? On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. 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. 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. 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? -Darin -- 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 -- 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] [WebGL] Recommending --no-sandbox
That would be nice to have. Everyone agrees that is a critical option to turn on, so a light red tone info bar would be great for that. -Mohamed Mansour On Fri, Dec 11, 2009 at 12:49 AM, Finnur Thorarinsson fin...@chromium.orgwrote: I wonder... should we show an infobar on startup when the sandbox is disabled? On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. 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. 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. 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? -Darin -- 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 -- 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.org wrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- 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] [WebGL] Recommending --no-sandbox
I don't think we should take away --no-sandbox in official builds. It's a valuable debugging tool in case an end-user is experiencing a startup crash or other wackiness. I think we should just add a modal dialog at startup that you must dismiss each time you launch Chrome until you remove the --no-sandbox option. That should be annoying enough to cause people to remove it once they can. We don't need to expend energy on anything fancier IMO. -Darin On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote: We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox. There are legit reasons we have asked users to try temporarily disabling the sandbox, more frequently than for those other flags. I'd prefer to just make the UI turn ugly a la Jeremy's bug. It might even make sense to re-enable --single-process and use the same UI technique to discourage it. --single-process is buggy and not well tested, and can cause deadlocks in some scenarios. I think only developers should run without the sandbox, as those are the ones who'd be able to understand the risks in doing so, and are the only ones who need to test out features like webgl that aren't ready yet. So I still think we should disable --no-sandbox in shipping Google Chrome builds, and if someone needs it, they can use Chromium builds. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
