[tor-dev] Hacks to reduce Tor's initial download on slow Internet, sacrificing privacy?

[Holmes Wilson]

This is what I was looking for. Thanks!

On Mon, May 8, 2023, 4:56 PM Mike Perry <mikeperry at torproject.org> wrote:

>
>
> On 5/3/23 17:24, Holmes Wilson wrote:
> > Hi everyone,
> >
> > Is there a way right now to get Tor hidden service functionality
> > (hosting a hidden service, connecting to hidden services) on a
> > connection where the Internet is so slow and unreliable that the initial
> > download of network information currently takes ~forever, provided one
> > is willing to sacrifice metadata protection?
> >
> > Is there a way to download, say, 100x less network information on
> > startup and still effectively host and connect to hidden services? Or is
> > there a way to hardcode network information with the client, since that
> > can be installed before going into the slow Internet zone, from a CDN
> > that is less impacted, or from a source on the local network? (I read
> > that this is how Tor worked in the past?)
> >
> > The context is the following:
> >
> > I have a p2p messaging app that uses Tor and hidden services (Quiet) in
> > a way similar to Ricochet or Onionshare. I'm going to a conference where
> > last year the Internet was so slow that Tor's initial download of
> > network information took too long and kept timing out, rendering Quiet
> > unusable. The Internet was, however, fairly reliable and usable for e.g.
> > web browsing and messaging. I'd like to be able to use Quiet at this
> > conference. It would be used purely as a demo for a few days, and we
> > could warn everyone that our use of Tor did not offer its typical
> > security properties. (Then in future years we might support p2p
> > connectivity over local wifi, like Briar does!)
> >
> > My understanding is that the network information download step is to
> > protect users against epistemic attacks. My intuition is that for
> > situations where this doesn't matter there is some way to use Tor with a
> > small subset of the network information and that the initial download
> > could be skipped.
> >
> > Is this true? What's the best way to do it in the Tor client we ship?
>
> If you include a Tor data directory with a fresh set of the cached
> microdesc consensus and microdesc descriptor documents in your app
> distribution, and *also* hack REASONABLY_LIVE_TIME in
> src/feature/nodelist/networkstatus.c to be as long as you expect that
> release to be published, I think this gets you what you want.
>
> The default is 24 hours, which means that clients will accept these
> cached documents for up to 24 hours as valid, before blocking everything
> to download a new one.
>
> So you can hack this value to be much higher (at the cost of increased
> risk to clients from being fed a stale consensus continually), and
> refresh your download files to include new documents, once per time window.
>
> I think this will work, but I would not be surprised if you hit a few
> other "safety" checks that are elsewhere in the codebase, other than
> that #define, that you also have to change.
>
> > (I'm familiar with the Walking Onions paper, but looking for something
> > that is ready now. There isn't already an implementation of Walking
> > Onions, is there?)
>
> No. Also arti-relay impl will mean fewer relays in the consensus,
> because of multicore support. It will also probably mean better
> consensus diff support. But that isn't done either.
>
>
> --
> Mike Perry
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20230508/ddd26af9/attachment.htm>