508109 - Firefox Allows Hidden Extensions (e.g., Java Console)

Status: RESOLVED FIXED

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

Description

[Catherine C. Brady]

Certain extensions are hidden to users.  Need to understand why and how this can be changed.

Firefox shouldn't allow hidden extensions.

--- First Response:
Determine why Firefox allows hidden extensions

--- First Response Timeframe:
Few weeks

--- Business Objective:


--- Other Party:
N/A

Comment 1

[Justin Scott [:fligtar]]

Dave's response was:

So fundamentally, if an extension wants to hide itself there is little we can do to stop it. There would be any way around any roadblocks that we put in place to stop it given the power that extensions have. Originally I think the point of hidden extensions was to allow for system administrators to include items in the Firefox install that users then wouldn't be able to tamper with. As it happens there are other ways to do this now and removing the hidden property that I think Java Console uses is on my lists of things I want to do. See also https://wiki.mozilla.org/Extension_Manager:Install_Locations

Comment 2

[Catherine C. Brady]

1. Determine if there are compelling reasons for Firefox to support hidden
extensions.

2. If no compelling reason, work to address this issue and expose all hidden
extensions to the users.

3. If so, disclose this in the Privacy Policy.  Create a means for a user to
determine what hidden extensions he/she has.

Comment 3

[Mike Shaver (:shaver emeritus)]

I see no reason to hide extensions, but I don't think it bears on our Privacy Policy?  Would be happy to see us get rid of em:hidden or whatever!

Comment 4

[Catherine C. Brady]

Great.  What will be the next steps:
1. to get rid of these hidden extension?
2. How will existing users who currently have the hidden extension be impacted?  Best result: will now show under their preferences.

Comment 5

[Dave Townsend [:mossop]]

I'm happy to remove the hidden attribute (the bit that allows extensions installed by local applications and system administrators to be hidden), but I'd like to know just what problem we're trying to solve here and why first.

Comment 6

[Benjamin Smedberg]

Why is this bug private? This sounds like a product decision that should be public.

The hidden attribute was added so that system administrators (and specifically the CCK) can customize Firefox without having the extension show up and confuse users. I think this use-case is certainly still valid, but it can probably be satisfied just as easily by putting the extension in appdir/distribution/bundles.

I'm pretty sure we only honor em:hidden for app-install locations, not registry-installs or profile locations... Dave is that correct? I would without hesitation recommend that.

Comment 7

[Mike Shaver (:shaver emeritus)]

When administrators install other software on a controlled system, it shows up for the user to see.  We typically refer to software that hides itself from the user as being a rootkit.

I don't think that we should be optimizing for the case of CCK-deployed users being confused because their add-ons window contains something labelled "Shaver Industries Customizations".  Having these hidden changes makes their use of our support community more difficult, and bugs they file less useful.

We should list all the add-ons that a user has installed, regardless of which esoteric means are used to install them, because it's a simple(r) way for them to communicate differences from the stock build, and because it's in like with our values of clarity and user information.

I feel, quite strongly, that we should remove support for the hidden attribute and just be done.  Making it easier for administrators to make "silent" modifications to the product is a non-goal, and not something that we should have any complexity in our software to support.

Comment 8

[Mike Shaver (:shaver emeritus)]

I don't understand why it's private either, or what it has to do with our privacy policy or EULA.  Seems like a product bug, not a Legal one, to me.

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #6)
> I'm pretty sure we only honor em:hidden for app-install locations, not
> registry-installs or profile locations... Dave is that correct? I would without
> hesitation recommend that.

We currently honour em:hidden for extensions in the application dir, the system install locations (global not per user) and the registry (global not per user)

(In reply to comment #8)
> I don't understand why it's private either, or what it has to do with our
> privacy policy or EULA.  Seems like a product bug, not a Legal one, to me.

This is what I'd like better understanding on. I'm fine with removing the hidden attribute, just want to make sure there isn't some reason for the discussion that I'm missing, especially since it is still possible for extensions to hide themselves after we do this.

Comment 10

[Catherine C. Brady]

This discussion arose out of another legal bug about whether some information could be disclosed under our Privacy Policy.  In the course of understanding the data that metrics wanted to disclose, and how it was collected, I found out this hidden extension, which seemed antithetical to Mozilla's open policy.

So, to follow-up, I wanted to find out if there was a compelling reason to allow hidden extensions - especially ones that attach without the user knowing about it.  If there was a compelling reason, and we decided to keep this functionality, I felt that this should be disclosed in the Firefox Privacy Policy.  Again in keeping with our goals of transparency and giving the user as much information as possible.

I think that I can close out this as a legal bug and the discussion can continue in a product bug.  May I be copied on the new bug?

Comment 11

[Benjamin Smedberg]

This is the product bug now.

Which privacy policy are we talking about? I didn't know we had a product privacy policy (I certainly don't see anything in the Firefox UI).

Comment 12

[Reed Loden [:reed]]

(In reply to comment #11)
> Which privacy policy are we talking about? I didn't know we had a product
> privacy policy (I certainly don't see anything in the Firefox UI).

http://www.mozilla.com/en-US/legal/privacy/firefox-en.html

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #6)
> The hidden attribute was added so that system administrators (and specifically
> the CCK) can customize Firefox without having the extension show up and confuse
> users. I think this use-case is certainly still valid, but it can probably be
> satisfied just as easily by putting the extension in
> appdir/distribution/bundles.

I think that it makes sense for any extension that the administrator wants to make a fundamental part of the app should just go in as a bundle rather than an extension. The only downside is that some extensions can't be included like that since they rely on the EM API to find their install location or version. I don't think that that is enough of a reason to stop us removing the hidden support though.

Comment 14

[Dave Townsend [:mossop]]

Songbird are currently using hidden extensions in their application directory and from the looks of things it would be problematic for them to switch to the bundle mechanism. Going to try to figure out what their needs exactly are.

Comment 15

[Stephen Lau]

I emailed some of this to Dave already, but figured it would be worth posting here in the bug as well.

We use hidden extensions for a couple of different use cases, but none of which couldn't be satisfied by hiding them via a CSS rule overlaid into the XUL for the add-ons manager.

I talked with a few other Songbirders about it today and I think we can manage without <em:hidden/> extensions.  Thanks!

Comment 16

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This drops support for hidden items. It no longer imports the hidden property on install and also ignores it in the UI for any items that already have it.

Comment 17

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/87bd1c2b832d

Comment 18

[Dave Townsend [:mossop]]

Comment on attachment 400026 [details] [diff] [review]
patch rev 1

Risk free patch that we should get onto the branch before beta.

Comment 19

[Daniel Veditz [:dveditz]]

nom'ing for blocking even.

cc'ing Kev to make sure partner packs don't get blindsided by this (I assume they use bundles already).

Comment 20

[Kev Needham [:kev]]

thx dveditz, repacks are unaffected, as all customizations are done via the distribution/ directory and/or bundled extensions that are visible. no issues.

are we going to post about this anywhere so orgs that may incorporate it with their releases are aware of the change?

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

Kev: where do you think those orgs would look? We should blog on Planet, of course, but what related documentation should be updated?

Comment 22

[Kev Needham [:kev]]

I don't know how often we remove functionality vs. adding it, but think it's worth calling out when features that are expected disappear (which we usually do). At a minimum, https://developer.mozilla.org/en/Install_Manifests should be updated to reflect it, but having it in the FAQ or a version changelog would be good, too.

Comment 23

[Dave Townsend [:mossop]]

Landed on branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/90b9680ef71d

Comment 24

[Eric Shepherd [:sheppy]]

Documentation updated:

https://developer.mozilla.org/en/Install_Manifests#hidden