Enormous slow down after immunizing Firefox!

[PIGSgrame]

Today I downloaded the new 1.5 version of Spybot S&D and tried the "improved" immunization feature. After immunizing Firefox, I noticed that it took significantly longer to load a page.

The reason is that 6,153 bad domains are added to the image blocklist, the popup blocklist and the XPI installation blocklist, which means that Firefox has to look through a list af almost 20,000 entries in total on every page load.

But the really bad thing is: This is absolutely unnecassary! Since the domains are already in the hosts file and thus are routed to 127.0.0.1, there is no chance for Firefox to load anything from those sites, no matter if images, cookies, installations, or whatever are on the blocklists. I have not tested the reaction of other browsers, but I noticed that Spybot S&D does the same here: It unnecessarily adds entries to browsers' internal blocklists although those entries are already in the hosts file.

Please fix this with an upcoming update and prevent this completely useless slowdown from happening.

[MacDana]

Agreed. When you "immunize" Firefox, over 19,000 lines are added to your hostperm.1 file. This can have a pronounced negative effect on browsing/rendering speeds because that entire file is parsed every time a page is loaded.

A post from another newsgroup:
"Much of Spybot's immunization for Firefox is redundant and unnecessary.
Software installation and pop-ups are forbidden by default, so it makes
no sense to forbid them for specific sites, which is what Spybot does.
It might make sense to enable the 'Cookies' immunization and possibly
'Images' (it mostly forbids images from porn sites), but 'Popups' and
'Installations' make no sense whatsoever IMHO. If you forgo those two
immunizations, the performance hit will be significantly reduced."

[Zenobia]

You could try unimmunizing just Firefox,or unimmunizing parts of it.The only way I could find to do that in the Immunizing section,was to uncheck everything else except the checkmarked Firefox entries,and then click Undo.If you rightclick,and select deselect all,then go back and checkmark just the Firefox entries then click undo,it makes it go quicker.

After that,I did still have a large amount of entries still in the hostperm.1 file that look quite Spybotty though,I noticed,here's just a couple of them:
host image 2 f*ckdenniss.com
host image 2 f*cknicepics.com
host image 2 free-f*cking-video.com
host image 2 needf*cknow.com
host image 2 satisf*cktion.net
host image 2 .tjdo.com
host image 2 .ebav.com
host image 2 .ebgo.com
host image 2 .ebaw.com
host image 2 .ebkb.com
host image 2 .ebmu.com
host image 2 .ecmp.com
host image 2 .edhq.com
host image 2 .edty.com
I'd assume those should be removed after removing Firefox immunization,but I don't know enough about Firefox immunization to say that for absolute certain,and I don't have a slowdown on Firefox with Spybot's immunization to check that out for you.
Someone on Mozillazine forums mentioned having to edit out the Spybot entries in hostperm.1 to gain back performance,but like they said that could be tricky if you're not sure what to remove,as you might edit out entries that really should stay in there if they were added by something else other than Spybot:
http://forums.mozillazine.org/viewtopic.php?p=3046850&sid=5576abf73409fd67d744d454a51c4f95


But the really bad thing is: This is absolutely unnecassary! Since the domains are already in the hosts file and thus are routed to 127.0.0.1, there is no chance for Firefox to load anything from those sites, no matter if images, cookies, installations, or whatever are on the blocklists.

I prefer not to add the Spybot hosts list by personal choice,so that really doesn't work for me,and prefer that there is a choice to immunize/unimmunize Firefox instead,though I might be in the minority there.

[Yodama]

this is odd,

just checked the performance on Firefox 2.0.0.4 on Windows XP Pro SP2 when immunized with Spybot 1.5.
Opened multiple tabs (about 12), browsed and switched between the tabs. There appeared to be no performance loss at all.
The test computer has a AMD X2 4200+ with 512MB Ram.
The hostperm.1 file is 592KB after immunisation.

@PIGSgrame
could you specify your computer's configuration to determine the peformane loss? And could you specify

I noticed that it took significantly longer to load a page.?
Are we talking about seconds, minutes or else?

This appears to be an issue which does not happen on every configuration, so your help in finding a reason for this is appreciated.

@Zenobia


After that,I did still have a large amount of entries still in the hostperm.1 file that look quite Spybotty though,I noticed,here's just a couple of them:
host image 2 f*ckdenniss.com
host image 2 f*cknicepics.com
host image 2 free-f*cking-video.com
host image 2 needf*cknow.com
host image 2 satisf*cktion.net
host image 2 .tjdo.com
host image 2 .ebav.com
these entries will not be added with the Spybot version 1.5.15 and thus do not get removed after unimmunization. These could have been added when you used the beta or RC. Can you confirm this?


I prefer not to add the Spybot hosts list by personal choice,so that really doesn't work for me,and prefer that there is a choice to immunize/unimmunize Firefox instead,though I might be in the minority there.
I agree that the user is supposed to have the choice to immunize/add the Spybot hosts list as he pleases, thus giving a more personalized level of security.


What mightyglydd wrote in theses forums (uninstalling 1.5 and reinstalling 1.4): http://forums.mozillazine.org/viewtopic.php?p=3046850&sid=5576abf73409fd67d744d454a51c4f95
is not recommended since the level of immunization can be chosen and Spybot 1.5 has better routines for removal and detection of malicious software.

[Zenobia]

Yes,they're probably from the beta or rc.I remember now,when unimmunizing it got stuck,so I uninstalled and installed the new Spybot without unimmunizing.

After unimmunizing and editing out the Spybot entries in hostperm.1,the entries are removed/added as they should be when immunizing/unimmunizing.Thanks. :)

[tigreseis]

I have Firefox 2.0.0.6 and Spybot 1.5.1.15 installed. I never installed a beta or rc and I am having a significant slowdown in Firefox.

1.4 never did this, but after immunizing with 1.5 there is a noticable slowdown in loading pages and switching tabs. This does not occur in IE7.

It is an extended pause when switching tabs or loading pages. I unimmunized and the slow down was gone. When I immunized again, the slowdown was back.

[md usa spybot fan]

Tigreseis:


I have Firefox 2.0.0.6 ... and I am having a significant slowdown in Firefox.

1.4 never did this, but after immunizing with 1.5 there is a noticable slowdown in loading pages and switching tabs. ...
Just so that you aware, there was no immunization for Firefox in Spybot releases prior to Spybot 1.5. Therefore the fact that "... 1.4 never did this, …" is irrelevant.

Trying to determine the possible cause(s) of what you are experiencing vs. others who are not experiencing a problem is not a question of coding differences for Firefox immunization between Spybot 1.4 and Spybot 1.5, but rather the differences between the versions of Firefox, the system's OS (Operating System), system capacity or some other yet to be determined factor for the implementation of Firefox immunization in Spybot 1.5.

Pehaps it would be helpful if you provided more detail about the system where you are experiencing the problem.

[tigreseis]

Tigreseis:


Just so that you aware, there was no immunization for Firefox in Spybot releases prior to Spybot 1.5. Therefore the fact that "... 1.4 never did this, …" is irrelevant.

Trying to determine the possible cause(s) of what you are experiencing vs. others who are not experiencing a problem is not a question of coding differences for Firefox immunization between Spybot 1.4 and Spybot 1.5, but rather the differences between the versions of Firefox, the system's OS (Operating System), system capacity or some other yet to be determined factor for the implementation of Firefox immunization in Spybot 1.5.

Pehaps it would be helpful if you provided more detail about the system where you are experiencing the problem.

I didn't mean to imply that 1.4 immunized Firefox. I was merely stating that I never had a slowdown issue in 1.4, but with the advent of immunization in 1.5, I have. Since "undo"ing the immunization on Firefox there is no issue. Now as to my system:

I have an HP dv4000 laptop running XP Professional with 1gb memory and a 2ghz processor. I use Firefox 2.0.0.6 and IE7.

[HeinekenPissr]

I just reformatted my dell inspiron 8500 2.2 Ghz and 512 MB Ram and reinstalled WinXP. The first thing i did was install all drivers, install firefox and install all security updates for windows.

After reboot i installed my trusty Spybot S&D (v 1.5.1.15) , downloaded new updates (no beta or rc1) and immunized all. My Firefox was instantly crippled!! Not only did simple pages like google take 5 to 10 seconds longer to load but mere tab switching on pages already loaded in those tabs took about 3-5 secs depending on the page.

Solution: As stated above all i needed to do was to disable all firefox related immunizations

Still this is a major problem!

I can't give a recommendation to people without a warning. Which means i don't recommend this product anymore because i don't want the tech support phone calls phone calls.

[Always Confused]

Please note: I am not being argumentative, merely raising a few points:

1. I use Firefox 2.0.0.6 (.7 has not yet shown up).

2. I use Spybot 1.5.1.15.

3. I immunize Firefox, which causes no noticeable slowdowns.

Ergo, I have to question what is actually causing Firefox slowdowns. That is is what I mean by not being argumentative, as I am not stating that some Firefox/Spybot users are not seeing slowdowns.

Thus, I believe that some more testing needs to be done by those who are encountering the problem of slowness in Firefox when immunized by Spybot.

My suspicion, and it is nothing more than that, is that those who are seeing slowness in Firefox have one or more problems in their Firefox profile, extensions, or themes.

The first thing to do is to start Firefox in Safe Mode, which disables most such items. If, and only if, the slowness is no longer seen, then it is time to start disabling extensions and/or changing themes, to see if an interference can be found.

On the other hand, if no difference in speed is seen when running FF in safe mode, then the next test is to create a new FF profile, immunize that new profile with Spybot, then see if the slowness is still there. If, and again only if, the slowness remains, then at least there would be some reasonable conclusion that something in Spybot is indeed the proximate cause of the problem.

[TLEvans]

I am also suffering from very slow response since upgrading from 1.4 to 1.5.

In response to requests for additional information, I removed all my add-ins and performance returned to normal.

I found that CookieSafe 2.0.6 was the issue. When enabled response is very slow, even when switching from tab to tab. Disabled, everything is good.

Hope this helps!

[pbrandao]

I've encountered the same problem described in this thread. And, as suggested, "nailed" it to Cookie Safe 2.0.0.6. CookieSafe also checks and maintains a host based control list, that seems (???) not to be efficiently parsed.

Conf is:
windows XP SP2 (all the updates up to date
Firefox 2.0.0.9
CookieSafe 2.0.0.6
SpyBot 1.5.1.15I must add that I was not able to undo all the Firefox and Mozilla immunizations, as SpyBot just stayed in what it seemed an endless loop (had to kill the process).
I removed the hostperm.1 file and started firefox. A new hostperm.1 file was created without the immunization (Spybot states it as unprotected).
Slowdown has disappeared.

As an extra note, I've looked at the CookieSafe extensions forum and it seems CookieSafe is discontinued (https://addons.mozilla.org/en-US/firefox/reviews/display/2497) in favor of CookieSafe Lite (http://forum.softwareblaze.com/viewtopic.php?p=501) (not in Mozilla's addons).

After installing the extension and immunizing Firefox (with the browser shut down) I did not have the slowdown mentioned.

So perhaps they optimized the parsing (??)

HTH,

[FFKefka77]

Hmm, I dont know what's going seems fine on all mu pcs.:red: I have 2 comps (1 Windows XP Home and 1 Prof) n 1 laptop (Windows XP Media Center) all with the latest service pack and updates. They all have Spybot 1.5.1.15 and full immunize and have use Firefox 2.0.0.9 and there doesnt seem to be any slowdown or performance issues with pages or anything. But I think I didnt update Firefox from 2.0.0.8 on the laptop yet.

[pudelein]

I just saw this thread as I logged onto the forum with some complaints about Firefox (FF) immunization. Like several others in the thread, I use Windows XPSP2, fully patched; FF 2.0.0.9 as of this morning, but 2.0.0.8 was identical in behavior. I also use SeaMonkey(SM) 1.1.5 and SpyWareBlaster (SWB) and, when forced, IE7. The last plays no part in the following. I also use Spybot S&D (SSD) 1.5.1.17 (beta) [the HE beta].

Three files are involved here: The Hosts file, which I refer to as etc/hosts (Unix/Linux bias!); hostperm.1 in my FF profile; and hostperm.1 in my SM profile. All files receive large additions from SSD and/or SWB, as follows:

SWB makes no entries in etc/hosts; it adds (currently) 210 tracking cookie sites to each of the hostperm.1 files.

SSD adds no entries to SM hostperm.1, 7294 items to etc/hosts, and around 22000 entries to FF hostperm.1. The FF entries include 110 more tracking cookie sites, but more than 7000 lines controlling each of 'image', 'popup', and 'install' activities (3 x 7000+ = 22000). None of these sites should be listed in FF hostperm.1, since all (I think!...checking in detail is not practicable) are also in etc/hosts!

The real issue I have is this: the normal control of FF hostperm.1 is through the Tools | Options section. The enormous number of additions makes it extremely difficult to load and examine FF hostperm.1! In my view, it is urgent that only hosts not in etc/hosts be added to FF hostperm.1!

At the same time, it would be nice if anything from the drastically reduced list used to immunize FF hostmerm.1 could also be added to SM hostperm.1.

[Yodama]

hello,

thank you for your statements and reports on this issue.

About the performance issue with the Firefox it appears that Firefox has an issue when handling a large hostperm.1. However this issue does not appear to be obvious on all computer configurations. There are some steps which can be done on our part to improve this (like reducing the items added) , but the main issue still lies with Firefox handling the hostperm.1 file.

About the Immunization redundancy, as you may have noticed each part of the Spybot S&D Immunization is optional, you can check or unckeck the lines you want.
Additonally there is a simple reason why hosts file and browser Immunization overlap: to make it more difficult for malware to get what it wants.

[pudelein]

Yodama,

Thanks for your reply. I have in fact unchecked all Firefox immunizations in SSD except those for "cookies" so I no longer have the enormous hostperm.1 file. That, as is clear from my previous post, takes care of matters.

However, the reasons FF is so slow in handling the large hostperm.1 file seem to be these: first, it must search out and save all of the entries for "install" (for example); and second, it must alphabetize the list. The developers surely had no idea that this file would be used in the way that SSD does, as part of a security barrier. So I think it is a little disingenuous to assert that this is an FF issue, not an SSD one: SSD has made the issue appear. I also cannot see how "doubling up" the security "protection" prevents malware from doing malodorous things: If the etc/host file is working, the malware never gets into the target system to a place where the hostperm.1 protection could be effective at all.

Perhaps a compromise would be: ship SSD with Firefox immunizations disabled by default, coupled with a careful statement of how to turn them on and what the consequences of this are.

[pudelein]

Yodama,

When I posted earlier today, I omitted one point that I had intended to make. This is that in Firefox, the user can (should!) set controls to deny (block) all sites from install, popup, and image activities; then specific sites may be allowed such activities as "Exceptions" (this is the labeling on the buttons in Tools |Options). This being the case, I would argue that adding 7000 (or so) sites with "block" for popups, for example, is just wrong. Even if these sites were not in etc/hosts, the protection against their activities would be in place unless they were explicitly allowed.

Please read this post in conjunction with my post just above.

[Yodama]

pudelein,

thank you for your feedback and thoughts on this issue. You are right that the Immunization issue was caused by Spybot S&D, since it is Spybot that adds the entries. Maybe the FF Immunization should be turned off by default, on the other hand it was a feature requested by many users.
Another way for FF Immunization would have been to add the entries to an adblock list, but not every FF installation does have an adblock add-on. So we had to stick with the hostperm.1. My point about performance was that we have no direct influence on the way FF reads out the hostperm.1 the only thing we can do is to change the number of entries there. So we cannot directly fix the issue without disabling the FF Immunization or enter the FF dev team.

The FF options you mention store the sites entered into the hostperm.1, while the popupblocker is activated by default , installation is also restricted by default (so we may skip these during immunization), loading of pictures is on by default , so explicit blocking would be necessary. Having all pictures blocked by default and only allow pictures on demand would certainly cause a lot of inconvenience for most users.

The hosts file however does not guarantee that malware cannot enter your computer. For once the hosts file only protects against explicitly listed hosts, for example:
127.0.0.1 www.badhost.example
127.0.0.1 badhost.example

www.badhost.example would be blocked if it were directed to the local host IP or any invalid IP.
The same applies to badhost.example.
But bad.badhost.example would not be blocked.
In other words, the Windows hosts files cannot handle wildcards.
Also if an IP is contacted directly this would not be blocked either.
Browsers however are able to handle wildcards, this is also a point where we can compact the entries for the hostperm.1.

Having in mind the different ways a computer can be infected, it does make sense to have multiple overlapping layers of protection. While the browser Immunization only affects the browser, the hosts file would affect all internet connections aside from direct IP communication.

I am sorry if I made the impression that we would not work on this issue.

[pudelein]

Yodama,

One final post before I abandon this subject, at least for now. I had not thought about the wildcard hostname issue in etc/hosts. You are right, that is an advantage to using the browser's capabilities. Actually, adding wildcard capability to the lookup of hosts in etc/hosts might be a useful addition to the OSs (all of them!), but that is certainly beyond us all. You are, of course, correct about the "image" issue: I knew this, but one can in fact block all "third party" images by using about:config to change permissions.default.image from the default value "1" (allow all images) to "3" (block third-party images); the value "2" blocks all images. This would minimize the impact of image-blocking, but might not actually suffice for many users.

Best wishes for your success in mitigating SSD's impact on FF!