reconsidering default exit policy

Valient Gough vgough at pobox.com
Fri Mar 11 15:08:06 UTC 2005



Geoffrey Goodell wrote:
>>I might be a good idea to filter out multicast space, though. That's
>>224.0.0.0/4. And other "special use" spaces:
>>
>Your argument is that we can filter these without hurting the Tor
>network, and generally speaking you are probably right.  However, we
>should require POSITIVE reasons to filter, not NEGATIVE reasons not to
>filter.  There is a subtle difference.
>Tor should adopt the most liberal policy that avoids making the general
>population angry, not the most conservative policy that allows essential
>functionality to continue.
Both of your arguments are biased by a very different view then that of
a system administrator.  There are two target audiences here --
anonymous users and server administrators.  The policy choices which are
ideal for one group are probably not ideal for the other.

Once apon a time systems shipped with all services publically visible
and no firewalls, because if there was no known exploits (positive
reasons to filter), then they may as well be enabled.  That was
convenient from a user's view.  However as we all know by now, that
turned out to be bad from a server administrators point of view.

Consider you want to entice system admin A to host a tor server.  Sure,
you could tell him that this is a cool funky 90's retro service which
will proxy basically everything to everywhere unless he figures out how
to limit it down to reduce the blacklisting mail, server attacks, and
usenet spam reports he gets.  Although as an administrator I prefer to
see systems that come online with minimal necessary functionality and
then let you enable things from there as you become comfortable with them.

This default policy choice doesn't have to be set in stone.  As tor
becomes more stable and abuse-prone services (like google's usenet
proxy) figure out how to deal with anonymous access, then I suspect the
default policy can become less restrictive without causing more
frustration to a server administrator.

Valient

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20050311/029921de/attachment.pgp>


More information about the tor-talk mailing list