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. 2) Info bar. This seems like one of the more popular options at the moment. The main problem is what to do when there are multiple info bars that need to be displayed...for example with session restore. Also there's the problem of users leaving the browser open for a long time. We could periodically re-show the info bar, but that seems clunky. 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? 4) Add some warning to the new tab page. Once again, no one's really thought about this seriously. Any thoughts? I think I'm going to take a stab at one of these in the next week or two. On Fri, Dec 11, 2009 at 12:16 PM, Alice Lin <[email protected]> wrote: > 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 > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
