Delivery-Date: Thu, 03 Jul 2014 04:26:49 -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 D0FB91E09F5
	for <archiver@seul.org>; Thu,  3 Jul 2014 04:26:47 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 756ED29C66;
	Thu,  3 Jul 2014 08:26:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4B07E27A13
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 08:19:02 +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 mz_NK4-KSw_v for <tor-talk@lists.torproject.org>;
 Thu,  3 Jul 2014 08:19:02 +0000 (UTC)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com
 [IPv6:2a00:1450:400c:c00::234])
 (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 F22D42707C
 for <tor-talk@lists.torproject.org>; Thu,  3 Jul 2014 08:19:01 +0000 (UTC)
Received: by mail-wg0-f52.google.com with SMTP id b13so318083wgh.23
 for <tor-talk@lists.torproject.org>; Thu, 03 Jul 2014 01:18:59 -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=vs/9U9jq68p7+OZTqusNNU8y3DjeF4hwpSArW97t4rA=;
 b=kRDdz2+EF0d5OdDfgbUVT867TZWkisDSh2fwsHWSaINoJ7BlJCT6GWlUDlFG2bpNPW
 /BvjvLpE+sSDFKb0ZmukpaJk4hoZ6EZQXItGOrFATBlvfbee+ZP/cRmKVCcL+1DuJica
 4aK4DxRk53sVmCnyewzIo5AUQpeXk6B6KFu70YjDFMpm4OuwUeG49t67lJBnv8Qmy6sd
 Q4ZR9e79mzaM+xTP43IkZGllY1A5qmUgBdSK68KsFa0P7XP8nydkSs4ca4g+eoN0zqqZ
 6g0jmvI+azngCW3ZXRo3ZGV7Eg7Qk8TpZvj8j4To1jo3l41HlMnanBjN8diGkWhkclHm
 ntkw==
X-Received: by 10.180.76.132 with SMTP id k4mr9420989wiw.1.1404375538465;
 Thu, 03 Jul 2014 01:18:58 -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 gc5sm64452995wic.6.2014.07.03.01.18.57
 for <tor-talk@lists.torproject.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Thu, 03 Jul 2014 01:18:57 -0700 (PDT)
Message-ID: <53B511EB.2020104@gmail.com>
Date: Thu, 03 Jul 2014 10:18:52 +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>
 <CAD2Ti2_L++oBpNgb4ga8qYE6yKqx4KSGoGJTP5nKUfhJKU-_dA@mail.gmail.com>
In-Reply-To: <CAD2Ti2_L++oBpNgb4ga8qYE6yKqx4KSGoGJTP5nKUfhJKU-_dA@mail.gmail.com>
Subject: Re: [tor-talk] High-latency hidden services (was: Re: Secure Hidden
 Service
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>

Maybe one day, something like Peersm combined with [1] in order to =

follow/or use [2] and [3] (don't focus on google developing this here, =

these concepts are the only way to really secure a web page)

Basically you fetch the web page with something like Peersm, then =

retarget it in a sandboxed context (sandboxed window like Caja or =

node-dom inside browsers can do), so the website appears inside your =

browser like a standalone widget/gadget (and certainly not an iframe) =

and then you parse the links and fetch the resources with the same =

techno used by Peersm (ie Tor protocol inside the browser).

Once you have captured the initial web page, you can do all this offline =

and queue the fetching.

This must work without hacking inside the browser, unfortunately you can =

not easily say to the browser "fetch everything using 'my secure function'".

It's very difficult to do but not impossible and some advanced features =

will not work due to the same origin policy but that's not an issue for =

the intended use.

Coming back to the origin of this thread, it's more easy to use Peersm =

as it is and have some kind of distributed P2P hidden services with =

difficult end to end corelation possibilities, even if we don't advise =

to use it to do strange things.

[1] https://github.com/Ayms/node-dom
[2] https://code.google.com/p/google-caja/wiki/SES
[3] =

http://static.googleusercontent.com/external_content/untrusted_dlcp/researc=
h.google.com/en//pubs/archive/37199.pdf

Le 03/07/2014 07:04, grarpamp a =E9crit :
> On Wed, Jul 2, 2014 at 7:18 PM, Helder Ribeiro <helder@discor.de> wrote:
>> On Sun, Jun 29, 2014 at 9:58 PM, Seth David Schoen <schoen@eff.org> wrot=
e:
>>> Then a question is whether users would want to use a service that takes,
>>> say, several hours to act on or answer their queries (and whether the
>>> amount of padding data required to thwart end-to-end traffic analysis
>>> is acceptable).
> I probably missed some context in thread. Link padding doesn't imply
> or have a tie to high[er] latency (other than minimal processing overhead=
).
> It's just the usual committed bandwidth, but always full, with wheat,
> or backed by chaff when there's not enough wheat to fill it.
>
>> High-latency web browsing is actually a great use case and could
>> benefit from the extra security.
>>
>> Apps like Pocket (http://getpocket.com/) work as a "read it later"
>> queue, downloading things for offline reading.
> I think it was Freenet where 'web' (page/browsing) was modeled
> as a non-real-time-interactive, retrievable (and updateable) object.
> Essentially documents. But were delivered in real time over the net.
>
> Torrents seem similar... queing, updatable, latency tolerant. Though
> there's no 'hours' delay storage buffer nodes between actual source
> and sink either.
>
> Besides mail mixes, what systems use such formal buffers in between?

-- =

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

