Delivery-Date: Tue, 09 Sep 2014 07:45:18 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 2A4761E0A8F;
	Tue,  9 Sep 2014 07:45:17 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 163832F97B;
	Tue,  9 Sep 2014 11:45:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 1922D2F97B
 for <tor-talk@lists.torproject.org>; Tue,  9 Sep 2014 11:45:11 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5O5kyxJAkadd for <tor-talk@lists.torproject.org>;
 Tue,  9 Sep 2014 11:45:11 +0000 (UTC)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com
 [IPv6:2a00:1450:400c:c05::230])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id BB2652F9E5
 for <tor-talk@lists.torproject.org>; Tue,  9 Sep 2014 11:45:10 +0000 (UTC)
Received: by mail-wi0-f176.google.com with SMTP id bs8so4272718wib.15
 for <tor-talk@lists.torproject.org>; Tue, 09 Sep 2014 04:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
 bh=LhZc8zbvoUh+tkzogNyGxepDvKEbMq3iSB1waBtEWtA=;
 b=QsyGUoJNOTfA5KfZxP52bfB2XnTcJY38EtDXxjyn38fhwz9LQErbh0QjHQMMRLfIO5
 IOKzwgwaiKiwCzWkn7p6nlvp/38kzUhjL1SyixeZujPXcl9CG7BXuw1r5PjLuvHG4noe
 ssUAMEM817gkQjqERSxTazIwBBF9ajrVed8/0zYKO0YDqXnVBKG3Xa8v7SXfVhF1/mGa
 WHekwkAr+Oe+MXknanFeFD8N93w2wO/2+nrruFmpHqZmaQ4BRH/BrODRuSgcrYlbvzP9
 t7eL8gq9zZp0xPrPL6wkLGPTq3rG9SbUrUFm9rUi4SsO/85iTAWSiLB9lappoc5ifg9k
 ItlQ==
X-Received: by 10.194.77.212 with SMTP id u20mr42571851wjw.27.1410263107758;
 Tue, 09 Sep 2014 04:45:07 -0700 (PDT)
Received: from [192.168.1.11] (ANice-652-1-394-243.w86-203.abo.wanadoo.fr.
 [86.203.249.243])
 by mx.google.com with ESMTPSA id k5sm15156815wiv.21.2014.09.09.04.45.06
 for <tor-talk@lists.torproject.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 09 Sep 2014 04:45:07 -0700 (PDT)
Message-ID: <540EE84E.9060908@gmail.com>
Date: Tue, 09 Sep 2014 13:45:18 +0200
From: Aymeric Vitte <vitteaymeric@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20140909000553.GN8132@moria.seul.org>
In-Reply-To: <20140909000553.GN8132@moria.seul.org>
Subject: Re: [tor-talk] What should our 31c3 talk be?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


Le 09/09/2014 02:05, Roger Dingledine a =E9crit :
> 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/Plugg=
ableTransports/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@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

