Bittorrent

[slush]

>
>     Well, that's what exit policies are for.  As far as relay traffic goes,
> the more traffic my relay handles, the more useful my relay seems to be and
> the better it makes me feel about running a relay.
>

Well, me to.


>      As has been discussed to death here many times already, there is no
> way to inspect traffic prior to its exit without destroying the functional
> protections of tor.


Disagree. I wrote _port_ oriented QoS, not _content_.  There can be config
option to prioritize some port (port range) above other. Just because
somebody want to support HTTP transfer than other, but he dont want to fully
stop other services (torrents).

Simply I imagine that in same style like ExitPolicy. Did you ask others, why
are they using ExitPolicies? I dont think so. It is part of Tor and nobody
(as far as I know) is against - because it is free choice of relay operator
which kind of traffic he will support.

I know it is "barrelhouse talk". Im just talking it, because dont know, if
it was debated before. Unfortunately, it is long time ago, when I was able
to handle C code on sufficient level. So I cannot show any prototype of my
idea. Maybe it could be done by priorities on transparent proxy behind tor
exit. But is is ugly hack and non system solution.

> destroying the functional protections of tor.

What do you mean by it in discussed situation? I think priorities are not
against security and anonymity.


> if you like, but you cannot even know whether you are relaying Bittorent
> traffic inside the tor network, so you may as well ignore and forget the
> idea and get on with enjoying your life. :-)


Thank you, you are so gracious :-).

Marek

P.S. Please dont get irritated by my English, Im really doing my best ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090218/893bae03/attachment.htm>