In Defense of HTML5
thesecuritypractice.com
thesecuritypractice.com
However I used to run IE6 + Flash on WinXP without any anti-virus and never remember any significant problems with malware on my computer (witnessed a lot on other people's though).
A. The two groups are in reality about as disjoint as any sets of CSS functionality implementers could be.
B. The premise of WebGL is that it implements a security boundary. ActiveX did not.
http://msdn.microsoft.com/en-us/subscriptions/ms531079(v=vs....
Back then everything needed to tie into Win32 somehow, so of course they introduced Binary Behaviors:
http://msdn.microsoft.com/en-us/library/aa753685(v=vs.85).as...
"A Binary Element Behavior (or binary behavior) is a Component Object Model (COM) object loaded by a Web page and assigned to an element type in the page—either a custom element tag or an existing HTML tag. The COM object is then able to customize the behavior of the tag by implementing the IElementBehavior interface. Customizations include any options available to scripted behaviors and more advanced behaviors such as Windows Graphics Device Interface (GDI) rendering.
Because a binary behavior is a COM object, a binary behavior can execute any code after loading. For that reason, the security profile of a binary behavior is very similar to that of a Microsoft ActiveX control, and the same security considerations apply. Binary behaviors, like ActiveX controls, run with the security credentials of the user running the browser process. This means a binary behavior cannot only render to the screen, it can also potentially access local files, configuration settings, or network resources. Accessing a page that loads a malicious binary behavior presents a considerable security risk."
Java was designed from the ground up to be secure. It had a ponderous standards process (though not quite as slow as the W3C) and got new features years after other languages, but the result was a rock-solid environment. You still occasionally see flaws that let things escape the sandbox, but only very rarely. And while java-the-language gets larger, the JVM itself is simple and well-specified; the attack surface is the eye of a well-defined needle that you have to thread to go from the managed JVM into the OS outside.
Flash didn't have the benefit of so much design and specification, but the sheer pressure of attacks forced adobe to reach something close to Java's level of security. It's certainly possible to form a clear separation between the "VM" and "sandboxed" areas of Flash. Not to mention that you had the option, as many "advanced" computer users did, of disabling flash except for some whitelisted sites - at which point you could be sure, since it was a separate process, that no flash code could possibly be used to attack your system.
Maybe IE itself was a badly-written program and is now a better one - we'll have to take the author's word for that - but that's an argument for Microsoft writing better code, not for HTML5.
Retrofitting security onto an existing codebase is basically impossible. So no, I really would sooner trust HTML4+Java+Flash - where the active behaviours are fully decoupled from the browser, and Java at least has a well-designed sandbox that was there from the start - over HTML5, where you have this enormous monolithic codebase dating from 1993 and full of all kinds of behaviours.
I guess the main lessons here are 1) you need your web platforms in another sandbox for defense in depth, and 2) you won't get there without obsessive attention to security, proactive fuzzing, and luck.