Delivery-Date: Fri, 04 Jul 2014 06:58:22 -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 E6B4A1E08C6
	for <archiver@seul.org>; Fri,  4 Jul 2014 06:58:18 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id DAA4B2F557;
	Fri,  4 Jul 2014 10:58:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0E3532CEF5
 for <tor-talk@lists.torproject.org>; Fri,  4 Jul 2014 10:52:40 +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 QqHEZyXAoC46 for <tor-talk@lists.torproject.org>;
 Fri,  4 Jul 2014 10:52:39 +0000 (UTC)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com
 [IPv6:2a00:1450:400c:c03::22a])
 (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 BFB6D2A09F
 for <tor-talk@lists.torproject.org>; Fri,  4 Jul 2014 10:52:39 +0000 (UTC)
Received: by mail-we0-f170.google.com with SMTP id w61so1505142wes.15
 for <tor-talk@lists.torproject.org>; Fri, 04 Jul 2014 03:52:36 -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=cg2AVAVSGeD7h1lHRYBgbLtRLzH86lpG47BMCT7OORk=;
 b=cZ3YGmb7BlEwFeeK97pEILpdhgijD/lKahAnOxKj/l2b8lqpWevYx6qxhTDiSsT6lO
 WbulUBM+6bVpU4BTWaJHHctoeEcfPzpnAcrOmTEQzw4+EfPflJaks/TaFa1cn3r5v2u9
 5StlBphOMx8GkxYC9/wT6h+X9Ajx3tKM2Ha53lgfkyeaga+9QTwP+ZR2ZVFzzcuVAoCa
 ki/+9sqYRF0qFEeVDeGfwnbGksak7zoWDWREMP5k8GhuASlbTqhXkbMgGJEPHDMy5Tq2
 xLMWfBlaNgM+pbAtvvuiycizzCSr15xsyFlWPIZz1Qvf0AxZOh+dIcswgHPuG2dsiefn
 Hfkw==
X-Received: by 10.194.200.67 with SMTP id jq3mr2606198wjc.114.1404471156640;
 Fri, 04 Jul 2014 03:52:36 -0700 (PDT)
Received: from [192.168.1.11] (ANice-652-1-345-13.w83-201.abo.wanadoo.fr.
 [83.201.68.13])
 by mx.google.com with ESMTPSA id i3sm77870840wiz.13.2014.07.04.03.52.35
 for <tor-talk@lists.torproject.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 04 Jul 2014 03:52:35 -0700 (PDT)
Message-ID: <53B68773.1060409@gmail.com>
Date: Fri, 04 Jul 2014 12:52:35 +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: <53AB742E.5000400@riseup.net>
 <DUB121-W1602424B2673FF14097129C8180@phx.gbl> <53ABAAFA.1040406@riseup.net>
 <C21E9389-F7C9-47E7-B475-A3D23C8C4F14@hidemeta.com>
 <20140626073045.GA10980@inner.h.apk.li> <6334967458078911169@unknownmsgid>
 <CAP3fC8TUmMGFOnyXNRWzR30ynk_bxFod0_VwcKAtguDESi70Fg@mail.gmail.com>
 <53B5AE90.60405@virtadpt.net> <20140703221652.GP10613@sescenties.(null)>
 <53B603F7.1020803@riseup.net>
In-Reply-To: <53B603F7.1020803@riseup.net>
Subject: Re: [tor-talk] High-latency hidden services
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>

If I understand correctly the question here is not about browsing but =

fetching something that you don't need immediately for offline reading =

and that you download with high latency using different circuits.

That's easy to do, if you take Peersm again, it's easy to send several =

random requests to different circuits requesting part of the resource to =

the website and then store them asynchronously, you can request the =

pieces in the order you like and when you like, you can retrieve them =

from the website or the peers if they have it.

Le 04/07/2014 03:31, Mirimir a =E9crit :
> On 07/03/2014 04:16 PM, Seth David Schoen wrote:
>> The Doctor writes:
>>
>>> On 07/02/2014 04:18 PM, Helder Ribeiro wrote:
>>>
>>>> Apps like Pocket (http://getpocket.com/) work as a "read it later"
>>>> queue, downloading things for offline reading. While you're reading
>>>> an offline article, you can also follow links and click to add them
>>>> to your queue. They'll be fetched when you're online so you can
>>>> read them later.
>>> I've been using the Firefox extension called Scrapbook
>>> (https://addons.mozilla.org/en-US/firefox/addon/scrapbook/) for this
>>> for a while now.  I've done some experiments with it (packet sniffing
>>> at the firewall and on the machine in question), and from observation
>>> it seems sufficiently proxy-compliant that it routes all traffic in
>>> question through Tor when it downloads and stores a local copy of a
>>> page.  Secondary opinions are, of course, welcome and encouraged.
>> That's great, but in the context of this thread I would want to imagine
>> a future-generation version that does a much better job of hiding who
>> is downloading which pages -- by high-latency mixing, like an
>> anonymous remailer chain.
> One can imagine a browser extension that introduced random delay at each
> step of getting a page. Webservers tend to drop very slow clients, as
> defense against slow-loris DoS, so the extension would need to learn the
> limits for each site.
>
>> The existing Tor network can't directly support this use case very
>> well, except by acting as a transport.
> The ability to switch circuits during the process of getting a page
> would help greatly.
>
>> Right now, people who are using toolks like Pocket or Scrapbook over Tor
>> _aren't_ really getting the privacy benefits that in principle their
>> not-needing-to-read-it-right-this-second could be offering.  That is,
>> a global-enough adversary can sometimes notice that person X has just
>> downloaded item Y for offline reading.  There's no reason that the
>> adversary has to be able to do that.
>>

-- =

Peersm : http://www.peersm.com
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

