668999 - xpinstall.enabled is supposed to be a kill switch, not prompt for re-enabling

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Daniel Veditz [:dveditz]]

xpinstall.enabled = false is not the default setting and there is no UI for that setting. If it's turned off it's been turned off 1) by someone who knew what they were doing and 2) who definitely wanted it that way. We should not prompt users with an easy button to re-enable. I believe the prompt was added when we took away UI for the disable checkbox in fear of people who wouldn't know how to re-enable. It should have been a one-time thing to get people back to the default state. In any case, anyone who has it disabled now really wants it that way.

IMHO we should silently fail and not prompt at all, but if that's too mysterious I could live with something like xpinstallDisabledMessageLocked that is non-interactive. Since about:addons has a "Get Add-ons" tab either that would need to be disabled (with a replacement pane/message?) or you would need the DisabledMessageLocked prompt in at least that case.

xpinstall.enabled = false should also apply to auto-discovery and install of local add-ons, both global and per profile. Since we have a separate "update addons" pref that functionality can be kept separate.

Comment 1

[David E. Ross]

I definitely disagree.  I set xpinstall.enabled to "false" as a safety measure, to prevent inadvertent installation of an add-on.  When I go to install or update an add-on manually, I definitely do want the option to enabling the installation.  The current prompt provides that option.  Eliminating the UI for this does not serve the users.

Comment 2

[Mike Kaply [:mkaply]]

Dan, i totally agree with you.

David, that's an interesting idea, but I bet you would be hard pressed to find anyone besides you that even knows this preference exists and what setting it does.

And you really can't "inadvertently install an add-on" - you'll get a dialog that pops up with a timeout that you can cancel at that point. 

What administrators do now is to lock the preference and then it works as expected.

But the reality is it is quite silly we have a preference that disables xpinstall and when you disable it, it pops up and says "I'm disabled, do you want to enable me"

There is a much bigger issue which you brought up which is that is that when xpinstall is disabled (and even locked), you can still install add-ons via the the and I believe you can also open local XPIs.

There needs to be a global way to prevent users from installing XPIs.

Comment 4

[Mike Kaply [:mkaply]]

See also bug 657150

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Michael Kaply (mkaply) from comment #2)
> you can still install add-ons via
> the the and I believe you can also open local XPIs.

Via the.... ?

Comment 6

[Mike Kaply [:mkaply]]

Oops :)

via the add-ons manager.

You can still search AMO and install add-ons and you can use the Get Add-ons tab.

You can also select Install add-on from file.

Turning off xpinstall should turn off the ability to install add-ons completely.

Comment 7

[O. Atsushi (Torisugari)]

What happens an extension tries to update itself with the flag disabled? Blocked?

(In reply to Michael Kaply (mkaply) from comment #2)
> David, that's an interesting idea, but I bet you would be hard pressed to
> find anyone besides you that even knows this preference exists and what
> setting it does.

I'm afraid it's not that hard, since bug 310737 had 45 dupes at that time. This bug can be easily crowded with spam-like posts. If pref locking is too troublesome for enterprise users, I think we need a new mechanism. Boolean -> Int, or a new pref key to suppress the dialog.

Comment 8

[Mike Kaply [:mkaply]]

> What happens an extension tries to update itself with the flag disabled? Blocked?

No, that's not an install. That's an update.

> I'm afraid it's not that hard, since bug 310737 had 45 dupes at that time.

You realize that bug was six years ago?
And the reason it had dupes is because it was really screwed up in Firefox 1.5.
This isn't Firefox 1.5.


There are multiple issues in this bug which should probably be split out:

1. xpinstall.enabled (whether disabled or locked) doesn't affect the add-ons manger.

2. xpinstall.enabled is poorly named since when xpinstall is disabled, you can still enable with one click

3. xpinstall.enabled should disallow local file installs.

Comment 9

[O. Atsushi (Torisugari)]

(In reply to Michael Kaply (mkaply) from comment #8)
> You realize that bug was six years ago?
> And the reason it had dupes is because it was really screwed up in Firefox
> 1.5.
> This isn't Firefox 1.5.

Hmmm. Probably you are right. |xpinstall.disabled| is not useful.


> There are multiple issues in this bug which should probably be split out:
> 
> 1. xpinstall.enabled (whether disabled or locked) doesn't affect the add-ons
> manger.
> 
> 2. xpinstall.enabled is poorly named since when xpinstall is disabled, you
> can still enable with one click
> 
> 3. xpinstall.enabled should disallow local file installs.

1. and 3. are almost identical because <browser.js> actually blocks local files with |xpinstall.enabled| off. But, yes, 1. and 2. are different.

And |xpinstall.whitelist.required| should be able to block local files instead. And if you are to save David, the one click UI should work for |xpinstall.whitelist.required| instead of |xpinstall.enabled|. Then nobody except for enterprise users will use |xpinstall.enabled|.

Comment 10

[Richard van den Berg]

I just found that add-ons can still be installed through the add-on manager when |xpinstall.enabled| is false and locked. This is a horrible scenario in a managed environment. Even with xpinstall.whitelist.required set to true (default) and xpinstall.whitelist.add set to example.com (default is addons.mozilla.org) users can still install add-ons using the add-ons manager interface.

Why does the add-ons manager not respect these preferences? Is this by design?

Comment 11

[Mike Kaply [:mkaply]]

> Why does the add-ons manager not respect these preferences? Is this by design?

I'm sure it was just an oversight. When the add-on manager design happened, folks weren't aware of what the install.enabled preference did when it was locked.

Comment 12

[Richard van den Berg]

The severity of this bug is made worse by bug 601442 because the Get Add-ons pane can no longer be hidden.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Does the pref locking (http://kb.mozillazine.org/Locking_preferences) work anyway? I'm unable to get it working. The value can be still changed in about:config.

Comment 14

[Mike Kaply [:mkaply]]

(In reply to Martin Stránský from comment #13)
> Does the pref locking (http://kb.mozillazine.org/Locking_preferences) work
> anyway? I'm unable to get it working. The value can be still changed in
> about:config.

It was working as of Firefox 13. How are you locking the preference?

I provide a lot of detail on this here:

http://mike.kaply.com/2012/03/16/customizing-firefox-autoconfig-files/

Comment 15

[Martin Stránský [:stransky] (ni? me)]

The variable locking is broken in latest trunk, works as expected in Firefox 14. Filled as Bug 776490.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Follow up bug - Bug 815120 - xpinstall.enabled=false still allows to install xpi via. addon search bar

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Actually I believe it can be dangerous for admins to fix this bug. The real deal is to lock the xpinstall.enabled and when it's locked the enable prompt is not shown. Without the locking admins can have false feel of disabled addons.

Comment 19

[O. Atsushi (Torisugari)]

> when it's locked the enable prompt is not shown.

Yeah, that's what bug 310737 did. This bug is something left out of it.

I'm not too sure, but there should exist many dialogs which change prefs, besides |xpinstall.enabled|. And basically they should check locked or not before prompting them. The problem is, even if this bug is fixed, we will make another left-out some day.

Probably "when it's locked the enable prompt is not shown." is a little too complicated, though I don't have a good idea.

Comment 20

[Richard van den Berg]

(In reply to Martin Stránský from comment #18)
> The real
> deal is to lock the xpinstall.enabled and when it's locked the enable prompt
> is not shown. 

This is of course true for managed installs, but it makes no sense in unmanaged situations. Since there is no UI for locking prefs, if I set |xpinstall.enabled| because I share my Firefox with other people, I don't want or expect those people to get a prompt to re-enable it. Similarly, if I set |permissions.default.image| to 2 I also do not expect a prompt "Do you want to enable loading images by default?" every time a page contains an image.

> Without the locking admins can have false feel of disabled addons.

All set but unlocked prefs give a false feel in your reasoning. Unlocked but changed prefs mean "Default chosen by admin, but user can override this when needed" but not "Default chosen by admin, but Firefox will prompt to revert this" IMHO.

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

dveditz, is this still the case that you want the default behavior for this preference prompt to change? It came up in our testday today. Thanks!

Comment 22

[Daniel Veditz [:dveditz]]

Yes. I plan on looking into this as part of other add-on work I'm looking at.

Comment 24

[Buck Manhands]

It would be really great as a parent to be able to keep my kids from installing add-ons with something this simple, and this should do the trick if it actually did what it said. It is absurd to think that xpinstall.enabled||false would then simply prompt the user to turn installation back on without an administrator password. I can't think of a scenario where this would be useful, but I can think of hundreds of scenarios where easily disabling the installation of add-ons without an administrator password would be extremely useful.

Comment 25

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 26

[Mike Kaply [:mkaply]]

Since we now have the ability to block extension installs via policy that doesn't rely on this policy, solving the xpinstall.enabled locking problem, I'm going to close this bug as WONTFIX.

It's not worth trying to change xpinstall.enabled behavior at this point, and we provide easier ways to prevent addon installs.