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.org>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 <j...@chromium.org>wrote:
>
>>
>>
>> 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.org>wrote:
>>>
>>>>
>>>>
>>>> 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.com>wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> 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
