"There is much that is attractive about HTML5," says Douglas Crockford, known to millions of developers as the discoverer of JSON (JavaScript Object Notation), the widely used lightweight data-interchange format.

"But ultimately," Crockford continues, "the thing that made the browser into a credible application delivery system was JavaScript, the ultimate workaround tool." The problem is that there is what he calls "a painful gap" in the specification of the interface between JavaScript and the browser. The result? XSS and other maladies. The responsible course of action, Crockford contends, is to correct that defect first before pushing ahead with HTML5.



In an email exchange with Jeremy Geelan, here is what Crockford (pictured above) says, in his own words...

"The most serious defect in web browsers is the incorrectly named Cross Site Scripting (XSS) vulnerability. XSS enables an attacker to inject code into a web page that runs with the authority of the site that issued the page. The rights granted to the attacker include the right to interact with the server, the right to scrape data from the page, the right to modify the page, the right to dialog with the user, the right to load additional scripts from any server in the world, and the right to transmit the data it obtained from the server, the page, and the user to any server in the world. This is dangerous stuff.

XSS is misnamed for two reasons. First, it is not necessary for a second site to be involved. Sites that can reflect user generated content can be attacked without the participation of a second site. But more importantly, XSS suggests that cross site scripting is a bad thing. In fact, cross site scripting is a highly beneficial thing. It is what enables mashups. Cross site scripting enables Ajax libraries, analytics, and advertising. The problem is that the browser's security model did not anticipate mashups.

The XSS problem comes from two fundamental problems. The first is that the language of the web is unnecessarily complicated. HTML can be embedded in HTTP, and HTML can have embedded in it URLs, CSS, and JavaScript. JavaScript can be embedded in URLs and CSS. Each of these languages has different encoding, escapement, and commenting conventions. Statically determining that a piece of text will not become malicious when inserted into an HTML document is surprisingly difficult. There is a huge and growing set of techniques by which an attacker can disguise a payload that can avoid detection. New techniques are discovered all the time, and usually the attackers find them first. The web was not designed as a system. Instead it was a sloppy cobbling, and that sloppiness aids the enemy.

The second problem is that all scripts on a page run with the same authority. The browser has a better security model than desktop systems because it can distinguish between the interests of the user and the interests of the program (or website). But the browser failed to anticipate that there could be other scripts that represent additional interests. As a result, the browser is confused, treating all scripts as equally trusted to represent a site, even when it has loaded scripts from different sites.

This problem first appeared 15 years ago in Netscape Navigator 2. Those developers could be forgiven for having not foreseen the way that browsers would ultimately be used. But to have this problem incorporated into web standards and left in place for 15 years is intolerable. This problem must be fixed.

The HTML5 proposal does not attempt to correct the XSS problem and actually makes it worse in three ways:

1. HTML5 is huge and bloated. It is likely that this bloat will create new opportunities for malicious script injection.

2. HTML5 adds powerful new capabilities (such as local database and cross-site networking) that become fully available to the attacker.

3. HTML5 is a large effort. The solution of the XSS problem may have to wait until HTML5 is completed, which could be years away.

The fundamental mistake in HTML5 was one of prioritization. It should have tackled the browser's most important problem first. Once the platform was secured, then shiny new features could be carefully added.

There is much that is attractive about HTML5. But ultimately the thing that made the browser into a credible application delivery system was JavaScript, the ultimate workaround tool. There is a painful gap in the specification of the interface between JavaScript and the browser, and that is a source of XSS and other maladies. The responsible course of action was to correct that defect first.

That course is still available to us. My recommendation is that we suspend the current HTML5 activity. We start over with a new charter: To quickly and effectively repair the XSS vulnerability. Then we can mine the bloated HTML5 set for features that have high value and which do not introduce new security vulnerabilities.

HTML5 has a lot of momentum and appears to be doomed to succeed. I think the wiser course is to get it right first. We have learned the hard way that once an error gets into a web standard, it is really hard to get it out.

What do you think? Add your feedback below.

• Yahoo! Architect Douglas Crockford Proposes "A Kinder, Gentler HTML 5"
• HTML5: Media in a Flash...Without Flash!