Security is about the person using the browser, not the browser itself, nor the
page that the browser is displaying. /They/ aren't going to loose money, get
infected, be advertised at unwantedly, whatever... The person is -- or may be.
If the whole settup (Java/Flash/JavaScript/HTML/etc) is such that an actual
user is mislead, then that is security failure, and then it's just a matter of
finger-pointing as to which part of the system takes how much blame.
I prefer to draw a distinction between "attacks" that rely on confusing
the user to direct them to a fake site (I'll call this phishing for lack
of a better name) and attacks that actively harm you (more traditional
security exploits). To some degree, phishing attacks are unavoidable due
to stupid users, and you can make a case that many would be better
handled not by informing the user of the malicious page switch
beforehand but rather by indicating that the target of the link is not
what the link claimed it was. Although success in the latter arena isn't
great, either.
I expect I'll be able to make the same claim about HTNL5 soon, if I can't
already.
One point of pedantry I want to bring up: JavaScript the language is not
the same as the set of JavaScript libraries used in web programming
(often known as DOM). The set of new additions to this repertoire over
the past several years has fallen under the terminology of "HTML5"
(although I know many web engine developers who dislike that term).
HTML has problems. JavaScript makes it easier to exploit those problems, and
adds new ones of its own. Java, FLash, and any other pluggin can be expected
to add yet more problems -- it's inherent in the nature of a plugin (by which I
mean exernal compiled code) that it may open too many doors (NACL aside,
perhaps).
The source of vulnerabilities is often in libraries, not languages; most
of the security problems in Java that I can think up are not in the core
VM but rather in the expansive set of libraries that make up the
standard library. Similarly, JS's core language isn't the source of most
problems but rather the DOM. In a similar vein, Flash and NaCl have
problems simply because they allow access to rather less well-secured
libraries.
The only way you could get rid of these vulnerabilities would be to
freeze the allowed access and the implementation except for bug and
security fixes and then wait for 20 years (think TeX). And that's not
going to happen.