Spybot Immunize Plus IE 8 Final Equals Disaster On WinXP SP3

[war59312]

Hello,

It seems Spybot 1.6.2 is causing massive problems with IE 8 final on Windows XP SP3 machines. Vista SP1 appears to be unaffected.

If you do a complete spybot immunize it causes massive problems for not just IE 8, but all applications, so it seems.

Please See:

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=03b98c78-0b3a-417a-9590-0d5a0c6bb0fe

Notice an IE MVP has replied and stated that reports are coming in about this, so I'm not alone.

In my case though, on all 3 computers I have tried this on, every single problem was caused because of spybot immunize only. Spyware blaster continues to work just fine.

But mainly it causes IE 8 to use 100% CPU for about 5 minutes when starting it. Same with trying to load the windows control panel and many applications.

If you try and download a file in firefox for example it too freezes because it starts using 100% CPU.

So if you undo spybot immunize then no more problem.

By the way IE 8 RC 1 does not have this problem.

Thank You,

Will

[war59312]

Well, more information coming it.

People getting different results..

Heck even I am.. Still have orginal problem now on PCs that dont even have spybot. What the hell Microsoft!!!

Anyone else seeing any of this?

[Rouke]

Seeing problems with IE8?

yep, me too. (since the rc1 version)
Only difference is: I'd let Microsoft do some re-writing, not Safer networking.. :devil:

[djpailo]

I'm all for spybot, but don't start blaming Microsoft...

[Rosenfeld]

I don't seem to have any problems. I had immunized with IE 7 installed, then installed IE 8 and have no problenms, You do close the browser before immunizing?

XP pro SP3 all updates IE 8 Spybot 1.6,2 46 all updates

[war59312]

Indeed I always make sure all browsers are closed before immunized.

Screw IE 8 anyways, it's a dog even on Vista. POS!!

[Rouke]

@Djpallo: I'm all for stable browsing with IE ( especially since it's necessary with some sites & services)
Problem with IE7 & 8 is; both of them created instable situations on - otherwise - stable systems.. (updating from the last version)

I'm not one of those people who's always blaming Microsoft; but since sp3 Microsoft is making it increasingly more difficult for XP users..
Using certain options or installing new - but essential - software for instance..

@Rosenfeld: I installed IE beta2 before even installing S&D; after I had several issues with IE8 rc1.. (I installed my windows several times during that - very - problematic period.)
I'm not even risking IE8 final.. (that's oke, I use Opera & another browser as alternatives)

[PepiMK]

Immunization means using the browsers own options for protection.

All the immunization does is filling the browsers blacklists. Leading to the same result as if you would add all those domains manually.

From my standpoint, its not a question whether the list was made for such a huge amount of entries or not - Microsoft has been knowing for years that it is being used for that, and should have adjusted. And it's not like it would be complicated, previous IE versions were dealing with it fine. In computer science, it should be a standard test case to check every user maintained list for its capacities. Granted, it's not always done, and I have to admit we've failed on that aspect as well before (see our problem with huge lists of user cookies). But that means fixing up the mess (what would you've said if we told you "just don't use that many cookies"?).

[reygeko]

So, what will the future solution be?

Wait till Microsoft fixes the problem?

I supose someone is in contact with microsoft.

When is the solution expected to be fixed?

Thanks.

[m00nbl00d]

http://news.softpedia.com/news/Post-RTW-IE8-Bugs-Will-Be-fixed-in-the-Next-Version-of-Internet-Explorer-107612.shtml

This might give you a clue of when it will be solved.

Unless there is a massive complaint against Microsoft, I don't see how this issue will be quickly solved.

I know this might sound bad, but, if people wish to see things solved, perhaps, they should threaten Microsoft they will start using alternate browsers.

Would that do the trick?


Regards

P.S: As Patrick well mentioned, this is not an issue with Spybot. It's a bug within IE 8 (Final Version), regarding the Restricted Sites zone.

This issue also affects applications requiring administrative rights, such as Spybot's updating. It will increase the response time.

Could you guys imagine waiting like 30 minutes (Just an estimative.), just to install an application like VMWare Workstation? I believe that would be the time to wait for an UAC prompt to appear.
It takes like 8 minutes or so, just to wait for Spybot's update module to respond.

[2harts4ever]

Good morning m00nbl00d,

I must be one lucky 'sucker' because when I check for Spybot S&D updates it is almost instantaneous as was the case before I installed IE8 on my computer (Compaq Presario AMD Athlon(tm) 64 Processor 3300+, 2411MHz/1.93 GBs RAM, running Windows Xp Home, SP3., with IE8).

Maybe I am one of the lucky ones.

Regards,

2harts4ever:wub::wub:

[m00nbl00d]

Hello 2harts4ever,

I forgot to mention that, as far as I'm aware of, this issue only affects Windows Vista (including SP1, which is the one I use, x86, but I believe it affects all versions), with UAC enabled.


Regards

[Rosenfeld]

Further to my previous post, I've now done some tests. The only effect for me of having Spybot immunization is a slight delay when first opening IE 8. It takes ~2 seconds to load my home pages without any restricted sites, ~5 seconds with the ~10500 sites added by Spybot. I can live with that.

[m00nbl00d]

Further to my previous post, I've now done some tests. The only effect for me of having Spybot immunization is a slight delay when first opening IE 8. It takes ~2 seconds to load my home pages without any restricted sites, ~5 seconds with the ~10500 sites added by Spybot. I can live with that.

It depends on how many domains are placed at the Restricted Sites Zone.

The more there are, the slower things become.

I did a test, by making use of Spybot, SpywareBlaster and IE-Spyad entries, and the result is what I mentioned, previously.

[bitman]

If the choice is between filling my Restricted Sites with thousands of entries on a weekly basis or using Internet Explorer 8, I'd use IE 8. Here's a comment about this issue from the Internet Explorer Blog relating to the RTM release.

http://blogs.msdn.com/ie/archive/2009/03/19/internet-explorer-8-final-available-now.aspx#comments

# re: Internet Explorer 8 Final Available Now
Saturday, March 21, 2009 9:49 PM by EricLaw [MSFT]

@Howard: Firstly, please notice that I did not suggest that users "disable Spybot" but rather that they not use the "Immunize" feature.

The immunization feature offered by SpyBot is not required to browse safely with Internet Explorer 8. IE8 includes more reliable protections against malicious sites, including per-site ActiveX, ActiveX opt-in, DEP/NX, Protected Mode, and SmartScreen Filter.

Blocking a static list of sites using Zones is fundamentally a losing game, because (as phishers have demonstrated for years) attackers can simply deliver malicious attacks from new domains or IP addresses.

IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter (http://blogs.msdn.com/ie/archive/2009/03/25/ie8-security-part-ix-anti-malware-protection-with-ie8-s-smartscreen-filter.aspx)

Personally, I haven't been using immunize on current operating systems myself for a couple years. The fast-flux networks and other quickly changing location technologies involved in malicious delivery systems today make this relatively slow method of site blocking nearly useless and simply an exercise in update futility.

Since these registry and hosts entry systems were never really designed for automated 'stuffing' of large lists, they've always been limited by the overhead they create. The idea that these lists have no effect on the operation of a system and are in effect 'passive' is a myth that has pervaded the home security community for years. Any 'list' contained within a program will require a finite amount of time to search, regardless of the efficiency of the code that performs it.

However, the real problem here isn't the abused technolgy, it's the valid points made by Eric in his comment that there are much better protection systems now built into IE 8 itself. These systems in some cases don't suffer from the scalability issues that are inherent with locally hosted and searched lists. For example, SmartScreen Filter uses a list which is hosted by Microsoft, to which any IE 8 user can contribute and which is thus much more quickly responsive than a local list downloaded weekly.

Much is often discussed about the limitations of collecting and distributing lists of malicious code (i.e. viruses) and the inherent delay involved. However, few ever consider this same issue as it relates to malicious sites, since these somehow seem less likely to change. In reality though, many of the most prolific malware delivery systems in use today are much more dynamic and thus too quickly changing for such old ideas to work. These systems are best left for the user to perform blocking of individual sites on demand, which was their intended purpose in the first place.

Bitman

[ssuperdave]

I also updated to IE8 and have had no problems .. the only glitch i have is it takes a few seconds longer for the main page to load ..

[2harts4ever]

bitman,

Excellent response! I find it filled with well-thought out reasoning on your part and written in such a way that folks like me with limited computer knowledge can understand what you are saying.

I for one appreciate you sharing your thoughts with the rest of us watching this thread.

Thanks and regards,

2harts4ever :wub::wub:

[m00nbl00d]

If the choice is between filling my Restricted Sites with thousands of entries on a weekly basis or using Internet Explorer 8, I'd use IE 8. Here's a comment about this issue from the Internet Explorer Blog relating to the RTM release.

http://blogs.msdn.com/ie/archive/2009/03/19/internet-explorer-8-final-available-now.aspx#comments


IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter (http://blogs.msdn.com/ie/archive/2009/03/25/ie8-security-part-ix-anti-malware-protection-with-ie8-s-smartscreen-filter.aspx)

Personally, I haven't been using immunize on current operating systems myself for a couple years. The fast-flux networks and other quickly changing location technologies involved in malicious delivery systems today make this relatively slow method of site blocking nearly useless and simply an exercise in update futility.

Since these registry and hosts entry systems were never really designed for automated 'stuffing' of large lists, they've always been limited by the overhead they create. The idea that these lists have no effect on the operation of a system and are in effect 'passive' is a myth that has pervaded the home security community for years. Any 'list' contained within a program will require a finite amount of time to search, regardless of the efficiency of the code that performs it.

However, the real problem here isn't the abused technolgy, it's the valid points made by Eric in his comment that there are much better protection systems now built into IE 8 itself. These systems in some cases don't suffer from the scalability issues that are inherent with locally hosted and searched lists. For example, SmartScreen Filter uses a list which is hosted by Microsoft, to which any IE 8 user can contribute and which is thus much more quickly responsive than a local list downloaded weekly.

Much is often discussed about the limitations of collecting and distributing lists of malicious code (i.e. viruses) and the inherent delay involved. However, few ever consider this same issue as it relates to malicious sites, since these somehow seem less likely to change. In reality though, many of the most prolific malware delivery systems in use today are much more dynamic and thus too quickly changing for such old ideas to work. These systems are best left for the user to perform blocking of individual sites on demand, which was their intended purpose in the first place.

Bitman

Yes, IE 8 brings additional security.
But, let's not forget important facts here.

Fact - Not everyone has, unfortunately, patience to deal with UAC. There's always something that doesn't work quite well, and, if people can't make it to work, then, they'll have to find people who'll do it for them. Perhaps, their IT professionals.

Fact - Even though is IE 8 is safer than any other previous version, it won't be 100% effective. Nothing is.

Fact - Regardless if some user makes use of SpywareBlaster, Spybot - Search & Destroy, IE-Spyad or any other entries, to add to IE's restricted sites zone, there's always going to exist this additional layer of security.

Fact - If the Restricted Sites Zone is useles, why still existing? Makes no sense, at all.

Fact - Not everyone has the knowledge to tweak IE for a safer browsing, like disabled ActiveX and only enabling per site. They'd got lost with those tweakings.

Fact - All that was said on that post, in no way, is a valid reason not to fix this bug, that didn't exist in the release candidate version.

One thing is theory, one other practice. Two different realities.

[bitman]

It's not theory, none of the computer systems I mentioned or any of my own have any special settings other than the Windows XP/Vista and/or IE 7/8 defaults and they've protected both myself and my nephews very well. Any of the products you mentioned are add-ons not included with Windows and require special additonal operations by the user to use them, so they are actually more difficult for a non-technical user to manage.

The only advertised reason that Restricted sites exist is to allow a user to add an entry manually one at a time within Internet Options, Security tab, Sites button. Automated 'stuffing' of these registry entries has never been addressed in any Microsoft Technical literature and thus is not officially supported. It is products such as Spybot S&D and SpywareBlaster that have implied that this is the reason they exist, not Microsoft.

How to use security zones in Internet Explorer
http://support.microsoft.com/kb/174360

Windows Help and How-to: Security zones: adding or removing websites
http://windowshelp.microsoft.com/Windows/en-US/Help/fd277a6b-3722-445b-b32e-1f8e925c385a1033.mspx

Please note that I did not include UAC in my discussion, since that's not really a security feature, it's a nag box designed purposefully to annoy users of badly written software in hopes they'll complain to the real offenders, the vendors of the software that are unnecessarily requiring Administrative priviledge for their programs to operate. Otherwise, the only prompts you should see are those that would actually require Administrative access, such as program installation.

And note that I never stated the 'bug' shouldn't be fixed, though I personally don't care if it ever is for the reasons I've already stated. If there's one thing I've learned by observing these and other forums it's that many people will only feel protected if they've installed and updated a half dozen often conflicting and questionable products every week, even if the aggregate protection provided by these products is no better than what one good product might provide. It's also quite obvious that many of these same users will avoid or ignore updating either thrid-party software products or even Windows itself, even though these are the most proven methods of providing actual protection.

True security is actually very simple, repetitive and mundane. The more complex the process is made the more likely it will fail.

Bitman

[m00nbl00d]

It's not theory, none of the computer systems I mentioned or any of my own have any special settings other than the Windows XP/Vista and/or IE 7/8 defaults and they've protected both myself and my nephews very well. Any of the products you mentioned are add-ons not included with Windows and require special additonal operations by the user to use them, so they are actually more difficult for a non-technical user to manage.


Actually, making use of Spybot's and SpywareBlaster's immunizations, is a lot easier than actually having to tweak IE, to offer, by itself, a better protection.

It's a two step process. Update and re-immunize. Simple.



The only advertised reason that Restricted sites exist is to allow a user to add an entry manually one at a time within Internet Options, Security tab, Sites button. Automated 'stuffing' of these registry entries has never been addressed in any Microsoft Technical literature and thus is not officially supported. It is products such as Spybot S&D and SpywareBlaster that have implied that this is the reason they exist, not Microsoft.


Then, why not just take the Restricted Sites Zone option, since, what you mention, would be better to place at the HOSTS file, which would prevent anything in the system to connect to that domain.

But, what the Restricted Sites Zone offers, that the HOSTS file lacks, is the capability of adding domains like *.bad-domain. com. By placing a *, the user would be blocking access to any domain within the domain .bad-domain. com, and not just to the main one.

So, such feature and such entries, are, in my most opinion, useful, and waste no resources. Most important, provide an extra layer of security.




How to use security zones in Internet Explorer
http://support.microsoft.com/kb/174360

Windows Help and How-to: Security zones: adding or removing websites
http://windowshelp.microsoft.com/Windows/en-US/Help/fd277a6b-3722-445b-b32e-1f8e925c385a1033.mspx


This info my be useful to some person, digging through this thread. Not to me, though. But, thanks.



Please note that I did not include UAC in my discussion, since that's not really a security feature, it's a nag box designed purposefully to annoy users of badly written software in hopes they'll complain to the real offenders, the vendors of the software that are unnecessarily requiring Administrative priviledge for their programs to operate. Otherwise, the only prompts you should see are those that would actually require Administrative access, such as program installation.


Actually, it is a security mechanism. When UAC is enabled, it will also enable the Protected Mode in IE7 and IE8, in Windows Vista and Windows 7. This will decrease what IE can do in the system.

UAC is also a good way to know when something is requiring elevated rights to do important changes in the system.
Let's imagine that some user would open an e-mail, and, UAC alert for something. "Houston, we have problem.".

So, UAC is much more than just an annoyance.



And note that I never stated the 'bug' shouldn't be fixed, though I personally don't care if it ever is for the reasons I've already stated.


Fair enough.



If there's one thing I've learned by observing these and other forums it's that many people will only feel protected if they've installed and updated a half dozen often conflicting and questionable products every week, even if the aggregate protection provided by these products is no better than what one good product might provide. It's also quite obvious that many of these same users will avoid or ignore updating either thrid-party software products or even Windows itself, even though these are the most proven methods of providing actual protection.


Unfortunately, it happens. But, this are people, who get, perhaps, their first system. Are not even aware of the existing dangers.
But, the main problem here, are the IT professionals. They don't alert the costumers for that very same fact. They just install a free and crippled antivirus, and that's it, pretty much.

Last year, a relative of mine, bought a computer (New computer user), and the folks where this computer was bought, only installed a free and crippled antivirus. They didn't care to explain how to update it. They haven't enabled UAC. They also didn't explain how to work with it, obvisiouly.
To make things a lot worse, they didn't create a normal user account.



True security is actually very simple, repetitive and mundane. The more complex the process is made the more likely it will fail.

Bitman

Yes, I agree. That security should be simple, that is. But, just because one makes use of a layered security, that doesn't mean it isn't simple.

One can just make use of a very complex Intrusion Prevention System. But, would it be simple, then?


Best regards

[bitman]

Actually, making use of Spybot's and SpywareBlaster's immunizations, is a lot easier than actually having to tweak IE, to offer, by itself, a better protection.

It's a two step process. Update and re-immunize. Simple.
Even simpler, don't bother to 'tweak' at all, I never do. My nephew still couldn't successfully install the fake anti-virus product he downloaded both because he didn't have the priviledge (Standard account) and the AV/AS app caught most of the trojans and other files anyway. This required me to install a properly updating security product initially, but requires absolutely no maintenance since then, since everything performs automatic updates.

The new SmartScreen Filter in IE 8 should improve this even further by detecting most malware before it ever reaches the filing system.

IEBlog: IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter
http://blogs.msdn.com/ie/archive/2009/03/25/ie8-security-part-ix-anti-malware-protection-with-ie8-s-smartscreen-filter.aspx



Then, why not just take the Restricted Sites Zone option, since, what you mention, would be better to place at the HOSTS file, which would prevent anything in the system to connect to that domain.

But, what the Restricted Sites Zone offers, that the HOSTS file lacks, is the capability of adding domains like *.bad-domain. com. By placing a *, the user would be blocking access to any domain within the domain .bad-domain. com, and not just to the main one.

So, such feature and such entries, are, in my most opinion, useful, and waste no resources. Most important, provide an extra layer of security.
Spybot S&D Immunize by default places the same entires in the Hosts file, but I don't use that either. As with the current issue with Restricted Sites, large Hosts file lists often create peformance issues, though usually only on Windows 2000 and older systems that lack resources. The more common issue is with many current anti-virus products which contain monitoring features that partially conflict with such large files, causing their own performance issues.

As I stated earlier, all lists which are searched linearly will create some overhead, the only question is how much. Unless either the PC is very high performance or the lists are indexed like a database, performance will eventually suffer, it's simply a matter of at what quantity it will become noticeable.



This info my be useful to some person, digging through this thread. Not to me, though. But, thanks.
The developers who are 'stuffing' these lists programatically don't want to hear that Microsoft doesn't support this, but they need to.



Actually, it is a security mechanism. When UAC is enabled, it will also enable the Protected Mode in IE7 and IE8, in Windows Vista and Windows 7. This will decrease what IE can do in the system.

UAC is also a good way to know when something is requiring elevated rights to do important changes in the system.
Let's imagine that some user would open an e-mail, and, UAC alert for something. "Houston, we have problem.".

So, UAC is much more than just an annoyance.
I'll give you some of this, since what I should have said is that UAC isn't a 'security boundary', it's merely an alerting system tied to the process elevation ability. However, UAC itself desn't create the Protected Mode, it merely enables it to function within a Standard account to provide the security. Here's the key elements and a link to the complete explanation.

http://technet.microsoft.com/en-us/library/cc749393.aspx

While most Internet Explorer 7 security features will be available in Internet Explorer 7 for Windows XP Service Pack 2, Protected Mode is only available on Windows Vista because it is based on security features new to Windows Vista.


User Account Control (UAC) makes it easy to run without Administrator privileges. When users run programs with limited user privileges, they are safer from attack than when they run with Administrator privileges because Windows can restrict the malicious code from carrying out damaging actions.

Integrity mechanism restrict write access to securable objects by lower integrity processes, much the same way that user account group membership restricts the rights of users to access sensitive system components.

UIPI prevents processes from sending selected Windows messages and other USER APIs to processes running with higher integrity.

The Windows Vista security infrastructure enables Protected Mode to provide Internet Explorer with the privileges needed to browse the Web while withholding privileges needed to silently install programs or to modify sensitive system data.


< SNIP >



Unfortunately, it happens. But, this are people, who get, perhaps, their first system. Are not even aware of the existing dangers.
But, the main problem here, are the IT professionals. They don't alert the costumers for that very same fact. They just install a free and crippled antivirus, and that's it, pretty much.

Last year, a relative of mine, bought a computer (New computer user), and the folks where this computer was bought, only installed a free and crippled antivirus. They didn't care to explain how to update it. They haven't enabled UAC. They also didn't explain how to work with it, obvisiouly.
To make things a lot worse, they didn't create a normal user account.
Unfortunately the Microsoft estimate is that roughly 60% of systems out there belong to people who don't even have a current antimalware installed or being updated (expired subscriptions) on their PC, let alone those operating with several conflicting programs of dubious value.

Actually, though I agree with your general discussion here, I wouldn't call these 'IT professionals', they're mostly sales people and often just kids. In any case, their primary job is to get the buyer out of the store and not have them calling to ask questions, so security is of little concern to them. If they do things like turn on UAC or provide Standard accounts, most users would complain or call the store for help, so they take the easy out.

This isn't surprising and is just a portion of the symptoms of a dysfunctional computer industry that's based on selling the box rather than the services that are really needed by most customers. Unfortunately the US consumer himself is the problem here, since he wants to buy the box cheap and not pay anything for support, so he gets exactly what he paid for.



Yes, I agree. That security should be simple, that is. But, just because one makes use of a layered security, that doesn't mean it isn't simple.

One can just make use of a very complex Intrusion Prevention System. But, would it be simple, then?
I'm not saying the system you're trying to use isn't simple enough, but is it really the most effective? If you're deciding to stay with IE 7 to keep the Spybot S&D Immunizations then you're missing the improved security features included in IE 8.

I know you'd rather have both, but the discussion here has asssumed that for some they appear to be mutually exclusive, at least until the perfomance problem has been resolved.

Bitman

[Yodama]

hi,

first I have to say that the entries Spybot S&D adds to the restricted zones is a redundant part of the protection provided. It is also covered with the hosts file immunization and the SDHelper. If I am correct there are no reported issues between the SDHelper and the IE8, so using the IE8 without immunizing it but using the SDHelper should also provide a sufficient level of security for most users.

Secondly I need to bring up the endless discussion about effective security measures. There are basically 2 points of view, one states that most security measures are useless to harmful and the other states that most security methods are useful. Personally I tend more to the second group.
As critics state correctly there are malware in the wild which can overcome most existing security measures, in this case by switching domains quickly, but there is a whole lot more malware which cannot. This basically applies to all parts of a security system and in general also applies to other real life security systems, for instance in a car.
A car maybe a good example to explain my view to most people. It has a chassis and stuff like airbags, seat belts and so on. But as everyone should know this does not protect the users of the car from all possible ways of harm they could experience on the road. A frontal crash at a colliding speed of 100km/h for example will most likely kill all persons inside the car, regardless of the quality of airbags, chassis and seat belts. But at a colliding speed of 60km/h most passengers will survive due to the chassis, airbags and seat belts.
I guess that there are very few who would like to trade off chassis and airbags for less weight and thus less costs in a car with the argument that these things are useless against a frontal crash with a common traveling speed on the highway.

Thirdly, back to the IE8.
One of the main problems during software development is that often the software does not get designed as it should be but "grows". The IE is almost as ancient as the internet itself and the IE8 still offers downward compatibility while it "grew". Keeping downward compatibility is usually used for user comfort, but this often also brings issues with it, in most cases loss of performance. In this case with the IE8 and restricted zones, there is indication that Microsoft does not intend to support this old IE feature anymore. If that were the case, the IE8 team would have tested different input values for the restricted zones, including numbers of domains close to the maximum number of possible entries and beyond.

Team Spybot will discuss this issue on Monday in detail to determine our course of action with this issue.
It is also to be seen how Microsoft will react to this issue.

[qwerty59]

Until this is sorted out, I think I've worked around the issue by Undoing immunization for \SOFTWARE (Domains), .DEFAULT (Domains) and User (Computer Name) (Domains); I haven't found it necessary to do the same with the Secure Domains alternatives, or Global (Hosts).

Am I on the right track?

[m00nbl00d]

[...]

I'm not saying the system you're trying to use isn't simple enough, but is it really the most effective? If you're deciding to stay with IE 7 to keep the Spybot S&D Immunizations then you're missing the improved security features included in IE 8.

I know you'd rather have both, but the discussion here has asssumed that for some they appear to be mutually exclusive, at least until the perfomance problem has been resolved.

Bitman

I'm using IE 8 RC, and this issue does not exist.

Also, this is not about IE 8 (Final Version) vs Spybot and others. This is about a bug, that didn't exist in the RC version, nor in the Beta versions, if I well remember.

If a bug or not (something, intentionally, done by Microsoft), is another story. But, if, in fact, their choice, then the user should be alerted for that, during IE 8 installation.


Regards

[bitman]

Though I personally have no interest in using the Immunization features on a recent OS, I still use it on Windows 2000, where other protection is less available and IE 6 is still present. I believe this is the appropriate place for such features to remain and so this may affect the future design decisions for them within the SBSD 2.0 product.

I had enough interest in this subject that I attended the recent IE team Expert Zone chat on Wednesday and noticed that PA Bear, an MVP from the Microsoft Security group was also in attendance. I asked the first of the following two questions and I believe he asked the other. Though these aren't definitive, they do help in understanding how it occured and to some extent how Microsoft views the issue.

Bitman


Frank [MSFT] (Expert)[12:12]:
Q: [4] Does Microsoft (or IE Group specifically) have an official stance towards the 'stuffing' of Restricted Sites performed by Spybot S&D, SpywareBlaster and others, especially as it relates to performance? Any references or supporting documentation available?

A: We have received a lot of reports from users about perf issues being caused by this...We are following up with software developers on these issues. We will have more documentation on IE extensibility soon.


EricLaw [MSFT] (Expert)[12:13]:
Q: [16] Can you briefly discuss the change made in IE8 Final that causes the conflict with having a large number of sites running in Restricted Sites zone (cf., SpywareBlaster; Spybot; et. al.), especially since the conflict was not seen in any beta builds?

A: This was a side-effect of a recent change to better support non-standard top-level-domains which are becoming more common. You can read about the general issue with non-standard TLDs on http://publicsuffix.org. IE8 maintains an internal public suffix list. That list changes IE's handling of "known" special TLDs. Unfortunately, the Zones registry format has a dependency on TLDs, which means that we must recalculate the registry against this new TLD list. That works fine in the general case, but fails badly when there are thousands of sites in the lists. We're working on this issue.

[IanHarrop]

I emptied the hosts file of all 10,000 plus Spybot entries and IE 8 is still very slow to launch.

I don't use teatimer or the resident part of Spybot because I have other protection. I simply use Spybot to double check once a week on Wednesdays after the updates come out.

I like the idea of immunization, but emptied the hosts file as a test.

[md usa spybot fan]

IanHarrop:

I'm sorry that you seem to be caught up in the middle of possibly controversial situation.

If I understand the problem you are experiencing, you indicated that you emptied the HOSTS file of Spybot entries and still are experiencing slow loading of Windows Internet Explorer 8. The problem with slow loading of Windows Internet Explorer 8 (IE 8), as I understand, it is not related to HOSTS file entries, but rather that the quantity of the "Restricted zone" entries.

To elevate the problem try go into Spybot » Immunize » uncheck all entries except those entries designated as "… (Domains)" or "… (Secure Domains)" and then click "Undo" (in the left hand pane).

_____

It appears to me that although there were widely reported delays in the loading of a IE 8 when there were significant number of "Restricted zone" entries in the registry during beta testing, Microsoft elected not to correct the problem before the releasing IE8 nor have they elected to officially publicize the cause of the problem and their official recommendations.

I welcome anyone to publish a Microsoft URL that acknowledges that a problem with IE8 "Restricted zone" entries exists or what they official resolution is.

[IanHarrop]

Thanks.

That greatly improved load time!

[bitman]

< SNIP >

It appears to me that although there were widely reported delays in the loading of a IE 8 when there were significant number of "Restricted zone" entries in the registry during beta testing, Microsoft elected not to correct the problem before the releasing IE8 nor have they elected to officially publicize the cause of the problem and their official recommendations.

I welcome anyone to publish a Microsoft URL that acknowledges that a problem with IE8 "Restricted zone" entries exists or what they official resolution is.

Hey there md,

The point at which Micorosft declares something 'official' is when they've decided to do something specific, have a plan and usually a date or at least a general idea when it will be resolved. This has always been true, since saying anything before all of these things are in place just generally results in useless bickering as has happened here.

However, the two Q&A segments I posted above from the IE team Expert Zone chat are about as official as it ever gets without the above. Though they aren't commiting to anything specific, they are admitting and in fact detailing what has caused the problem, as well as indicating they are 'working on the problem'. Though this isn't saying it will be fixed, it at least shows that they are both aware of and investigating the possiblity of a solution to the problem.

Since this was stated in a public chat that anyone could attend, and in fact should be published somewhere on the Microsoft sites in the chat log, it's far from a secret now and has already been published in at least one blog.

In any case, I think this should still be taken as a wake up call to the Spybot Team that the Restricted sites function which has never been officially supported for this type of use by Microsoft might best be reconsidered for future support by Spybot S&D. If this were a published method, my thoughts would be different, but I have never seen large lists described in anything other than problem resolution documents myself.

Bitman

[m00nbl00d]

Hey there md,

The point at which Micorosft declares something 'official' is when they've decided to do something specific, have a plan and usually a date or at least a general idea when it will be resolved. This has always been true, since saying anything before all of these things are in place just generally results in useless bickering as has happened here.

However, the two Q&A segments I posted above from the IE team Expert Zone chat are about as official as it ever gets without the above. Though they aren't commiting to anything specific, they are admitting and in fact detailing what has caused the problem, as well as indicating they are 'working on the problem'. Though this isn't saying it will be fixed, it at least shows that they are both aware of and investigating the possiblity of a solution to the problem.

Since this was stated in a public chat that anyone could attend, and in fact should be published somewhere on the Microsoft sites in the chat log, it's far from a secret now and has already been published in at least one blog.

In any case, I think this should still be taken as a wake up call to the Spybot Team that the Restricted sites function which has never been officially supported for this type of use by Microsoft might best be reconsidered for future support by Spybot S&D. If this were a published method, my thoughts would be different, but I have never seen large lists described in anything other than problem resolution documents myself.

Bitman

One better solution, considering, also, that the Restricted Sites Zone entries go all to the Windows registry, would be for this Spybot's feature to work as an in-the-cloud service.

[bitman]

One better solution, considering, also, that the Restricted Sites Zone entries go all to the Windows registry, would be for this Spybot's feature to work as an in-the-cloud service.

Agreed. The problem is that such centralized web database designs require a significant amount of resources in both hosting and bandwidth, generally distributed worldwide. Unfortunately only organizations with big budgets like Microsoft and McAfee usually have this kind of funding.

Note from that link I posted earlier that the IE 8 SmartScreen Filter not only protects based on sites, but also files, so it's more like a combination of Immunization and the SDHelper resident. However, it's potentially far more responsive since it operates from a central database which can be updated much more quickly with a much broader and deeper database than the weekly updates Spybot S&D provides.

As you mentioned earlier, if they can be combined you can receive the protection of both, though there'll always be overhead and thus a performance hit, though it may not be noticeable in all cases. From my standpoint though, I believe that Microsoft will usually provide most of the same protection, so I'd be creating a lot of duplication and overhead for very little return. Of course, this isn't true for any older operating systems like the Windows 2000 PC I have, so I'll still use all of the features there to compliment the Avast! AV and SpywareBlaster.

I think the biggest point here is that as malware has changed, so has the response from the security community including Microsoft itself. Though Spybot S&D is very configurable which allows reacting to this change, only technically minded users are able to fully understand the requirements of these changes. Thus if Team Spybot wants to support the less technical user they'll need to monitor these changes and react to them with the default tuning of their product, since that user base simply won't take the time to understand security products.

The other choice is simply to decide that the Spybot S&D product is a technical users tool, which has really always been true, and leave the configuration decisions up to the user or adminstrator. This is likely to reduce the numbers of users of the product, but this may be appropriate if they don't wish to 'dumb down' the product in an attempt to service the non-technical user.

I have no problem making these decisions myself, but I have over 30 years background in microprocessor based computers, networks and their security along with several years of assembly language programming experience. The confusion about this issue shown in this and other threads makes it quite clear that many don't have the patience and background to react to such issues in a logical (technical) manner. This has been a tough lesson for even Microsoft to learn as the last 10 years has shown quite clearly.

Bitman

[m00nbl00d]

Another solution would be to place the domains entries in a XML file, for example. Rather than placing them at the Windows registry.

Of course, this XML file would need to be well protected by Spybot's self-defense.

Actually, looking at present scenario (Registry) and the other solution I provided earlier, this one sounds more doable.

[PepiMK]

A XML file? XML is a very slow thing actually, and I've never heard that IE supports XML files for these entries.

Please keep in mind, it's not us deciding on the data structure (we would've simply picked a pre-sorted binary file), but Microsoft, since the immunization uses their data structure.

[m00nbl00d]

A XML file? XML is a very slow thing actually, and I've never heard that IE supports XML files for these entries.

Please keep in mind, it's not us deciding on the data structure (we would've simply picked a pre-sorted binary file), but Microsoft, since the immunization uses their data structure.

I see. I don't know much about XML files, but, it was just an idea. But, it could be a text file or whatever.

The current solution places such entries at the registry, which bloats the registry. The more bloated the registry is, the slower system will become.

And, when I talked about XML, without knowing they're slow, I didn't say that IE supports it or that even Microsoft would have to do it.

In the way I see it, and correct me if I'm wrong, it has nothing to do with IE and Microsoft. It would be the way/the new way Spybot would block access the malicious domains, instead of placing such entries at the registry.

Spybot, instead of placing those entries at the registry - and I'm talking about the domains and not activex and cookies, of course - it would place them in a text file or any other faster solution.

[bitman]

m00nbl00d,

Unfortunately your responses are making the point that you don't really understand how any of this currently works. If you wish to understand what's really happening and how the existing Immunizations really work, you should start with the following 'Sticky' thread in the main Spybot S&D forum.

How Spybot-S&D protects against the installation of Spyware/Malware
http://forums.spybot.info/showthread.php?t=281


Patrick, if this doesn't make my point I don't know what will. Your product has drawn a much wider audience over the years than might have been expected for such a technical tool, but that has lead to exactly the paradox of needing to simplify its use. I know you are attempting to do this, but just like Microsoft attempting to better secure its OS this leads to much pain in the evolution.

I believe you are planning to make many of these changes in the 2.0 version, along with trying to resolve some of the resource issues that have plagued your more recent versions on older less capable hardware and OS. Keeping both types of users happy is quite difficult as OneCare proved to Microsoft. However, keeping the product lean and as simple as possible helps in either case, so at least you already have this going for you.

To me the key appears to be deciding the defaults for the non-technical users and then keeping the controls for the technical users available, but hidden from the non-technical so they don't become confused. You already appear to have begun this in recent 1.5 versions, though I'm not certain why you're placing the effort there, except maybe as a test bed for 2.0?

Resolving these interface issues while attempting to track the changing landscape of the Windows OS itself is quite enough. How much effort to place into the older OS versions simply confuses the matter more. If you wish to remain in business, my opinion would be to concentrate on the newer OS versions which are the future and only do what can be easily done in parallel to support the old.

Bitman

[m00nbl00d]

m00nbl00d,

Unfortunately your responses are making the point that you don't really understand how any of this currently works. If you wish to understand what's really happening and how the existing Immunizations really work, you should start with the following 'Sticky' thread in the main Spybot S&D forum.

How Spybot-S&D protects against the installation of Spyware/Malware
http://forums.spybot.info/showthread.php?t=281



I do understand how Spybot works.

Perhaps, I didn't explain my self the best way I could, and I don't know if know I will also.

Spybot protects by two ways:

- Passively, by placing entries in the restricted sites zone, blocking tracking cookies and activex.

All this immunizations end up in the Windows registry, which, the more it's added, the more bloated it becomes. The slower system will get.

- Actively, by TeaTimer.

Now, my suggestion, considering that the in-the-cloud service would require a lot effort, would be to make use of a new way to block access to malicious domains.
One way, would be for example to place such entries in a .txt, .lst, or whatever file.

I'm not saying that this would done to block cookies and activex. That wouldn't work. But, it is possible to do this to block access to malicious domains.

What I am saying is that, instead of loading the malicious domains to the Restricted Sites Zone, to load them to a file, be it a .txt, .lst or any other.

And, before someone mentions the HOSTS file. That's not what I am talking about here.

The HOSTS file allows to add entries like this

www. baddomain. com
ismy. baddomain. com

But, it doesn't allow to add entries like

*. baddomain. com

Which would block access to any domains within the domain .baddomain .com

Or even, allow it to be blocked like *.baddomain.*

[bitman]

I do understand how Spybot works.

Perhaps, I didn't explain my self the best way I could, and I don't know if know I will also.

Spybot protects by two ways:

- Passively, by placing entries in the restricted sites zone, blocking tracking cookies and activex.

All this immunizations end up in the Windows registry, which, the more it's added, the more bloated it becomes. The slower system will get.

< SNIP >

Hmm, now that I go back and read your last two posts again I can't see what made me think you didn't understand this. Maybe it was the 'passive' which I really never have agreed with or more likely the idea that registry 'bloat' is the core of the issue.

In reality Immunization has never been 'passive' it's just that the 'active' code required wasn't part of Spybot S&D itself, but rather code within Internet Explorer that handled the Restricted sites list. However, the Sticky I referenced does make that claim, so you come by this honestly.

As for registry 'bloat', it isn't the size of the registry itself that matters it's merely the number of entries being seached through. I know you probably see these as the same, but there is a difference. At its core however, the real problem was a design change by the Microsoft IE development team to handle a seperate issue that created this side effect as my earlier post detailed.

I also understand that you are just throwing out ideas for a way to replace this functionality within Spybot S&D itself, but that's not really necessary. If you'll look closely at the last sentance of PepiMK's last post you'll see that he's already indicated what he'd have done instead.


Please keep in mind, it's not us deciding on the data structure (we would've simply picked a pre-sorted binary file), but Microsoft, since the immunization uses their data structure.

Text or other human readable format files are really unnecessary for use within Spybot S&D and are simply slower for the machine to parse, so this makes sense. However, this would require conversion as entries are added in the current Restricted sites list in Internet Explorer, so it's not surprising that a simple text format was used by Microsoft, especially since this feature was added in much earlier versions of the IE browser and designed for manual (human) entry.

The real issue isn't how the list is stored anyway, it's how to replace the functionality that existed within Internet Explorer to actually process this information. Since IE would actually check the list itsself, that made this an easy thing to do by simply providing the list. However, if that's not available then something similar to the exisiting SDHelper.dll would need to be created to take its place, if that's even possible.

I really just think that the Immunize feature should either be supressed or at least the list reduced to complement the protection that SmartFilter now provides when IE 8 is installed. If many of the sites that are now Immunized are already flagged by SmartFilter, it's really not necessary to duplicate them in the Immunization. However, this feature may still be useful for those with earlier versions of IE installed, whether that's due to an older operating system or simply not having upgraded to IE 8 yet.

Bitman

[MSUStevo]

I'd like to thank the various contributors to this thread for doing such a nice job of explaining what's going on between IE8 and Spybot. Having read the 4 pages of posts I'm coming away with the impression that the new SmartScreen filter in IE8 essentially does away with the need to manually immunize via Spybot/SpywareBlaster as it accomplishes the same ultimate goal in a more efficient fashion

With this as a given, I'm assuming IE8 users should:

* Go to immunize and Undo
* Uncheck most of the boxes
* Which begs begs the question of which boxes should we leave checked?

Firefox
Opera
Chrome
Safari
IE 32 bit
IE 32/64 bit
Windows

I only use Firefox and IE personally, but thought I should mention the other popular browsers for the benefit of those whose read this later

For the moment I've undone all the immunizations in Spybot and SpywareBlaster. IE8 has gone from taking a good minute to open to opening in a few seconds

Stevo

[vodanh]

First i'd like to mention that no other browser has this issue on my computer : Firefox, Chrome, IE7, So i feel IE8 needs to fix this if they want to attract more users.

"For example, SmartScreen Filter uses a list which is hosted by Microsoft, to which any IE 8 user can contribute and which is thus much more quickly responsive than a local list downloaded weekly."

Explain to me how having to fetch a list from MS is more efficient than a local list (minus the fetching) unless the data is stored in and processed in a more efficient way. MS has never been faster or safer at protecting individuals than people who find the exploits and report them and often provided a fix before hand and reporting them as a courtesy for MS to fix it in a more maintream method.

---
I have found a fix, and to make sure I found the same link to it from a more mainstream site that is more trustworthy, from the days when I downloaded HOSTS files instead of just using S&D's.

http://www.mvps.org/winhelp2002/restricted.htm

Mainly the link for : http://www.mvps.org/winhelp2002/DelDomains.inf

It will quickly delete all the restricted zones I suppose. I am assuming that this fix will make IE8 more responsive, while still using the HOSTS as one of the layers of protection, I am really hesitant about just disabling immunization as I assume this also removes the HOSTS entries.

Spybot + any AV + safe usage has proven to be the safest method for me and I would prefer the fix not to be 'not immunizing", as I said before, none of the other browsers are affected IE8 should fix this.

I do agree with the discussion above that just a list that continously grows is not effective when it gets too big, maybe more wild card usage, or removal of dead hosts if this isn't already checked i assume it is, or just a better way to list the data and fetch/process it.

But right now, it has been EXTREMELY effective for me, this IE8 bug is just really really really annoying. was working fine in IE7, make it work in IE8, by theory yes its a bad idea, however, it shouldn't have crossed the critical line in this short period of time from perfectly fine i IE7 to completely broken in IE8.

[Rosenfeld]

Yodah,
You can selectively disable individual immunizations in Spybot, just undo all, then uncheck the boxes that you don't want, check the ones you do, then click immunize. So you can, for example, just do the hosts entry (at the bottom of the list) to keep Spybot's HOSTS entries.

[bitman]

< SNIP >

"For example, SmartScreen Filter uses a list which is hosted by Microsoft, to which any IE 8 user can contribute and which is thus much more quickly responsive than a local list downloaded weekly."

Explain to me how having to fetch a list from MS is more efficient than a local list (minus the fetching) unless the data is stored in and processed in a more efficient way. MS has never been faster or safer at protecting individuals than people who find the exploits and report them and often provided a fix before hand and reporting them as a courtesy for MS to fix it in a more maintream method.

---
< SNIP >

But right now, it has been EXTREMELY effective for me, this IE8 bug is just really really really annoying. was working fine in IE7, make it work in IE8, by theory yes its a bad idea, however, it shouldn't have crossed the critical line in this short period of time from perfectly fine i IE7 to completely broken in IE8.

There are several reasons an Internet accessed list can be more effective, assuming the system providing the responses to queries has enough bandwidth available to support the requests.

First, changes to the status of a site become available as soon as they are added to the Internet attached system, rather than waiting up to a week after they are detected with Spybot S&D's weekly updates. Second, downloading and searching a list of thousands of web sites locally is inherently inefficient, since it's unilikely anyone will ever access more than a handful of these sites in the lifetime of their PC, let alone a short time period. Third, the filtering can be done with much more granularity, down to a specific page or even file, which also implies the potential for hundreds of thousands to millions of entries in the database which obviously can't be supported locally on each PC.

Also, since the previous design that SmartScreen Filter is based upon itself used a smaller cached list of commonly accessed 'bad' sites, I'd assume it does the same. Since this list was downloaded only when it changed, which may have been weekly to monthly, it only contained a small number of well known bad sites that didn't change very often, which is what PepiMK stated they generally use Immunize for anyway.

So in general, SmartScreen Filter has all of the positives of Immunization and more with virtually none of the negatives. I personally make my security choices based on logical examination of the abilities, not historical determinations of what has worked in the past. This is important since significant changes in the design of either the OS or something like Internet Explorer can have major effects on the ability or even need for some of the older security programs to provide protection. Ignoring these changes simply leaves the protection in an out of date status and may actually reduce the true security overall, exactly the point everyone else believes they're trying to make here.

Bitman

[m00nbl00d]

Is this the fix Microsoft found out, and promised to look at?

http://support.microsoft.com/kb/969938/en-us

If I well understand it, they say to contact the software vendor (Safer Networking) to solve this issue.

I hope I am not misinterpreting it.

[ky331]

No, that Microsoft article is discussing how to find a conflicting ADD-ON... the SpyBot issue is not with an add-on, but rather, with the restricted sites zone.

in fact, that article contains the explicit NOTE:
If you currently have Spybot installed with the immunization feature enabled, you will need to disable that feature until that issue is resolved.

[2harts4ever]

Hi,

Just updating my files.

Does anyone know if this immunization problem between Spybot and IE8 has ever been solved?

Thanks and regards,

2harts4ever

[Rosenfeld]

I think so. I have no slow down with IE 8 with many sites in the restricted zone put there by Soybot and/or Spywareblaster.

[2harts4ever]

Hi Rosenfeld,

I appreciate the update. I guess I will go ahead and immunize all the Internet Explorer settings in Spybot and see what happens.

Thanks for the quick response.

Regards,

2harts4ever

[Gopher John]

http://www.safer-networking.org/en/news/2009-03-25.html

[2harts4ever]

Gopher John,

Yep ... I have that IE8 update and everything (speed) seems to be much better this time around.

Thanks and regards,

2harts4ever

[BillGio]

There are no Spybot immunization problems. Only bad Spybot immunization techniques.

It seems to me that anyone that is having problems with Spybot and IE8 is most probably NOT following a "best practices" attitude. And I've looked at the Microsoft links some of you novices have provided and none of them blame Spybot.

In order to properly update and immunize with Spybot, this is the ONLY procedure to follow:



Computer is turned off
Fresh boot into an Administrator account
All Browsers are CLOSED and have NEVER been opened for the session
Open and update Spybot
Immunize
Close Spybot
Shutdown and relogin to your normal user account.
(if your normal user account is an Administrator account, then you deserve a messed-up computer)

BTW, this is the same procedure to perform when installing Windows Updates.

Also, if you have any application that is running slowly (Teatimer?) and that application uses a large, and constantly updated, file (Windows HOSTS file updated via immunization?) then remember to defrag your hard drive at least once a month.

BTW, Teatimer may appear to take `100% of your CPU but it really isn't - if Spybot is properly installed and updated, Teatimer runs at IDLE priority so don't worry about it.

Don't blame Microsoft or Safer Networking for your poor computer maintenance skills.

[2harts4ever]

BillGio,


Don't blame Microsoft or Safer Networking for your poor computer maintenance skills.

Wow! You have such a way with words! :rolleyes:

I can't thank you enough for coming down off your 'lofty perch' long enough to help a mere mortal such as myself.

It has always amazed me how some folks seem to forget what it was like when they first entered the world of 'cyper space'.

By the sounds of your response that is exactly how I have you pegged!

Have a great day!

[BillGio]

BillGio,

Wow! You have such a way with words! :rolleyes:
Thank You!


I can't thank you enough for coming down off your 'lofty perch' long enough to help a mere mortal such as myself.

It has always amazed me how some folks seem to forget what it was like when they first entered the world of 'cyper space'.

By the sounds of your response that is exactly how I have you pegged!

Have a great day!
I graciously accept your praise.:thanks: