00:22:22 video length
Strange Loop is a developer-run software conference. Innovation, creativity, and the future happen in the magical nexus "between" established areas. Strange Loop eagerly promotes a mix of languages and technologies in this nexus, bringing together the worlds of bleeding edge technology, enterprise systems, and academic research. Of particular interest are new directions in data storage, alternative languages, concurrent and distributed systems, front-end web, semantic web, and mobile apps.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
So unless XP dies, IE6 wont die, and its easy to predict IE6's approx lifetime based on the estimated lifetime XP still has.