+++ This bug was initially created as a clone of Bug #531337 +++ I was just thinking that maybe we shouldn't blocklist this yet. It isn't difficult for the developer to realize that his malware isn't running any longer, and when he does investigate he'll see that we simply match the name of the dll. From there it wouldn't be tough to make the dll always have a random name and totally bypass our protection. I don't really have a better solution in mind, but I'm just curious if we really want to start flexing this muscle already.

If we can fix our #9 topcrasher, why not do it? We're not doing this because it's malware, we're doing it because it's hurting our users.

I've said it a couple times before and I'll say it again - the DLL blocklist (like the plugin blocklist!) is not an anti-malware system. It is a name+version pairing, and is hopeless at blocking malware. So, bent, I agree fully that things should not be added to the DLL blocklist because they are malware - that way lies a long and useless list. I think Benjamin is right, though - we should block things, malware or otherwise - that cause a lot of crashes for our users. That *is* the purpose of the blocklist. I'd like to make suitably sure over in bug 531337 that hook.dll actually is malware before we block it, but I don't have any problem blocking DLLs which happen to be malware, if it reduces crashes. Incidentally, what was the thinking behind making this a separate bug? I think your concerns and this discussion make sense over in bug 531337, don't they? I'm guessing the separate bug was so that you could mark this half sec-sensitive, so I appreciate the caution there. Nevertheless, I've let that cat out of the bag a couple times, that anyone dedicated to defeating the list would have no trouble doing so. So I think we can fold this discussion back into that one?

As I mentioned to vlad in a crash kill meeting a few weeks ago. I don't think we should kid ourselves, we have stepped over a line towards providing anti-virus like features. We have stepped over this line because we have seen increasing numbers of reports from users and in crash data that they are running into threats. To not act would be irresponsible. Microsoft failed to act quickly to shut off problems with ActiveX, and that openned the door for Firefox's success. This is important work to help us maintain a Firefox as a competitive browser as we become a "bigger target." That does not mean we are on a path to being an anti-virus company or need to enter the arms race with malware providers. We can, and should, develop boundaries for what we do with blocking to avoid entering the arms race. That is a good discussion to have. I think the general criteria looks something like mentioned in comment 1 and 2. When we have information before us that indicates that users are at risk or under attack, or inhibited from a good experience while using the web, and our blocking techniques can be used to improve that experience, then we should consider any side effects and take action. When I say "consider any side effects" I'm mostly talking about if the impact of disabling reduces any features expected by the user. In the specific issue raised in comment 0 about .dll wildcard naming; that is already happening and is a technique used by some malware. See https://bugzilla.mozilla.org/show_bug.cgi?id=516112 In that case we have drawn the line about it being out of scope for what we can reasonable block given the blocking tools we have now, and have tried to engage with anti-virus partners.

Ok, that's all great. I just wanted to make sure that this conversation had taken place. And yeah, I made it a separate bug just to keep the discussion off the radar.