Hello,
My name is Danilo Carvalho, I am from ITA, Brazil, and I'm thinking about enabling flash proxy to use WebRTC, specially Data Channels, to connect between the client and the flash proxy. Some of the benefits involved would be:
1 - Flash proxies now would be able to receive incoming connections, this would remove the current need for the flash proxy to connect to the client. With the client being able to connect to the flash proxy, ticket(
https://trac.torproject.org/projects/tor/ticket/5426) would be solved. If the client is the one controlling the connection, it wouldn't be needed for the flash proxy to guess his usage time.
2 - We could use the built in resources of the WebRTC to do nat traversal, through ICE and STUN servers. Although it isn't quite right to use public, company-owned ICE and STUN servers for that, we could build that functionality into the flash proxy, allowing the ones that are not behind nat to work as STUN and ICE servers for the others. Also, with the WebRTC already in use, it would be easy to port to NAT-PMP or UPnP, with I believe will be integrated into it in the future.
Now, on the regards of how well spread WebRTC is, it's already built into Firefox and Chrome, and they both interoperate(
http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html).
On how much work it would demand: Some work would be required to enable the use of WebRTC in the _javascript_ part of the flash proxy, and probably some parts will require rewriting, since the flash proxy will not operate in the same way anymore. The client plugin will need big changes, since it will need to connect via Data Channels, that is not trivial(
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-04#section-1), and most of the controlling would be done there. On the facilitator part, I believe only minor parts will require change, mostly to handle the flash proxy address giveaway(It should be controlled in some way, else an attacker could keep polling enough address to know the majority of them).