Closed Bug 721264 Opened 13 years ago Closed 12 years ago

Please consider blocking BabyFox.dll from Babylon

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox15 --- unaffected
firefox16 + fixed
firefox17 --- fixed

People

(Reporter: verdi, Assigned: johnath)

References

(Blocks 1 open bug)

Details

(Whiteboard: [3rd-party-bustage][dll])

Attachments

(1 file)

Blocklist babyfox.dll, all versions
1008 bytes, patch
benjamin
: review+
Details | Diff | Splinter Review
We get a lot of support requests concerned with the Babylon toolbar. When installed (often bundled with other software) it changes the user's home page and search engine. If you remove the Babylon desktop software with the add/remove programs control panel in windows, the Firefox add-ons (3 of them) don't get removed. If you remove the Firefox add-ons you still have to reset your home page and search engine. Also it seems to have added itself to the default list of search engines so even if you delete it, if you later restore the default list of search engines, Babylon comes back. But wait, there's more. If you do all of that it will then add a button to the window title bar. A quick google search for "babylon toolbar" turns up lots of results for complicated steps to remove it from your system and registry.
Component: Add-ons Manager → Blocklisting
Product: Toolkit → addons.mozilla.org
QA Contact: add-ons.manager → blocklisting
As I read the blocklisting guidelines, this is a typical case that *shouldn't* be blocklisted: https://wiki.mozilla.org/Blocklisting#A_High_Bar fligtar?
Blocks: 700176
Blocks: 715757
See Also: → 715744
As Scoobidiver's indicated with bug links, not only is Babylon difficult to remove, but causes Firefox to crash. Has anyone tried or been able to get in contact with Babylon yet?
No longer blocks: 715757
This block is being considered in bug 715744, and we haven't been successful in contacting Babylon.
Assignee: nobody → jorge
Status: NEW → ASSIGNED
The Babylon Toolbar was not identified as the cause of the crash in any of the cases we have, but libraries installed by Babylon software have been. Not sure if they come with the toolbar or something else. The crashes are NO argument for blocking the toolbar. Usability problems, violating "no surprise", etc. can be arguments, though. I'm not arguing that we shouldn't block it, just noting that the toolbar itself doesn't seem to be strongly correlated to or even found to be the cause of crashes right now.
One of the installed Babylon addons* loads multiple scripts in <script> tags as http in on overlay so is suseptible to MITM attacks. We've (threatened) to block other third party addons for the same thing. * ffxtlbr@babylon.com 1.1.9
Marking as security-sensitive, per comment #5.
Group: client-services-security
Andrew, what are URLs being loaded with chrome permissions?
<script type="application/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.min.js"></script> <script type='application/javascript' src='http://cnfg.montiera.com/appsCntrl/babylon/appDef.js'></script> <script type='application/javascript' src='http://mntr.babcdn.com/mntr/appscntrl/babylon/bblndef.js'></script> <script type='application/javascript' src="http://mntr.babcdn.com/mntr/cnfg/babylonBtns1.js"></script> <script type='application/javascript' src='http://mntr.babcdn.com/mntr/misc/BabyTBPlugin.js'></script>
Blocks: 733892
Marking with [3rd-party-bustage], a new whiteboard tag I'm using to track problems caused by third-party add-ons.
Whiteboard: [3rd-party-bustage]
No longer blocks: 733892
Blocks: 742113
(In reply to Jorge Villalobos [:jorgev] from comment #1) > As I read the blocklisting guidelines, this is a typical case that > *shouldn't* be blocklisted: https://wiki.mozilla.org/Blocklisting#A_High_Bar Could this fall into the exception to a high bar? "The above conditions assume users have chosen to install the add-on or software in question. If the software is installed without user consent, the bar is significantly lower to blocking for the above and other reasons." We have well over 15,000 reports on SUMO of users who don't know how they got this toolbar and want to get rid of it and change their Firefox search and home page settings back. (In reply to Jorge Villalobos [:jorgev] from comment #6) > Marking as security-sensitive, per comment #5. Any update on this? Is there a security risk here?
(In reply to Verdi from comment #10) > We have well over 15,000 reports on SUMO of users who don't know how they > got this toolbar and want to get rid of it and change their Firefox search > and home page settings back. Their install base is over 100 million, according to them, so we need to keep those numbers in context. They don't have 100 million Firefox ADUs, but I think they are very high on the most used list. For this, I believe it shouldn't be blocked, but we should revisit this bug after the Add-ons Work Week that is happening in June. We'll be discussing cases like this and possible solutions. > (In reply to Jorge Villalobos [:jorgev] from comment #6) > > Marking as security-sensitive, per comment #5. > Any update on this? Is there a security risk here? This should be fixed in current versions of the toolbar.
Jorge, from the survey we did, of random Babylon toolbar users we found that they don't want it. It's not that only 15k out of 100M don't want it, it's that 50% of the users that have the toolbar want to delete it and they can't. So we can say that 50M Firefox Users are struggling with a toolbar that brings some benefits but in general is malicious. That's what we are trying to say here. For more context: https://etherpad.mozilla.org/babylon-toolbar-survey
I know about the survey, and that's quite the extrapolation you're making. While I don't doubt there are significant numbers of users with this problem, we need to weigh the benefits with the impact such a block would have. Like I said in my previous comment, I'll be more comfortable making these calls once we have better blocklisting and better blocklisting policies, which will be discussed soon.
> This should be fixed in current versions of the toolbar. So can we close this bug, now that the security issue it was appropriated to track has been resolved? In general, I'd prefer if data such as we have in comment 12 could be discussed in public. Although perhaps Jorge could clarify whether there's anything that's up for discussion between now and the work week; if not, I'm not sure there's much to be accomplished by filing a new bug.
(In reply to Verdi from comment #10) > change their Firefox search and home page settings back. Blocklisting the add-on won't fix the search engine and home page hijacking. It will only fix crashes that are dependent on it. To prevent the hijacking, you should have a kind of third-party user.js prompt similar to the third-party add-on one.
(In reply to Justin Lebar [:jlebar] from comment #14) > > This should be fixed in current versions of the toolbar. > > So can we close this bug, now that the security issue it was appropriated to > track has been resolved? Since blocklisting policy is bound to change soon, I'd rather keep these blocklist bugs on hold until then. If nothing changes in our policy / tools, then yes, I'll close this bug. In the interim I think it's too risky to block this add-on.
If you're keeping this bug open to discuss blocklisting, then it should be public. I'm not entirely comfortable opening up this bug since it contains a critical security hole in software which users might still be running, which is why I suggested opening a new bug to discuss blocklisting. But in no case should we be keeping a private bug open for a non-security issue. It's important that everyone be able to contribute to this discussion.
Ok, I removed the security flag since the security problem has been resolved. However, this bug is for discussing the Babylon Toolbar block, not blocklisting in general.
Group: client-services-security
Jorge, when you talk about Risks...what exactly are you referring to? - PR implications? - Technical implications (something stops working)? - User experience implications? If we understand what risks you are talking about we can work on a plan to minimize them. The more concrete the better.
User experience implications, pretty much. See for example the feedback here: http://blog.mozilla.org/addons/2012/04/02/blocking-java/ http://blog.mozilla.org/addons/2012/04/04/update-on-java-blocklist/ The Java plugin is something that we would expect people to want *less* than an add-on such as this one. We've had similar backlash for blocklisted add-ons such as Internet Download Manager. I don't have the bug numbers handy, but there are some pretty long bugs filled with expletives that show us blocklisting isn't generally a good approach when dealing with non-malicious add-ons.
I don't think anyone is saying we should hard-block this add-on. Soft-blocking gives users an explicit opportunity to opt-out of the block. Indeed, "soft-block" is perhaps a misnomer; a better name might be "suggest-disable".
For most users there's no difference, unfortunately. They'll just dismiss the dialog and won't know how to re-enable.
(In reply to Jorge Villalobos [:jorgev] from comment #22) > For most users there's no difference, unfortunately. They'll just dismiss > the dialog and won't know how to re-enable. You probably have some evidence of this, but per comment 13, do you think it's fair to extrapolate your evidence to "most users"?
The difference between the softblock and hardblock dialogs is very subtle, and I think it's fair to say that a significant portion of users who have installed the Babylon toolbar aren't knowledgeable about add-ons and couldn't find the Add-ons Manager on their own. But you're right. Saying "most users" is stretching things past what can be proven.
After Uninstalling all Babylon Firefox Addons, and programs from add-remove programs and restarting Firefox, the following Remains: home Page and New Tab is Set to http://search.babylon.com/home Search bar is set to Babylon Search These are controlled by the following about:config strings and values: browser.babylon.HPOnNewTab;search.babylon.com browser.newtab.url;http://search.babylon.com/?tt=3112_3&babsrc=NT_def browser.search.defaultenginename;Search the web (Babylon) browser.search.order.1;Search the web (Babylon) browser.search.selectedEngine;Search the web (Babylon) browser.startup.homepage;http://search.babylon.com/home?tt=3112_3 extensions.BabylonToolbar_i.newTab;true extensions.BabylonToolbar_i.newTabUrl;http://search.babylon.com/?tt=3112_3&babsrc=NT_def keyword.URL;http://search.babylon.com/?tt=3112_3&babsrc=KW_def&mntrId=d465b9c300000000000000216a81a978&q= It's worth noting that Babylon also takes over IE as well. At the very least these values should be Reset when the add-on is disabled or Removed. There is a opt-in checkbox that is poorly worded on the Babylon installer that asks if current values should be saved for when the program is, however the majority of users will not read these values and will not choose to select this value.
This sounds to me like they are breaking the "no surprises" rules and should be blocked, but for anyone who already has them installed, they have been turned to their services with no way back (and from a look at how they are ripping off Goggle and using Google ads, they might even break Google's rules as well, possibly, but I don't think that helps us or the users). We really really need a story to recover people that undergo search engine, keyword URL, home page and new tab hijacking like that, primarily for improving the user experience (getting back to normal), but even for third parties not intercepting our defaults and profiting from what would be our income stream without user control. IMHO, we need to 1) put the user back in control and 2) ensure that nobody other than the user is redirecting those core assets that also happen to fund our work to improve the open web and give control to users.
> We really really need a story to recover people that undergo search engine, keyword URL, home page > and new tab hijacking like that The "Reset Firefox" button in about:support does this. It's not automated, of course, if that's what you were looking for.
There is also https://addons.mozilla.org/en-US/firefox/addon/searchreset/, which will reset Search settings in Firefox. Perhaps we can release a Hotfix of sorts that will revert the settings made by Babylon (everything that Babylon changes in Firefox is Opt-Out, and does not require a user's informed consent to change BTW).
Given comments 27 and 29, it would seem apparent that this addon must be blocked without delay and the addon removed from AMO. Users shall not suffer due to misbehaving addons which break known rules.
(In reply to Justin Lebar [:jlebar] from comment #28) > The "Reset Firefox" button in about:support does this. It's not automated, > of course, if that's what you were looking for. I'm looking for something we can automatically deploy, yes. Something that doesn't require explicit user interaction. "Reset Firefox" also is not that easy to find, I guess - and does it reset all those options to the default? That is, if I intentionally set different search engines, home pages, new tab pages, I lose them with the reset option?
Robert, Reset does fix all these settings, however, depending on which app the user got Babylon from, once it is reopened, the toolbar will reinstall itself, and then the cycle will start over. This is why a block, and a Reset combination is necessary. babylon itself is set to start up with the computer, and will try to reinstall into Firefox when it's opened up again. Is it possible to have a hotfix that if the user has Babylon installed, the hotfix is pushed, and simply reset these prefs. It is true however, if you had a customer home page, etc. before installing Babylon, resetting these prefs won't bring that back.
(In reply to Tyler Downer [:Tyler] from comment #26) > There > is a opt-in checkbox that is poorly worded on the Babylon installer that > asks if current values should be saved for when the program is, however the > majority of users will not read these values and will not choose to select > this value. If you choose the opt-in to clear the settings, is everything set back to their initial values, or is there anything left behind? I want to give as much detail to Babylon to fix this.
Let me test this in detail tomorrow, and I will get back to you.
I don't think this bug should be mixed up with https://wiki.mozilla.org/Program_Management/Projects/SearchHijacking that seems given up. Babylon is not the only one to hijack those things. Thus the first French provider does that with an application and a user.js file. If the Babylon toolbar is blocklisted, it would be old versions from Fx 16.0 because of bug 766877.
Blocks: 766877
Alright, well when I tell Babylon to save my current settings, it does restore my home page and search engine. However it leaves the following: browser.babylon.HPOnNewTab;search.babylon.com browser.newtab.url;http://search.babylon.com/?affID=55555&tt=3112_5&babsrc=NT_def extensions.BabylonToolbar_i.newTab;true extensions.BabylonToolbar_i.newTabUrl;http://search.babylon.com/?affID=55555&tt=3112_5&babsrc=NT_def keyword.URL;http://search.babylon.com/?affID=55555&tt=3112_5&babsrc=KW_def&mntrId=d465b9c300000000000000216a81a978&q= Leaving users with a Babylon Search Engine in the search bar
(In reply to Tyler Downer [:Tyler] from comment #37) > Leaving users with a Babylon Search Engine in the search bar Not just that, but also giving people a completely different new tab page and directing default searches from the location bar to Babylon. IMHO, that's not acceptable.
Blocklisting the extension won't get these values back to their defaults because it's not caused by the extension itself but the install process. Any third-party software can change the pref.js file or create a user.js file. As long as there is not a protection against search, home page, New Tab page hijacking, it will be possible. Many people don't even know the Reset Firefox feature to fix that.
I filed bug 780280 to deal with the settings problem. Since the crashing issue can still become blocklist-worthy, I'm keeping this bug alive.
DLL name: BabyFox.dll DLL versions to block: All (no longer used in Babylon 9.0.5 and above) Applications, versions, and platforms affected: Firefox 16+, Windows Homepage and other references and contact info: http://www.babylon.com Reasons: bug 766877
Summary: Please consider blocking the Babylon Toolbar → Please consider blocking BabyFox.dll from Babylon
Whiteboard: [3rd-party-bustage] → [3rd-party-bustage][dll]
DLL blocks have to be shipped with Firefox, so it might be best to do an extension block. I need 2 things before continuing with the block: 1) Have we seen any recent change in the crash rate? 2) Is 9.0.5 the lowest version that doesn't exhibit this problem?
(In reply to Jorge Villalobos [:jorgev] from comment #42) > DLL blocks have to be shipped with Firefox, so it might be best to do an > extension block. I don't know the matching version table between Babylon Toolbar and BabyFox.dll. Based on correlations in 14.0.1, there are 6 versions of Babylon Toolbar in the wild (from 1.1.3 to 1.5.0) and 25 ones of BabyFox.dll (from 7.5.2.10 to 9.0.4.26). In addition, they don't appear in the same crash signature: BabyFox.dll is only in startup crashes and Babylon Toolbar only in non-startup crashes. I don't even know if BabyFox.dll is loaded with this toolbar or with the Babylon program itself. That is why I asked a DLL blocklist instead of an extension blocklist although the DLL blocklist seems ineffective. > 1) Have we seen any recent change in the crash rate? Answered in bug 766877. > 2) Is 9.0.5 the lowest version that doesn't exhibit this problem? Babylon 9.0.5 is indeed the lowest non-crashy version (based on captlib.dll version).
FWIW, there are three Babylon toolbars: * ffxtlbr@babylon.com * ocr@babylon.com * adapter@babylontc.com
Since this is happening only in Firefox 16 an above and we don't know what the DLL is correlated to, it makes sense to do the DLL block, ideally before the beta merge. Assigning to jonath.
Assignee: jorge → johnath
status-firefox15: --- → unaffected
status-firefox16: --- → affected
tracking-firefox16: --- → ?
(In reply to Scoobidiver from comment #43) > although the DLL blocklist seems ineffective. I meant inefficient. Indeed, bug 725503 is #20 top browser crasher in 14.0.1 although radhslib.dll is blocked.
(In reply to Scoobidiver from comment #46) > (In reply to Scoobidiver from comment #43) > > although the DLL blocklist seems ineffective. > I meant inefficient. Indeed, bug 725503 is #20 top browser crasher in 14.0.1 > although radhslib.dll is blocked. There's 4 or 5 different ways to load DLLs into a Windows process. Our DLL blocklisting can block all but one of those, IIRC, so if this doesn't use the rather obscure case we cannot catch, our DLL blocking is effective, but there's the (rather rare) cases where it's not.
I haven't tested this and can't push it to try because my commit account's gone dormant. While I wake it up, here's a patch. And if someone else wants to push to try/test it, that would be lovely. For the record, I am hereby giving bsmedberg rights to review DLL blocklist patches in the future.
Attachment #653956 - Flags: review?(benjamin)
(In reply to Johnathan Nightingale [:johnath] from comment #48) > Created attachment 653956 [details] [diff] [review] > Blocklist babyfox.dll, all versions > > I haven't tested this and can't push it to try because my commit account's > gone dormant. While I wake it up, here's a patch. And if someone else wants > to push to try/test it, that would be lovely. > > For the record, I am hereby giving bsmedberg rights to review DLL blocklist > patches in the future. And on checkin I, or whomever checks it in, oughta add a bug reference to the comment
Comment on attachment 653956 [details] [diff] [review] Blocklist babyfox.dll, all versions Given what we know, this seems like the right solution.
Attachment #653956 - Flags: review?(benjamin) → review+
(In reply to Benjamin Smedberg [:bsmedberg] from comment #50) > Comment on attachment 653956 [details] [diff] [review] > Blocklist babyfox.dll, all versions > > Given what we know, this seems like the right solution. Thanks, Benjamin. I wonder if I can find someone to land this for me on central/aurora? Maybe someone whose commit rights *aren't* dormant?
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
> And on checkin I, or whomever checks it in, oughta add a bug reference to the comment Oh, the comment in the code, not the checkin comment. Comment fixed in https://hg.mozilla.org/mozilla-central/rev/ee1fb253dfce And Aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/68264c5a8669
I am still able to install Babylon Toolbar 1.5.0 on Firefox 16 beta 6 on Windows. Is that ok?
(In reply to Simona B [QA] from comment #56) > I am still able to install Babylon Toolbar 1.5.0 on Firefox 16 beta 6 on > Windows. > Is that ok? The latest Babylon version doesn't have the BabyFox DLL, so you have proved nothing. The check should be done with bug 766877 based on crash stats.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: