I don't know what threat model you're using, but this claim just seems like a strange non-sequitur. The client executes the source code, and the client obviously trusts itself...

I'll put Sundialsvcs aside for now:

Those people won't notice, because they're only interested in reading the books on their tablets.

That, and if the producers of the e-books are still around then they will have the option of using the DRM module mentioned above though they may have some coding to do to display their books. Again though, that's their fault for relying upon a technology designed to make funny animations and games for something else.

Indeed and, nowadays, the move seems to be for the client to have the ability to execute in a sandbox to prevent other applications interfering and vice-versa.

It isn't meant as a non-sequitir, but as a statement of a basic ruling assumption: that the client environment should be presumed to be compromised at all times. And, the problem with JavaScript is that you can inject a "compromise" into the environment ... dynamically ... which can fundamentally alter the behavior of the code that you have so-carefully tested.

It is impossible(!) to certify that JavaScript code will, on the client's machine, actually do what the author intended and nothing more.

Whereas, you can do that with Flash and with Silverlight. You can furnish object-code to the client, digitally signed, and this object code's behavior will not be vulnerable to tampering or functional alteration by anything unknown-to-you in the client's environment.

But if "HTML5+JS" becomes the norm, and the Flash plug-in is discredited and finally driven off the field, Google Corporation through its unknown-to-you modified Chrome browser will be able to surreptitiously collect ... and sell ... even more information about you than they already do.

And whom do you trust to verify this digital signature? The client?

Can you give us an example of a case where that would be a problem? And in that case, who is it a problem for?

And let's not get too ahead of ourselves, but: how universal is that case?

In a typical client-server architecture, the server is specifically designed to not care what the client does with its responses.

This being my thought process. If I'm the one using the client device and I don't trust my device not to inject code or spy then I can't use that device no matter how trutworthy the application is.

Unless it's code that I want to inject.

I think I mentioned that that's how ad blockers work?

sorry, yes, I was being simplistic. Perhaps I should have typed "... not to inject code I do not approve of...". Apologies, my excus is I am on my Android device without a full-sized keyboard and mouse device.

Adobe says that now, but things can change within those next three years. I'll believe it when I see it.

Do Adobe still sell any products relating to Flash? I tried to check their website for products but their website it, predictably, not working properly in my browser...
If they do sell products related to Flash then the sign that they're serious will be when they stop selling them.

I think that e-v-e-r-y-t-h-i-n-g will "suddenly change" when a few legal cases are finally handed down. You cannot "secure" a JavaScript program, because you can fundamentally alter every aspect of its behavior, without altering it(!), by hooking into its prototype-based class structure.

There will be an enormous demand for an open source, compiled system which can produce encrypted, digitally-signed executables, which will be the only thing that the operating system will permit to run. (Apple's OS/X, nee MacOS, already has this capability turned-on by default.) The "loosey-goosey" days of the Internet will be forever gone.

Be advised: it is easy to foresee this turn of events, and to see that it is not a long time in coming! It will affect your fairly-immediate future (career). (And, if you are not a native-born citizen of the country in which you are now working, possibly-ugly side effects could occur which affect you further. History has some pretty-grim stories to tell.)

You've asserted this multiple times, but never explained how the fact that I can alter a program which I run can possibly compromise "security". Therefore, I have to say this is total BS.

Didn't someone already point out that "this is how ad-blockers work?" The entire behavior of JavaScript is based on a prototype-based system of inheritance which in fact completely defines how every object within the system actually behaves. By altering these data structures, you can alter the behavior of any object and/or introduce new behaviors which the existing programming knows not of – and, cannot prevent.

JavaScript's power derives from the fact that it is a totally dynamic language, with run-time binding of everything. However, this means that there is no (true) compile-time, and no compile-time binding. I really don't feel the need to fully develop the case that it has significant architectural vulnerabilities – and is understood to be so – because so much discussion has been written about it already. Please "trust, but verify" me, however, that what I am saying is certainly not "total BS."

JavaScript would not be the language that it is, however, if it did not have these characteristics. Everything has its price.