Huh? Maybe I misunderstand what you're going on about, but if you can XSS in javascript, you can certainly change the meaning of even signed code - just hijack Object.prototype.constructor or similar.
That may very well be the case, but isn't this a solvable problem? Just like apps made in C need to be protected against buffer overflows, apps made in JS need to be protected against XSS. Both are reasonable threats that can be mitigated.
> Yes, but just because it can be mitigated doesn't mean that it is mitigated.
Sure, but I just want to point to the fact that this is a solvable problem. A lot of people talk as if it is some sort of insurmountable obstacle, whereas I think responsible programmers can solve it and move on.
You're arguing for a theoretical world, we're arguing from a practical one. I've spent enough time down in the trenches finding attacks in extremely well-reviewed code, that adding a massive new attack surface is not a thrilling proposition.
I'm a really optimistic type, really. Optimistic to the annoyance of some people. But in the case of security and cryptology there does not exist a choice between optimism and pessimism, but a choice between sharp eyed paranoia and wilful ignorance.
A defence is always only as strong as the weakest link, and an attacker usually has all the time in the world to find and exploit it.
