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

[Mike Perry]

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