On Mon, Jun 9, 2008 at 6:08 AM, David Gerard dgerard@gmail.com wrote:
Yes, you are quite right that only the pro-TOR side of the picture was considered in implementing this extension.
Certainly, I see quite significant benefit in tor - more than most do. However, I strongly object to your insinuation that my extension was not written with the best interests of the Wikimedia projects at heart.
The extension was not written for the tor people (although they were quite happy when I spoke to them of my plans - as I needed their technical co-operation to produce the list in software), and I reject any insinuation that I am somehow writing code to benefit tor, rather than the foundation.
I saw a problem - in this case, the fact that tor is now blocked using a hodgepodge of blocks by various bots, scripts, and people, many of which are no longer tor nodes, and many tor nodes are not blocked. It is suboptimal that tor nodes are hard-blocked, and it was my impression (perhaps mistaken?) that the general consensus is that while we are loathe to hard-block tor, we are forced to do it by the amount of nonsense that comes through it.
I recognised that a solution was possible - in-software handling of tor exit nodes. I realised that I could kill two birds with one stone here - both standardise the treatment of Tor by Wikimedia wikis, AND remove the hard-blocks on Wikimedia wikis by instituting some kind of special treatment of tor, which balances the needs of individuals who require privacy, and Wikipedia as a whole, which needs to have this sort of nonsense removed.
I must note that those checkusers who indicated that most of what comes through tor is nonsense have the sample they're working with skewed - they will only ever see the bad tor nodes, because (I hope) they don't go running checkusers on random users to see if they're using tor. I would imagine that we get quite a considerable amount of good editing from tor, which goes unnoticed because we have some semblance of a privacy policy.
Evidently, this is a situation requiring compromise, and I would like to see some suggested compromises from those who still maintain that hard-blocks are the only option. Remember that this is being implemented in software (something FT2 indicated that he had not realised), and therefore the sky's the limit. ANY special technical handling of tor nodes is possible. Here are a few ideas to get started: * A special page listing all recent tor users/contributions/edits. * Special marking in recentchanges, checkuser, contribs, diff pages. * Allow disabling tor per-page or per-user. * Allow temporary disabling of tor site-wide with good cause (through a special page). * Require a user to be autoconfirmed before using tor (causes a catch-22 situation, though).
As I've stated before, ipblock-exempt or a similar process will be ineffective unless torblock-unblocked is granted liberally, as a catch-22 situation is produced.