[tor-bugs] #5578 [Flashproxy]: Investigate WebRTC for flash proxy NAT punching

[Tor Bug Tracker & Wiki]

#5578: Investigate WebRTC for flash proxy NAT punching
------------------------+---------------------------------------------------
 Reporter:  dcf         |          Owner:  dcf
     Type:  task        |         Status:  new
 Priority:  minor       |      Milestone:     
Component:  Flashproxy  |        Version:     
 Keywords:              |         Parent:     
   Points:              |   Actualpoints:     
------------------------+---------------------------------------------------

Comment(by cjb):

 I chatted with a friend who is a Google WebRTC developer (Ben Schwartz),
 and he had some good ideas and pointed out some problems that I hadn't
 thought of.

 The largest problem is how the client transport plugin is going to work,
 because there's not yet any headless WebRTC implementation; it's very
 attached to the DOM.  I'd been assuming that node.js will grow a library
 that speaks WebRTC across each of Firefox/Chrome/node with a common API --
 socket.io does this for websockets -- but the requirements for WebRTC are
 far greater.  Ideally you need a full libjingle port, and at the least you
 need ICE and SCTP.  Node currently doesn't have any SCTP support, as far
 as I can see.

 So our options include waiting for node to grow a lot of code that doesn't
 exist right now, or having the client transport plugin be written in C
 instead of node and linked with libjingle, or finding a way to avoid
 having a full client transport plugin.

 Ben's suggestion for avoiding a client transport plugin is that the plugin
 could be a SOCKS-style proxy that bounces the data back into the local
 browser through a websocket on the local machine, and some JavaScript in
 the browser handles brokering between the websocket and an outgoing WebRTC
 datachannel.

 Some interesting node projects:

 https://npmjs.org/package/peer-connection-shim
 https://github.com/rogerwang/node-webkit

 Current status of the browser-side code is that peerjs.com looks like the
 right thing for a common API, but it only supports Chrome rather than
 Firefox, and only Firefox has support for reliable transfers in
 datachannels.  So we're either waiting for Chrome to support reliable
 transfers, or PeerJS to support Firefox.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5578#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online