Hi all,
After working through the code with Tim for a few hours this afternoon, the TorBlock extension has been enabled on Wikimedia.
The TorBlock extension will override local IP blocks to provide a consistent treatment of tor. Currently, this involves allowing only logged-in users to edit, and requiring tor users to have 100 edits, and a 90-day-old account, prior to being autoconfirmed.
Hopefully, this will provide a balance between allowing users to edit through tor without the difficult process of granting per-wiki IP block exemptions, and preventing pagemove vandals (such as the user known as 'Grawp' on English) from using Tor for vandalism and so on.
I haven't yet implemented this, but I am interested in the prospect of marking Tor users as such on either CheckUser, or (privacy policy depending) on Recent Changes.
2008/6/4 Andrew Garrett andrew@epstone.net:
I haven't yet implemented this, but I am interested in the prospect of marking Tor users as such on either CheckUser, or (privacy policy depending) on Recent Changes.
OH YES PLEASE.
You'll also get a *lot* of feedback from the checkusers on just how much abuse comes through Tor anyway.
- d.
^_^ Nice, a way to block tor. Sounds like a ToInstall on my own servers. There's absolutely no valid reason for anyone to use Tor to access my sites.
~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
Andrew Garrett wrote:
Hi all,
After working through the code with Tim for a few hours this afternoon, the TorBlock extension has been enabled on Wikimedia.
The TorBlock extension will override local IP blocks to provide a consistent treatment of tor. Currently, this involves allowing only logged-in users to edit, and requiring tor users to have 100 edits, and a 90-day-old account, prior to being autoconfirmed.
Hopefully, this will provide a balance between allowing users to edit through tor without the difficult process of granting per-wiki IP block exemptions, and preventing pagemove vandals (such as the user known as 'Grawp' on English) from using Tor for vandalism and so on.
I haven't yet implemented this, but I am interested in the prospect of marking Tor users as such on either CheckUser, or (privacy policy depending) on Recent Changes.
In practice, soft-blocking proxies is the same as not blocking them at all. On the CheckUser list there is considerable opposition to what appears to be a unilateral over-riding of both local and meta policy, creating a new policy that might work for a little edited wiki but would not be appropriate at all on wiki-en. I encourage the developers to ensure that this change has wide acceptance at the local level and support from the Foundation before implementing.
On Wed, Jun 4, 2008 at 6:03 PM, DanTMan dan_the_man@telus.net wrote:
^_^ Nice, a way to block tor. Sounds like a ToInstall on my own servers. There's absolutely no valid reason for anyone to use Tor to access my sites.
~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
Andrew Garrett wrote:
Hi all,
After working through the code with Tim for a few hours this afternoon, the TorBlock extension has been enabled on Wikimedia.
The TorBlock extension will override local IP blocks to provide a consistent treatment of tor. Currently, this involves allowing only logged-in users to edit, and requiring tor users to have 100 edits, and a 90-day-old account, prior to being autoconfirmed.
Hopefully, this will provide a balance between allowing users to edit through tor without the difficult process of granting per-wiki IP block exemptions, and preventing pagemove vandals (such as the user known as 'Grawp' on English) from using Tor for vandalism and so on.
I haven't yet implemented this, but I am interested in the prospect of marking Tor users as such on either CheckUser, or (privacy policy depending) on Recent Changes.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2008/6/4 jayjg jayjg99@gmail.com:
In practice, soft-blocking proxies is the same as not blocking them at all. On the CheckUser list there is considerable opposition to what appears to be a unilateral over-riding of both local and meta policy, creating a new policy that might work for a little edited wiki but would not be appropriate at all on wiki-en. I encourage the developers to ensure that this change has wide acceptance at the local level and support from the Foundation before implementing.
Seconded. Just blithely switching this on for en:wp is an astonishingly bad idea.
- d.
On Thu, Jun 5, 2008 at 8:17 AM, jayjg jayjg99@gmail.com wrote:
In practice, soft-blocking proxies is the same as not blocking them at all.
My understanding is that the primary problem with tor is page-move vandals such as the user known as 'Grawp'. These were the main objections to the extension that came from my discussions with CheckUsers and stewards. In response to this, I implemented the additional restrictions on tor users becoming autoconfirmed. A number of CheckUsers were happy with this compromise, but apparently, I didn't speak to enough of them.
On the CheckUser list there is considerable opposition to what appears to be a unilateral over-riding of both local and meta policy, creating a new policy that might work for a little edited wiki but would not be appropriate at all on wiki-en. I encourage the developers to ensure that this change has wide acceptance at the local level and support from the Foundation before implementing.
Of course, the extension can always be disabled for further development, but I do encourage those who oppose the use of this extension to think about alternative treatment of tor by the software (similar to the expanded autoconfirm limits), rather than simply hard-blocking tor.
2008/6/5 Andrew Garrett andrew@epstone.net:
On Thu, Jun 5, 2008 at 8:17 AM, jayjg jayjg99@gmail.com wrote:
In practice, soft-blocking proxies is the same as not blocking them at all.
My understanding is that the primary problem with tor is page-move vandals such as the user known as 'Grawp'. These were the main objections to the extension that came from my discussions with CheckUsers and stewards. In response to this, I implemented the additional restrictions on tor users becoming autoconfirmed. A number of CheckUsers were happy with this compromise, but apparently, I didn't speak to enough of them.
Almost all of what comes through Tor on en:wp is vandalism, sockpuppetry and rubbish.
Of course, the extension can always be disabled for further development, but I do encourage those who oppose the use of this extension to think about alternative treatment of tor by the software (similar to the expanded autoconfirm limits), rather than simply hard-blocking tor.
You're speaking to people who've been there and done that.
In practice, soft-blocking Tor is equivalent to not blocking at all. I've looked. Have you?
- d.
On Thu, Jun 5, 2008 at 9:10 AM, David Gerard dgerard@gmail.com wrote:
2008/6/5 Andrew Garrett andrew@epstone.net:
Of course, the extension can always be disabled for further development, but I do encourage those who oppose the use of this extension to think about alternative treatment of tor by the software (similar to the expanded autoconfirm limits), rather than simply hard-blocking tor.
You're speaking to people who've been there and done that.
In practice, soft-blocking Tor is equivalent to not blocking at all. I've looked. Have you?
I'm not suggesting a plain soft-block. I'm suggesting special treatment. For instance, we can handle sockpuppetry by marking edits made through tor as such in recent changes. When users have their edits revealed as made through tor, they'll go back to their open proxy farms which aren't as easily identified. I'm not sure how we sit with this in terms of the privacy policy, however.
On Wed, Jun 4, 2008 at 7:21 PM, Andrew Garrett andrew@epstone.net wrote:
I'm not suggesting a plain soft-block. I'm suggesting special treatment. For instance, we can handle sockpuppetry by marking edits made through tor as such in recent changes. When users have their edits revealed as made through tor, they'll go back to their open proxy farms which aren't as easily identified. I'm not sure how we sit with this in terms of the privacy policy, however.
The privacy policy only restricts the dissemination of information that could be used to identify an editor. The mere fact that someone is editing using Tor provides no such information. Indeed, posting the IP address of the exit node wouldn't be a privacy problem. That's the whole point of Tor, after all. :)
2008/6/5 Simetrical Simetrical+wikilist@gmail.com:
The privacy policy only restricts the dissemination of information that could be used to identify an editor. The mere fact that someone is editing using Tor provides no such information. Indeed, posting the IP address of the exit node wouldn't be a privacy problem. That's the whole point of Tor, after all. :)
The mere fact that someone has been using Tor has, in practice, been a MAJOR drama magnet on en:wp [*] and has scuppered RFAs, produced a presumption of malice, etc. It may not technically fall afoul of the privacy policy, but it's something people using it may reasonably not wish known about them, if Tor editing is allowed.
[*] not that en:wp needs much of an excuse for drama
- d.
What is the current set of things you can restrict to? Configurable? What about setting up the TorBlock extension, similar to the ConfirmEdit extension (well, maybe a larger list of things that can be restricted). Basically, so that rather than making it part of the extension, we can configure what rights or abilities we want the TorBlock extension to revoke. [Link adding, group rights (edit, move, or even view in the most restrictive way), edit patterns matching a regex, talkpage editing, etc...] and also give a flag to higher groups like sysop that disables the Tor soft blocking. Then TorBlock can be enabled, and individual communities can decide what type of bad actions are coming in from Tor to their wiki, and have those actions disabled. A semi-permissive community could even generally block edits from Tor users, but permit them to edit talkpages to request edits or moves. Like with the ConfirmEdit extension, the regex is quite useful. I actually have /^\s*$/ which generates a captcha when someone tries to blank an article. Rather than removing editing, that kind of thing could be used to prevent page blanking coming from Tor users. If tor is used to pagemove vandalize, then remove move permissions for tor users. If tor users mass vandalize pages, then remove edit permissions, but allow them to edit talkpages, or just require autoconfirmed. If they linkspam, restrict the ability to edit when adding links.
~Daniel Friesen(Dantman) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
Andrew Garrett wrote:
On Thu, Jun 5, 2008 at 8:17 AM, jayjg jayjg99@gmail.com wrote:
In practice, soft-blocking proxies is the same as not blocking them at all.
My understanding is that the primary problem with tor is page-move vandals such as the user known as 'Grawp'. These were the main objections to the extension that came from my discussions with CheckUsers and stewards. In response to this, I implemented the additional restrictions on tor users becoming autoconfirmed. A number of CheckUsers were happy with this compromise, but apparently, I didn't speak to enough of them.
On the CheckUser list there is considerable opposition to what appears to be a unilateral over-riding of both local and meta policy, creating a new policy that might work for a little edited wiki but would not be appropriate at all on wiki-en. I encourage the developers to ensure that this change has wide acceptance at the local level and support from the Foundation before implementing.
Of course, the extension can always be disabled for further development, but I do encourage those who oppose the use of this extension to think about alternative treatment of tor by the software (similar to the expanded autoconfirm limits), rather than simply hard-blocking tor.
Andrew Garrett wrote:
The TorBlock extension will override local IP blocks to provide a consistent treatment of tor.
I've disabled this behaviour for now, so that we can have a more orderly phase-in period with community discussion. Admin blocks of Tor exit nodes will continue to work. The new protections which have been introduced will also work, and so Tor anonymous users on the English Wikipedia will typically see two block messages.
-- Tim Starling
2008/6/5 Tim Starling tstarling@wikimedia.org:
Andrew Garrett wrote:
The TorBlock extension will override local IP blocks to provide a consistent treatment of tor.
I've disabled this behaviour for now, so that we can have a more orderly phase-in period with community discussion. Admin blocks of Tor exit nodes will continue to work. The new protections which have been introduced will also work, and so Tor anonymous users on the English Wikipedia will typically see two block messages.
Thanks for holding off on this :-)
I've asked the other checkusers concerned about this to post useful information to wikitech-l about what we actually see in practice on en:wp (buckets of toxic waste through Tor, the fabulously illustrative case of Runcorn concerning softblocks, etc), so as to supply the devs with good info.
- d.
wikitech-l@lists.wikimedia.org