You simply can't verify native x86 code - there's way too many tricky things that can be done. Somebody might come up with a partial solution that works "pretty OK for standard code", but malware authors aren't going to stick to "standard code". Trying to verify x86 code is a waste of time.
The only thing you can really do about native code is requiring the modules to be digitally signed, and then hope users have enough sense to not run code that's been signed by SneakySoftware Inc. And hope that signing authorities won't let anybody register "Mircosoft", "Goggle", etc.
Once the native code runs, you can try to sandbox it... but you'll ultimately fail. There's so many sneaky things x86 code can do, and so many holes you have to be aware of. AFAIK IE8 already has some sandboxing mode available... running in a thread with reduced privileges will get you a long way, but native code will be able to exploit browser bugs and the like, since native code can use pointers and (attempt to) write to arbitrary memory locations.
I really don't see wtf google is trying to achieve, they should stick with ActiveX (which fulfills native code needs) and JAVA (which is safer). The only way to get native code to run safely would be running it in a virtual machine... and virtual machines like vmware have had "escape outside the box" exploits. Even if you do a full emulation (without the run-certain-stuff-natively like vmware and friends do), you'd need some communication channels between the emulated code and the host, which might be open to exploitation. And the benefit of native code is speed, which would be killed by emulation.
Just focus on speeding up your javascript engine and memory allocators, dammit! (Oh, and beat SUN engineers with a big clue stick until they reach the JVM performance that Microsoft's JVM had).
