• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Web Sockets and the risks of unfinished standards

Enthusiasm for a promising new standard called Web Sockets has quickly cooled in some quarters as a potential security problem led some browser makers to hastily postpone support.

The Web Sockets technology, which opens up a live communication link between a browser and a server, remains an important part of plans to make the Web a home for more dynamic, interactive sites. It could, for example, speed up Google Instant searching and multiplayer games. But Mozilla and Opera put their Web Socket plans on hold this week until the wrinkles are ironed out.

The reversal is only the latest difficulty, though. Web Sockets development already had become somewhat contentious as eager browser makers--Google in particular--began including support for a specification they knew wasn't done. Overall, the Web Sockets history illustrates some pitfalls of the style and pace of Web standards development.

When technology companies are working on the next version of standards for Ethernet or USB, much of the work happens among dedicated engineers informed by work at test labs. But with the Web, the entire Internet is the test lab. That's because Web developers, not just browser makers and other industry powers, play a role in early-stage work shaping specifications and gauging interest.

Browser makers, naturally eager to curry favor with this influential audience in the highly competitive browser market, race to include new technology. With Web Sockets, Google was the first with a version of Chrome a year ago. Apple has followed suit with Safari 5; Mozilla had been building Web Sockets into the upcoming Firefox 4 and Opera into its upcoming Opera 11.

Web Sockets problem

Now, though, plans are shifting with publication of a security problem by Adam Barth, a programmer with extensive browser security expertise. In a November 26 paper (PDF), Barth pointed out a problem with the "handshake" used to set up Web Sockets connections. By exploiting it, an attacker could get a browser to run malicious code through a mechanism called cache poisoning, Barth and the paper's co-authors said.

"Although raw socket access is an important capability for full-featured browser-based applications, providing sockets safely has proven to be challenging," the paper said. The paper proposed a new, more secure mechanism that has won support among browser makers.

The backtracking came a few days later.

"We've decided to disable support for WebSockets in Firefox 4, starting with beta 8 due to a protocol-level security issue," Christopher Blizzard, a Mozilla leader of new-technology work, said in a blog post. "Once we have a version of the protocol that we feel is secure and stable, we will include it in a release of Firefox, even a minor update release...To be clear, we're still excited about what WebSockets offers and we're working hard with the IETF [Internet Engineering Task Force] on a new WebSockets protocol." (Although the World Wide Web Consortium (W3C) is standardizing Web Sockets as part of HTML5, the IETF is in charge of the actual communication protocol it uses.)

Next came Opera. "Until the new WebSocket protocol handshake is sorted out by the IETF it will be behind a preference in Opera," Anne van Kesteren, who works on standards for Opera, said in another blog post.

Apple hasn't made commitments, but it appears to be concerned too. "We would be hesitant to ship protocol updates that do not fix the handshake. Given the security issues identified by the paper from Adam and company, we would even consider disabling WebSocket entirely in future releases until there is a more robust handshake," Maciej Stachowiak, a lead developer of Apple's Safari, said in a mailing list post.

Microsoft, which is trying to make up for lost time supporting new Web standards with Internet Explorer 9, was more cautious about Web Sockets support even before the security problem arose. So its commentary on the matter took the form of an I-told-you-so in a blog post by Web technical evangelist Giorgio Sardo.

"Rushing the implementation of a specific feature and call it "done deal" is dangerous and in some circumstance can bring to unpleasant results," Sardo said.

But Google, which employs Web Sockets editor Ian Fette, sees things differently from the rest of the pack. Fette had this to say in a statement to CNET:

We are not hiding it behind a flag at the current point in time. We released the details of the research to help guide the working group towards what we believe will be a more secure version of the Web Sockets protocol, and are hoping that the group will reach consensus in the next few weeks. 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.

It's important to note that the research paper Adam Barth et al. published does not demonstrate a working attack against the actual Web Socket implementation, but rather against one part [of] the protocol taken in isolation. There are other parts of the protocol that would make an actual attack more complicated in practice. We believe there will be consensus on a new version of the protocol, and implementation in Chrome of that new version, before someone is able to actually demonstrate an attack against the full Web Socket protocol as currently shipping in Chrome.

Web Sockets' background

In the early days of the Web, communications between browsers and servers were limited. A browser would request a Web page and a server would deliver it.

The modern Web, though, needs more. Web sites are becoming actively updated, and Web applications must communicate with the outside world. To that end, programmers have come up with workarounds such as Comet and long polling to try to keep a communications channel open.

Web Sockets is designed to make this task much easier to program and much faster in operation.

That could be very useful for many dynamic Web tasks--for example a site with live-streaming updates or multiplayer games with real-time interaction. Another example, from Fette, is a Web-based e-mail program: typing a letter in the "To:" field, the server might want to start providing a list of names or e-mail addresses that begin with that letter, then update the list when the next letter is typed.

That sort of communication is exactly what goes on with Google Instant, which provides search results on the fly, so it's not hard to imagine that Google would like Web Sockets there, too, in its obsession over cutting any millisecond possible out of the search process.

The technology has two important attributes. One is low latency: there's a smaller delay between when a message is sent and when it's received than using current approaches. Another is that Web Sockets doesn't use as much data.

It's therefore no surprise that browser makers were eager to embrace Web Sockets. Google, with its Chrome OS and Chrome Web Store push to enable a world of rich Web applications, has a particularly strong incentive.

Breaking changes

Even before the new security problem, the Web Sockets development had been contentious as Google and others issued browsers using the early "-76" version of the technology. One issue was whether Web Sockets support should be tucked behind what's called a vendor prefix. That would mean a Web programmer would call upon the feature using browser-specific instructions. That approach protects against Web sites breaking when the final, incompatible version is released later.

The debate about how to handle early-stage Web Sockets support has been going for months on the Mozilla mailing list.

"I think the best strategy is to just keep breaking people to force the expectation that this is still a work in progress, and if you're not aware of that you shouldn't be using it," Fette said in one comment. "From the browser perspective, my intent is to keep pushing out new revisions, with the assumption that we auto-update and will not have old versions lying around to deal with."

But not everybody updates software as diligently as might be ideal. That can lead to difficulties ensuring new technology doesn't break older technology, even if the older technology doesn't comply with modern standards.

"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," Sardo said. "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."

In his comment to CNET, Fette defended Google's approach, including shipping Web Sockets early in Chrome with the possibility that its underlying technology would change.

"We have gained a good deal of insight by having an implementation we and others can experiment with," Fette said, including details about message sizes, compression, and interactions with the complex realities of networking. "I don't think it would be possible to do this work without that ability to experiment."

Because of that value, it's not likely that Web standards development will stop relying on real-world trials.

But what is changing is that development's pace. Google has a sense of urgency around developing Web Sockets. But with other major browser powers concluding otherwise, it's clear that Web Sockets' momentum has been slowed.

by Stephen Shankland

Источник: CNet

Оставить свой комментарий:

Комментарии по материалу