[tor-talk] High-latency hidden services (was: Re: Secure Hidden Service

[Aymeric Vitte]

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/research.google.com/en//pubs/archive/37199.pdf

Le 03/07/2014 07:04, grarpamp a écrit :
> On Wed, Jul 2, 2014 at 7:18 PM, Helder Ribeiro <helder at discor.de> wrote:
>> On Sun, Jun 29, 2014 at 9:58 PM, Seth David Schoen <schoen at eff.org> wrote:
>>> 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