Putting the HTML5 genie back in the bottle in the name of web security?
There's a lot of wisdom in what Crockford continues to say about HTML5 and web security:
The HTML5 proposal does not attempt to correct the XSS problem and actually makes it worse... 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.
It makes a lot of sense in theory, but I doubted the practicality of it ina Dec 2008 item:
after wrestling with the patchwork of javascript security policies in browsers in the past few weeks, the capability approach in adsafe looks simple and elegant by comparison. Is there any chance we can move the state-of-the-art that far? ... it seems an impossibly high bar to reach, given the worse-is-better tendency in software deployment...
He acknowledges the difficulty, to some extent:
HTML5 has a lot of momentum and appears to be doomed to succeed.
Chuckle.
He goes on to recommend to suspend the current HTML5 activity now:
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.
Would that standards had so much impact. It's true that once a W3C Working Group is in motion, it's difficult for the organization to decide to stop it. But that's really only tangentially related to the heart of the problem: shipping code. Much of the web development community and many of the users have their fingers on the shiny new features; who's going to go first in taking them away?