Is Chrome 4 the next IE 6?

“HTML5” is huge. Different specifications are at different status: First Public Working Draft, Working Draft, Candidate Recommendation, Proposed Recommendation, and lastly Recommendation.

As we stated many times before, it’s important to make it right.

Browser makers have a big responsibility with developers: it’s wrong to claim “standard support” for a specification that is still changing. Or, at least, they should make clear it is still a work in progress (for example, by using vendor prefix extensions).

Rushing the implementation of a specific feature and call it “done deal” is dangerous and in some circumstance can bring to unpleasant results. Today we’ve seen an example of this with an important specification: Web Sockets.

Web Sockets (W3C Specification)

Web Sockets enable Web applications to maintain bidirectional communications with server-side processes. The specification (from the WebApps WG) is currently in the “Working Draft” stage; there is also a dependency on the Web Sockets Protocol, discussed in the IETF hybi mailing list.

Chrome 4+ has been the first to implement it in a “final RTW build” at the end of 2009, followed by Safari 5.0.2. Instead Firefox was planning to support them in the version 4beta and Opera in version 11, but they never went in production (credits for monitoring its status before going live). IE doesn’t implement this spec in current build.

Over time the specification changed and each browser tried to adapt by releasing sequential implementation updates. Some developer even built “The Ultimate HTML5 Browser Support Test” based on specs like this that are still in Working Draft stage. A few users commented on IE Blog about IE being “the only browser” not supporting it yet.

On Nov 26th, Adam Barth shared the results of his experiments with IETF.

“The Upgrade-based handshake is vulnerable to attack in network configurations
involving transparent (or intercepting) proxies.”

 

In other words, the current protocol used by Web Sockets might be unsecure and unstable.

Based on this discovery, Firefox and Opera promptly did the right thing, announcing they would disable Web Sockets in future releases – until a solution is found. At the time I’m writing this post, I haven’t seen any announcement made by Google or Apple yet, although I’m confident they will follow soon (as Mozilla developers do).

In developer language, this is what I call a “breaking change”. Changing (or even worst, removing) support for a feature from a version to the next one – possibly breaking all applications built by developers based on the assumption that the feature (a supposedly “web standard”) would have been supported moving forward.

After today announcements, I wonder how many apps using Web Sockets will need to be brought offline, or “freezed” or “re-written” – at least until the spec get more solid and secure? Did these developers use browser feature detection, or they just assumed that any version after (for example) Chrome 4 will support that feature the same way?

What about those existing enterprise solutions, for example Kaazing, that rely on the assumption that “most browsers” already support Web Sockets? Will they just use the Flash-based layer (as they do for IE today) for any browser?

Personally I like Web Sockets. I’m looking forward to seeing them available in all browsers. But I also do care about consistent implementations, that work the same (interoperable, secure, stable) way across any browser – over time. I don’t want to write some code today, falling in the “(non) Web Standard trap”, and then have to re-write my code in 1 year from now because that particular implementation wasn’t exactly ready for prime time yet and has been removed or changed.

I don’t want to see the “IE6 phenomenon” happening again to “Chrome4” or others. Do you?

Someone today was so disappointed that he created a short humoristic video…

Time to go back to W3C and IETF to discuss what went wrong and look at what we can do to accelerate the progress of this (and other) specs...

Comments

• Anonymous
  December 08, 2010
  I wouldn't compare it to the IE6 catastrophe, but I am curious what the solution to web sockets will be.

• Anonymous
  December 09, 2010
  Thats a weird comparison when one company auto updates properly and the other has zero auto updating aside from the OS level.

• Anonymous
  December 09, 2010
  This argument might make more sense if Chrome didn't have seamless updates. If WebSockets (or any other "alpha" feature) are deemed unsafe or problematic, Google pushes an update out. Also, the IE6 problem (which extends to IE7 and bits of 8) was that Microsoft didn't take the proper steps to formalize and spec out the features they augmented into HTML, CSS and JavaScript. There's a big difference there. Implementations of unrecommended specs give us developers time find the holes and problems in the spec. We don't want to end up with another CSS2 do we? Not to mention we'd probably not have found this WebSockets vulnerability had it not been for the implementations done by browser vendors.

• Anonymous
  December 09, 2010
  I think you are making a good point. Is "seamless updates" in the browser "enough" in this scenario? We are talking about a feature that has been available for more than one year now. It wasn't labeled as "incomplete" to developers. It wasn't using vendor prefix extensions (like, let's say, newest CSS3 features...or new performance APIs). I think it's good that browser vendors experiments with work in progress specification, but at the same time - they have a responsability with developers to explain clearly that "it might change" in the future. Otherwise, no matter how quickly you update the browser, developers website will break. what do you think?

• Anonymous
  December 09, 2010
  It should be pointed out that Opera 11 hasn't actually shipped yet--the WebSockets implementation has only been in alpha/beta builds. When 11 actually is shipped, it will be behind a preference just like FireFox 4.

• Anonymous
  December 09, 2010
  @Mike: thanks for the correction, for some reason I thought Opera11 was already out. I updated the post above.

• Anonymous
  December 09, 2010
  It's not the standard that's at fault, it's the proxy servers.

• Anonymous
  December 09, 2010
  The comment has been removed

• Anonymous
  December 09, 2010
  @Max Williams: From what I've read, nobody is being alarmist or condemning WebSockets to the scrapheap. What people are saying, which is rightly justified, is that the specs need more time to be fully vetted before being pushed out as a production-ready implementations, WebSockets included. That's not a bad thing, especially when it comes to the safety of users.

• Anonymous
  December 09, 2010
  Is it then your position, Giorgio, that IE8 should have vendor-prefixed its use of postMessage, querySelectorAll, and XDomainRequest? I do not believe that Chrome 4's use of WebSockets will hold back the web because:

• Chrome 4 had few users, as a proportion of the web
• It has virtually zero users now
• Unlike with IE6, Google has demonstrated that it isn't going to disband the team after releasing Chrome 4, leaving it to grow in market use but not keeping up with the direction of standards and developer techniques. Even though they're a competitor, I think Google has done a good job with updating users, living with the cost of removing speculative features once they are outdated by standardized ones, and setting developer expectation.

• Anonymous
  December 09, 2010
  As Mike mentioned, Chrome auto-updates so I don't think we need to worry about having a ton of old clients out there. I think it's important to keep a few things in mind. First, WebSockets server support is still not trivial to set up. You have to jump through hoops at the moment, and in jumping through those hoops you will probably figure out that WebSockets is still in development. Yes, it will change, but if you've managed to set it up you can hopefully manage to upgrade your server code. We wanted to ship WebSockets so that people could experiment and provide feedback as the spec was being developed. Trying to design by committee in a vacuum without any implementation experience often doesn't go well. The cost of doing that is that people have to be willing to move along to the next version when it's ready. We have made it clear from the Chrome side that we intend to ship the updated version of the protocol. It's important to note that the research paper Adam Barth et al published does not demonstrate a working attack against the actual WebSocket implementation, but rather against one part the protocol taken in isolation. There are other parts of the protocol that would make an actual attack more complicated in practice. Given that their experiment was conducted with existing, shipping plugins, and given that even so it only targets a small percentage of users, the likelihood of someone actually taking the effort to try to exploit someone using the WebSocket code shipped in Chrome (against which an attack has not yet been demonstrated) seems like a bit of a stretch at the moment. We already have detailed a proposal for a more secure version, and are addressing various concerns that have been raised by others in the standards community. Ian Fette Senior Product Manager, Google Chrome team, Editor, WebSocket Protocol

• Anonymous
  December 09, 2010
  The comment has been removed

• Anonymous
  December 09, 2010
  @Ian: ops, I just saw your message. Thanks for giving an update here, it's really appreciated. It’s great to see the conversations already happening at IETF; it must have been two very busy days :). For other readers, you can follow at www.ietf.org/.../threads.html (Ian please correct me if I’m missing other locations). >You have to jump through hoops at the moment, and in jumping through those >hoops you will probably figure out that WebSockets is still in development. I suspect you are obviously in a good position to know how Web Sockets as a “speculative feature” (ok ok, I’ll stop calling it this way :)) are being used at the moment. I’d be interested to know how many developers are already using Web Sockets. Is this something you are tracking? Btw, if it wasn't clear - I genuily love the idea of having sockets in a browser. I can think about some interesting scenario coming out from there...and looking forward to them reaching a solid level of stability. I appreciate all browsers (and in general all people in IETF community) efforts to make this possible!

• Anonymous
  December 09, 2010
  Well, IE9 is going to have un-prefixed <video> and <audio>, and those specifications might yet change such that what's in IE9RC isn't compliant (even IE9 final, since I think that will be before HTML5 reaches Recommendation status).  I don't think they're wrong to do so, either! Sites can be broken by any change, any bug fix (including, as all ES5 implementors have found, improving standards compliance), any addition of a feature or change in settings of a feature (like ActiveX activation).  IE6 is a problem because people were encouraged to write to features that were never submitted to standardization, identified bugs in standard support weren't fixed, and performance and security weren't improved.  And then it had many years to metastatize across web sites, documentation, tooling and similar.  In a standards-based web, there are multiple implementations to break ties and improve site testing, and developer expectation isn't that you can write it and forget it for 5 years. The bigger risk is that people don't implement ahead of standardization, and get broad developer, implementor and user feedback to shape the final form.  I would much rather see Microsoft participating in the discussions earlier and more actively, and proposing things like site integration points for standardization, than waiting to implement anything until it's Fully Standardized.

• Anonymous
  December 09, 2010
  >I would much rather see Microsoft participating in the discussions earlier and >more actively, and proposing things like site integration points for >standardization, than waiting to implement anything until it's Fully >Standardized. Great, we are on track then ;-) Standardizing HTML6: blogs.msdn.com/.../standardizing-html6-through-the-w3c-my-trip-to-tpac-2010.aspx Standards Development at W3C TPAC: blogs.msdn.com/.../web-standards-development-at-the-w3c-tpac-2010.aspx