Doug Crockford on HTML and Fixing the Web

1. Doug, you’ve been working a lot with HTML5 recently and the specification of HTML5. What are your thoughts on that process so far?

I have some reservations about HTML5. It contains a lot of new features, some of which are badly needed, some of them are well thought out, much of it is not well thought out, much of it is too big. It’s a rambling specification, but my biggest concern is that it does not attempt to correct the most serious security deficiencies that we’ve had in the browser. It not only fails to correct that problem, it makes it significantly worse. It makes it worse in three ways: first, the problem I’m talking about is the misnamed cross-site scripting problem, which allows third party script if it can get on to a page.

And it’s much too easy for it to get on to the page, to get full control of all of the resources of the page it has access to, including your link to the server, your presentation to the user and the ability to communicate with any server in the world, including the most dangerous and most evil server in the world. Nothing in the current browser architecture defends you against that. HTML5 makes it worse. The way it makes it worse is it enlarges the attack surface of the browser by adding a lot of complexity. There are now likely to be new opportunities for attackers to inject code into a page and have it get access to all this evilness.

Second, HTML5 brings in a lot of new capability which becomes available to the attacker, so there is now a local database. The attacker gets to read the local database, can steal data, can poison the database, can put material in there which will allow the page to continually re-infect itself. So there are lots of things available and HTML5 does absolutely nothing to defend you against that.

Then, third, HTML5 is huge and complicated and it’s going to take years to get it right and finished. While that is going on, that may prevent correction of this more serious problem. The cross-site scripting problem has been with us for 15 years now and it is serious and in my view, the HTML committee was negligent in not dealing with it.

2. What do you think is a good approach to deal with this issue? What would be your ideal solution?

We have experience now with securing applications and components within the browser. Google’s Caja project, for example, which is just being used on the Yahoo! front page today, my own ADsafe project, both demonstrate how we can apply capability reasoning to the problem of securing software within a browser. We now know what the cause of the cross-site scripting problem is and based on the experience that we’ve accumulated, we know how to fix it.

3. How does the current JavaScript Sandbox model contribute to this problem as it stands right now?

JavaScript, as it’s practiced in the browser, comes close to being a secure environment. In fact it is a better or more secure application delivery system than virtually everything else there. It’s certainly much more secure than the desktop. The thing that JavaScript got right or the browser got right and everybody else continues to get wrong is that it does not confuse the interests of the user with the interests of the program that the user is running. That’s why it’s safer to deliver an application as a web application than as a desktop application.

The thing that the browser got wrong or didn’t think through quite far enough is that there could be code representing multiple interests within the browser. Because it didn’t anticipate that. It assumes that all of that code represents the same interest and that’s where the cross-site scripting problem happens. Some of the work that we did with ECMAScript 5, particularly in the new Strict Mode that’s ECMA Script 5, allows us to constrain the capabilities that we give to a piece of code coming from a third party, so that code doesn’t instantly and automatically get access to all of the capabilities of the browser.

That’s why HTML5 Strict is such an important piece of technology going forward. It does not by itself solve the cross-site scripting problem because most of the problem is on the browser side of the DOM interface, not on the JavaScript side. Ultimately we need to fix the browser in order to fix it completely.

4. With the number of browsers that exist, both between a variety of desktop browsers and also a variety of mobile browsers, what’s the best way to start to get some of these fixes to all of those browsers? How can we ensure that they are compliant with this?

First, we have to get the standards right. The cross-site scripting problem is not due to browser bugs. It’s due to the specification of the web being wrong. If you were to implement a browser and if it did not subject your users to cross-site scripting attacks and all of the harm that can come with those attacks, then it is not standards compliant. So the first thing we have to do is fix the standard.

5. HTML5 is not yet completed, but there seem to be browsers implementing HTML5 functionality. What’s your thought about that?

There is a proposal and it is not complete. One problem with the way that HTML5 rolled out is that the browser makers got way ahead of the standard. In a way that’s good because it allows for testing of the standard before it gets finalized. The problem with that is in exposing all of those APIs to the web early, a number of developers have started implementing stuff, applications, sites using HTML5. It’s half-baked still. So W3C is no warning "Don’t use HTML5 yet. It’s there just for testing purposes." Because a lot of interoperability hasn’t been worked out yet, the proposals are going to have to change possibly in significant ways before they are finalized.

And if you are writing applications on it now, then they are going to fail when the proposals are corrected. The danger is that if enough developers get in front of this thing then we will not be able to correct the specifications because we don’t want to cause mass breakage. If that’s the case, then things are going to be like they were back in the Netscape era, except even more so, in which inter-browser compatibility is severely broken. The group that is going to suffer the most for that would be the web developers.

6. You mentioned there were some parts at the HTML5 standard which were very good and some parts which were not quite as good. Which parts do you think are the strong parts of HTML5?

What I like about HTML5? I like the Canvas; I think the Canvas is great. The DOM model is so bankrupt that being able to say "Let’s start over and scratch it all the way down to pixels and start building applications there" is really attractive to a lot of developers. It’s a shame that that’s how it is going to be used, but at least we have that option now; we didn’t have that option before. Ultimately I think that’s a bad approach for us to be taking and I think we should make the APIs that the browser provides us actually work correctly.

We are going to lose a lot in re-implementing the DOM in Canvas at the application level. It would be nice if we done that in HTML5. That’s probably my biggest objection to HTML5. The DOM has always been misfeatured and at the wrong level of abstraction, and much too difficult to use and not composable and not modular. There are a lot of things wrong with it and they just left it as it is. My biggest objection with HTML5 overall is that it wasn’t focused, it wasn’t disciplined, it didn’t start with looking at what are our most significant problems.

They started, I think, with "What would be most fun to have?" and did it that way. So: undisciplined, unprofessional, but it looks like we’re going to be stuck with it.

7. The model that you’re describing for HTML5 with the capabilities sounds very much like ACLs on Unix.

It’s nothing like ACLs. It’s possible to transform ACLs into capabilities and back and forth, but they are really different concepts: one is permissive, one is restrictive. Capabilities I think are going to be a much more effective model for web applications.

8. When do you expect the HTML standard to finally be ratified and to become an official standard that browsers can implement?

They are already implementing it. The browser makers are likely to be finished with it before it goes through the formal process. If they had done that as experimentation, that would have been a good thing, but they are shipping the final product now of something which is half-baked and that’s unfortunate.

9. One of the big issues which I recall from the 90’s and into 2000 was the incompatibilities between multiple browsers. For instance, any time you say Internet Explorer 6 a collective shudder falls over the audience. Do you see something similar happening with HTML5 given that so many browsers are already implementing portions of it before the standard is complete?

That’s the danger. It’s difficult to predict what the future holds, but based on past experience it doesn’t look good.

10. What is your favorite language and what is your second favorite language? I’m going to assume the answer to the first one is JavaScript, but I’m willing to be surprised.

I will be surprised and tell you that’s JavaScript. I’ve not always liked or enjoyed this language, but over the years I’ve come to have more and more respect for it, particularly when I determined that there was an elegant subset of the language. Learning to think in that subset I think has made me a better programmer and I enjoy working in that language. So, as a result of that, JavaScript has become my favorite language.

I think my second favorite language would be E. E is a capability scripting language, which was developed at company of mine which is actually informing a lot of the work that’s happening in Caja and ADsafe. It’s actually a very good language; it’s unlikely to ever see mainstream adoption, but there is brilliance in it.

11. With ECMAScript 5 strict mode are there any concerns with the current or future browsers with the ability to utilize or implement that?

It appears that the browsers are all on track to implement all of ECMA Script 5, especially the Strict Mode which is the most important new feature in ECMAScript 5. We’ve already seen Firefox is making good progress on it, Apple Safari is doing some good work as well, they’ve already starting doing some testing and it’s looking very good. In Microsoft’s IE 9 previews they have most of ECMAScript 5, but they have not shown us Strict Mode yet and they have not said whether or not they intend to support Strict Mode and that would be a problem. The ECMA Script standard does not have any provision for subsetting.

So Microsoft has a choice of either being standards compliant or not, and so far they have not said in public that they intend to be standards compliant. If they are, then everything is going to be great. Microsoft has done some really good work on IE 9, it’s very impressive. People don’t remember this, particularly web developers, but there was a time when Microsoft made the best web browser in the world. IE 6 was by far the best and continued to be the best browser in the world for many years after, but the other browser makers have all gotten ahead of them. And there is a chance that with IE 9 Microsoft might get that back.

IE 9 is that good, except that it might not have Strict Mode in it. So depending on whether they do the complete language or not, JavaScript is the ultimate workaround tool. Whatever they get wrong in the DOM, whatever they get wrong in HTML, we fix it in ECMAScript. As long as ECMAScript is there and complete and portable, we can manage whatever crap at us. But if the language is not complete, then life gets a lot harder for us. So depending on what Microsoft does with IE 9, it either possibly becomes the best web browser in the world, or it just becomes the next version of IE that we have to get rid of. I don’t know which way that’s going to go yet.

12. You have mentioned IE 6 and that brings to mind another question for web developers who are eyeing HTML5 and wondering about somebody’s capabilities, such as video tags and such. How can a web developer provide for browsers which implement HTML5 capabilities while still maintaining some compatibility with previous browsers? This is often referred to as the IE 6 problem. How do you address that as a web developer?

In the short term, life gets much worse for web developers. HTML5 will raise the bar on what’s expected of web applications, web developers will be expected to meet it and to make it work on IE 6, which is going to be either impossible or extremely difficult. There is no winning if you are a web developer. So life gets tough. Ultimately, the only solution is we have to kill IE 6. We have to make it go away and it’s hard. Microsoft hasn’t been able to do it. IE 7 and IE 8 were not sufficient to get rid of IE 6. There are a number of reasons for why it’s still hung on. It’s 10 years old, which is really old in the Internet time, but we have to get rid of it.

Ultimately I think it means that at some point in time we’re going to have to make a hard choice and say "No, we’re just not going to support it anymore." Waiting for it to decay sufficiently and go away on its own has not worked. In 2000 we had a similar pain point with Netscape 4. Netscape 4 was a crime against humanity. It was so bad that it made IE 6 look like the best web browser in the world. It took about five years for it to fade away. Because it took five years to go away, that’s why the Ajax revolution happened in 2005 and not in 2000. Because Ajax wasn’t a viable application delivery system as long as it was also necessary to also support Netscape 4.

In 2005 I predicted that it would probably take a similar five years for IE 6 to go away. We’re now five years later and IE 6 is still stronger than Opera, Safari and Chrome together. So it’s not going away, it’s hanging on and we’re going to have to explicitly kill it. In the way we have to kill it, the only tool available to us is to stop supporting it. So we’ll have to convince our companies and our clients that they do not want IE 6 support anymore. That’s going to be hard. Again, that pain is going to fall on developers, but ultimately that is the only way forward.

13. How do libraries such as jQuery, such as YUI, help a web developer to achieve compatibility across for IDE browsers?

The Ajax libraries have been wonderful. The DOM is this awful crippled, terrible, painful, hateful UI that we have to use, but JavaScript is such an amazingly powerful expressive language that a small amount of JavaScript on top of that worst API turns it into something that’s productive and pleasant. So JQuery, YUI, Dojo, lots of others (there are hundreds of them now) are all great and all very effective. Ultimately, they shouldn’t exist, that we should take the goodness that’s in those things and push them down into that substructure so that’s just the way the browser works. Unfortunately that’s not the way the web standards are going.

14. In the Java world there was Java EE and that was progressing as it was progressing and there were things which were later described as anti-patterns, such as EJBs. What ended up changing the landscape there was that you had external innovators, such as Spring who were innovating outside of the standard and just doing things the right way. And that eventually fed back into Java EE and a lot of the features of Spring for instance are now part of Java EE 6. Do you see a similar process happening with the HTML5?

Sadly no. For the last five years the innovation in browser technology shifted from the browser makers to the web developers. So the Ajax libraries have been doing amazing things very quickly, very smartly improving the environment just by writing JavaScript well. Unfortunately that did not get fed back into HTML5. HTML5 instead was the browser makers trying to become relevant again - so, adding things that you couldn’t do in JavaScript. In a sense, that’s a good thing because it extends our capabilities generally and that’s great, but their lack of focus on what web developers actually do, I think is going to be hurtful in the long run.

15. With HTML5 video one of the concerns has been around the codec. For instance Firefox would only implement Ogg Theora because that is an unencumbered format and Apple has implemented H.264, even though there is still some question of patent litigation around that. What are your thoughts on that? How can HTML5 video be implemented in the consistent way across all browsers? What’s the solution?

I side with Mozilla on this one. I think web standards should be completely open and the issue here is really a DRM issue. There are some parties that have an interest in Digital Rights Management meaning that they can control what you can see and when you can see and what you can do with what you’ve seen. Ultimately I think DRM regimes fail. We’ve seen it happen over and over again, but there are content owners who have not given up yet and that is I think what’s behind this controversy about codecs. I don’t think it’s really about codecs, I think it’s about trying to close what has up till this point been an open standard. I’m hoping that the web stays open.

16. How does Google’s WebM fit into this?

I think that’s great. Having additional open codecs available to us I think is good and it certainly weakens the patent argument. It doesn’t eliminate it because with patents it’s impossible to know if any invention infringes or not, which is a huge problem with patents as they are currently practiced and maybe another reason for why we need to get rid of them - at least with respect to software systems. But I applaud Google for opening that codec. I think it’s great and I would like to see everybody get on it.

17. Thank you very much.

Thank you.