Open MCHuijgen opened 5 years ago
@mkaply : any chance of being implemented in the near future?
Not setting the default engine. Do you just need to add an engine?
Mainly adding, yes, but also PreventInstalls and Default.
For Remove I found a workaround by blocking a specific built-in search engine via ExtensionSettings: "SearchEngineName@search.mozilla.org": { "installation_mode": "blocked" },
But I think it would be neater to be able to do that with SearchEngines.
Any Reason for this policy being ESR only?
It's to prevent bad actors using policies to do search hijacking. I'm looking at making most of it available except setting the default search engine.
Ok, thanks. One more question if you allow: I don't want to hijack this issue, but will the change also affect policies.json or GPO only?
One more question if you allow: I don't want to hijack this issue, but will the change also affect policies.json or GPO only?
Anything I do will be GPO and policies.json.
Chrome gets around this by only allowing certain policies if you are connected to an Active Directory. I felt like this was limiting (and kind of unfair) which is why we went the ESR only route.
In the wild, we know that Antivirus are using policies to allow the OS certificate store, so we know apps are using these for things other than enterprise management.
Thanks for looking at making most of it available! I really appreciate that.
I understand you want to prevent default search engine hijacking, fair enough. But what about home page hijacking? Malicious actors can do that since long time with a policy, I wonder if that isn't just as bad as hijacking the default search engine. And since setting the home page isn't limited to ESR, why keep the default search engine limited to the ESR?
I don't mean to be disrespectful here, and maybe I'm seeing things wrong, but it doesn't seem quite logical to me.
Enabling this for RR would be really great for my organization (9000+ employees), and I guess other enterprise environments. We are using RR because we want to be able to quickly use new features, the ESR is too slow for us. And the lack of this particular policy is the only discomfort using the RR.
I've restarted the conversation around this internally. Hopefully we can come up with a good solution.
Sorry for jumping on this thread, however i was just myself looking at why my policy for this wasn't being applied. I'm not sure i understand the reasoning behind this at all...
i mean, if "bad actors" have acces to hijack your GPO's, then you have a LOT more to worry about than your browser homepage/search engines...just saying.
And besides...a LOT of people hate the fact that google is the default, probably one of the first things that gets deleted :)
Even adding them as Extensions>Uninstall entries (ie:
Unfortunately it's not my decision.
Even adding them as Extensions>Uninstall entries (ie: @search.mozilla.org etc) doesn't work, like they're completely ignored.
Other people have said this works (at least for removing things.
Even adding them as Extensions>Uninstall entries (ie: @search.mozilla.org etc) doesn't work, like they're completely ignored.
Did you try both blocking via ExtensionSettings and removing via SearchEngines | Remove?
It only worked for me to add both in policies.json. Maybe it's the same for GPO.
{
"policies": {
"ExtensionSettings": {
"google@search.mozilla.org": {
"installation_mode": "blocked"
}
},
"SearchEngines": {
"Remove": [
"Google"
]
}
}
}
@mkaply : Any good news since June last year?
I've restarted the conversation around this internally. Hopefully we can come up with a good solution.
I mean, I don't have an actual problem now: I'm removing (and adding) a search engine by setting Installation_mode to blocked/force_installed in ExtensionSettings (which applies to both RR and ESR), and can do the same thing with SearchEngines, but only with ESR? But what is the reasoning behind this? Why not also SearchEngines with RR? Or leave it out of SearchEngines and rely only on ExtensionSettings for adding/removing search engines? It is confusing for administrators like me and prone to error.
@MCHuijgen It's because of a fear of search hijackers using policies.
We're investigating workarounds.
@mkaply As mentioned before (June 10 2020), for changing policies in Windows one needs to have admin permissions (for writing to HKCU\Software\Policies). And if a piece of malware has admin permissions, a lot worse actions than just hijacking a search engine could be performed to harm Firefox. Search engine hijacking is the least thing to worry about then. So with all due respect I think this fear is unfounded.
So with all due respect I think this fear is unfounded.
Yeah, we're getting there as well. What we're looking at is a ways to tell users their search is taken over my some other mechanism (policy or extension) as well as using telemetry to scope the problem.
We're moving closer to a solution.
Hello,
Can we get an update on this feature request please ?
Have you explored the possibility to detect if firefox is installed as root and if policy file is owned by root, if yes allow the change, otherwise forbid it ? (similar checks can be done for Windows I guess)
If the blocking point is the ability to add new searchengines, please at least allow us to remove preinstaled ones and set one of the preinstalled ones as default through policies.
This feature is not only required for enterprises. I use ansible to generates policies + autoconfig.js/firefox.cfg to deploy a default firefox configuration and behavior on 20+ physical hosts and VMs in a "home" context. This allows me to keep all devices and configurations up to date with no hassle and create VMs quickly depending on my family's needs. The only limitation I have is the fact that I cannot set the default search engine to the one I need.
With all due respect, I don't understand the risk argument mentionned above as in any case In order to modify the autoconfig / policies I need to have sudo access anyway, which means that I can do much more harm than setting a "bad search engine". And why authorizing changing proxy settings through policies if you consider that there are security risks of harmful configurations ? I don't think you consider proxy attacks less harmful than search hijacking, am I wrong ?
If the issue is related to other aspects than security risks (risk of losing money from major search-engines for instance) please tell us.
Best regards,
Mainly adding, yes, but also PreventInstalls and Default.
For Remove I found a workaround by blocking a specific built-in search engine via ExtensionSettings: "SearchEngineName@search.mozilla.org": { "installation_mode": "blocked" },
But I think it would be neater to be able to do that with SearchEngines.
Nice to see I'm not the only one who struggles to disable undesireble pre-installed "search" exstensions from dubious sources.
I have tried many ways to get rid of wikipedia, eBay, google, yahoo, youtube, amazon, bing and twitter, but nothing I can find is working; unfortunately not your suggestion as well.
Here are some of the settings I have been trying in my /etc/firefox/policies/policies.json
"Extensions": {
"Uninstall": [
"google@search.mozilla.org",
"startpage@search.mozilla.org",
"yahoo@search.mozilla.org",
"youtube@search.mozilla.org",
"amazondotcom@search.mozilla.org",
"bing@search.mozilla.org"
]
},
"ExtensionSettings": {
"wikipedia@search.mozilla.org": {
"installation_mode": "blocked",
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
]
},
"ebay@search.mozilla.org": {
"installation_mode": "blocked",
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"allowed_types": [
"extension"
]
},
"google@search.mozilla.org": {
"installation_mode": "blocked"
},
"startpage@search.mozilla.org": {
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
},
"yahoo@search.mozilla.org": {
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
},
"youtube@search.mozilla.org": {
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
},
"amazondotcom@search.mozilla.org": {
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
},
"bing@search.mozilla.org": {
"blocked_install_message": "No thanks, we like privacy.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
},
"twitter@search.mozilla.org": {
"blocked_install_message": "No thanks Elon Musk.",
"install_sources": [
"https://addons.mozilla.org/*"
],
"installation_mode": "blocked",
"allowed_types": [
"extension"
]
}
),
anyone who have better luck?? or suggestions for how to get rid of these creeps?
@spirillen This is the ExtensionSettings config that does the trick for my organisation to block the search engines. I don't use any other extension policies. I'm using it on Windows by the way.
"ExtensionSettings": {
"*": {
"blocked_install_message": "Call the IT Service Desk to allow an extension.",
"installation_mode": "blocked"
},
"bolcom@search.mozilla.org": {
"installation_mode": "blocked"
},
"ebay@search.mozilla.org": {
"installation_mode": "blocked"
},
"amazon@search.mozilla.org": {
"installation_mode": "blocked"
},
"marktplaats@search.mozilla.org": {
"installation_mode": "blocked"
}
}
Thanks for your suggestion @MCHuijgen However I have tried that simplified approach with no luck.
and the test of "Extensions" is new as I was reading it I thought YES just what I have been looking for.
What I could come to think of is, if there are some kind of weight in the rules that isn't mentioned, which "Re-Activate" a disabled ruled with an included
PS Running linux amd64 (ubuntu 22.04) FF 102.11.0esr
@spirillen I do this:
{
"policies": {
"SearchEngines": {
"Remove": [
"Google",
"Amazon.com",
"Amazon.de",
"Bing",
"Wikipedia (de)",
"Wikipedia (en)",
"eBay",
"Twitter"
],
"Default": "DuckDuckGo"
},
"ExtensionSettings": {
"wikipedia@search.mozilla.org": {
"installation_mode": "blocked"
},
"google@search.mozilla.org": {
"installation_mode": "blocked"
},
"bing@search.mozilla.org": {
"installation_mode": "blocked"
},
"amazondotcom@search.mozilla.org": {
"installation_mode": "blocked"
},
"amazondotde@search.mozilla.org": {
"installation_mode": "blocked"
}
}
}
}
In "Default": "DuckDuckGo"
, assuming that duckduckgo or whatever you want to set as default, comes bundled with Firefox.
The thing is, am not sure, it "works", just because it was the only one left after removing/blocking the others.
Hey @abisszett that works partly in Ubuntu FF-ESR and not at all on Debian 11, this is weird it is working for you guys and just not at all for me
Results:
Are you ESR on Debian?
@spirillen If you go to about:policies
and have a look at the errors, you will see something like Policy SearchEngines is only allowed on ESR
. So it "works" only on ESR and if does on RR, that's a bonus, if not, well ya it's not supported.
My suggestion was meant as a workaround, not as a solution. The solution would be, when this is officially supported/documented and that's the purpose of this issue.
I tried different variants of:
{
"policies": {
"SearchEngines": {
"Remove": [
"SearchEngineName",
"SearchEngineID",
],
},
"ExtensionSettings": {
"SearchEngineName": {
"installation_mode": "blocked"
},
"SearchEngineID": {
"installation_mode": "blocked"
}
}
}
}
Nothing worked as expected. So, we have to wait until someone is willing to fix this.
Are you ESR on Debian?
Yes and on ubuntu as well
The Search Engine policies are the only policies left that are limited to the ESR as far as I can see. All other policies that were limited to the ESR-versions were made available to the RR in 2018. Can these policies also be made available to the RR-versions?