On a compromised client's computer, the attacker only has to wait for the user to start any transaction. The attack consists in replacing the transaction (generated client-side) into one that sends all funds to the attacker. User doesn't know this, she enters 2FA and encryption key believing everything's ok.
Right, then I'll create the transaction server-side so the user validates it before entering the 2FA and/or her encryption key!
No, because then the attacker will target the server and present a bogus transaction to the user, who will happily agree with it without knowing that it's fake and provide the key.
Only the scenario where both the server and the user are compromised does the attack succeed. This is why mbelshe is proposing the P2SH approach, because two signatures are needed, and they must of course be signing the exact same transaction.
dserrano is right - there are some types of attacks you can't catch. He suggests a real-time attack, where you wait for the user to transact, and then change the contents of the transaction (depending on the API this could be a client-side or server-side attack). For example, you may be able to change the destination address without the user noticing. Of course, all wallets, even local ones, are susceptible to this attack today. But with the client/server hybrid, the server can act as your co-signer and make sure it at least fits the right parameters. In the future, I believe you could use this same mechanism to send to a human co-signer (like a business partner) for a human verification.
But, I think the P2SH address, used either web-based or locally is fundamentally stronger than a single-key address.
Mike