Point / counterpoint. However, I still like the fact that Firefox+NoScript doesn't download "pages full of crap" *at all*. Give me Chrome+NoScript and I'd be one happy camper. :-)

I just checked Chrome out for the first time, and yes it does render pages quickly. But it's no faster (to my naked eye, at least) than Firefox with the NoScript extension running. And since Firefox+NoScript is also blocking scripts, Flash applets, etc. from running, it seems to me that it would be safer than Chrome anyway. YMMV, but I think I'll stick with my Firefox a bit longer.

Which just brings us right back to my second point - how do you *prove* it without access to the source?

Are we to believe then that, unlike every single piece of virus-scanning software ever, this binary scanning utility will never encounter a false positive? What happens when it shows some product as containing OSS, but it doesn't?

And with that in mind, even if you *do* identify a product as containing OSS, how do you prove it without access to the source code? The company could simply claim it was a false positive (regardless of whether or not that happened to be true), and you would be left with the burden of proving the tool wasn't flawed.

Of course, there are also the false negatives...

It's not completely gone - it's just been relocated here.

I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.

The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.

I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time...

As I understand it, any file in an NTFS partition can have one or more Alternate Data Streams associated with it, regardless of its type or location. So if you tell someone not to scan something like "Edb.log", does that imply that they should not scan "Edb.log:virus.exe" either?

I have to agree with Trend Micro on this one. Completely skipping specific files in specific directories may prevent performance issues, but it may also make it easier for malware authors to find new hiding places.

Following up on my own post, yes it is DansGuardian that can be configured to block Google searches if Google SafeSearch is turned off. So maybe Microsoft's filter is taking a similar approach? The obvious thing to try is to turn off the MS filter, check your Google preferences and make sure SafeSearch is enabled, then turn the filter back on and see if the problem persists.

I seem to recall a much older filtering software package (I don't recall which offhand - DansGuardian, maybe?) that will block Google if you have disabled "SafeSearch" in the Advanced Preferences - that is, if you have it set to "Do not filter my search results."

Who is "Deaf Leopard"? Are they bigger than Def Leppard?