CookieSafe 2.0.6 Add-In
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!
Thomas L. Evans
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:I 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).
- windows XP SP2 (all the updates up to date
- Firefox 2.0.0.9
- CookieSafe 2.0.0.6
- SpyBot 1.5.1.15
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 in favor of CookieSafe Lite (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,
Pedro Brandão
Hmm, I dont know what's going seems fine on all mu pcs.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.
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.
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.
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.
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.
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.
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!
Posting Permissions
Reply With Quote