Closed
Bug 1269292
Opened 9 years ago
Closed 7 years ago
Add ability to disallow users to enable/disable addons
Categories
(Firefox :: Enterprise Policies, defect)
Firefox
Enterprise Policies
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox49 | --- | affected |
People
(Reporter: yuki, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [design-decision-denied]triaged)
For enterprise use, specific addons are always required to be activated. MCD (Mission Control Desktop) can disallow to install addons by `lockPref("xpinstall.enabled", false);` directive, but it doesn't prevent changing enabled/disabled state of addons by the user. Currently we can do it by disabling the addon manager itself by userChrome.css and others, but after XUL is ended we need something to alter it.
This is similar to the bug 1269288 but different.
Reporter | ||
Updated•9 years ago
|
Blocks: fx-enterprise
Updated•9 years ago
|
Whiteboard: [design-decision-needed]triaged
Reporter | ||
Comment 1•8 years ago
|
||
A sample plan of the API is here:
chrome.extensions.lock() // disallow to install/uninstall/enable/disable addons
chrome.extensions.unlock() // allow to install/uninstall/enable/disable addons
The subject says that about enabling/disabling, but the main demand of this API is for enterprise use. The list of active addons should be locked completely in such usecase.
Because the administrator restrict operations only by the user, the method can have an optional parameter to control the level of restriction: by the user, or by anyone (other addons, via APIs).
This API should require special permissions.
Blocks: webextensions-additional-apis
Reporter | ||
Comment 2•8 years ago
|
||
APIs to control addons by an addon is proposed at the bug 1269288
Comment 3•8 years ago
|
||
We don't plan on this API in WebExtensions. Moving over to Firefox to see if that's something that would happen through configuration of other means.
Component: WebExtensions: Untriaged → General
Product: Toolkit → Firefox
Whiteboard: [design-decision-needed]triaged → [design-decision-denied]triaged
Updated•8 years ago
|
Component: General → Add-ons Manager
Product: Firefox → Toolkit
Comment 4•8 years ago
|
||
Doing this in the Add-ons Manager would be simple enough, but to what would we expose this API? Webextensions has already refused (and would have an interesting chicken-and-egg problem if it was to be implemented there...)
Mike, any thoughts?
Flags: needinfo?(mozilla)
Comment 5•8 years ago
|
||
If it were me, I would do a preference whitelist and a preference blacklist (based on IDs), and then I would only honor that preference if it was locked (implying it was set by a system administrator).
That would be pretty straightforward - check if a given ID is in the list of allowed/disallowed IDs, and if so enable/disable it always.
Flags: needinfo?(mozilla)
Comment 6•8 years ago
|
||
Removing from webextensions-additional-apis, this belongs in some kind of policy system.
No longer blocks: webextensions-additional-apis
Updated•7 years ago
|
Component: Add-ons Manager → Enterprise Policies
Product: Toolkit → Firefox
Reporter | ||
Comment 7•7 years ago
|
||
I think this is covered by the policy "BlockAboutAddons":true, because we need to access to the addon manager to enable/disable addons.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•