[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Is "gatereloaded" a Bad Exit?



Thus spake morphium (morphium@xxxxxxxxxxxxx):

> > Do you have a rational reason why we should allow people to carry the
> > unencrypted version of a service but not the encrypted one, other than
> > "Well, they could be bad actors even with a good policy!"
> 
> As I stated above, it's not a good idea to BadExit them, because it
> puts more load on the servers, that DO support https i.e. - and makes
> them slower.
> Those weren't 10K/s Nodes you blacklisted there, they've been really
> fast Exit Nodes.
> And I don't see ANY point in BadExit'ing 5 "random" Nodes, suggesting
> that no one could capture your unencrypted traffic now.
> 
> This is just further slowing down the whole Tor-Network.

This is not true. The exit nodes in question account for ~6% of the
network Exit-flagged bandwidth. That is, *IF* they actually had the
Exit flag (they did not), they would have provided 6% of that
bandwidth. They do not have the Exit flag, however, so they provide
0%.

This allows me to explain another reason why I have no problem banning
these obviously malicilously (or in your case, irrationally) speced
nodes. They make our lives harder for load balancing.

We put a lot of work recently into trying to correct load balancing
bugs wrt to node flags over the years. The algorithms have been
through four revisions, the last two of which were mine:
http://archives.seul.org/or/dev/Jan-2010/msg00012.html
http://archives.seul.org/or/dev/Sep-2010/msg00016.html

These equations are still only an approximation. If you'll direct your
attention to ticket #2395, you'll see that we really need to
differentiate between bitorrent-supporting exit and exits using the
default policy vs the "reduced" exit policy:
https://trac.torproject.org/projects/tor/ticket/2395
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/ReducedExitPolicy

Having to further differentiate our load balancing weights for
lunatics who decide to exit to 80 but not 443 requires us to create
yet a third category of weights, unless we choose to ignore the 1-2%
of exit bandwidth that appears to exit over port 443 (though it's
hopefully rising, thanks to our efforts in developing+deploying
https://www.eff.org/https-everywhere/).

So when I said in my earlier post that we don't need exit capacity
that bad, I meant it. Thanks, but no thanks. You are contributing
negative productivity, and none of the non-bitorrenting exits really
will notice your absence in terms of load. Please direct yourself
towards the nearest forbidden lake.

But whatever. For your exit, it's not even worth the effort for a
badexit line. We'll get you in the next batch. Or if not that, in the
solution for #2395.

Now, back to development.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgpC4aVdsvGY8.pgp
Description: PGP signature