Last Comment Bug 721264 - Please consider blocking BabyFox.dll from Babylon
: Please consider blocking BabyFox.dll from Babylon
Status: RESOLVED FIXED
[3rd-party-bustage][dll]
:
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Johnathan Nightingale [:johnath]
:
Mentors:
: 774270 (view as bug list)
Depends on:
Blocks: 742113 Babylon 700176 766877
  Show dependency treegraph
 
Reported: 2012-01-25 16:23 PST by Verdi [:verdi]
Modified: 2016-03-07 15:30 PST (History)
30 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
+
fixed
fixed


Attachments
Blocklist babyfox.dll, all versions (1008 bytes, patch)
2012-08-21 14:33 PDT, Johnathan Nightingale [:johnath]
benjamin: review+
Details | Diff | Splinter Review

Description Verdi [:verdi] 2012-01-25 16:23:51 PST
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.
Comment 1 Jorge Villalobos [:jorgev] 2012-01-26 08:09:35 PST
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?
Comment 2 Luke Wagner [:luke] 2012-02-06 09:24:07 PST
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?
Comment 3 Jorge Villalobos [:jorgev] 2012-03-02 11:58:40 PST
This block is being considered in bug 715744, and we haven't been successful in contacting Babylon.
Comment 4 Robert Kaiser 2012-03-06 05:49:48 PST
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.
Comment 5 Andrew Williamson [:eviljeff] 2012-03-06 06:04:26 PST
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
Comment 6 Jorge Villalobos [:jorgev] 2012-03-06 07:15:01 PST
Marking as security-sensitive, per comment #5.
Comment 7 Jorge Villalobos [:jorgev] 2012-03-06 07:59:23 PST
Andrew, what are URLs being loaded with chrome permissions?
Comment 8 Andrew Williamson [:eviljeff] 2012-03-06 08:10:23 PST
<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>
Comment 9 Justin Lebar (not reading bugmail) 2012-03-14 16:30:18 PDT
Marking with [3rd-party-bustage], a new whiteboard tag I'm using to track problems caused by third-party add-ons.
Comment 10 Verdi [:verdi] 2012-05-14 15:10:20 PDT
(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?
Comment 11 Jorge Villalobos [:jorgev] 2012-05-14 16:16:12 PDT
(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.
Comment 12 :ibai 2012-05-14 16:40:16 PDT
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
Comment 13 Jorge Villalobos [:jorgev] 2012-05-14 16:45:54 PDT
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.
Comment 14 Justin Lebar (not reading bugmail) 2012-05-14 18:53:17 PDT
> 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.
Comment 15 Scoobidiver (away) 2012-05-15 00:42:13 PDT
(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.
Comment 16 Jorge Villalobos [:jorgev] 2012-05-15 08:17:22 PDT
(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.
Comment 17 Justin Lebar (not reading bugmail) 2012-05-15 08:23:10 PDT
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.
Comment 18 Jorge Villalobos [:jorgev] 2012-05-15 08:29:08 PDT
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.
Comment 19 :ibai 2012-05-15 09:08:42 PDT
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.
Comment 20 Jorge Villalobos [:jorgev] 2012-05-15 11:21:15 PDT
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.
Comment 21 Justin Lebar (not reading bugmail) 2012-05-15 11:25:28 PDT
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".
Comment 22 Jorge Villalobos [:jorgev] 2012-05-15 11:28:18 PDT
For most users there's no difference, unfortunately. They'll just dismiss the dialog and won't know how to re-enable.
Comment 23 Justin Lebar (not reading bugmail) 2012-05-15 12:09:49 PDT
(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"?
Comment 24 Jorge Villalobos [:jorgev] 2012-05-15 12:52:54 PDT
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.
Comment 25 David Weir (satdav) 2012-07-16 07:29:20 PDT
*** Bug 774270 has been marked as a duplicate of this bug. ***
Comment 26 Tyler Downer [:Tyler] 2012-08-01 12:30:03 PDT
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.
Comment 27 Robert Kaiser 2012-08-01 12:55:40 PDT
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.
Comment 28 Justin Lebar (not reading bugmail) 2012-08-01 13:00:50 PDT
> 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.
Comment 29 Tyler Downer [:Tyler] 2012-08-01 13:03:37 PDT
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).
Comment 30 Paul Wright 2012-08-01 13:09:17 PDT
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.
Comment 31 Robert Kaiser 2012-08-01 13:13:42 PDT
(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?
Comment 32 Tyler Downer [:Tyler] 2012-08-01 13:29:47 PDT
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.
Comment 33 Tyler Downer [:Tyler] 2012-08-01 13:35:20 PDT
This is also one of our top issues on SUMO, with users who removed the Toolbar wondering how to get rid of the other stuff it leaves behind
https://support.mozilla.org/en-US/questions/932297
https://support.mozilla.org/en-US/questions/923451

https://support.mozilla.org/en-US/search?q=Babylon&num_voted=0&num_votes=&asked_by=&answered_by=&q_tags=&created=0&created_date=&updated=0&updated_date=&sortby=0&a=1&w=2
Comment 34 Jorge Villalobos [:jorgev] 2012-08-01 14:32:47 PDT
(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.
Comment 35 Tyler Downer [:Tyler] 2012-08-01 14:36:35 PDT
Let me test this in detail tomorrow, and I will get back to you.
Comment 36 Scoobidiver (away) 2012-08-01 15:39:04 PDT
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.
Comment 37 Tyler Downer [:Tyler] 2012-08-02 10:53:17 PDT
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
Comment 38 Robert Kaiser 2012-08-02 11:20:59 PDT
(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.
Comment 39 Scoobidiver (away) 2012-08-03 00:15:33 PDT
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.
Comment 40 Jorge Villalobos [:jorgev] 2012-08-03 14:17:53 PDT
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.
Comment 41 Scoobidiver (away) 2012-08-19 07:21:34 PDT
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
Comment 42 Jorge Villalobos [:jorgev] 2012-08-20 07:49:23 PDT
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?
Comment 43 Scoobidiver (away) 2012-08-20 08:19:03 PDT
(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).
Comment 44 Scoobidiver (away) 2012-08-20 08:49:19 PDT
FWIW, there are three Babylon toolbars:
* ffxtlbr@babylon.com
* ocr@babylon.com
* adapter@babylontc.com
Comment 45 Jorge Villalobos [:jorgev] 2012-08-20 09:04:43 PDT
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.
Comment 46 Scoobidiver (away) 2012-08-21 01:31:15 PDT
(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.
Comment 47 Robert Kaiser 2012-08-21 06:10:47 PDT
(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.
Comment 48 Johnathan Nightingale [:johnath] 2012-08-21 14:33:32 PDT
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.
Comment 49 Johnathan Nightingale [:johnath] 2012-08-21 14:35:37 PDT
(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 50 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-08-22 09:34:15 PDT
Comment on attachment 653956 [details] [diff] [review]
Blocklist babyfox.dll, all versions

Given what we know, this seems like the right solution.
Comment 51 Johnathan Nightingale [:johnath] 2012-08-22 12:18:59 PDT
(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?
Comment 52 Justin Lebar (not reading bugmail) 2012-08-22 13:34:28 PDT
https://hg.mozilla.org/mozilla-central/rev/102dc2118737

I'll push to Aurora in a few minutes.
Comment 53 Justin Lebar (not reading bugmail) 2012-08-22 13:41:23 PDT
> 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
Comment 55 [:Cww] 2012-10-02 18:17:01 PDT
*** Bug 797139 has been marked as a duplicate of this bug. ***
Comment 56 Simona B [:simonab] 2012-10-03 06:33:41 PDT
I am still able to install Babylon Toolbar 1.5.0 on Firefox 16 beta 6 on Windows. 
Is that ok?
Comment 57 Scoobidiver (away) 2012-10-03 06:41:10 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.