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