I feel like DataChannels are the best part of the WebRTC standard (or would be, if they were usable): a true p2p connection allowing transfer of arbitrary data without plugins or anything. This gives multiplayer games, file transfers, realtime chat and collaborative editors (let your imagination run wild...) and the only thing a server is required for is establishing the connection (and saving state). This functionality is much more exciting than simple video or audio chat.
I agree, and it's easy to tell just in the way you can describe it. The first thing video/audio chat brings to mind to anyone is 'Skype in the browser'. That's still cool and there is definitely more potential than that, but just having an arbitrary connection is a lot more open ended and exciting.
It's a JavaScript implementation of the Kademlia DHT. It doesn't support WebRTC as a transport yet, but they're working on it. The code looks pretty reasonable, and they seem to have some momentum going.
Firefox has as full DataChannel implementation (SCTP-based), while Chrome has a partial one (RTP-based). They don't interoperate yet. I implemented most of the partial implementation and am working on the full implementation now.
I'm glad that you're excited about them. I am too. I hope to have it ready for you soon :).
Out of curiosity - do you mean that you're writing a full SCTP-based implementation, or completing the RTP-based one? The standard draft specifies SCTP, right?
Well, when I heard that WebRTC was in Chrome stable I thought this must surely include DataChannel, since it's simpler than a full-blown video stack. So although it being behind a flag is better news than it not being there at all, I was still pretty disappointed when I read that page :)
edit: also, I don't see it as an about:flags flag.
edit 2: I should just tunnel data through video then, what could possibly go wrong?
It's not quite that simple. We (I work with the Chrome team) have an RTP-based data channel (sort of what you call "tunnel through the video" already in Chrome), but it provides no congestion control or reliability. To provide those, the IETF has proposed as the standard to use SCTP. Firefox has already integrated SCTP into their implementation, and we're working to get it into Chrome. So, you can start using the API now, but it'll get much better soon.
$(document).keypress won't pick up keystrokes from across tabs or windows. So unless the popup is the active window, you should be safe from something like this.
They don't have to use ajax. They can load an image with an arbitrary url and pass the keypress data in the url parameters, or dynamically create a script tag, or create an iframe and submit a form in it, etc. The script tag method also lets them get data back from the remote endpoint, if the remote endpoint is kind enough to encode it as JSONP.
I think he's referring to a hostile script trying to bind to keydown -- usually you shove the banners in iframes to limit this possibility when you include external untrusted content. I assume the same holds true here, though.
The Same Origin Policy can be overridden by the site accepting the connection (http://www.w3.org/TR/cors/), so assuming that site is hosted by the attacker it wouldn't be helpful. If the site used (and the browser supported) a Content Security Policy (http://www.w3.org/TR/CSP/) you could restrict such outgoing connections.
I don't think this is an issue. The popup would only capture whatever keystrokes are typed into the popup (as dbaupp illustrated). DataChannels doesn't change the boundaries within which a webpage/Javascript runs
It's true that the audio, video, and data are all encrypted. But it's not the case that you can send audio and video over the data channel. Well, you could send audio and video data, but there's no way to pipe audio and video data into the data channel. That's an interesting idea, but it would probably take a long time to figure out and become part of the standard, if it ever happened at all. We'd probably need a worthwhile use case to justify it.
My bad, I haven't played with this stuff in... jeez, nearly a year. I had a PoC with an signaling server written in Go, but it hasn't even been updated since the move from ROAP to JSEP and I haven't played with the compat js shim either...
