encouraging the users to disable the sandbox considered harmful
Paweł Hajdan, Jr.
(http://googlechromereleases.blogspot.com/2010/02/dev-channel-update_12.html)
again encourage users to disable the sandbox. There are even no
warnings about the risks.
Shouldn't the notes at least be updated to discourage disabling the
sandbox instead of encouraging it?
Jeremy Orlow
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Anthony LaForge
Anthony Laforge
Technical Program Manager
Mountain View, CA
Brian Rakowski
I was not taking this on, but I'll look into it. I don't believe there's been any discussion since we last talked about this in December so I'll circle back and figure out what we should do.
Peter was looking at a solution to warn of invalid flags, but I think he may have abandoned it because it was trickier than it seemed.
-Brian
Jeremy Orlow
[resending from chromium address]
I was not taking this on,
but I'll look into it. I don't believe there's been any discussion since we last talked about this in December so I'll circle back and figure out what we should do.
Peter was looking at a solution to warn of invalid flags, but I think he may have abandoned it because it was trickier than it seemed.
Peter Kasting
Peter was looking at a solution to warn of invalid flags, but I think he may have abandoned it because it was trickier than it seemed.
Antoine Labour
Peter Kasting
I seem to recall someone already had code to do this (was it you, Peter?). I think we should just check that in.
I also think that we should have a strict policy against blog posts that involve turning off the sandbox, and ideally ban that in the release notes as well as those get consumed by people who may have no clue. If it's not running without the sandbox, it's not ready to be advertised to people outside of chromium-dev IMO.
Darin Fisher
--
Viet-Trung Luu
better to run such dialogs inside the main message loop, which is late
in the startup sequence and at which point the main menu is probably
active. We run the importer dialog before that point, but it's pretty
seriously broken (Quit from the main menu doesn't work -- Cocoa is
really confused about what's in the main menu at that point). Adding
even more brokenness doesn't sound like a great idea.
- Trung
Darin Fisher wrote:
> What's wrong with just using MessageBox on Windows and the equivalents
> on other platforms? If we do this early enough, it should be fine (so
> that the message pumping performed by MessageBox does not cause nasty
> re-entrancy bugs).
>
> -Darin
>
>
> 2010/2/16 Peter Kasting <pkas...@google.com <mailto:pkas...@google.com>>
>
> On Tue, Feb 16, 2010 at 1:11 PM, Ian Fette (イアンフェッティ)
> <ife...@google.com <mailto:ife...@google.com>> wrote:
>
> I seem to recall someone already had code to do this (was it
> you, Peter?). I think we should just check that in.
>
>
> I think you're thinking of Evan's infobar code. That would probably
> be better than nothing. If no one is motivated to write a dialog,
> we should probably get Evan's code checked in.
>
> I also think that we should have a strict policy against blog
> posts that involve turning off the sandbox, and ideally ban that
> in the release notes as well as those get consumed by people who
> may have no clue. If it's not running without the sandbox, it's
> not ready to be advertised to people outside of chromium-dev IMO.
>
>
> I'm not sure I'd go that far, but I would agree that we shouldn't
> ever tell people to turn off the sandbox, and if we want some
> testing on a feature that requires it, we should build that into the
> feature, and only do it when we're "reasonably close" to being able
> to turn the sandbox on with it.
>
> PK
>
> --
> Chromium Developers mailing list: chromi...@chromium.org
> <mailto:chromi...@chromium.org>
Henry Bridge
On Tue, Feb 16, 2010 at 1:11 PM, Ian Fette (イアンフェッティ) <ife...@google.com> wrote:I seem to recall someone already had code to do this (was it you, Peter?). I think we should just check that in.I think you're thinking of Evan's infobar code. That would probably be better than nothing. If no one is motivated to write a dialog, we should probably get Evan's code checked in.I also think that we should have a strict policy against blog posts that involve turning off the sandbox, and ideally ban that in the release notes as well as those get consumed by people who may have no clue. If it's not running without the sandbox, it's not ready to be advertised to people outside of chromium-dev IMO.
I'm not sure I'd go that far, but I would agree that we shouldn't ever tell people to turn off the sandbox, and if we want some testing on a feature that requires it, we should build that into the feature, and only do it when we're "reasonably close" to being able to turn the sandbox on with it.
PK
Mike Mammarella
> I'm not sure I'd go that far, but I would agree that we shouldn't
> ever tell people to turn off the sandbox, and if we want some
> testing on a feature that requires it, we should build that into the
> feature, and only do it when we're "reasonably close" to being able
> to turn the sandbox on with it.
>
> We're reasonably close, should be a couple of weeks. Keep in mind
> that as Pepper APIs get implemented, this may happen again. As for
> building the --disable-sandbox into the flag, I'd only do that if we
> *do* have a sandbox down warning, otherwise it seems easy for people
> to copy and paste the --enable-X flag around the web without
> thinking about it.
The benefit of doing it this way, even without a warning, is that then
when the feature enabled by the flag no longer requires the sandbox to
be disabled, the code can be changed to stop disabling it when the
feature enable flag is given. But with an explicit --no-sandbox flag
alongside the feature enable flag, you can't just ignore it later on.
(Although, see vandebo's previous suggestion of --no-sandbox-
until=<date>.)
Nevertheless I support adding a warning. A dialog, an infobar, even a
mandatory black-and-yellow-stripe caution-tape theme. People should
not be doing this except temporarily to test something new, and they
should know they're doing it. We are probably inflating the threat a
little, but it would be a shame for attacks that only work if the
sandbox is disabled to show up some day because some reasonable
fraction of users have it disabled and forgot about it (or had it
disabled on their behalf and never knew).
--Mike
Jeremy Orlow
2010/2/16 Peter Kasting <pkas...@google.com>On Tue, Feb 16, 2010 at 1:11 PM, Ian Fette (イアンフェッティ) <ife...@google.com> wrote:I seem to recall someone already had code to do this (was it you, Peter?). I think we should just check that in.I think you're thinking of Evan's infobar code. That would probably be better than nothing. If no one is motivated to write a dialog, we should probably get Evan's code checked in.I also think that we should have a strict policy against blog posts that involve turning off the sandbox, and ideally ban that in the release notes as well as those get consumed by people who may have no clue. If it's not running without the sandbox, it's not ready to be advertised to people outside of chromium-dev IMO.Reminding people that the sandbox is off seems like a good idea, but please no blanket policy. I think people are over-inflating the threat here a bit. How many people consume release notes and blindly change flags just because they can? If we were providing a shiny new feature for users that required the sandbox to be down to work, I'd consider this dangerous, but not so much for a developer technology with no games to play yet :)