(This is the first part in a series of articles that accompany my Security Summit presentation, HTML5 Unbound: A Security & Privacy Drama.)

The Meaning & Mythology of HTML5

HTML5 is the most comprehensive update in the last 12 years to a technology that’s basically twenty years old. It’s easy to understand the excitement over HTML5 by looking at the scope and breadth of the standard and its related APIs. It’s easy to understand the significance of HTML5 by looking at how many sites and browsers implement something that’s officially still in draft.

It’s also easy to misunderstand what HTML5 means for security. Is it really a whole new world of cross-site scripting? SQL injection in the browser? DoS attacks with Web Workers and WebSockets? Is there something inherent to its design that solves these problems. Or worse, does it introduce new ones?

We arrive at some answers by looking at the history of security design on the web. Other answers require reviewing what HTML5 actually encompasses and the threats we expect it to face. If we forget to consider how threats have evolved over the years, then we risk giving a thumbs up to a design that merely works against hackers’ rote attacks rather than their innovation.

First let’s touch on the meanings of HTML5. A simple definition is a web page with a <!doctype html> declaration. In practice, this means new elements for interacting with audio and video; elements for drawing, layout, and positioning content; as well as APIs that have have their own independent specifications. These APIs emerge from a nod towards real-world requirements of web applications: ways to relax the Same Origin Principle (without resorting to insecure programming hacks like JSONP), bidirectional messaging (without resorting to programming hacks like long-polling), increased data storage for key/value pairs (without resorting to programming hacks that use cookies or plugins). It also includes items like Web Workers to help developers efficiently work with the increasing amount of processing being pushed into the browser.

There’s a mythology building around HTML5 as well. Some of these are innocuous. The web continues to be an integral part of social interaction, business, and commerce because browsers are able to perform with desktop-like behaviors regardless of what your desktop is. So it’s easy to dismiss labels like “social” and “cloud” as imprecise, but mostly harmless. Some mythologies are clearly off mark, neither Flash nor Silverlight are HTML5, but their UI capabilities are easily mistaken for the type of dynamic interaction associated with HTML5 apps. In truth, HTML5 intends to replace the need for plugins altogether.

Then there are counter-productive mythologies that creep into HTML5 security discussions. The mechanics of CSRF and clickjacking are inherent to the design of HTML and HTTP. In 1998, according to Netcraft, there were barely two million sites on the web; today Netcraft counts close to 700 million. It took years for vulns like CSRF and clickjacking to be recognized, described, and popularized in order to appreciate their dangers. Hacking a few hundred million users with CSRF has vastly different rewards than a few hundred thousand, and consequently more appeal. If CSRF is to be conflated with HTML5, it’s because the spec acknowledges security concerns more explicitly that its ancestors ever did. HTML5 mentions security over eighty times in its current draft. HTML4 barely broke a dozen. Privacy? It showed up once in the HTML4 spec. (HTML5 gives privacy a little more attention.) We’ll address that failing in a bit.

So, our stage is set. Our players are design and implementation. Our conflict, security and privacy.