Excluded Cookies in Settings being wiped

[gdhopcroft]

I've spent a bit of time hunting through the Spybot-S&D forum looking for whether this is a reported Known Problem, as I was pretty sure it would have been.

Unfortunately, using Search, I haven't been able to find the exact problem, although I went close, in two instances. I mention that because I just may have an answer to the one of those which is still current for you, as well as to my own issue.

My issue? Cookies.sbe (in C:\Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Excludes), where the Cookies I wish to retain in Usage Tracks cleaning are stored, is being creamed each time I access it through a different WinXP login.

I know why that is occurring, I think, and imagine that it grew out of earlier versions of Windows rarely being used as multi-user systems, like NT allowed, in fact, sort of forced. On a single-User system, this little glitch doesn't matter a jot, and many, if not most, Win9x-based systems were run that way.

Cookies, being user-based and pretty dynamic, means that Spybot-S&D has to go read C:\Documents and Settings\%username%\Cookies each time you go into Settings > Exclude Cookies, not just read the data out of Cookies.sbe. I guess, at that time, Spybot-S&D is doing a Merge of the data in Cookies.sbe with what it pulls out of the Cookies folder.

This gives a list of both the ones previously selected, and all the new ones, not yet checked. But where I suspect it goes wrong is that it seems to be dropping anything from the Cookies.sbe file that ISN'T for the CURRENT Windows User, hence the "creaming" action I'm seeing, if that list, for multiple Windows Users, is being maintained as a regular occurrence, once the data the User has been working on is written back out to Cookies.sbe.

The easy solution, of course, is that Cookies.sbe needs to be stored within each individual User profile (in a new folder, C:\Documents and Settings\%username%\Application Data\Spybot - Search & Destroy\Excludes, I expect), rather than at the All Users level, or the (just slightly) more tricky programming exercise of storing the selected Cookies for all Windows Users in the one Cookies.sbe file, which the program has now, could be implemented.

Whichever, Spybot-S&D needs to recognise the User basis of the Cookies, and that each Windows User is likely to have completely different lists of Cookies, to fix my issue, on a system with six different Users, the bulk of whom have the responsibility of keeping the system clear of infestations while it is under their control.

I can work around the problem, until it can be fixed, by taking Spybot-S&D off the other Users, but that won't work forever, as they'll then buck-pass the responsibility (of keeping the system pristine) for all time. So, it'd be great to see it fixed. Oh, by the way, I believe it could basically be a problem in any Windows installation on which multiple users are active, even poor old Win9x.

Oh, yeah, I mentioned two instances, within the Spybot-S&D forum, that I thought might relate to my issue.

The first, Updates deselect selected Cookies, seemed related but, I'm prepared to admit, probably isn't, as on my system, it has nothing to do with either Updates or Fast User Switching. In truth, I really do think that the issue in that Thread is caused by what I'm reporting but, hey, let's not go there, as the solution given at the time worked for that User.

I can reproduce my issue, without going anywhere near the Search for Updates button and, on this system, we are using Win2K-mode sign-ins, with FUS turned off. Two of the Users are me (Owner-Admin and myself in a more limited mode), but the others are separate individuals, so it's not really appropriate to do much FUSsing ... so we don't do any.

Hence my decision to leave that Thread, and what it had to say, pretty much alone.

The second, where I think it might help solve another reported issue, is one involving Spybot-S&D not recognizing Disabled Startup Items in alternate XP accounts, which I reckon could well be another User-based problem.

Let me see if I can clarify my thinking on this one, as it is only a similar principle involved, I think ...

These Startup Items, near as I can make out, appear to also be stored at the All Users level. On inspection, it seems to be in C:\Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Snapshots, if I'm not mistaken, as I cannot seem to find anywhere else it might be, unless of course you've squirreled it all away in the Registry?

Wherever, the principle is, most likely, the same, if the same type of process is carried out each time a User wishes to maintain such a user-based list.

Startup Items are w-a-a-a-y more complex, of course, as there's multiple places they can be stored, both at the All Users and the individual Users levels. But I'm guessing you see what the implication is that I mean.

If you have to recreate the lists, each time a different User maintains them, and you haven't stored away all the other Windows Users' ones, the end effect is that they have been "creamed" and are no longer recognized, as the program "bit bucketed" them.

Sorry this has been so long and convoluted, but I was sort of hoping it may help make Spybot-S&D an even finer application, and I wanted to try to explain what I thought was happening in each instance. Hope it all helps anyway.

If you want anything further from me on this, just ask; I can work it up for you.

[bitman]

Though I'm not privy to specifics, my understanding is that the Spybot S&D 1.5 version is being extensively re-written, both to allow better operation on Vista and within Limited User accounts on Windows XP, which are similar issues.

Though I haven't heard the specifics, it seems to me that issues like this one would be obvious within that context, though we'll have to wait for a beta to see for sure.

At this point, they're first planning to release an updated version of TeaTimer Resident (real-time) protection, possibly by next week. This has been in Beta for weeks now and can be accessed by selecting the Beta option in the Web Updates section of the Advanced Settings menu.

For more on these Beta versions, see the 'sticky' posts in the Spybot-S&D Beta forum above.

Bitman

[gdhopcroft]

Well, yeah, I guess that's a distinct possibility, that v1.5 might address it.

However, it's also my guess that the concept and the code that makes up this particular portion Spybot-S&D pretty much hasn't changed through any of v1.2, v 1.3 or v1.4, so I wasn't going to just count on that happening this time either.

I will admit, as bugs go, this is just a little one and only causes inconvenience, rather than any real problem. Still, minor ones can contribute to major ones, in other contexts, so I'd believe it to be worth fixing.

As such, it was also worth documenting the nature of the problem, seeing as I think it is symbolic of an area, multiple Windows User accounts, that needs some major rework.

It's also good to hear that the next stage of the v1.5 rework is almost ready to reach beta stage, and I'm sure we're all looking forward to it's availablilty.

I do note, though, that an updated version of TeaTimer doesn't have a whole lot of relevance to a fix for this Topic.

[bitman]

All of your points were the reason for my response, since it's obvious (to you and I) that multi-user needed work.

I also wanted you aware of the pending Beta, so you can hopefully help with the testing, since you understand these issues better than most.

I only mentioned TeaTimer due to the fact that it appears this version will be released in a piecemeal fashion, which may be confusing.

I'm not sure if the core scanning module will be released next or not. My understanding is that it will be stripped of some of the Advanced Mode tools and the Integrated Update facility will be placed in its own separate module too. This is happening both to simplify the scanner and improve security, since only the updater will need Internet access.

The Advanced Tools are moving to RunAlyzer from what I've heard, since these are really for technically knowledgeable types anyways. This will also reduce the scanner's overhead, likely helping in low memory situations and on older processor/OS combinations.

As I mentioned above, most of this is also required for the new Vista security requirements such as User Access Control, and old issues such as the Immunization of multiple accounts including XP Limited access have also been mentioned. So I wouldn't be surprised if the multi-user cookie issues were also addressed, but it's definitely something that should be tested.

Don't wait and assume others will test this, since that's how such things have been missed before. Few bother with Restricted or Limited Account access on XP, so being involved in the beta is the only way to insure that there won't be another couple years with this bug. It's better to get it right during the beta than to document it later.

Bitman

[gdhopcroft]

All of your points were the reason for my response, since it's obvious (to you and I) that multi-user needed work.

I also wanted you aware of the pending Beta, so you can hopefully help with the testing, since you understand these issues better than most.

Thanks for being so detailed in your response; it is really appreciated, even if I had not seemed quite so appreciative.

Sorry, that's a bit of a function of the number of hours in my day I expect but, I know, we all do have those.

I only mentioned TeaTimer due to the fact that it appears this version will be released in a piecemeal fashion, which may be confusing.

I do understand that, believe me, but I'm sure that's most likely because the Development Team wants to minimise the time taken to get all of the Upgrades out to us Users in the field.

Once again, I appreciate the effort.

I'm not sure if the core scanning module will be released next or not. My understanding is that it will be stripped of some of the Advanced Mode tools and the Integrated Update facility will be placed in its own separate module too. This is happening both to simplify the scanner and improve security, since only the updater will need Internet access.

The Advanced Tools are moving to RunAlyzer from what I've heard, since these are really for technically knowledgeable types anyways. This will also reduce the scanner's overhead, likely helping in low memory situations and on older processor/OS combinations.

As I mentioned above, most of this is also required for the new Vista security requirements such as User Access Control, and old issues such as the Immunization of multiple accounts including XP Limited access have also been mentioned. So I wouldn't be surprised if the multi-user cookie issues were also addressed, but it's definitely something that should be tested.

Once again, thanks for the most detailed reply and explanation of what is occurring with the product.

All of those things sound like logical design moves to me and will, once all done, make Spybot-S&D an even better product, especially at it's most reasonable price!!!

And, yes, having read all that, I can see why you are sure that my issue, along with all other multi-user aspects, are likely to be addressed in full.

Don't wait and assume others will test this, since that's how such things have been missed before. Few bother with Restricted or Limited Account access on XP, so being involved in the beta is the only way to insure that there won't be another couple years with this bug. It's better to get it right during the beta than to document it later.

Of course, what you say there is absolutely correct and I cannot disagree in any way.

Right now, though, I have ZoneAlarm Pro, WindowsDefender and WinPatrol (yep, all three of them) telling me everything that TeaTimer would tell me, so I've actually got TeaTimer not running on this system, even though it is installed.

However, if I can be of assistance in the beta testing of the new modules and it won't be incompatible with how I have my system configured, please feel free to press-gang me into service.