« Certificate Authorities asked to step up for Internet security; CABF takes a step back instead. | Main | Enterprise Networks Need to Prepare for the Security Impact of New TLDs »

November 30, 2012

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e5502ec8d98834017ee5c7f4dd970d

Listed below are links to weblogs that reference In Defense of HTML5:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Steffen Ullrich

HTML5 security still depends on a security aware developer instead of being secure by default:
- strict Content-Security-Policy is not enabled by default, if it is implemented at all
- sandboxes for iframes need to be explicitly specified
- cross-origin-requests still include cookies and authorization data, and there is no way to restrict this behavior
- ...

IMHO the framework should be secure by default and disabling any security should be painful.
Browsers should just break with applications, which do not implement a tight security model.
Otherwise most will not take the additional costs and time to implement secure solutions.

jameswilddev

Almost as bad however is that attack surface is moving to drivers. As someone who has worked with graphics APIs and has accidentally caused severe performance degradation or worse brought down the OS by doing something fairly innocent, I keep WebGL firmly shut off and advise anybody else do the same.

I'm not fond of these audio APIs that expose recording and the ability to send arbitrary audio buffers to sound cards either. VIA's audio drivers fall over on a weekly basis on x64 without really doing anything, and you want one millimeter of this attack surface exposed to the internet!?

Christian Sciberras

To break down this huge wall of text:

HTML 5 is a security nightmare because:
- A LOT of experimental APIs suddenly springing up (with a lot of classical bugs, eg, use-after-free, stack/buffer runs etc)
- A lot more features, vastly increasing the attack surface.
- Adding to my earlier point more features mean new classes of vulnerabilities suddenly springing up - with possible catastrophic effects.

Brad, I've long advised several people, including ones in W3C that the whole concept of testing experiments in the wild is plain wrong. While there have been a LOT of fixes in the last few years, browsers are very much still open to problems, just as they did back in '02, except in a different manner.

Jeff Walden

Sure, HTML5 isn't perfect. There's some legacy compatibility considerations that mean you can't quite have fully-secured-by-default, because you break *too much* stuff. (Browsers breaking sites using long-stable stuff usually isn't an option. New stuff that's being tested as it's being standardized, sure, but not old stuff, except at the far margins. Breaking long-stable sites just isn't going to happen, when the user who encounters a broken site will just switch browsers. Or, just as bad, downgrade to a less-secure, older browser, or not upgrade from it.)

But in the long run those best practices can become second nature. And even opt-in security, when implemented by the top sites (as it will be, as it becomes best practice), secures an awful lot of stuff for an awful lot of people.

Regarding "And it didn’t take any regulatory or agency incentives – it began with self-motivated business decisions", definitely. But it also began at least partly with actions and decisions of a different nature from Mozilla (disclosure: to which I have long contributed) -- not just "self-motivated business decisions", exactly, because we take more into account than the well-being of our own business. And that's good -- variety in motivation provides value just like variety in implementation does.

And (of course :-) ) I also think you don't do us justice by not naming Mozilla as a notable contributor to this sea change, in our rise to prominence and in playing a pretty key role in getting the standards process working again and actively competing against plugins. The standards ship was well on its way when Google jumped into the browser fray and when Apple omitted plugins from iOS. Reenergizing the standards process was a multilateral affair including contributions from Apple and Google and Microsoft, certainly. But I think we at Mozilla deserve at least equal mention with the principals you've called out by name here.

Anyway, an excellent post, notwithstanding those minor quibbles.

MSDN Searcher

After a quick search I found this on MSDN:
Internet Explorer Binary Behaviors Security Setting

Applies To: Windows Server 2003 with SP1

http://technet.microsoft.com/en-us/library/cc776248%28v=ws.10%29.aspx

0xdabbad00

Great article! Flash, Silverlight, Java, Adobe Reader, and any other browser plug-ins are dying. The only plug-ins left in browsers will be javascript based (Adblock, Ghostery) that don't abuse the security model. This is good. Reduce the attack surface. However, there is a danger that HTML5 is built in functionality. With the recent Java issues, most people could just disable Java. How can you disable HTML5 if it has issues?

The only need for Java and Silverlight is the desire to keep a single language when coding (code the server in Java, so you might as well code the client in Java), but the world is rapidly becoming language agnostic due to cross-compilers (seems like almost every language today can be converted to javascript).

The comments to this entry are closed.