[tor-relays] [tor-dev] Hidden service policies

[Thomas White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Hearn,

Simple. If you start filtering anything at all, regardless of what it
is (yes, even if you filter child porn or fraud sites) then I will
block any connection of your relays to mine (which are exits and
guards totally 4Gbps). There are uses for preventing some connections
like if you are legally required to then I guess the tradeoff of some
inconvenience for a handful of relays, but still providing high-speed
access to Tor for most people and sites is worth it. When you begin to
do it as a proactive censorship event is when I will be firmly against
you.

The moment people censor things because it is illegal, immoral or
"terrorist" is the moment that person accepts responsibility for the
traffic that passes through their nodes and is an active attempt by
them to filter what people can access. Freedom isn't free unless it is
totally free and a selective reading policy through Tor is not just a
bad idea as stated below, I find it outright insulting to me and
everyone else who cares about the free and open internet. The fact
somebody has the audacity to come to a project like Tor and propose
blacklisting mechanisms is jaw-dropping.

In addition, botnets using Tor actually improve the security of the
network. Generally the more traffic there is, the harder it is to
conduct statistical attacks against the users. Now of course it is not
the most politic thing to say or the most popular, but it's the truth.
We don't need to stop x y or z using Tor, we need to get more people
using Tor regardless of their purpose. Botnets are the result of
design/security flaws and not something within the scope of Tor
Project to address.

You did mention the development of a workaround to avoid people who do
block whatever resource they are trying to access, but what is the
point? Once it is easy to start blocking hidden services like that,
it's only a very small step to blacklists floating around, then like
Spamhaus that list maintainer acts like a mafia to coerce other
operators into using it. Even in the wording of what you admitted
yourself, additional complexity, Tor should be spending time improving
it's systems and fixing bugs rather than making censorship easier for
the masses. This is one of the concerns I voiced in the Paris Tor
developer meeting only a few weeks ago too.

As I recall, you are also the person who raised the idea of coin
tinting or a similar concept in the bitcoin community to identify
"suspect" coins and that backfired spectacularly on you. Don't try to
bring such ideas to Tor because they are not the same and I doubt you
would try to propose blacklisting bitcoin addresses on the bitcoin
network? Then again, after reading that message, I honestly don't know
so while you are reading this, let me know if you run any relays so I
can avoid them. I could go on for a lot longer, but I'll leave it at
this for now or I will not be getting to sleep tonight. Just know I'd
rather go to prison than act as an assistant of censorship.

- -T

On 21/07/2014 00:38, grarpamp wrote:
> On Sun, Jul 20, 2014 at 6:34 PM, Mike Hearn <mike at plan99.net>
> wrote:
>> Hello,
>> 
>> As we know, hidden services can be useful for all kinds of
>> legitimate things (Pond's usage is particularly interesting),
>> however they do also sometimes get used by botnets and other
>> problematic things.
>> 
>> Tor provides exit policies to let exit relay operators restrict
>> traffic they consider to be unwanted or abusive. In this way a
>> kind of international group consensus emerges about what is and
>> is not acceptable usage of Tor. For instance, SMTP out is widely
>> restricted.
>> 
>> Has there been any discussion of implementing similar controls
>> for hidden services, where relays would refuse to act as
>> introduction points for hidden services that match certain
>> criteria e.g. have a particular key, or whose key appears in a
>> list downloaded occasionally via Tor itself. In this way relay
>> operators could avoid their resources being used for
>> establishing communication with botnet CnC servers.
>> 
>> Obviously such a scheme would require a protocol and client
>> upgrade to avoid nodes building circuits to relays that then
>> refuse to introduce.
>> 
>> The downside is additional complexity. The upside is potentially
>> recruiting new relay operators.
> 
> HS's will just change their HS keys out from under your list. Then
> it becomes whack a mole. And you'll also be taking out shared
> services with the bathwater. Are you funding maintenance of that
> list? Ready to be called a censor when you exceed your noble
> intent as all have done before? And to be ignored by those 
> operators who don't care to subscribe to your censor list thus
> nullifying your efforts (not least of why because it may be illegal
> for them to look at services on the list to verify it, or to look
> at and make decisions regarding content of traffic that transits
> them). And ignored by botnet ops who will surely run their own
> relays and internal pathing. 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJTzHNsAAoJEE2uQiaesOsLz88QAKKZpFZBEygrD2aq/l9hBzqz
9+9kf6/eFtt1O9gZiJJZgCKRvCegejU+mt/7MMOIEWOdhxYqIIEbDE4YXQG2x+UK
eNlnFHfFwhVqvCoMOJbQfBhRLCxDdzasAllDI7jw27d4AfZCxeeCkHYu/+hTqCEQ
QHIY/Ebph2zZStIXQWAzNItUmLmhrfSs2AHlsvLKTPxFpJvZEmYd4/dlp29FRFVy
BwLXTLcS+3ji3vx2xHLbxaC4n946EbD7RAr1RzkRdfH/DwSzxrdlM6inQTRW/SF8
1gUanQitZlettMFOUXqw5H0YapDJU+a9nzQm3qHByMaFBKO7zoxowC5JFU00x1yf
8OvPj2K8plW4Sr8zabZmUsT+G1+WhbNH1ANjFOgKdATh4wvBlM7+vjpGVU/7pmTJ
w6cJ9Dn3hPjWsFaxywsRZjGS2lP3Sq2JNl3BrX6HfJxHN5Fz/NL45XaxniyBxLQg
jIOkMiyrxZmrdYS8k5THHDrpUR3WMoXGEMpOI4hh5R8NekdrrtQar5785BsQmJTG
9lZKaXBSVa3uiGv+vLMZW1Qt+iqSX6q2SG07qULY7Ttd0wkIqH0wEb6CGG137Qv7
jwxkclmQqiVQH7RFVC2AY4ePEdhT74EbhzhubedhOuzd9YG4XjgO/h/RVJpl/Wsy
0cn4HvbqrSgiHVw4bQBY
=uhJR
-----END PGP SIGNATURE-----