Firefox 6 - WebSockets are back | Hacker News Reader

Firefox 6 - WebSockets are back

hacks.mozilla.org

147 pointsthefox38 comments

Firefox 4 ditched WebSockets for security reasons. Does anybody know the justification to add it back now? More specifically, do they fix the security issue of WebSocket, or do they just give up to the popular demand?

Yes, the security concern has been fixed using masking. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...

Maybe someone could explain the original security concern, and how masking is able to address that concern?

In the original protocol, it was possible to get two endpoints to transact over Websockets even if a middlebox between them didn't perfectly enforce the protocol. This is bad because it potentially confuses the middlebox about which parts of the stream are HTTP/1.1 requests or not, which can allow attackers to poison caches.

In the new protocol, Websockets traffic is (trivially) encoded so that it (a) can't accidentally be interpreted by either endpoint as something other than Websockets and (b) can't confuse middleboxes.

Basically, "new" Websockets has custom Websockets encryption that nothing other than Websockets will be speaking, so, if you're talking Websockets, it's because both endpoints consented to do so.

That seems like a horrible solution - now we have to wait until all companies update their proxies to support websockets.

No, just the opposite - this change was necessary to get WebSockets to work with old, broken proxies. Previously those proxies might interpret part of the body of the WebSocket traffic as an HTTP header; now they will correctly just pass the traffic through.

What does this mean for servers? Do we need to support both versions of the protocol for now? Is that even possible?

To be more precise, obfuscation.

That would indeed be more precise, but it would also be bad writing. And my writing needs all the help it can get.

The full details are here:

http://w2spconf.com/2011/papers/websocket.pdf

(Full disclosure: I'm a co-author of that paper.)

Yes, the security concern with the WebSockets protocol has been resolved.

That's good news, WebSockets is probably the second coolest thing to come out of the HTML5 movement, right after WebGL I think. Everything else is cool and all but those two are major changes.

I'm also happy and couldn't agree more, but I would make it more generic: Canvas/WebGL is the huge change. And I would add Local Storage as a distant third to WebSockets' strong second. The rest is fun but not game changing.

Yeah that's true, Canvas is a huge win also. I use both extensively for my current work project. The File Api is also pretty awesome, I'd tie it up to local storage. In the field (Medical imaging) I'm in, allowing users to load data from their computer with no round trip to the server is very important. It helps for security reasons.

Local Storage is limited to 5MB, which cripples the ability of indie game developers to effectively use WebGL as an alternative deployment platform.

You will be able to ask the user for more than 5MB.

It has unlimited storage if you use Chrome's Webstore. I suppose it will just take a while before the other browsers can figure out how to implement it the right way for more than 5 MB of storage.

Other browsers have figured it out. Other browsers had it figured out before there was a Chrome Webstore.

> Local Storage is limited to 5MB

You can store a lot more than that in IndexedDB. The browser asks the user every 20MB or so.

I disagree, I think that history.pushState is the most important thing.

There's a difference between cool and important. pushState isn't that cool as we can almost do the same thing without it (#!), but web sockets are a whole new concept. That said, for sites that don't constantly update, pushState will be more useful than web sockets.

...because history.pushState is what makes it ok to use all the other cool stuff.

In case you're wondering what "this API will be temporarily namespaced" means, see http://bugzil.la/659324. Before Firefox 6 is pushed to the release channel, the constructor will will be changed to "new MozWebSocket()". Once the JavaScript API is stabilized, it will be changed back to "new WebSocket()".

Rwaldron has some good coverage of this over at http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eve...

Funny, I just posted this link to Rwaldron's coverage right before you posted to the link he is responding to.

IE does not inherently support WebSockets, so apps with worker threads will block. You can support WebSockets in IE clients using this hack:

http://bit.ly/irM6XV

What are some potentially practical uses of WebSockets?

Realtime web apps. No need for long poling when you can have a live connection open

Anything that Comet or other long-polling techniques provide, really.

The advantages of WebSockets include constantly changing specifications which are neither backwards- nor forwards-compatible, a lack of proxy traversal, an arbitrary and unreasonable limitation on binary data transfer, and lack of unified browser and server support.

It's not that bad. Right now you basically have support for the -76 protocol in release channel Chrome and Firefox 4 or 5, it's nearly trivial to support all of those with a single server.

With Firefox 6.0, I had to spend some time to upgrade our little Python server, but now it happily serves both -76 and -07. It also looks like -07 is very close to being signed off on as the actual standard, so the compatibility problems are probably a thing of the past soon (-76 and -07 are actually completely trivial to discern from a server point of view).

I haven't tried with binary data, but it looks like it's explicitly supported with -07. Not sure about proxies, they aren't relevant to our work app.

For server side development, I've found that Jetty has a good websockets API. I had difficulty getting the server and browser to agree a few months ago when I tried it (common libs in python and C# were tested). Moving to Jetty got it working. I'm not sure how current it is though.

I've held off on using WebSockets until binary frames are supported. I'm amazed they haven't been so far.

Ericsson has a working implementation for this, they do voice and video browser to browser with Webkit:

https://labs.ericsson.com/apis/web-real-time-communication

http://news.ycombinator.com/item?id=2600585

In practice, things like Base64 encoding are used. That's what we use in Ganeti Web Manager to host a noVNC (HTML5 VNC client) and have it talk WebSockets with the backend.

In theory, there's no good reason we can't have binary frames; I have internally filed it under the "Why can't we have nice things?" category.

WebSockets will generally provide latency improvements over long-polling as they won't have the overhead of creating and breaking down many HTTP connections (as to "push" using long-polling you need to return to the browser). XHR-multipart communication is better than long-polling, but only Firefox supports it.

I still don't understand "web" sockets. I mean, to get a web page, I already have a TCP connection. TCP connections are bidirectional. All we need is for the browser to write stuff to the socket and read stuff from it.

Yes, I understand that proxies may assume HTTP is request/response... but that's fine. My app breaks when you use that proxy. I can live with that.

The future-proof fix is to add some Cache-control header that says, "hey, this response is infinitely long! don't cache!".

Also, the 'Web Console' developer tools are interesting. Somewhat rough at the moment, but it has some useful features.

I am completely in love with the persistence of the console between pages; Really, really helpful for a whole bunch of hard-to-debug cases.

Do you guys know of good tutorials on WebSockets?

Reply on news.ycombinator.com