I realize why this seems like a good solution at first glance, but it's actually very impractical. First off, much of the detection you want to do is computationally expensive and just can't be bundled into a standalone application shipped to end users. Consider simulated/sandboxed execution, which is great for identifying malicious code but typically requires a whole supporting environment to work.
Second, even when you can push some subset of detection to the client, the fact is that doing so undermines its own effectiveness. Malicious code detection is an arms race, and once the bad guy knows exactly how your detection works he'll alter his signature accordingly. So, by keeping the detection private you force the bad guy to come to you if he wants to test it. And he needs to keep resubmitting his code until it passes, which is in-and-of-itself a useful collection of data for malicious extension detection.
Finally, malicious code detection is often a rapid-response situation. You're constantly getting more data, and evolving and experimenting with different methods. So, you don't want to be bound to a multi-week release cycle, or risk destabilizing Chrome by forcing more frequent releases.
Second, even when you can push some subset of detection to the client, the fact is that doing so undermines its own effectiveness. Malicious code detection is an arms race, and once the bad guy knows exactly how your detection works he'll alter his signature accordingly. So, by keeping the detection private you force the bad guy to come to you if he wants to test it. And he needs to keep resubmitting his code until it passes, which is in-and-of-itself a useful collection of data for malicious extension detection.
Finally, malicious code detection is often a rapid-response situation. You're constantly getting more data, and evolving and experimenting with different methods. So, you don't want to be bound to a multi-week release cycle, or risk destabilizing Chrome by forcing more frequent releases.