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 <[email protected]>wrote: > (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 <[email protected]>wrote: > >> >> >> On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher <[email protected]>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 >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow <[email protected]>wrote: >>>> >>>>> On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting >>>>> <[email protected]>wrote: >>>>> >>>>>> On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek >>>>>> <[email protected]>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. >>>>>> >>>>> >>>>> 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 | [email protected] 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
