[tor-relays] new relays

[grarpamp]

>> This is why we need to implement extended exit flags for exits that want
>> to run post-exit filtering/enhancement policies, say for example
>>   "noporn"
>> that way we can get all the religious groups dumping their tithes into
>> not just beaming reruns of the 700 club around the world, but a pile of
>> uber fast exits too.
>
> What a disastrous notion; the exit policy system works because clients can
> predict in advance whether an exit will pass a given connection; it depends
> only on the destination host/port.

It works because clients can reject some exits they figure they shouldn't
waste their time on trying and can proceed trying matching ones. And
because the matching ones have historically not been much problem.
Predicting the future behavior of exits based on their past, or their current
statements, is an odds game some wouldn't put much faith in.


> That could never be the case for any of these.

As with dest ip:port, clients could similarly manage exits based on their
postfilter flags.

It could work for various purposes but it was more meant ...

>> And how about
>>  "novirus" delivered by microsoft
>>  "doublesyourcoins" propped up by the donations of fools
>>  "trusted" run by legit governments
>
> Oh, please, do tell where you expect to find a 'legit' government and why
> one should 'trust' it?

 ... "forthelols" ...
which would replace all web pages with (re-read as humor) proposals
like this when tor-*@ is busy being too serious, flips the occaisional
bird to each other in threads, etc ;)


Hopefully all the plaintext protocols will die soon and some replacement
for the CA cert model is agreed upon so that there isn't much left to bet
on exitwise but the dest ip:port working.