It's not WebSockets it's your broken proxy

websockets-proxy.png

Several commentators have suggested that this is the death knell for WebSockets, and we should all go back to long-polling. This is completely false. Learn why.

Introduction

The Twittersphere has exploded recently with the news of Firefox and Opera’s decision to remove WebSockets from their next browsers. Several people have suggested that this is bad news for WebSockets, and by association, us. We’d like to take the opportunity to talk a bit about what the actual issue is, and why it is not a massive cause for concern for us.

The short version: this is a temporary setback and will be resolved fairly soon. WebSockets remain the best solution for pushing information to client browsers. Pusher will still work with Firefox and Opera, by using a Flash socket instead.

WebSockets are not dead

Several commentators have suggested that this is the death knell for WebSockets, and we should all go back to long-polling. This is completely false. WebSockets are an early stage specification at the moment, and there are bound to be setbacks.

Mozilla remains optimistic:

Mozilla is still excited about what WebSocket offers and we’re working hard with the IETF on a new WebSocket protocol.

http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/

It is worth noting that WebSockets have not been removed from the code-base, but have been temporarily disabled. It is possible for users to re-enable WebSockets through a user preference option.

What is the issue?

The issue is described in detail here. It essentially boils down to client javascript behind a buggy caching proxy being able to poison the cache for another site, allowing them to change the content delivered to other clients (behind the same caching proxy). This is obviously a pretty serious issue with large ramifications.

The thing is though, that it is not a WebSocket issue per se. It is a problem with the caching proxies, that can be exploited by a client machine. The tests were done with Java and Flash clients, and it is therefore something that has presumably been an issue for many years. The arrival of WebSockets has exposed the problem, as more scrutiny has been applied to the mechanism.

In fact there has not even been any demonstrated exploit using anyWebSocket draft. At this state an attack using WebSockets is purely a theoretical possibility.

In an enterprise environment, IT departments can clock installation of Flash and Java plugins in their browsers, but the same is not necessarily true for native functionality. This is why Browser vendors have to act responsibly.

The problem is completely unrelated to any socket server implementation, and exists whether or not there are socket servers such as Pusher on the internet. We are not causing an issue by continuing to run our service, and there is no way we can safeguard against vulnerabilities in client browsers.

Going forward

We follow developments of the specification very closely, and were aware of this discussion prior to the announcements by Mozilla and Opera. We will not only be keeping our service up to date with the latest specification so that our clients don’t need to worry about the details, but we will also be contributing back to the OpenSource Ruby library that constitutes a major component in our socket stack.

While this is temporarily inconvenient, we support the browser vendors’ decision to keep their users safe. It is in our best interests for security problems to be discovered and resolved early, as we are certain that WebSockets will play an extremely important role in the web going forward.