Web sockets allows you to support cross domain access however you want by checking the "Origin:" header. If you only want to allow your own domain, then you can compare the Origin equals your own domain and if you want to allow some domains or all domains you can whitelist as you want.
According to the lastest version of the draft spec's security concern: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-55#section-7 One thing to understand is that WebSockets are not really HTTP. WebSockets handshakes may start out looking like an HTTP in the initial request and initial response but that only so that it's possible for a web server serving HTTP today could be used to handle the requests and be able to tell that it's a WebSocket and internally switch over to handling the request as a WebSocket internally. Websockets are not like HTTP though in that they are full duplex communication (real two way communication). It avoids some of the tricks you have to do with AJAX Comet/Long polling/http streaming by giving the browsers something more like traditional TCP/IP sockets to communicate back the server while still working through HTTP proxies and firewalls. Jetty, the web server that Twitter uses today on the streaming side supports WebSockets in its latest version (http://blogs.webtide.com/gregw/entry/jetty_websocket_server). Most of the web socket server implementations that exist today are built on top of traditional web servers, but they don't use epoll or any kind of event based async sockets (most design around having a single thread handle the connections for a user) and so they are unable to handle massive numbers of simultaneous open concurrent connections like you can with Jetty or FriendFeed's Tornado (http://www.tornadoweb.org/). I would love to see a streaming server implementation using WebSockets from Twitter, not only just for access from web browsers but from desktop clients that support websockets. There are some doors that open with that like being able to send back messages to Twitter up the socket (like sending a tweet, or changing the paramaters of what we are filtering on the stream, or request all sorts of things that you would have to do on the querystring and have to reconnect to change them). Zac Bowling @zbowling On Sun, May 16, 2010 at 11:29 AM, John Kalucki <j...@twitter.com> wrote: > I did a quick reading, and I couldn't tell if WS connections are > restricted back to the domain of the calling page, or if arbitrary > connections are allowed. If the former, there may not be a reason for > the Streaming API to support this. If the latter, perhaps there's a > valid use case. > > Looking at the protocol itself, this wouldn't be trivial to support, > but it might not be that bad either. We'll have to keep an eye on the > installed browser base and see when this might make sense. > > It is too bad that they didn't allow HTTP connections with incremental > byte reads in addition to WB connections on that interface. I'm sure > they had their reasons. > > -John Kalucki > http://twitter.com/jkalucki > Infrastructure, Twitter Inc. > > > > On Sat, May 15, 2010 at 3:22 PM, Abraham Williams <4bra...@gmail.com> wrote: >> I'm not particularly familiar with the specifics of WebSockets but here is >> the draft documentation: http://dev.w3.org/html5/websockets/ >> I don't see Chrome Extensions as being any different from desktop >> applications as they are both manually installed by the user on their >> desktop. >> Abraham >> >> On Sat, May 15, 2010 at 09:02, John Kalucki <j...@twitter.com> wrote: >>> >>> The first release of User Streams is not intended for web clients due >>> to capacity constraints. >>> >>> http://apiwiki.twitter.com/ChirpUserStreams >>> " >>> All services, mobile and browser-based clients must not use Streaming >>> until we've sorted out Desktop clients at some scale. One problem at a >>> time. >>> " >>> >>> That being said, of course we'd like to encourage experimentation with >>> other client types, so that clients can evolve as we scale out the >>> service. >>> >>> While others at Twitter are well-versed in the latest browser >>> technologies, I'm totally and willfully ignorant. If you could give a >>> brief summary of how the existing Streaming API does not work for >>> WebSockets, that might be helpful. What's missing? >>> >>> -John Kalucki >>> http://twitter.com/jkalucki >>> Infrastructure, Twitter Inc. >>> >>> >>> >>> On Fri, May 14, 2010 at 9:38 PM, Cezar Sá Espinola <ceza...@gmail.com> >>> wrote: >>> > Hey guys, >>> > Quick question, are there any plans on supporting WebSockets protocol >>> > for >>> > the Streaming API? >>> > That'd be awesome for browser based Twitter clients (i.e. Google Chrome >>> > extensions). Without this it'll be very difficult for this kind of >>> > client to >>> > lavarage benefit from the upcoming user streams. >>> > Thanks a lot for all your hard work, >>> > Cezar Sá Espinola >>> > @cezarsa >> >> >> >> -- >> Abraham Williams | Developer for hire | http://abrah.am >> @abraham | http://projects.abrah.am | http://blog.abrah.am >> This email is: [ ] shareable [x] ask first [ ] private. >> >