1269298 - Add ability to disable "share" related features - Pocket, context menu items, etc

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[YUKI "Piro" Hiroshi]

For enterprise use, SNS-related features to share something easily are now allowed by the administrator. Currently we can do it via userChrome.css and some addons, but after XUL is ended we need something to alter it.

Comment 1

[Andy McKay]

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.

Comment 2

[Shane Caraveo (:mixedpuppy)]

This isn't a socialapi issue, and specifically pocket is not socialapi.  This is an issue with locking down features for enterprise/distributions.  One element is to be able to disable addons, including system addons.  socialapi providers are merely a kind of addon.  disabling the ability to install addons would essentially disable socialapi.

Comment 3

[:Gijs (he/him)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> This isn't a socialapi issue, and specifically pocket is not socialapi. 

There is already a lockable pref for pocket.

> This is an issue with locking down features for enterprise/distributions. 
> One element is to be able to disable addons, including system addons. 

There are separate bugs for that - bug 1269294 and bug 1268407 come to mind.

> socialapi providers are merely a kind of addon.  disabling the ability to
> install addons would essentially disable socialapi.

But that wouldn't disable the 'share' and "send via email" button, would it?

Comment 4

[Shane Caraveo (:mixedpuppy)]

send via email is also not socialapi.  I think a more generic mechanism is needed to hide/remove ui elements.  It could be a set of prefs for each functional area (e.g. CUI):

lockdown.cui.buttons=id_list (hides these buttons)

or even more generic

lockdown.elements.ids=id_list (hides elements in the list)

Comment 5

[:Gijs (he/him)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #4)
> send via email is also not socialapi.  I think a more generic mechanism is
> needed to hide/remove ui elements.  It could be a set of prefs for each
> functional area (e.g. CUI):
> 
> lockdown.cui.buttons=id_list (hides these buttons)
> 
> or even more generic
> 
> lockdown.elements.ids=id_list (hides elements in the list)

That's not what the bug is about, and I don't think we should implement this. The bug is specific to 'share' features, which are not specific to toolbar buttons (e.g. context menus, sidebars, etc. come to mind).

I don't think we should implement this on a preference basis, and certainly not with a wide range of IDs (and then having to support all the breakage you could cause by e.g. locking down the location bar). That would allow unprivileged code on the user's machine to take the user's firefox profile hostage. IMO We should either go whole hog and implement group policy support, or wontfix.

The other thing to note is that a direct tie-in to UI element IDs is asking for problems. Any admins would have to continuously keep such a list up-to-date and it would be tied to Firefox internals, so if we changed the IDs of something, their setup would break and "accidentally" allow something they want to forbid. None of that is attractive.

Comment 6

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #4)
> > send via email is also not socialapi.  I think a more generic mechanism is
> > needed to hide/remove ui elements.  It could be a set of prefs for each
> > functional area (e.g. CUI):
> > 
> > lockdown.cui.buttons=id_list (hides these buttons)
> > 
> > or even more generic
> > 
> > lockdown.elements.ids=id_list (hides elements in the list)
> 
> That's not what the bug is about, and I don't think we should implement
> this. The bug is specific to 'share' features, which are not specific to
> toolbar buttons (e.g. context menus, sidebars, etc. come to mind).

I wasn't limiting it to buttons, that was an example and just one idea of a different approach.  In the larger picture, this is not about share features.  This is about turning off features that we (Mozilla) choose to implement that some Enterprise wants turned off or hidden.  We can pick them off one by one, or think about something more general that an enterprise can use on a locked down machine.

> That would allow
> unprivileged code on the user's machine to take the user's firefox profile
> hostage.

I'm taking a guess that if I can get executable code onto a users machine, I don't need this functionality.

> The other thing to note is that a direct tie-in to UI element IDs is asking
> for problems. Any admins would have to continuously keep such a list
> up-to-date and it would be tied to Firefox internals, so if we changed the
> IDs of something, their setup would break and "accidentally" allow something
> they want to forbid. None of that is attractive.

Well, this is what they already do.  Barring investing efforts into some kind of policy system, an easy way to handle it is to let them continue doing what they already do, even if in a slightly different way.

Comment 7

[Shane Caraveo (:mixedpuppy)]

Another idea.  We provide an enterprise distribution (easy to do, just another distro like our partner distros).  This distro includes a system addon that can hide/disable/etc stuff.  That addon could be contributed to by various enterprises to add functionality that is needed.

Comment 8

[Kris Maglione [:kmag]]

Closing all open bugs with the [design-decision-denied] whiteboard flag.