
WebSockets Disabled by default for Firefox 4 - thehodge
http://cometdaily.com/2010/12/07/websockets-disconnected-for-firefox-4/
======
pjscott
Damn it! WebSockets are one of the nicest things in HTML5, and even for people
using a compatibility layer like the excellent socket.io, things just seem to
work better when the browser supports WebSockets natively.

Of course, we're not going to get ubiquitous WebSocket support until Internet
Explorer 10 becomes the new IE 6, which I doubt will happen for a long time.
Even so, Firefox could make a big difference here. It would be nice.

~~~
natmaster
From: [http://hacks.mozilla.org/2010/12/websockets-disabled-in-
fire...](http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/)

"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."

------
kondro
I think the WebSockets movement just died a little.

It's already hard enough to write modern web-apps that work across a multitude
of browsers either replicating features with crappy techniques in the older
ones or being given the capability to degrade gracefully. Now, a feature that
was expected on modern browsers now doesn't exist on some of them.

Yes, I understand that there are security concerns, but it was concerns like
this that lead browser makers to disable cross-domain JavaScript rather than
implement a solution to do it securely. I hope WebSockets doesn't end up going
the same way.

~~~
Tichy
Maybe there is no simple solution.

~~~
kondro
For WebSockets? Maybe there isn't. It's not really the browsers fault
necessarily, W3C takes many, many years to ratify standards so they go ahead
an implement things themselves causing incompatibilities and, in the case of
WebSockets, for them to provide features they now have to take away again.

For cross-site scripting, there are many ways this could be enabled. Like the
way Flash does it, for example, by placing a file at the root of a domain
which specifies all the other domains it is allowed to talk to. Providing a
manifest like this is likely the simplest solution to a problem that makes
designing thick-clients quite annoying.

~~~
franck
Just for the sake of correctness, I want to point out that it's the IETF, not
W3C, which is responsible for the WebSocket protocol.

~~~
kondro
I do apologize however, they don't move any faster. Has SIP even been ratified
yet? :-p

------
jerf
It still seems to me the problem is that they tried too hard to wrap the
sockets into "the web". Just open a standard TCP socket to the web site's
specified port and server. Layer me in some automatic SSL negotiation using
the site's HTTPS cert (or something signed by it) if you want to win points.
(Probably should mandate this, in fact, as it would block off most of the
remaining "forging what site to connect to" issues; not unless you have the
correct SSL info, in which case you've won anyhow.)

I'm not sure what proxies are doing involved in sockets at all. I do not see
what useful thing you can do with a proxy, except maybe flat-out block web
sockets. They can't meaningfully cache, they can't meaningfully enforce policy
except with the blindest, stupidest of approaches that should probably be in
another layer anyhow. There's not enough structure in a raw socket connection
to do anything with, what structure is there could and should be managed by
your router.

I'm sure there's some massive problem I'm missing here. (Though if it's "users
can't use websockets through a proxy", frankly, I don't really see that as a
problem that has a solution. By the time you fix up your "proxy" to allow
"essentially arbitrary socket connections" what you've got there is a
"router". If you're in an environment where you actually must use a proxy for
some reason, you're in an environment that is probably going to ban arbitrary
socket connections anyhow.) Now's your chance to enlighten me, I guess. I'm
not trolling here, I do believe this, but I'm interested in the answers people
give too. Maybe someone will convince me. (No joke.)

~~~
jimmyjazz14
Features like the "Host" header and built in support for proxies are important
to the infrastructure of the web, I believe websockets are an attempt to
preserve these feature among others while allowing a socket like connection.
This idea seems supported by the fact that Websockets use an intial handshake
over HTTP which allows the same server that handles HTTP request to handle
websocket request.

~~~
adamzochowski
Except for ssl the header is encrypted. so you can't use Host header on ssl
proxy. This is where HTTP CONNECT comes in. Connect is a second header that
tells proxy on how to proxy, and then the rest of connection is raw (to
preserve secure actual request header).

------
wmf
It's not clear that this security issue is real, but the WebSocket protocol is
definitely going to change soon in a major way. I've been reading the the IETF
HyBi list and the whole situation is pretty depressing.

~~~
tptacek
I'm not sure how one could interpret "we launched this attack using an
advertising network on the general population of the Internet and found cases
where connection routing fell under the control of our attacker" as "not a
real issue".

I see the political concern in your followup, but you didn't actually rebut
the paper. It's an EKR-endorsed protocol security paper; my bet is, they're
right. The problem statement certainly makes sense (browsers and proxies, both
critical to Internet security, are not evolving the HTTP protocol in lock
step).

~~~
wmf
The experiments in the paper didn't use WebSocket framing which likely would
have prevented the attack from working. [http://www.ietf.org/mail-
archive/web/hybi/current/msg04750.h...](http://www.ietf.org/mail-
archive/web/hybi/current/msg04750.html)

------
tjarratt
I'm really curious what Mozilla's motivation is for disabling websockets over
security concerns. Is it that they are susceptible to man in the middle
attacks, and a websocket connection could be started with an untrusted server?

Anyone familiar with security and websockets?

edit: I'm using websockets in a few projects (gracefully degrading to flash or
XHR), and I'd like to know whether I should reevaluate webSockets.

edit2: according to this mailing list, it's an issue with how proxies handle
the HTTP Upgrade header. Awesome.

[http://www.ietf.org/mail-
archive/web/hybi/current/msg04744.h...](http://www.ietf.org/mail-
archive/web/hybi/current/msg04744.html)

~~~
oofo
Exactly the other way around, some man in the middle attacks get confused in
the presence of websockets: "The Upgrade-based handshake is vulnerable to
attack in network configurations involving transparent (or intercepting)
proxies"

It's pretty weird that they consider this a problem with websockets.

~~~
tptacek
It's not an issue of "attributable fault". It's an issue of a reasonable
protocol that doesn't work reliably on deployed infrastructure. Unlike, say,
HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that
tickles a bug in a widely deployed proxy can be catastrophic.

Let's all be _clear_ that the "fault" lies in crappy HTTP code deployed in
middleboxes (and that includes mine), but _pragmatic_ in understanding that
that doesn't matter; browsers can't become roving exploits for proxy bugs just
because a standard says so.

------
mike-cardwell
The long polling technique that people currently use is good enough for the
vast majority of cases, so I don't mind if WebSockets takes another few years
to develop into something final. There's no need to rush out a protocol here.
I'd rather they released something _good_.

------
catshirt
maybe there is a problem. this is not the solution.

another checkmark on a long list of frustration with firefox 4.

~~~
weavejester
What else can they do? If the websocket protocol is insecure, they need to
wait until its fixed. They'll probably re-enable it in Firefox 4.0.1 or 4.0.2
with a fixed websocket implementation.

~~~
drdaeman
Stop spreading FUD.

Websocket protocol _is_ perfectly fine. What's insecure are broken proxies.

~~~
weavejester
Why take such an aggressive and accusatory tone? You don't have to reply with
such vitriol.

Secondly, I didn't actually say websockets _were_ insecure; I said _if_ they
were, then Firefox is sensible not to include them.

Third, even if the websocket protocol is secure in theory, if the majority of
proxies don't correctly implement the upgrade header, then using websockets is
insecure in practise.

------
drdaeman
What I don't get is why they're not disabling Java and Flash support too,
then?

------
tieTYT
This article didn't provide any more information than the title. Can anyone
fill the rest of us in. What are WebSockets and why should I care?

~~~
pjscott
They're bidirectional sockets between the web browser and the server,
essentially. They're handy whenever you want messages going back and forth
between client and server without a bunch of reconnecting, or really ugly
hacks.

For example, apps like Etherpad or Apache Wave need to send messages for each
editing operation (e.g. keystrokes), and it would really suck if they had to
open a new HTTP connection for each one and do long-polling to receive from
the server. Websockets make this sort of thing simply a matter of sending and
receiving on a socket. Easy.

You can fake them with something like Socket.IO, if you want the API and are
willing to tolerate unpleasant performance on browsers that don't support it.

~~~
mhitza
WebSockets are ugly hacks on their own. They use HTTP as well for the
underlying channel of communication.

The only difference is that with the WebSockets the ugliness is hidden from
your daily programmer via a nice API.

~~~
jimmyjazz14
Thats not entirely true, Websockets do initiate over http (by using the
'Upgrade' header so they can share port 80 with normal http traffic) but after
the initialization handshake is finished the traffic no longer uses the http
protocol.

~~~
mhitza
Indeed, I made a false assumption due to my lack of experience with WebSockets
and sparse look I had over them.

But I'll still going to stick with the fact that they are ugly hacks.

------
DjDarkman
> Unfortunately, this will not happen in time for the release date of Firefox
> 4.

Then why release? Why release a product that is clearly not ready? Think about
the developers for a second!

------
drivebyacct2
Yet another reason Chrome's rolling release auto updates are glorious. (When
the protocol is fixed, Chrome users will all have it within a day or two;
Firefox users, not so much)

Additionally: Nochum's comment is concerning, if accurate:

>This is gonna suck since the feature detection will be totally thrown off.

>E.g.:

>if (WebSocket in window) > ...

~~~
axod
Relying on feature detection alone for WebSocket is a big mistake though.
Websocket can fail for a number of reasons - proxies, stupid ISPs that
interfere with HTTP traffic etc.

In Mibbit, the code is something like this:

    
    
      if(WebSocket in window) {
        tryWebsocket();
        window.setTimeout(function() {
          if (nothingHappened()) useComet()
        }, 5*1000);
      } else {
        useComet();
      }
    

Where comet in this case is keep alive long polling XHR.

~~~
taitems
That's an interesting way of managing timeouts. Is the 5*1000 intended to just
be a more readable way of specifying seconds?

~~~
mcav
I assume so. I do the same thing.

------
roschdal
Scandalous.

