[tor-talk] What should our 31c3 talk be?

Aymeric Vitte vitteaymeric at gmail.com
Tue Sep 9 11:45:18 UTC 2014


Le 09/09/2014 02:05, Roger Dingledine a écrit :
> 1) An update on pluggable transports: obfs3, obfs4, FTE, librtc and
> uproxy, and other acronyms you don't recognize. Many transports are now
> integrated into the default Tor Browser, we're starting to get some more
> useful usage statistics, and pluggable transports have played an important
> role in various countries in recent years. Plus we're soon going to start
> some projects on evaluation and comparison of transport designs, e.g.
> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorS/PluggableTransports/Proposal
>
> One of the most intriguing pieces of pluggable transports lately is
> the convergence of "make it hard to DPI for the protocol so the censor
> can't block it" with "make it hard to DPI for the protocol so the global
> surveillance adversary doesn't know to add that flow to its database".
> In particular, systems like Flashproxy might be especially effective
> against the global surveillance adversary, since the many transient
> addresses that separate the users from the known Tor relay addresses
> make it harder to build a list of users that are worth watching.

Of what exists today, from my standpoint flashproxies and meek [1] are 
the most disruptive/interesting, and probably easy to sketch to a non 
technical audience.

Of what will exist, maybe CloudTransport as mentioned in another post, 
and freedom.js-like solutions.

What is librtc? I did not find anything about it.

As far as I understand, with freedom.js browsers can only communicate 
one way with the backend processes, they can not be triggered unless 
they implement themselves a backend process or unless they maintain 
continuously connections with backend processes, which seems unlikely, 
or unless there is a facilitator to do such like with flashproxy.

That's why I still think there is room for a WebRTC solution where we 
have local clients running a headless browser (chrome app, knowing that 
Tor public might not be enclined to use a chrome-based app) or a node.js 
(node-webrtc, node-webkit) solution, or another one supporting WebRTC, 
acting as a Tor node and discussing with browsers to relay the traffic 
and/or act as other Tor nodes (which is very exactly what 
Peersm/node-Tor is doing), the context is different but this is similar 
to what is being discussed in [2].

[1] https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart
[2] https://github.com/feross/webtorrent/issues/39#issuecomment-45715318

-- 
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms



More information about the tor-talk mailing list