Closed Bug 1144127 Opened 9 years ago Closed 9 years ago

Remove support for distribution/bundles

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

(Keywords: addon-compat)

Attachments

(1 file)

distribution/bundles is now actively being used to install malware and hijack Firefox settings. I believe it is time to remove this feature.

There have been prior discussions about this since this is also being used for various custom/enterprise settings, but I don't think there's an automated way to distinguish those cases and so I don't plan on providing a direct replacement for this feature. mconnor can you please confirm.
Flags: needinfo?(mconnor)
Attachment #8578671 - Flags: review?(dtownsend)
Please don't rush this in. This is going to be a MAJOR issue for enterprise.

This is the standard mechanism enterprises use to deploy extensions. I'm working on a better way for the CCK2, but it's not ready yet.
It it possible to cause a chrome.manifest load via Javascript?

As in, would it be possible to put distribution/bundles support into an AutoConfig script?
I'm not sure how comfortable I am with enterprises silently installing add-ons as a general rule.  I get some of the use-cases, but it's still a concern from a brand reputation perspective.

That said, assuming this isn't hitting until Firefox 39, and thus not hitting ESR until 45, I think it's fine.  We'll just roll this into any planning/communication we do around the enterprise solution for signing add-ons.
Flags: needinfo?(mconnor)
> I'm not sure how comfortable I am with enterprises silently installing add-ons as a general rule.  I get some of the use-cases, but it's still a concern from a brand reputation perspective.

It shouldn't be a concern at all. The enterprise (or school, kiosk, web cafe, govt office) has control over the user's machine. They should be able to do what they need. I'll certainly be happy to publish how to write an extension that hides itself from the Add-ons Manager if that's what you'd prefer I do.

From the very beginning, you guys said you would prefer enterprises not use the ESR. It was supposed to be a backup.

But at every turn, you implement things in the mainline that make it impossible for people to use the rapid release for enterprise.

So are we now officially acknowledging that the ESR will be around forever?
Comment on attachment 8578671 [details] [diff] [review]
1144127-distributionbundles

Review of attachment 8578671 [details] [diff] [review]:
-----------------------------------------------------------------

r+ from a code standpoint, I leave you and mconnor to figure out if this is the right choice or not though ;)
Attachment #8578671 - Flags: review?(dtownsend) → review+
(In reply to Mike Kaply [:mkaply] from comment #5)
> > I'm not sure how comfortable I am with enterprises silently installing add-ons as a general rule.  I get some of the use-cases, but it's still a concern from a brand reputation perspective.
> 
> It shouldn't be a concern at all. The enterprise (or school, kiosk, web
> cafe, govt office) has control over the user's machine. They should be able
> to do what they need. I'll certainly be happy to publish how to write an
> extension that hides itself from the Add-ons Manager if that's what you'd
> prefer I do.

Plenty of those tutorials exist, mostly for malware writers.  That it's possible at all is a bug, not a feature. Overall, the lack of transparency is my primary concern, as we're letting third parties make invisible changes that users will associate with Firefox.

> From the very beginning, you guys said you would prefer enterprises not use
> the ESR. It was supposed to be a backup.
> 
> But at every turn, you implement things in the mainline that make it
> impossible for people to use the rapid release for enterprise.
> 
> So are we now officially acknowledging that the ESR will be around forever?

Not yet, but it's definitely something that needs to be discussed as we look to better protect consumers from malware.  It may be better to commit to ESR long term and allow some very well-scoped divergence.  The tradeoffs we're looking at now are significantly different than in the early days of ESR.  Those changes won't hit 38, so we have the rest of 2015 to decide whether we should refine our approach to the enterprise market.
(In reply to Mike Connor [:mconnor] from comment #7)

> Not yet, but it's definitely something that needs to be discussed as we look
> to better protect consumers from malware.  It may be better to commit to ESR
> long term and allow some very well-scoped divergence.  The tradeoffs we're
> looking at now are significantly different than in the early days of ESR. 
> Those changes won't hit 38, so we have the rest of 2015 to decide whether we
> should refine our approach to the enterprise market.

No, you have to decide it before this change goes in.

Because if you aren't going to commit to the ESR having things that enterprises need, people need to know now so they can start looking for alternatives to Firefox.
How about leaving distribution/bundles for ESR and for ESR only? That way, the ordninary user has not to deal with malware while the enterprises still can rollout _preconfigured_ browsers with security enhancing addons (noscript, adblock).

Representing an enterprise with 700 users, the transition 17 ESR -> 24 ESR was very smooth, but the migration 24 ESR -> 31 ESR was already almost too diffcult for us. Don't leave us behind.
(In reply to Mike Kaply [:mkaply] from comment #8)
> (In reply to Mike Connor [:mconnor] from comment #7)
> 
> > Not yet, but it's definitely something that needs to be discussed as we look
> > to better protect consumers from malware.  It may be better to commit to ESR
> > long term and allow some very well-scoped divergence.  The tradeoffs we're
> > looking at now are significantly different than in the early days of ESR. 
> > Those changes won't hit 38, so we have the rest of 2015 to decide whether we
> > should refine our approach to the enterprise market.
> 
> No, you have to decide it before this change goes in.

This change is going in, it's being actively abused by malware in the wild.  The enterprise use case doesn't trump overall security of our users.

> Because if you aren't going to commit to the ESR having things that
> enterprises need, people need to know now so they can start looking for
> alternatives to Firefox.

38 ESR will be supported until May 31, 2016.  I'm obviously not planning to wait until December, but there's no reason to rush into a decision on the future of ESR and whether/how we'll diverge from the baseline release.
I've already found a workaround that allows things to continue to be loaded from the distribution/bundles via AutoConfig. I'll be integrating that into the CCK2.
Worth noting: if you can use it for good, others can use it for evil.  I wouldn't bank on that workaround staying intact for any length of time.
(In reply to Mike Connor [:mconnor] from comment #12)
> Worth noting: if you can use it for good, others can use it for evil.  I
> wouldn't bank on that workaround staying intact for any length of time.

Then you'll need to rewrite Firefox in 100% C/C++.
Keywords: checkin-needed
Keywords: checkin-needed
And of course AutoConfig can be used for evil. Everything can be used for evil.

Until support is added for Group Policy on Windows and MCX on Mac, we're stuck with it.
As a personal user, I like Firefox - been there since Netscape 1.x, but as an institutional administrator for more than 1000 computers with Firefox installed, these sorts of changes cause me no end of hair-pulling - there is already pressure from other admins to stop using Firefox due to the IMMENSE amount of work required to prepare Firefox for users with preconfigured mandatory profiles.  Out students don't own persistent settings, and very few of them would sit through initial profile and extension configuration every time they approached the computer.  With >80,000 active students we'll never have the resources to allow for persistent profiles.

What I don't understand is how distribution/bundles can be used as a malware vector without having administrative rights over the computer (isn't located under C:\Program Files?).  If admin rights are required, then malware has a million vectors and this is just low hanging fruit.  Malware will move on to the next hook.  But for enterprise admins this stuff isn't optional.

Chrome and IE have the required administrative hooks for our environment.  Firefox ESR is the bone you're throwing us to "kinda" keep this manageable.  Closing this stuff down, you might as well kill ESR completely as far as I'm concerned.

Sorry to vent, but Mozilla SO DOESN'T get this.  Too focused on pursuing the Mozilla mission and losing your followers along the way.  I support the mission, but you're putting us in a place where we CAN'T follow.
Hi Mark, the tl;dr is that yes, there are many paths to abusing users with admin access, but our goal is to draw a clear line between "normal and acceptable" and "bad and abusive" approaches, so security software has an objective standard for recognizing badness. distribution/bundles is an extremely powerful mechanism that abuse, and for our consumer users (by far the majority) the right thing is to not support 

ESR is something that, between signing and bundle support, has a set of needs that is rapidly diverging from the needs of Firefox as a consumer app.  No major changes will happen in 38, giving us time to re-evaluate our current approach to ESR and the enterprise use case.
Hi Mike, Thanks and I appreciate your mission, your priorities, resource limitations and even the intention or this change.  But, I truly believe this divergence (lack of accommodation?) is also a huge problem for Mozilla, not just us "small" set of enterprise users.

The educational enterprise sector is the one you'll lose first.  We have the least resources and a fixed school-year planning and implementation cycle that are the hardest hit.  Frankly, a "we change this on the mainstream and we have x cycles of ESR to figure out a new solution" will cause many of us to change course to avoid getting boxed in when our deadlines approach and ESR isn't "fixed".

I strongly believe this is a problem for Mozilla, as a lot of users are introduced to Firefox in an education environment as students.  Most people are lasy and take the easiest option, even if that is IE (blech!).  I know usage patterns swung wildly here when we switched away from Firefox as the default webbrowser (we have been supporting IE, Firefox and Google Chrome).
I do get the concern, and it's my expectation that we'll know the future of ESR sometime in the summer.  In the meantime, the patch should likely be in the form of a build switch so we don't have to dig super deep to resurrect it.

As I've said multiple times, it's clear that we need to evaluate the impact of our moves to protect consumers in the context of the enterprise use-cases.  This bug isn't the right context to discuss it, however, the right place will be on the enterprise mailing list: https://mail.mozilla.org/listinfo/enterprise

It's a little hectic on a few fronts right now, but it's something we'll want to start discussions on in the next month.
Flags: needinfo?(jlal)
(In reply to Mike Connor [:mconnor] from comment #18)
> I do get the concern, and it's my expectation that we'll know the future of
> ESR sometime in the summer.  In the meantime, the patch should likely be in
> the form of a build switch so we don't have to dig super deep to resurrect
> it.
Where has the build switch gone?
Flags: needinfo?(mconnor)
I would like to echo the concerns of Mike K and Mark L.  Our entire business is dependent on a custom branded version of the ESR client that uses distribution/bundles & auto config.  Users don't necessarily know they are using firefox since all of the chrome has been removed (No buttons or menu's of any kind)and since it has been rebranded doesn't interfere with any other version of firefox that the user might have installed.  The client is very secure since it only talks https to one site over VPN network.  Users can't use it to surf the web and most users don't even have access to the web because they are working with confidential customer data.  Please don't remove this feature without a configurable way to turn it back on.
Ben,

As a datapoint, SeaMonkey installs our extensions via distribution/ for the mere facts that we:
* Are installing extensions also listed on AMO
* Want these extensions to auto-update if an update exists (sec reason or otherwise)
* Want to be able to match the versions that are shipped for products like Firefox

Will there be a configurable way to enable this feature at build time, if nothing else?
(In reply to Justin Wood (:Callek) from comment #24)
> Ben,
> 
> As a datapoint, SeaMonkey....

SeaMonkey actually is not affected by this (Thank you :Mossop for clarification) we install via distribution/extensions/
Just to add another voice from those of us who provide software to enterprises and need a reliable mechanism to deliver extensions. Removing distribution/bundles without a planned replacement is very unhelpful. It's worth noting that many enterprises don't use ESR, so unfortunately will be affected a lot earlier than the next ESR release. Yes, it's their own fault, but still it will cause them a lot of pain.

Chrome checks whether a workstation is joined to a windows domain as a way to selectively allows use of technology it no longer wants used in the mainstream (NPAPI). That could be a good mechanism for this change: remove distribution/bundles only on windows workstations not joined to a domain.

A Group Policy mechanism in windows for extension distribution would be great and seems a good way to identify valid enterprise distribution.

Rory
(In reply to Rory from comment #26)
> Just to add another voice from those of us who provide software to
> enterprises and need a reliable mechanism to deliver extensions. Removing
> distribution/bundles without a planned replacement is very unhelpful.

I wouldn't expect distribution/bundles to be very reliable for delivering extensions unless you only roll out new versions when you update Firefox too. Installing extensions via the registry is likely to work better: https://developer.mozilla.org/en-US/docs/Adding_Extensions_using_the_Windows_Registry

> A Group Policy mechanism in windows for extension distribution would be
> great and seems a good way to identify valid enterprise distribution.

It's been a long time since I used group policy but I think you can set registry keys with it allowing the above?
Flags: needinfo?(mconnor)
Flags: needinfo?(jlal)
Flags: needinfo?
(In reply to Dave Townsend [:mossop] from comment #27)
> (In reply to Rory from comment #26)
> I wouldn't expect distribution/bundles to be very reliable for delivering
> extensions unless you only roll out new versions when you update Firefox
> too. Installing extensions via the registry is likely to work better:
> https://developer.mozilla.org/en-US/docs/
> Adding_Extensions_using_the_Windows_Registry

Registry installation doesn't work for enterprise as there is no way to force enable extension by enterprise rule. In my company we use Registry Installation with distribution/bundles guard that check extension enabled state. I understand that this solution can be used for malware but i can't see any workarounds for company administrators. Google Chrome has lovely Group Policy settings for configuring a always installed and enabled extensions. I'm fine with disabling distribution/bundles but only after implementation of some enterprise specific workaround.
mAppBundleDirectories is also used for additional default prefs, plugin directories and chrome icons.

Any chance you could just remove the extension case and leave the others (still load the list of dirs, just not add the manifest files).

Plugins are the big one here.

I'd rather not go back to putting plugins in the browser\plugins directory...
Flags: needinfo?
(In reply to Mike Kaply [:mkaply] from comment #11)
> I've already found a workaround that allows things to continue to be loaded
> from the distribution/bundles via AutoConfig. I'll be integrating that into
> the CCK2.

Unfortunately, the AutoConfig workaround doesn't work for me as I'm trying to modify the startup migration dialog, which is opened just before AutoConfig is loaded.
> Unfortunately, the AutoConfig workaround doesn't work for me as I'm trying to modify the startup migration dialog, which is opened just before AutoConfig is loaded.

Yes, that's one thing that won't be able to be done. What are you doing to the dialog?
(In reply to Mike Kaply [:mkaply] from comment #31)
> 
> Yes, that's one thing that won't be able to be done. What are you doing to
> the dialog?

Beijing office ships a migrator from 360 secure browser with its Firefox repack, so we want to make the option available in that dialog and pre-select it if 360 secure browser is detected as default browser.
I'll let bsmedberg chime in on that one. Overriding that dialog is something that absolutely cannot be done with autoconfig (or any other method) except distribution/bundles (I've checked).
Partners also use distribution bundles in b2g to ship custom components. That patch can't land until we figure out another way to ship them.
I am planning on proceeding with this with a B2G ifdef. Hector, ping me if you think that the 360 browser import is important and let's decide whether we should move that into the main tree or find some other solution that doesn't open the door to hijacking.
Rather than a plain move of the 360 migrator in tree, it would be awesome to have 360 added to the Firefox migration component itself, since we already have the infrastructure, someone should just write a js migrator, it shouldn't be too hard, we have migrators for Chrome, IE and Safari to look at for examples.
https://hg.mozilla.org/mozilla-central/rev/53e602f84009
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: mozilla39 → mozilla40
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #35)
> I am planning on proceeding with this with a B2G ifdef. Hector, ping me if
> you think that the 360 browser import is important and let's decide whether
> we should move that into the main tree or find some other solution that
> doesn't open the door to hijacking.
Hi Benjamin, yes, we still want it, as 360 secure browser accounts for ~1/4 of startup migrations in Firefox China repack. I'll file a separate bug later, and convert the extension to a patch for feedback.

(In reply to Marco Bonardo [::mak] from comment #36)
> Rather than a plain move of the 360 migrator in tree, it would be awesome to
> have 360 added to the Firefox migration component itself, since we already
> have the infrastructure, someone should just write a js migrator, it
> shouldn't be too hard, we have migrators for Chrome, IE and Safari to look
> at for examples.
Hi Marco, our existing extension contains such a JS component, overlay for chrome://browser/content/migration/migration.xul to add the 360 secure browser option and the logic to (optionally) pre-select it, and override of chrome://browser/locale/migration/migration.properties for MigrationUtils.getLocalizedString to use.
Depends on: 1164752
As an entreprise team developper representative. We can tell we are very boring with these firefox team policies to set and remove functions without advertising developpers, users and so on.

This is not the first time, that our extension does not work anymore, but each time, we can sea it through our customers that call because firefox has been updated. That it updates, right, I agree. But that it breaks running software based on it , without advertising either user or developers a long time before is NOT acceptable.

Furthermore it seems normal to advertise and provide developers the way to  modify there extensions in order being compatible with next Releases.

So, for ourselves and our customers, this is no more acceptable. Then, we ca

Hey Guys ! Open your eyes , leave your computer, go and play a tennis ! Think a little bit !

Regards,
Stéphane ANCELOT

Team developer representative of a world wide real life enterprise 
http://www.numalliance.com
I know this bug is closed for a long time, but I've just been aware of this change after reporting Bug 1209117.
I just can't believe such a change was made. This will just **** off enterprise admins (like me) with *absolutely* no gain at all. As it has already been said, if a malware has write access to distribution/bundles then you're already screwed (the malware can even replace the whole Firefox binary with its own, how is that an improvement ?). Is there somewhere a documentation about how to deploy extension now ? With the same level of feature (no possibility to disable the extension, no copy of the extension over every user profiles, possibility to downgrade etc...)
Check with Mike Kaply  (https://mike.kaply.com/)
I believe he has a work around using AutoConfig
Yes, I've just tested his work around on Firefox 41 and it seems to be working. Just too bad that a work around is needed in the first place (and also invalidate the security argument: if less than 60 lines of JS is enough to bring the feature back, how will that prevent malware to install themselves ?). Anyway, thanks to Mike Kaply :-)
(In reply to Daniel B. from comment #41)
> I know this bug is closed for a long time, but I've just been aware of this
> change after reporting Bug 1209117.
> I just can't believe such a change was made. This will just **** off
> enterprise admins (like me) with *absolutely* no gain at all. As it has
> already been said, if a malware has write access to distribution/bundles
> then you're already screwed (the malware can even replace the whole Firefox
> binary with its own, how is that an improvement ?). Is there somewhere a
> documentation about how to deploy extension now ? With the same level of
> feature (no possibility to disable the extension, no copy of the extension
> over every user profiles, possibility to downgrade etc...)

The way to do that has always been installing the extension into one of the places listed here: https://developer.mozilla.org/en-US/Add-ons/Installing_extensions
(In reply to Dave Townsend [:mossop] from comment #44)
> The way to do that has always been installing the extension into one of the
> places listed here:
> https://developer.mozilla.org/en-US/Add-ons/Installing_extensions

None of those provide the equivalent functionality of distribution/bundles.

Distribution/bundles allowed a XUl/XPCOM extension to integrate invisibly into Firefox as if it were a pert of it with no ability for the user to mess with the changes.

It was exactly what a lot of enterprises needed for customization.
I'm just starting on Firefox ESR 38.3.0 and I wondered how things would pan out with the version 39 changes, even though ESR 45 won't be out for a few months. Reading through this thread, I'm not sure the Firefox folks realize, we who administer large populations of Macs in large environments ARE in fact hijacking the application. Because. Our job.

Well, at least CCK2 will work for a few months. Looks like Firefox will end up being retired, unless we are sure version 45 will be manageable. From what I'm reading, looks like Firefox folks are going to make it impossible for us to manage things. That's bad.

Don
So 45 ESR is out, and I don't see anything in the release notes about the distribution/bundles replacement.  Did I miss something?  

If not, what would be the best way for an enterprise to force deploy an extension to their users?  Also, for a mental exercise, lets assume that Mozilla can't/won't sign it.

Thanks!
(In reply to cparker from comment #47)
> So 45 ESR is out, and I don't see anything in the release notes about the
> distribution/bundles replacement.  Did I miss something?

There is no official replacement from Mozilla. You can use the CCK2 to recreate the functionality by placing your extension in the cck2/bundles directory

> If not, what would be the best way for an enterprise to force deploy an
> extension to their users?  Also, for a mental exercise, lets assume that
> Mozilla can't/won't sign it.

Any unlisted add-on can be signed. It doesn't require review.
(In reply to Mike Kaply [:mkaply] from comment #48)
> (In reply to cparker from comment #47)
> > So 45 ESR is out, and I don't see anything in the release notes about the
> > distribution/bundles replacement.  Did I miss something?
> 
> There is no official replacement from Mozilla. You can use the CCK2 to
> recreate the functionality by placing your extension in the cck2/bundles
> directory
I didn't realize that cck2 had added a bundles folder to duplicate the functionality.  Thanks!

> 
> > If not, what would be the best way for an enterprise to force deploy an
> > extension to their users?  Also, for a mental exercise, lets assume that
> > Mozilla can't/won't sign it.
> 
> Any unlisted add-on can be signed. It doesn't require review.

A day or two ago, the signing API refused to sign my unlisted addon that contained a ctypes dll.  When I removed the dll, it signed it.  Mozilla had signed a previous version of this extension, so I was assuming it was another change in policy that enterprise users would have to figure out how to get around.  I was using a custom tool to use the signing API, so there might be a problem with it.
If you're running into problems getting an add-on file signed, please report a bug here: https://github.com/mozilla/addons-server/issues/new
@jorgev - Thanks for the info.  I thought my problem was the dll, but it was a bad version in the install.rdf.  I was looking at a raw JSON output, from my tool.  I used jpm this time, and it worked great and worked better.
You need to log in before you can comment on or make changes to this bug.