On 08.12.2016 23:39, Alec Muffett wrote:
> For general interest (perhaps to Juha, especially?):
>
> * I am building a 6-node, 24-core cluster, specifically to run an
> Onion-traffic-serving experiment upon.
>
> * It's running a Debian variant - so the results/learnings should be
> generally applic
On 8 December 2016 at 20:09, scfith riseup wrote:
> Thanks for the correction on that. My other two points still valid in
> general?
Recapping:
>Second, if you do list .onion domains, know that they will be collected.
Well, yes, onion addresses are like any other form of network address.
Pe
Thanks for the correction on that. My other two points still valid in general?
> On Dec 8, 2016, at 3:01 PM, Roger Dingledine wrote:
>
> On Thu, Dec 08, 2016 at 02:06:30PM -0500, scfith riseup wrote:
>> First, not sure why you want to list .onion domains. The key here is that
>> they are HIDDEN
On Thu, Dec 08, 2016 at 02:06:30PM -0500, scfith riseup wrote:
> First, not sure why you want to list .onion domains. The key here is that
> they are HIDDEN services. But I am sure you have reasons.
Actually, that's part of the reason for the shift into calling them
"onion services" -- many peopl
First, not sure why you want to list .onion domains. The key here is that they
are HIDDEN services. But I am sure you have reasons.
Second, if you do list .onion domains, know that they will be collected.
Third, provide a simple path of machine-readable content to download so that
bots won’t ki
> This sequence of events got me thinking; the exit node queries servers on
> the behalf of the Tor Browser. Some sites simply cannot be connected to via
> HTTPS. Thus, the exit node must query the site requested in HTTP, which can
> be modified in transit. If done, what form of protections could a
