Okay. But XSS is class of bugs that has nothing to do with code delivery, and that is quite possible to mitigate. So overall, the problem of code delivery is still addressed to a notable (if not complete) extent with the use of downloadable signed browser apps.
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.