managing the TCO of preferences/statefulness

[Benoit Jacob]

Hi,

Interesting blog post:

http://blog.mozilla.org/verdi/166/the-new-reset-firefox-feature-is-like-magic/

So there is a significant number of people for whom clicking a button
can suddenly make the browser better. How do we avoid getting there?

Part of what 'Reset Firefox' does is reset the preferences which is
the primary persistent state that we have from a platform perspective.

Currently, correct me if I'm wrong, we're very lax about preferences.
Just some examples:
* it's easy to get r+ for a patch that subtly changes the meaning of
an existing preference.
* when adding preferences, we're not very careful about whether the
state space contains "should never get there" states.
* we do not remove old no-longer-used preferences. They stay around
as unused state; if later we re-introduce a preference with the same
name, we lose.
* Preferences can be changed by add-ons, I believe.
* Can preferences be changed by third party applications, and do we
warn about that like we do for third-party-installed add-ons?

What can we do?

Random ideas:
* do we already do preference fuzzing?
* report on non-default-value preferences in crash reports, like we
do in about:support (check possible privacy issues, maybe filter
prefs)
* do not allow add-ons to change arbitrary preferences. Maybe do not
allow them to change real prefs at all, instead maybe just allow them
to install an 'overlay' that overrides preference values as long as
the add-on is enabled.
* delete no-longer-used preferences?
* check for self-conflicting preferences?
* improve prefs API e.g. add enum preferences which would be better
than plain integer preferences, string preferences, or multiple
boolean preferences, as we currently use to emulate the missing enum
preferences, creating many opportunities for corrupted state?

Benoit

[Justin Lebar]

> Random ideas:

I think most of these are probably solving a problem we don't have.

If we make prefs a big commitment (I promise never to change the
meaning, I promise to strictly error check, I promise to fix fuzz
bugs), I'll just hardcode in values that I really should use a pref
for.

Even for values I intend to be static, using a pref makes it easy to
deploy different values on desktop/mobile/b2g.

In general, the browser can break if you mess with the prefs enough.
I don't think this is a problem; we already display a pretty scary
warning when you open about:config. And add-ons can arbitrarily break
FF already; keeping them from breaking FF by modifying a pref doesn't
solve anything.

So I don't think we should make prefs harder for devs.

However, this

>  * do not allow add-ons to change arbitrary preferences. Maybe do not
> allow them to change real prefs at all, instead maybe just allow them
> to install an 'overlay' that overrides preference values as long as
> the add-on is enabled.

would be *incredibly fantastic*.

Unfortunately I think this is harder than it sounds. IIRC we can't
tell what's add-on code and what's Firefox code when we run chrome JS.
We certainly can't tell in binary components.

FWIW this is a hard engineering problem, but it's a comparatively
simple problem to address via AMO policy. We could get 80% of the way
there by saying that we'll take action against add-ons which don't
follow our rules wrt prefs. That would address the Big Players, like
Babylon Toolbar, which override awesomebar search prefs.

We'd probably have to do something like this anyway, because we have
no way to separate out existing prefs into an add-on's "overlay".
Overlays would solve the problem only for prefs modified after we add
overlays.

Those who follow this list know it's an understatement to say that I'm
pessimistic that we'd get anywhere by asking the AMO folks for help.
But I want to emphasize here how dysfunctional this situation is.

-Justin

[Mike Hommey]

On Mon, May 14, 2012 at 11:24:27PM -0400, Justin Lebar wrote:
> > Random ideas:
>
> I think most of these are probably solving a problem we don't have.
>
> If we make prefs a big commitment (I promise never to change the
> meaning, I promise to strictly error check, I promise to fix fuzz
> bugs), I'll just hardcode in values that I really should use a pref
> for.
>
> Even for values I intend to be static, using a pref makes it easy to
> deploy different values on desktop/mobile/b2g.

For such preferences, we could use bug 440908 and ship them as locked,
but with different values across different versions.

Mike

[Mook]

On 5/14/2012 8:24 PM, Justin Lebar wrote:

>> On 5/14/2012 7:20 PM, Benoit Jacob wrote:

>> * do not allow add-ons to change arbitrary preferences. Maybe do not
>> allow them to change real prefs at all, instead maybe just allow them
>> to install an 'overlay' that overrides preference values as long as
>> the add-on is enabled.
>
> would be *incredibly fantastic*.
>
> Unfortunately I think this is harder than it sounds. IIRC we can't
> tell what's add-on code and what's Firefox code when we run chrome JS.
> We certainly can't tell in binary components.

It can also be _easier_ than that; just make this opt-in (i.e. let the
extension get at the prefbranch/whatever in a way that's associated with
the extension). If you're using FUEL, for example, have an API like
Application.getExtensions(function(e)
e.get("bl...@example.com").prefs.setValue("hello", "world"));

This might be a trade-off though - if it's implemented as loading extra
user pref files on startup (one per extension), it might mean more
seeks. But then we can just not load them for uninstalled extensions,
and yet have them magically come back on reinstall.

--
Mook

P.S. Sorry for being mean and bringing up FUEL ;)

[Benoit Jacob]

2012/5/14 Justin Lebar <justin...@gmail.com>:

>> Random ideas:
>
> I think most of these are probably solving a problem we don't have.
>
> If we make prefs a big commitment (I promise never to change the
> meaning, I promise to strictly error check, I promise to fix fuzz
> bugs), I'll just hardcode in values that I really should use a pref
> for.
>
> Even for values I intend to be static, using a pref makes it easy to
> deploy different values on desktop/mobile/b2g.
>

> In general, the browser can break if you mess with the prefs enough.
> I don't think this is a problem; we already display a pretty scary
> warning when you open about:config.  And add-ons can arbitrarily break
> FF already; keeping them from breaking FF by modifying a pref doesn't
> solve anything.

But in addition to the user messing with prefs, and add-ons messing
with prefs, there is also the case of us platform developers messing
with prefs. I hear you about not making prefs harder for us, but how
about this:

> * report on non-default-value preferences in crash reports, like we
> do in about:support (check possible privacy issues, maybe filter
> prefs)

For example, in Firefox 11 we were within hours of having to delay the
release due to a top-crasher (bug 711656, bug 715401) that was caused
by a preference having changed meaning subtly. If we had had modified
preferences in crash reports, the bug would have been obvious, but
without that, it's mostly due to luck that we identified the problem.

If preference _values_ are too privacy-sensitive, put at least
preference names in public crash reports. Also, many preferences are
not privacy-sensitive at all so maybe add an API to allow specifying
that.

Likewise,

> * delete no-longer-used preferences?

Should not make it harder to use preferences,

> * check for self-conflicting preferences?

Should only be a matter of having to specify which preference
combinations are incompatible,

> * improve prefs API e.g. add enum preferences which would be better
> than plain integer preferences, string preferences, or multiple
> boolean preferences, as we currently use to emulate the missing enum
> preferences, creating many opportunities for corrupted state?

Should be making developers' life easier, not harder, by providing
support for something we currently have to emulate in other ways.

Example of a enum preference emulated as multiple bool preferences:
webgl.disabled and webgl.force-enabled. We've had to answer several
times the question "what if they are both true?". Same for
layers.acceleration, gfx.direct2d, etc.

Example of a enum pref emulated as integer preference: all the
gfx.blacklist.* preferences. If we could have specified a symbolic
constant (stored as a string) instead of a raw numeric value, we
wouldn't have had the above-mentioned bug 711656.

Cheers,
Benoit

>
> So I don't think we should make prefs harder for devs.
>
> However, this
>

>>  * do not allow add-ons to change arbitrary preferences. Maybe do not
>> allow them to change real prefs at all, instead maybe just allow them
>> to install an 'overlay' that overrides preference values as long as
>> the add-on is enabled.
>
> would be *incredibly fantastic*.
>
> Unfortunately I think this is harder than it sounds.  IIRC we can't
> tell what's add-on code and what's Firefox code when we run chrome JS.
>  We certainly can't tell in binary components.
>

[Justin Lebar]

> * check for self-conflicting preferences?
>
> Should only be a matter of having to specify which
> preference combinations are incompatible,

Sure, specifying the combination as incompatible is relatively simple
once you know that the combination is incompatible.

But like I said, I don't think our goal should be to make Firefox work
with arbitrary preference values. If that were our goal, then surely
we'd hardcode in more magic numbers instead of specifying them as
prefs; that would be a net loss.

(For example, I often have imagelib bugs which are easy to test for by
moving a pref to an extreme value. If I hardcoded all these values
because these prefs could break things, I'd lose my ability to test on
released builds.)

What would specifying and testing the domain of acceptable preferences
buy us? I contend this is more work than you seem to think it would
be...

-Justin

[Justin Lebar]

On Tue, May 15, 2012 at 1:27 AM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> Babylon Toolbar isn't on AMO.  Nor are many of the badly behaved add-ons.
>
> It might still be a good thing to have as AMO policy, but it would
> just further increase the enforced quality gap between AMO and non-AMO
> add-ons.

I didn't mean to imply that the policy would be AMO-only. We have
policies for non-AMO add-ons too. For example, they can't crash
Firefox or cause "excessive" performance degradation.

We claim that many of these add-on authors are our "partners". It
seems reasonable to me that we might ask them to use a specific prefs
API.

I'd argue that we should enforce this through policy, but I expect
that would be a non-starter with the add-ons folks.

[Jorge Villalobos]

On 5/14/12 8:20 PM, Benoit Jacob wrote:
> * do not allow add-ons to change arbitrary preferences. Maybe do not
> allow them to change real prefs at all, instead maybe just allow them
> to install an 'overlay' that overrides preference values as long as
> the add-on is enabled.

This is already a policy we apply for AMO add-ons. They are not allowed
to changes preferences unless it is necessary for their functioning and
it doesn't surprise users.

If they set the preference changes in the default preferences file (the
recommended way), once the add-on is uninstalled the modified
preferences will change back to their original value. It's worth noting
that we have special warnings for preferences that we know shouldn't be
changed or that have been problematic in the past (home page, user
agent, etc.), so other preference changes might be overlooked.

Jorge

[Jorge Villalobos]

On 5/14/12 8:20 PM, Benoit Jacob wrote:

> * do not allow add-ons to change arbitrary preferences. Maybe do not
> allow them to change real prefs at all, instead maybe just allow them
> to install an 'overlay' that overrides preference values as long as
> the add-on is enabled.

[Benjamin Smedberg]

On 5/14/2012 10:20 PM, Benoit Jacob wrote:
> * Preferences can be changed by add-ons, I believe.

Sure, addons can do anything. We encourage them to change the default
preference values by providing a default pref file (in
<extension>/defaults/preferences). This is better than setting "user"
pref values because when the user disables the extension those values
are no longer present.

Extensions also use preferences as a place to store their own custom
key/values pairs, in which case they are using user preferences.

> * Can preferences be changed by third party applications, and do we
> warn about that like we do for third-party-installed add-ons?

Preferences are stored in the user profile. Sufficiently evil 3rd-party
apps could simply read/write this file with different contents, yes.
There is almost nothing we can do about this.

> * report on non-default-value preferences in crash reports, like we
> do in about:support (check possible privacy issues, maybe filter
> prefs)

We absolutely cannot report the values of non-default preferences: that
would violate all kinds of privacy principles. We could talk to the
privacy folk about reporting the keys of modified preferences, but there
are all kinds of variables here that make this difficult. And we'd still
probably need to keep that data private so that only a small subset of
people could see the key names, because they can probably be used to
correlate reports.

> * do not allow add-ons to change arbitrary preferences. Maybe do not
> allow them to change real prefs at all, instead maybe just allow them
> to install an 'overlay' that overrides preference values as long as
> the add-on is enabled.

Many addons store their own preferences. For SDK-based addons we could
perhaps segregate the user values saved by that addon from user values
stored by Firefox itself, but in the general case we cannot do that,
because we don't know what code is calling into the preference service.
> * delete no-longer-used preferences?
Defining what a no-longer-used preference is very hard, and will affect
addons. Just because a user disables an addon temporarily does not mean
that they want all their addons preferences to be thrown away.

> * check for self-conflicting preferences?

> * improve prefs API e.g. add enum preferences which would be better
> than plain integer preferences, string preferences, or multiple
> boolean preferences, as we currently use to emulate the missing enum
> preferences, creating many opportunities for corrupted state?

I really don't think we actually have a huge problem to solve here.
Enums might be nice, but in terms of storage and backwards compatibility
we'd probably continue to just store them as integers and make the API
for fetching them do some bounds checking so that invalid values get
ignored and we use a reasonable default instead (perhaps with a console
warning).

--BDS