At the last AMTSO workshop in Munich, a guidelines document on False Positive (FP) testing was approved, and is now available on the AMTSO documents page.

All this is potentially frightening and inconvenient (or worse) for a home user. And if it happens in a corporate environment, it can be very, very expensive to remedy. So while some of the public comments we see in the wake of such incidents may seem over the top, “FP rage” is certainly understandable.

ESET is not going to try to capitalize on McAfee's unfortunate false positive problem (and nor, I'm sure, is any other reputable vendor). Such problems can arise for any AV vendor: it's an inevitable risk when you're trying to walk the line between the best possible detection of threats and avoidance of false detections (someone please

Larry Seltzer posted an interesting item yesterday.  The article on "SW Tests Show Problems With AV Detections " is  based on an "Analyst's Diary" entry called "On the way to better testing." Kaspersky did something rather interesting, though a little suspect. They created 20 perfectly innocent executable files, then created fake detections for ten of them.

The anti-malware industry isn't a suitable environment for the thin-skinned. We get used to receiving "more kicks than ha'pence" (see http://www.virusbtn.com/spambulletin/archive/2006/11/vb200611-OK).. In particular, I've grown accustomed to the fact that many people expect all the following from an AV product: Absolute Protection Absolute Convenience Absolutely no  False Positives Absolutely no charge False positives (FPs) are

False positives. Every anti-malware vendor’s worst nightmare. The European publisher Heise, apparently recently reinvented as The H, has pointed out that both GData and Bitdefender were inaccurately flagging winlogon.exe as Trojan.Generic.1423603. In case you were wondering, this doesn’t mean the whole anti-malware industry has gone mad: GData’s product uses two engines, one of which is