> 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
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
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
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 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
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
