Comment by dbaupp | Hacker News Reader

Comment by dbaupp | Hacker News Reader

Parent Full thread

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.

This is what really excites me. I want to build a P2P DHT in the browser, basically see if I can implement something like Freenet entirely in JS.

You might be interested in KadOH:

https://github.com/jinroh/kadoh

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.

Thanks! This looks really interesting.

http://webp2p.org/

Unfortunately, if this page is accurate, DataChannels don't really work yet:

http://www.webrtc.org/chrome#TOC-Data-Channels-

A shame, because I have a use in mind for them. :)

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 :).

Good to hear.

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?

edit: this was addressed in another post.

It works on some alpha release of both Firefox and Chrome. There are already some file transfer apps if you're curious, although I haven't tested myself: https://github.com/lindstroem/FileTransfer and https://github.com/peer5/sharefest . Also, the folks from easyrtc ( https://github.com/priologic/easyrtc ) have already started working on adding DataChannels to their library.

A bit-torrent like client in the native browser would be interesting... wonder where Opera is on this one.

I tried this less than a week ago on Linux platform and was unsuccessful. I am also waiting on this feature, want to do some cool stuff :-)

They recently appeared behind an about:flags flag. :)

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.

Sctp is a pretty cool protocol. I'm actually planning on including it as part of a user land network stack I'm slowly working on.

Sorry, I forget not everyone is on the Dev channel, but I have this available:

Enable RTCDataChannel. Mac, Windows, Linux, Chrome OS, Android: Enable experimental RTCDataChannel for peer-to-peer data communications. Disable

Version 26.0.1397.2 dev

What sort of security is in place - e.g. what's stopping a pop-up ad from logging keystrokes and sending them to a remote endpoint?

This is possible with current technology: $(document).keypress(sendKeypressInfo)

$(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.

Hmm, we are not talking about web page js here, we are talking about Chrome API js here. It's far more powerful.

Won't the Same Origin Policy limit the exposure via ajax?

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

Hopefully DataConnections will also be used for video an audio so that encrypted connections can be used.

(Just so you don't copy my mistake, I was incorrect when I called them DataConnections, the term is DataChannel.)

They already are. But sure, you could do that if you wanted.

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

Yeah, let's start calling it web 4.0 now. Truly exciting stuff.

Reply on news.ycombinator.com