The real answer is that I don't know exactly how secure they are. It looks like they're at least as secure as Http and other transmissions.
Security has been a major concern, perhaps the major concern in development of the standard. Quite frankly, I can see no other reason except security concerns that such a standard took years to create. I'm quite confident that security is the reason this hadn't been done years ago. The has been lots of open review and people looking for ways to hack. A security issue did arise in one of the earlier drafts of the standard and they fixed it. There are extra requirements for communication from browsers to avoid hijacking - which was the big security issue that was fixed in version 7 of the draft standard. For non-browser communication, developers are allowed to be slightly more relaxed and it's up to server developers to take advantage of some of the security features. On the other hand, they're also allowed to implement additional security schemes within their own client-server designs that wouldn't be available in browser communication. If I'm not mistaken, your reference to issues with Ajax toolkits has to do with cross-site-scripting / hijacking. The WebSocket standard development group has announced that they're satisfied that the problem has been fixed as far as the WebSocket standard is concerned. It's up to server developers to ensure that the security measures are all completely implemented. In browser communication, most of them can't be avoided. But it appears absolutely certain to me that implementing all the security features properly is the way to go. Yes, you can encrypt data. There are two new prefixes to be used in place of http:// in the websocket address; ws:// for non-encrypted communication and wss:// for encrypted. Default ports 80 and 443 apply to each. ________________________________ Från: Pranav Lal <[email protected]> Till: [email protected] Skickat: torsdag, 8 september 2011 3:29 Ämne: RE: [svg-developers] Websockets, explained Roger, How secure are websockets? I believe there were security issues with Ajax toolkits? Can the communication between the browser and server be encrypted? Pranav -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roger F. Gay Sent: Wednesday, September 07, 2011 3:58 PM To: [email protected] Subject: [svg-developers] Websockets, explained Browser / JavaScript support for WebSockets is part of the HTML5 specification. It's the next big leap in interaction between browsers and "back-end" (server side) processes. If you've been around long enough, you may remember the olden days when you clicked and then had to wait until the response came back. Your browser was locked until it did. In fact, if there was a problem, your browser could just get locked up and you'd have to restart it. While that got smoother, "asynchronous" request-response (supported by Ajax) came along so there was no longer any need for the browser to wait for a response. Using this technology, you can continue about your business instead of coming to a standstill after a request is made. The browser doesn't lock up when the request is sent. It will react whenever the response shows up. WebSockets are the next big jump in this evolution. Their application in the client-browser is like Ajax, only easier and more powerful. Just a few lines of JavaScript code (easier than Ajax) and you have bi-directional communication between the browser and the server. By "bi-directional" I don't mean request-response. It's true bi-directional communication. (Since request-response is "bi-directional" (with limited characteristics), perhaps I would have chosen a different term to make the distinction. But this is what you'll find in descriptions and tutorials everywhere else.) THE SERVER CAN SEND DATA TO THE BROWSER ANYTIME THE APPLICATION PROCESSES TELL IT TO. It isn't limited to servicing requests from the client. The connection isn't closed when a response is made. It remains active for two-way communication until one side or the other closes it. (Which happens automatically when you close the page tab or browser, for example.) IT'S A HUGE OPPORTUNITY for everyone involved in web development, whether on the browser side or server side, or both; to completely rethink the web-page experience. The change-over to WebSockets is going to be more "disruptive" than the change to Ajax. Ajax made old-fashioned point-and-click request-response web functions (which I do not expect to go away completely) a much better experience. WebSockets provide the opportunity to easily turn browsers into full-fledged application interfaces. It becomes practical to deliver any application through the browser. It doesn't just make the webpage experience better, it makes it different. What about Ajax: Obsolete? I would still use Ajax in applications that are limited to point-and-click request-response. Why not? It's good technology. You can however, get the same effect with WebSockets. Neither end requires a response except when making the initial connection. Everything from there is inherently asynchronous. If you expect a larger number of interactions while a user sits on one page (searching through and listening to music samples for example) WebSockets offer the more efficient way to go. Once the connection is established, the overhead of communication is less, so it's faster and more economical for the Internet as a whole. [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ ----- To unsubscribe send a message to: [email protected] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
