Re: wikipedia vandalism

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Jan 22, 2005 at 10:59:52PM +0100, Frank v Waveren wrote:
> I've just had to block all Tor outproxies that do port 80 from editing
> Wikipedia[1], due to repeated vandalism. Those of you who use
> wikipedia and edit articles from the same address they run a tor port
> 80 outproxy on will want to add 
>  
>  reject 207.142.131.0/255.255.255.0:*

Hi Frank,

I noticed
http://en.wikipedia.org/wiki/User_talk:Fvw#Banning_Tor_outproxies from
my referer log earlier today, so I've been looking a bit at Wikipedia
banning policies.

I took a brief look around the block policy at
http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy and the pointer
to the February 2004 thread about anonymizers, but I didn't see any
definitive answers to the thread on the list. (In fact, it seems you point
to http://mail.wikipedia.org/pipermail/wikien-l/2004-February/010637.html
which isn't even in the thread.) Could you summarize for us to reasons why
Wikipedia doesn't want to require users _from Tor IPs_ to create accounts
in order to edit pages?

We have the beginnings of some Abuse faq entries on
http://wiki.noreply.org/wiki/TheOnionRouter/TorFAQ#Abuse
but there's still plenty more to discuss there.

> I assume wikipedia isn't the only one with trouble in this regard
> though. Perhaps it would be a good idea to have filters for certain
> known protocols (like HTTP) you can put on their assigned ports that
> block certain actions, like POST requests. People could still enable
> POST if they really wanted (and get blocked from wikipedia and other
> sites), but it would make our lives much easier and also surprise
> fewer people with blocks from wikipedia and other sites (or worse,
> complaints to their ISP).

This is tricky to do from a technical standpoint, a) because we need to
teach Tor about protocols and how to reach into the application-layer
stream, and b) because Tor clients would need to predict what the
application was going to do before it does it, in order to pick an exit
node that will allow the operation. We'd like to consider implementing
something like this down the road but it seems hard to get right without
adding a lot of complexity (which is bad for security systems).

Thanks,
--Roger