[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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




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

--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk