1196154 - Enterprise use case of searchEngine configuration broken

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect)

Description

[Kai Hendry]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2478.0 Safari/537.36

Steps to reproduce:

Try set an alternative search engine as a system wide deployment option using /opt/firefox/browser/searchplugins/DDG.xml


Actual results:

Defaults to Google


Expected results:

Should have setup DDG as default.

Comment 1

[Kai Hendry]

After spending some hours debugging, I've noticed search-metadata.json in the random salted profile_dir is now the FS location of configuring the default search engine. However this is not usable for Enterprise deployments. Preferences (although set as I can see in about:config) like browser.search.defaultenginename have no affect.

Related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1162569
https://bugzilla.mozilla.org/show_bug.cgi?id=1029148

distribution.ini style method of deployment as noted in https://mike.kaply.com/2015/08/13/firefox-40-breaking-changes-for-enterprise/, for example in /opt/firefox/distribution/searchplugins/common/DDG.xml is also broken. :(

I noticed you are probably going to break homepage preference too in https://bugzilla.mozilla.org/show_bug.cgi?id=1051082 which is a concern.

Can you please document a workaround for the Enterprise use case? Thank you

Comment 2

[Florian Quèze [:florian]]

See bug 1162569 comment 37. Basically, use ESR and a custom distribution/ folder. Not sure why you say the distribution.ini method is broken; the blog post you link says it's now in <installdir>/distribution rather than <installdir>/browser/distribution, but that doesn't make it 'broken'.

Comment 3

[Kai Hendry]

I tried the suggested distribution layout on FF40.0.2 and it doesn't work. http://s.natalian.org/2015-08-23/dist.tar

So basically Mozilla are foisting ESR onto mass deployments? I'm a little stunned that I have to downgrade 6000 machines to an older browser now. Guess the switch to Youtube's HTML player will take at least 12 weeks more? :( 

I will be amazed if your security team back port all the security fixes in a prompt manner. You've created more work for yourselves, myself and you've held back the Web with this decision not to allow files to configure a Firefox install.

Comment 4

[Kai Hendry]

Sorry, I take that back http://s.natalian.org/2015-08-23/dist.tar does work. :) I was testing on a stale profile or something. Nonetheless the sentiments remain.

Comment 5

[Florian Quèze [:florian]]

(In reply to Kai Hendry from comment #3)

> So basically Mozilla are foisting ESR onto mass deployments? I'm a little
> stunned that I have to downgrade 6000 machines to an older browser now.

You don't have to do this now. The distribution/ folder currently works in normal Firefox releases. We just gave you a heads up that in the future (no exact schedule yet), it likely will stop working in non-ESR builds.

Comment 6

[Kai Hendry]

I can confirm the distribution/ folder works. However it is a bit brittle. For example if a browser.search.defaultenginename is defined anywhere else, it gets overridden. If the override doesn't have a search plugin, it defaults to Google as I found out in https://github.com/Webconverger/webc/commit/6c4a5e3a4f5cf6e85135ae757a6d6059d502f4aa This took me an embarrassing amount of time to fix.



That said, I don't want to use ESR. I don't want to use a Firefox fork. I want the Web especially on Enterprise deployments to be up to date & current.


Can you please make this work on the standard Firefox build from getfirefox.com going forward? Where can I vote or lodge a complaint otherwise? Thank you,

Comment 7

[Florian Quèze [:florian]]

(In reply to Kai Hendry from comment #6)
> I can confirm the distribution/ folder works. However it is a bit brittle.
> For example if a browser.search.defaultenginename is defined anywhere else,
> it gets overridden. If the override doesn't have a search plugin, it
> defaults to Google

You may need to set browser.search.geoSpecificDefaults to false.

> That said, I don't want to use ESR. I don't want to use a Firefox fork.

ESR is not a fork, just a branch with a slower release cycle so that people with large deployments can take time to verify the new version works fine for them.

> Can you please make this work on the standard Firefox build from
> getfirefox.com going forward? Where can I vote or lodge a complaint
> otherwise? Thank you,

We are tracking how search defaults are being hijacked by malware. If the distribution folder becomes the top source of abuse, we'll have to disable it in default Firefox releases. We are not going to do it until we have evidence of abuse. It's not a matter of voting or lodging complaints; we are doing what's needed to protect users.

Comment 8

[Kai Hendry]

(In reply to Florian Quèze [:florian] [:flo] from comment #7)
> ESR is not a fork, just a branch with a slower release cycle so that people
> with large deployments can take time to verify the new version works fine
> for them.

And if doesn't work fine for them? There is no recourse. There is no point making release cycles slower imo. It's already frustrating for Web developers targeting Enterprise deployments and this will not help !

> We are tracking how search defaults are being hijacked by malware. If the
> distribution folder becomes the top source of abuse, we'll have to disable
> it in default Firefox releases. We are not going to do it until we have
> evidence of abuse. It's not a matter of voting or lodging complaints; we are
> doing what's needed to protect users.

IIUC you are protecting users from some malware dropping in a file redirecting users to their spam.

As mentioned on twitter https://twitter.com/kaihendry/status/635281154640207872

If malware can write files arbitrarily on a victim's system, surely no matter what you do, you will still have the same problem. You'll play an endless cat & mouse game that makes your software hard and harder to deploy.

Comment 9

[Florian Quèze [:florian]]

(In reply to Kai Hendry from comment #8)

> If malware can write files arbitrarily on a victim's system, surely no
> matter what you do, you will still have the same problem.

Malware can write arbitrarily on the victim's system, but whatever damage is being done to the install dir can (and will likely) be overwritten automatically at the next Firefox update, so that's not a very attractive target. The distribution/ folder is special in that it's explicitly excluded from what the updates will touch; this is why we expect it to be abused eventually.