Spybot is freezing on removing the HOSTS file.
- Thread starter Forever
- Start date
It does not look as a Windows Me-problem for me. Still with 1.4 on a XP SP2 (machine with 3.2 GHz and 2 MB RAM) I have noticed since some month, that removing of the Sypbot hosts list takes the time, forever mentioned, whereas adding the list gets done in a few seconds. With 1.5 it seems, that also the adding of the Spybot hosts list takes significantly more time; I see a hourglass for 20 to 30 seconds, until the progress bar at the bottom appears at all, after that, the job gets finished in a second or 2 (as with 1.4)
Yes, it takes about 30 seconds on average. There's still something done in that time, the progress bar is just not really well used.
Feature request 79: Speed up Windows Hosts un-immunization
Feature request 79: Speed up Windows Hosts un-immunization
Well, this leads me to a more general question.
Let me say beforehand, that I am not an expert in behalf of this matter, but I took some time to investigate about this. By doing so I found several sources who told, that a too big hosts file does make the network connections slower. I was not able to find a source, which does tell a reliable value for that, but the mostly found values are those, which Bubba mentions here in post #9, that is a file size of more than 135 kb. Well at the moment, the host file here (with nothing in it except the SSD-entries) has something about 180 kb. And so I wonder, if this method is really appropriate, even if it does, what it is expected to do.
The point is, that in SSD 1.4 the usage of the hosts-file was an advanced setting and AFAIK not used by default. With 1.5 - as far as I found out - this kind of protection seems to be used by default - related to the Global (Hosts) setting on the immunize-page. And this seems to be set on by default. (Even it would not be set to on, it is likely that most users would do so, because the would otherwise get alarmed by the number of 6370 (at now) unprotected items at the top of this page.)
Further more I read, that the slowing down of the network connection with such a huge hosts file can be solved by disabling the DNS Client service. But, besides the fact, that SSD does not seem to tell the user about this (90+% of the users will not know about this), it is to question, if this advice is the real solution. For those, who are in a domain network, it will not be a feasible solution, but also for those, who are not in a domain network, there is a warning from Microsoft, who say, that the overall performance of the computer will slow down. (see knowledge base article 318803.
If I draw the right conclusions from what I found, I think, that placing the entries into the hosts file is a rather secure way to prevent getting connected with those sides. But as long, as the computer is clean and all other preventions are set properly (immunization listed below Internet Explorer, SD helper, Teatimer, actual AV-program, actually patched Windows, using a limited user account a.s.o.) a hosts file with such an extent seems to bring more trouble than effect. If I take a look at my actual desktop machine I find, that the oldest (2 years) backup of the hosts file has about 30 KB, that means, in only 2 years it has grown to 6 times the previous size; and IMO it is likely, that this will continue, if all the malicious sites will get stored there in the future.
At the end: I don't feel comfortable with the default-integration of the hosts file into SSD-immunization and would be interested to learn, what the technical experienced people have to say about it.
Let me say beforehand, that I am not an expert in behalf of this matter, but I took some time to investigate about this. By doing so I found several sources who told, that a too big hosts file does make the network connections slower. I was not able to find a source, which does tell a reliable value for that, but the mostly found values are those, which Bubba mentions here in post #9, that is a file size of more than 135 kb. Well at the moment, the host file here (with nothing in it except the SSD-entries) has something about 180 kb. And so I wonder, if this method is really appropriate, even if it does, what it is expected to do.
The point is, that in SSD 1.4 the usage of the hosts-file was an advanced setting and AFAIK not used by default. With 1.5 - as far as I found out - this kind of protection seems to be used by default - related to the Global (Hosts) setting on the immunize-page. And this seems to be set on by default. (Even it would not be set to on, it is likely that most users would do so, because the would otherwise get alarmed by the number of 6370 (at now) unprotected items at the top of this page.)
Further more I read, that the slowing down of the network connection with such a huge hosts file can be solved by disabling the DNS Client service. But, besides the fact, that SSD does not seem to tell the user about this (90+% of the users will not know about this), it is to question, if this advice is the real solution. For those, who are in a domain network, it will not be a feasible solution, but also for those, who are not in a domain network, there is a warning from Microsoft, who say, that the overall performance of the computer will slow down. (see knowledge base article 318803.
If I draw the right conclusions from what I found, I think, that placing the entries into the hosts file is a rather secure way to prevent getting connected with those sides. But as long, as the computer is clean and all other preventions are set properly (immunization listed below Internet Explorer, SD helper, Teatimer, actual AV-program, actually patched Windows, using a limited user account a.s.o.) a hosts file with such an extent seems to bring more trouble than effect. If I take a look at my actual desktop machine I find, that the oldest (2 years) backup of the hosts file has about 30 KB, that means, in only 2 years it has grown to 6 times the previous size; and IMO it is likely, that this will continue, if all the malicious sites will get stored there in the future.
At the end: I don't feel comfortable with the default-integration of the hosts file into SSD-immunization and would be interested to learn, what the technical experienced people have to say about it.
Sure, every measure to make a machine more secure reduces performance in some way. Large host files can do that as well. How much exactly is needed depends on the overall system speed, on whether it's part of a domain or not, and probably even more things.
We do not recommend system changes like disabling DNS service etc. because there are situations where that would be hazardous (you already mentioned it). It's in our FAQ (entry 12) though
Actually, a growing hosts file wouldn't need to mean slower speeds, at least not as much as it currently seems to have. With a pre-build trie (cached and updated only when the hosts file has changed) and an algorithm like Aho-Corasick, lookup could be relatively independent of the size. But when Microsoft implemented the hosts file first, using it the way we use it was never intended, and I guess Microsoft never spent too much time thinking about updates to that, even though hosts file blocking has spread a lot
I would agree that other blocks are more performant - on plugin/addon level (e.g. a BHO for Internet Explorer as Resident/SDHelper is), one is able implement better comparison algorithms for sure. But then, I always argument that malware often knows how to counter one or the other blocking method, but two or three (e.g. in the case of IE: 1. Hosts file 2. Immunization 3. BHO) are way more difficult to overcome by malware (or malware writers just don't care to try to counter more). And of course, both Plugins and Immunization work only for the applications they're designed for, not for every running application, which is only the hosts file (or a firewall).
We do not recommend system changes like disabling DNS service etc. because there are situations where that would be hazardous (you already mentioned it). It's in our FAQ (entry 12) though
Actually, a growing hosts file wouldn't need to mean slower speeds, at least not as much as it currently seems to have. With a pre-build trie (cached and updated only when the hosts file has changed) and an algorithm like Aho-Corasick, lookup could be relatively independent of the size. But when Microsoft implemented the hosts file first, using it the way we use it was never intended, and I guess Microsoft never spent too much time thinking about updates to that, even though hosts file blocking has spread a lot
I would agree that other blocks are more performant - on plugin/addon level (e.g. a BHO for Internet Explorer as Resident/SDHelper is), one is able implement better comparison algorithms for sure. But then, I always argument that malware often knows how to counter one or the other blocking method, but two or three (e.g. in the case of IE: 1. Hosts file 2. Immunization 3. BHO) are way more difficult to overcome by malware (or malware writers just don't care to try to counter more). And of course, both Plugins and Immunization work only for the applications they're designed for, not for every running application, which is only the hosts file (or a firewall).
But it isn't "freezing" At least not in terms of "standing still like frozen".
It only appears freezed since it uses all the computing power it gets to work through the file, and non to update the user interface.
At least not in terms of "standing still like frozen".It only appears freezed since it uses all the computing power it gets to work through the file, and non to update the user interface.