HTML5 in the browser: HTML5 data communications
Cross-document messaging, WebSockets, and other HTML5 APIs bolster website and browser interactivity to create a faster, richer WebFollow @peterwayner
Then there's the security issue. Both Google and Mozilla decided to shut off their implementation of WebSockets for the time being after researchers Lin-Shung Huang, Eric Y. Chen, Adam Barth, Eric Rescorla, and Collin Jackson found it was possible to fool the browser into caching fake data [PDF]. They propose a more sophisticated mechanism, and the browser developers seem to be sticking with the idea. The code in Firefox, for instance, still works if you flip a secret configuration bit so that WebSockets can be used for testing. Once everyone regains their confidence, the
window.websocket object will magically reappear.
The number of options available to the modern HTML5 programmer can be a bit daunting. If an
XMLHttpRequest fetches information from the server and WebSockets carry data in both directions, you might wonder if there's a way for the server to send information unilaterally. Naturally, there is such a plan, called server-sent events.
There's not much to the code. First, create an
EventSource object pointing to the domain. Second, register a function to process the events if and when they arrive. There's no need to set up an open socket or to constantly poll a distant server. It's a spec that could save some battery power on handhelds.
A faster, simpler Web
All of these ideas for richer communications among websites and browsers should be both familiar and attractive to both developers and the ISPs. They reduce the need for extraneous message passing, and this alone should help cut down on some of the traffic on the Internet. Websites will seem a bit zippier.
However, the question of security still lingers. To most developers, the new specs should seem like baby steps that the browsers began taking long ago. What could possibly go wrong? The browser teams already shut down the WebSockets feature after some smart scientists found a sophisticated way to abuse it. The ideas may seem simple, but the implementations may have mistakes.
Such pitfalls raise the question about how much users can do about these new features. Unlike some of the newer ideas with a fancy HTML5 logo, most browsers don't offer the standard user any way to turn these communications features on or off. It may be possible to check on the number and size of local databases that a website is setting up -- another feature often considered part of HTML5 -- but there's no easy way to open up a preferences box and flip switches on any of these data communications features.
This will probably change if someone starts abusing them. There was no way to control pop-up windows until the advertisers made an annoyance of them -- then the pop-up blockers appeared. Will such controls be necessary? Although the standards seem simple and well thought through, hackers are surprisingly clever at chaining together several tiny slipups and turning them into a gaping hole. It may be good for everyone to adopt these ideas slowly while understanding the potential danger for fraud and malfeasance.
Note: This is the third article in a series devoted to the new features of HTML5. The first article, "HTML5 in the browser: Canvas, video, audio, and graphics," examined display options, including the <canvas> and <video> tags, Scalable Vector Graphics, and WebGL. The second article, "HTML5 in the browser: Local data storage," examined Web Storage, Web Database, and other APIs designed to transform Web pages into local applications. The next article will examine HTML5 forms.
This story, "HTML5 in the browser: HTML5 data communications," was originally published at InfoWorld.com. Follow the latest news in software development, languages and standards, and HTML at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.