In a postMessage scenario, today (without wasm), the receiver can be given a string that it then evals. An attacking sender sends malicious JS. The defense mechanism is the receiver identifying the origin of that message, and only after that eval-ing. 

In the wasm world, the recipient receives a Module object. This in itself does not mean any code of that Module was executed - the receiver has to first create an Instance. The receiver can still check the origin of the message before going these steps. So far, it all looks like the case before. However, the difference is that executable code has been laid out in memory, by the messaging pipeline, before the recipient had a chance to vet the origin of the message. So there is a period of time when, even with a judicious recipient, an attacker could have executable code injected this way, acting like landing pad for a subsequent attack. This time period starts with the message being received and ends with the GC collecting the code.

This is no better if we automatically compile the bytes upon receipt (this is the fallback mechanism of deserialization, if the serialized bytes don't work - e.g. cross VM versions), because malicious code may still be thus laid out in memory.

The key is giving the receiver the chance to vet the origin, and only then create executable code. This means we can keep our current APIs, but delay populating executable pages until Instantiate, if the Module came through serialization.