Spyware Blaster Database Update | July 1 2011

[siljaline]

14443 Total Items in database | 29 New IE CLSID's
No New IE Restricted Sites | None for Moz.

Silj


--
"Arguing with anonymous strangers on the Internet is a sucker's game
because they almost always turn out to be -- or to be indistinguishable from
-- self-righteous sixteen-year-olds possessing infinite amounts of free time."
- Neil Stephenson, _Cryptonomicon_

[JD]

siljaline wrote:
> 14443 Total Items in database | 29 New IE CLSID's
> No New IE Restricted Sites | None for Moz.
>
> Silj
>
>

Thanks Silj..

--
JD..

[siljaline]

JD wrote:
> Thanks Silj..

You're most welcome.

Silj


--
"Arguing with anonymous strangers on the Internet is a sucker's game
because they almost always turn out to be -- or to be indistinguishable from
-- self-righteous sixteen-year-olds possessing infinite amounts of free time."
- Neil Stephenson, _Cryptonomicon_

[VanguardLH]

siljaline wrote:

> 14443 Total Items in database | 29 New IE CLSID's
> No New IE Restricted Sites | None for Moz.

Something I've noticed about SpywareBlaster regarding the registry
entries for ActiveX classids (to add a disable for them) and for
Restricted Sites is that an update could end up leaving orphaned entries
in those registry locations.

The SpywareBlaster list could and has in the past removed some entries
from their lists. If you apply AX, Cookies, or Restricted Sites
protection, update SpywareBlaster, and apply the new updates, you may
find some remnants entries if you try to disable SpywareBlaster's
protection. That is, when you disable its AX, Cookies, and Restricted
Sites protection, you may still find some entries listed for these items
in the registry. Their protection doesn't remove items that were
removed from their lists. It only *adds* the lists to the registry keys
(and only removes that *same* list when you disable protection in
SpywareBlaster). If an entry was in one update and you applied it, that
entry is in the registry. A subsequent update might remove an entry but
that won't remove it from the registry. Because the entry is no longer
in the updated list, disabling protection won't remove the orphaned
entry because it wasn't in the latest updated version of the list.

So to ensure that I don't end up with remnants in the registry for
entries that have been removed from SpywareBlaster, I do the following:

- Disable all protection in SpywareBlaster (ActiveX, Cookies, Restricted
Sites). That removes the registry entries for the current lists.
- Do the update to SpywareBlaster.
- Enable all protection. Entries for the new list are added to the
registry.

If you don't do this for each update, and if you decide to later disable
all protection by SpywareBlaster (which you should also do before you
choose to uninstall it), you could end up with remnants in the registry
entries that you'll have to manually eradicate.

I understand why SpywareBlaster doesn't remove entries that are not in
its current list (which would be the current list after an update).
Entries might be manually added by the user to enlarge the list or added
by other security/privacy products. So SpywareBlaster won't step on
those other entries. However, this also means that an updated list
where entries were removed won't affect that same entry that was present
in an earlier version of the lists (that were left behind rather than
cleaned out before doing an update).

Although this was lengthy mostly to explain the cause of the orphaned
entries after updates and an uninstall/disable, the process is really
simple: disable, update, reenable.

[JD]

VanguardLH wrote:
> siljaline wrote:
>
>> 14443 Total Items in database | 29 New IE CLSID's
>> No New IE Restricted Sites | None for Moz.
>
> Something I've noticed about SpywareBlaster regarding the registry
> entries for ActiveX classids (to add a disable for them) and for
> Restricted Sites is that an update could end up leaving orphaned entries
> in those registry locations.
>
> The SpywareBlaster list could and has in the past removed some entries
> from their lists. If you apply AX, Cookies, or Restricted Sites
> protection, update SpywareBlaster, and apply the new updates, you may
> find some remnants entries if you try to disable SpywareBlaster's
> protection. That is, when you disable its AX, Cookies, and Restricted
> Sites protection, you may still find some entries listed for these items
> in the registry. Their protection doesn't remove items that were
> removed from their lists. It only *adds* the lists to the registry keys
> (and only removes that *same* list when you disable protection in
> SpywareBlaster). If an entry was in one update and you applied it, that
> entry is in the registry. A subsequent update might remove an entry but
> that won't remove it from the registry. Because the entry is no longer
> in the updated list, disabling protection won't remove the orphaned
> entry because it wasn't in the latest updated version of the list.
>
> So to ensure that I don't end up with remnants in the registry for
> entries that have been removed from SpywareBlaster, I do the following:
>
> - Disable all protection in SpywareBlaster (ActiveX, Cookies, Restricted
> Sites). That removes the registry entries for the current lists.
> - Do the update to SpywareBlaster.
> - Enable all protection. Entries for the new list are added to the
> registry.
>
> If you don't do this for each update, and if you decide to later disable
> all protection by SpywareBlaster (which you should also do before you
> choose to uninstall it), you could end up with remnants in the registry
> entries that you'll have to manually eradicate.
>
> I understand why SpywareBlaster doesn't remove entries that are not in
> its current list (which would be the current list after an update).
> Entries might be manually added by the user to enlarge the list or added
> by other security/privacy products. So SpywareBlaster won't step on
> those other entries. However, this also means that an updated list
> where entries were removed won't affect that same entry that was present
> in an earlier version of the lists (that were left behind rather than
> cleaned out before doing an update).
>
> Although this was lengthy mostly to explain the cause of the orphaned
> entries after updates and an uninstall/disable, the process is really
> simple: disable, update, reenable.

Thanks. I'll give that a try next update. If I remember. 8-)

--
JD..