This is what I was looking for. Thanks! On Mon, May 8, 2023, 4:56 PM Mike Perry <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
