what is "automatic cleanup of temp folder"?

temp == Temp Internet Files folder?

“cleanup”, as in, a privacy-oriented operation ~~ clearing cache+cookies+history?

With this enabled, after rebooting I checked the TempIntFiles folder and discovered that BOClean had not purged the “orphaned files” (leftover from crashed IE sessions)… nor had it removed the dangblasted ever-growing 1.8Mb index.dat file.

I’m also unsure what “automatic reset of security zones” does.
Resets all settings for the various zones to their Windows default values {gasp} ?

How about “automatic cleanup of hosts file”?
BOClean takes a startup snapshot (copy) of the HOSTS file… and overwrites the file back to that state if an app edits HOSTS???

Is there any benefit/drawback if “unattended cleanup and removal” is unchecked?

Thanks, in advance, for any pre-RTFM clarification you care to offer.

Since this was released without documentation, you’ll find that our documentation on the Privacy Software Corp site will be an almost acceptable substitute since not much in BOClean has changed from 4.22 to the new 4.23 version aside from the graphics … dunno when the COMODO pages will appear …

Great! Thanks for the link!

The download for the top-secret only-for-forum-members version
includes a shortcut which launches
http://www.comodo.com/boclean/supboc.html (404 not found)

Until the Comodo-branded docs are available…
it would be helpful if the shrocut pointed to the page linked in your reply above.

TYVM for the link…that gave me all the info I needed, it certainly answered all my questions :■■■■

"Automatic reset of security zones." A large amount of malware will change your security settings to allow future installation of malware by setting numerous sites and programs as "trusted." If this box is checked and malware is found, BOClean will automatically reset "security zones" to their default state thus setting ALL sites to "internet zone" in order to prevent reinfection. If this box is not checked, no action will be taken but any changes to your security zone settings will remain as they were, even if infected. We recommend checking this box for your safety.

Okay, I can understand the rationale for preemptively resetting (clearing) the list of “TrustedSites”,
but will the IE “list of of Restricted Sites” be reset also?

"[b]Automatic cleanup of HOSTS file[/b]." By default this is also checked because once again, the majority of malware will write to the HOSTS file to block access to antivirus and antimalware updates and this file is also commonly used to redirect you from sites you intend to visit to rogue sites instead. Some people and some programs make use of the HOSTS file to block other sites however it is not possible to programmatically determine which sites are safe and which aren't and therefore in the event of malware detected by BOClean, [b]we want to reset the HOSTS file to the Microsoft default of EMPTY in order to prevent reinfection[/b].

Um, no… we don’t want an ‘empty’ hosts file, so please consider my reply here as a suggestion - slash - feature request.

If the app provided a textbox (File|Browse) enabling input of the user’s “backup” copy of the HOSTS file, and the app effected a “reset” by overwriting the HOSTS file with the content from the backup file, that would be swell. Alternately, at least preserve the “possibly tainted” HOSTS file for manual inspection, by copying it to an incrementally-named file like HOSTS_BOClean_renamed(1).txt

ALL sites settings are dumped if the checkbox is left checked. And the HOSTS file is indeed set back to precisely the same as HOSTS.SAM … this has always been the preferred settings for corporate sites which is what BOClean was designed for. It’ll likely change in the future, but that’s the way it’s built now. Reason why we give you the options and the explanation is so that you can set it the way you want it to be.

And HOSTS files really don’t help much … if the link to malware is a hard IP address, whatever you do with a HOSTS file won’t make a difference because it won’t be read anyway. I’ve not considered HOSTS files to be much of a solution myself for quite a few years, same with that restricted or trusted. If you make someone avoid a DNS lookup by giving them (intentionally bogus IP here, don’t try clicking) …


… all of that does nothing. But feel free to uncheck those if you’d like - that’s why there’s checkboxes. :slight_smile:

The sixth checkbox is marked "[b]Automatic cleanup of winsock connectivity[/b]." This item is [b]turned on by default[/b] as well. However, this checkbox controls a number of additional cleanups which reflect the latest tendencies to corrupt the winsock "Layered Service Provider" (or "LSP") stack as well as the winsock itself. When certain malware inserts itself into the winsock stack and is subsequently removed, you lose all internet connectivity as a result of the "missing piece." Leaving this checkbox checked will cause BOClean to examine the "winsock stack" and repair the sequence to prevent loss of connectivity. We strongly advise leaving this box checked.

If unchecked, then any trojan which affects any of these items would require manual repair. We explain this in detail because any “network connectivity” issues have been a major portion of support requirement for us as a result of some nasties out there, and a major focus of BOClean 4.12 and later was a means of automating this most difficult cleanup since it seems no two internet providers setup the winsock the same way twice. As a result, when network connectivity was lost due to a trojan, we had to refer the victim to their ISP to help them remove and then reinstall “networking.” In addition, any DNS-tampering trojans will have any changes to “NameServer” and other connectivity issues automatically resoved when this item is checked.

It has come to our attention that a small number of people have configured their home machines to a hard-configured “DNS setting IP address.” From a security standapoint, this is not a good idea as those manual DNS settings are used extensively in malware to redirect victims to places other than where they had intended to surf. It’s ALWAYS best to leave your networking configured for DHCP or “get address automatically.” Despite this being a really bad idea to manually enter this data, some people insist upon doing so. If YOU are in this situation, we strongly advise going to automatic network configuration using DHCP. If you still choose not to, it is IMPORTANT that the “Automatic cleanup of winsock connectivity” box NOT be checked or BOClean will remove those settings when a trojan is found.

It’s ALWAYS best to leave your networking configured for DHCP or “get address automatically.”
I respectfully, yet vehemently, disagree with this “advice”.

So, as is, BOClean doesn’t protect AND support fixed-IP users from LSP stack infection.
Hella lot more than a small number of people are going to be using the free Comodo BOCLean, eh?

You could at least accomodate such users by enabling them to export a “last known good” *.reg file via the BOClean config interface, in advance, containing the regkeys which will be preemptively “wiped” during an incident.

Objections all noted for a future build. But just for argument’s sake … we save all that data and malware modifies it anyway. The whole point to the design was to restore a machine to the state it was in when the system was loaded, without having to format and reload it. And the design compromise was to make all of that optional by means of a checkbox for each capability so that if it conflicted with one’s desires, simply unheck and monitor it all yourself.

This is the way it was originally built. Now that it’s in COMODO’s hands, we’ll all discuss this once 4.23 is out. It’s been held up by this and that long enough I would guess … and it won’t be all that long before there’s another new version. But we’re not forcing anything on anyone … if the designed options, clearly explained, are unsatisfactory BOClean can be told not to do any of them. For now.

Observations, ermm suggestions… no objections, really. My feedback above wasn’t intended to nitpick; I think this is a great, well-thought-out app. The issues I raised were the few which I felt might dampen the enthusiasm of, and adoption by prospective users.

In general, I do agree with the inadvisability of “relying” on a HOSTS file.
Considering that Comodo BOClean is now in the realm of the “home user”, here’s a f’rinstance:

Specific to the app’s effect on the HOST file, the status quo doesn’t provide a “set and forget” solution, enabling me to install it on the kids PCs and trust that they’ll remain “protected”. AT A MINIMUM, I would need the hostfile to contain local proxy directives, ala: localhost Proximitron filtered.by.edexter

…so that we can “continue on our merry way” following a BOClean-mediated incident.

Thanks for listening.

And certainly no implications from my end that you’re “whining” or anything … I’m just used to the reality that for every move you make to stop them, the bad guys parry and lunge in response. If you back up a HOSTS file for “autorestore” then they’ll go after that. And knowing what should and shouldn’t be in a HOSTS file is anybody’s guess, same for zones. Therefore the only logical solution was to restore the system to a known state. Basically what I’m saying is that if the regular files are targetted, I’d expect any backups to be corrupted too since I’m placing my bet that a good number of people who’ve already downloaded the new BOClean did so in order to find ways around it. That’s the never-ending “spy vs spy” game out there. :frowning:

I’ve also been loathe to add things to BOClean because for every thing we add, it gets a little slower, a little pudgier, and suddenly we’ve got a 30 meg gila monster on our hands. So that’s also been part of the philosophy. That’s why we resorted to making those functions very optional. Just so you have an idea where I’m coming from. Once 4.23 is done and out and we see what people bump their heads against, 4.24 or whatever development will begin thereafter … and I’m definitely thinking about the ideas you’ve thrown out, as will others … but I’m merely trying to explain the processes behind the decisions already made as to why we did things the way we did.

It’s refreshing to hear a developer expressing an aversion to bloatware. However, throughout the app’s development interations, you should expect to incur a hellacious unnecessary support overhead, along with negative “word of mouth” resulting in lost market share, until these usability issues are addressed. Providing external documentation, regardless how detailed, clearly isn’t enough:

https://forums.comodo.com/index.php/topic,8208.0.html After installing BOClean last night, wish went smootly btw, this morning after turning on the pc, this happened :

Winsock damaged. Why? (The only thing I did was testing BOClean with leaktest from grc.com)
Hosts file deleted. Why ? (This was a host file, with entry’s made by my self)
And every item in C:\Windows\Downloaded Program Files, damaged. Why ?


the faint of heart should really think at least twice before installing this software, i´m sure it will work well for most of you guys, but it´s obvious that under some circumstances it will crash, if not your operating system, at least some of your programs…This was NOT really pleasant at all…
not even a System Restore to a point before installing BOclean worked, still the same errors as described earlier. Now this is getting really really serious, i´ve been working like a one legged man in a ■■■■ kicking contest to get this newly installed Vista system up and running the way i like it and now it all seems ruined. I am not a man of harsh words, but let me put it like this, i am in a really bad mood at the moment. Translate that into a more harsh language and you will find out what i really think about BOclean
… the option in BOclean "“Automatic cleanup of winsock connectivity” together with autostarting programs that needs Internet connectivity totally f**ks up Winsock. Even after uninstalling BOclean the errors remains.

Rather than deferring a more complete “resolution” until a later version, you could expedite release of an interim build which at least presents a popup (confirm dialog) to the user, urging them to read the docs to be sure they understand the implications, when changes to the configuration checkboxes are made.

Borking users’ network configurations, in the name of “remediation”… Idunno how the app’s reputation has managed to dodge richochets from that bullet to date. As a purchased app, perhaps the userbase was a bit more discerning, or at least more motivated to carefully read the docs.

Another “issue” which begs immediate attention (and has, for more than a year, vis the linked forum discussion) is clarification regarding “What exactly is the full implication of a NO response?” when malware is detected (and while unattended removal is UNchecked).

Please don’t shoot the messenger, eh?


In a post earlier in this thread, I mentioned reading somewhere that clicking the “No” button when BOClean prompts to remove an offending file also functions as a temporary excluder that remains in effect until the machine is rebooted. I haven’t been informed otherwise. Neither have I been able to locate my source. It has been at least six months since I read it, so I decided to try it and find out what happens. I’m not a malware tester and have no interest in becoming one, but this seemed simple enough for even me to do. I used GRC’s firewall leak tester “leaktest.exe” as the test application.

The behavior is a little different from what I recalled reading. Answering “No” when BOClean prompts to remove the file does act as a temporary excluder, but, instead of remaining in effect until the next reboot, the time window is around 5 seconds from the time the rogue application was previously executed. After initially answering “No,” I was able to start “leaktest.exe” as many times as I wanted for as long as I wanted (several minutes) without as much as a peep from BOC, if I started it within the ~5 second time window from the previous startup. However, waiting until after the time window closed always brought an alert from BOC.

The behavior of the “No” button is disconcerting, IMO, and does not seem to be described in the documentation. This user does not intuitively equate leaving a file on the file system with opening a hole in a security application – a hole that is big enough to drive Schwarzenegger’s Humvee (and 39.exe, apparently) through.

If it isn’t possible to correct the “No” button’s behavior, the warning message should, in my view, be changed to fully inform the user that the file not only “can still be started up again” but also without an alert from BOClean. Answering “No” is definitely asking for trouble.