Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

TorBlock extension enabled

 

 

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


andrew at epstone

Jun 4, 2008, 2:27 AM

Post #1 of 58 (1154 views)
Permalink
TorBlock extension enabled

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.

--
Andrew Garrett

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 4, 2008, 2:45 AM

Post #2 of 58 (1129 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/4 Andrew Garrett <andrew[at]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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dan_the_man at telus

Jun 4, 2008, 3:03 PM

Post #3 of 58 (1118 views)
Permalink
Re: TorBlock extension enabled [In reply to]

^_^ 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[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jayjg99 at gmail

Jun 4, 2008, 3:17 PM

Post #4 of 58 (1120 views)
Permalink
Re: TorBlock extension enabled [In reply to]

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[at]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[at]lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 4, 2008, 3:21 PM

Post #5 of 58 (1119 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/4 jayjg <jayjg99[at]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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andrew at epstone

Jun 4, 2008, 4:02 PM

Post #6 of 58 (1118 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Thu, Jun 5, 2008 at 8:17 AM, jayjg <jayjg99[at]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

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 4, 2008, 4:10 PM

Post #7 of 58 (1120 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 Andrew Garrett <andrew[at]epstone.net>:
> On Thu, Jun 5, 2008 at 8:17 AM, jayjg <jayjg99[at]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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andrew at epstone

Jun 4, 2008, 4:21 PM

Post #8 of 58 (1117 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Thu, Jun 5, 2008 at 9:10 AM, David Gerard <dgerard[at]gmail.com> wrote:
> 2008/6/5 Andrew Garrett <andrew[at]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.


--
Andrew Garrett

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jun 4, 2008, 4:36 PM

Post #9 of 58 (1112 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Wed, Jun 4, 2008 at 7:21 PM, Andrew Garrett <andrew[at]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. :)

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tstarling at wikimedia

Jun 4, 2008, 7:55 PM

Post #10 of 58 (1110 views)
Permalink
Re: TorBlock extension enabled [In reply to]

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


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dan_the_man at telus

Jun 5, 2008, 12:28 AM

Post #11 of 58 (1117 views)
Permalink
Re: TorBlock extension enabled [In reply to]

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[at]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.
>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 5, 2008, 5:50 AM

Post #12 of 58 (1104 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 Tim Starling <tstarling[at]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 mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 5, 2008, 5:56 AM

Post #13 of 58 (1100 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 Simetrical <Simetrical+wikilist[at]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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


thatcher131 at gmail

Jun 5, 2008, 9:49 AM

Post #14 of 58 (1102 views)
Permalink
Re: TorBlock extension enabled [In reply to]

>From: David Gerard <dgerard[at]gmail.com>
>Date: 2008/6/5
>Subject: Re: [Wikitech-l] TorBlock extension enabled
>To: Wikimedia developers <wikitech-l[at]lists.wikimedia.org>
>
>
>2008/6/5 Tim Starling <tstarling[at]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.

I don't have the records to do a statistically valid analysis of the
use of Tor by sockpuppets and vandals as compared to other types of
proxies. I'm sure that the new extension, which amounts to global
"firm" blocking of Tor exits (more than a soft block but less than a
hard block) will cut down on the use of Tor by casual or lazy vandals.

However, the firm block would not address the problem of determined
abusive users using proxies to conceal their activities. The two most
prominent cases that come to mind are Poetlister (whose sock Runcorn
downgraded blocks on Tor exits so that her other socks could use them)
and Mantanmoreland, who created a second account that exclusively used
proxies in order to avoid checkuser confirmation. Or see
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_checkuser/Case/Fantevd,
where a nominally good user with 6000 edits was found to be running a
sock farm via open proxies, ultimately involving 24 accounts with 3000
edits to

Both of these accounts caused significant disruption and drama.
Blocking all proxies that exit to Wikipedia could potentially prevent
similar future situations, but not if all the puppetmaster has to do
is to keep a low profile for 90 days.

And at least on enwiki, the "moral" reason for softblocking Tor exits
(to allow people to edit from repressive locations, etc) has been
voided by the enabling of the IP block exemption.

Gmaxwell correctly pointed out in an email to checkuser-L that if Tor
exits are hardblocked, smart puppetmasters will use other proxies.
True, but we can block those proxies. We *can't* block Tor exits, at
least if the override behavior is in place. In fact, with the
override enabled, the new extension will actually *encourage*
sockpuppeteers to use Tor, because it will guarantee they will always
be able to edit as long as they have the patience to wait for their
socks to be autoconfirmed. They will no longer run the risk of
enrolling in a commercial anonymizing service only to discover that we
have blocked it.

I think this extension is a great idea and I thank all the volunteers
who worked on it, but I think the override is a very bad idea.

Thatcher

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Jun 5, 2008, 1:33 PM

Post #15 of 58 (1101 views)
Permalink
Re: TorBlock extension enabled [In reply to]

Thatcher131 Wikipedia wrote:
> Gmaxwell correctly pointed out in an email to checkuser-L that if Tor
> exits are hardblocked, smart puppetmasters will use other proxies.
> True, but we can block those proxies. We *can't* block Tor exits, at
> least if the override behavior is in place. In fact, with the
> override enabled, the new extension will actually *encourage*
> sockpuppeteers to use Tor, because it will guarantee they will always
> be able to edit as long as they have the patience to wait for their
> socks to be autoconfirmed. They will no longer run the risk of
> enrolling in a commercial anonymizing service only to discover that we
> have blocked it.

Then it could be configured to perform a complete block for those wikis
which really want that (not as the default, although completely blocking
tor is tempting). It will still keep an updated Tor list, as opposed to
having half tor edits working or not, or running a bot as sysop each X
time to block exit nodes.
It might be a good idea to set a magic IP address, such as
255.255.255.tor whose blocks affected to any exit node in case of tor
vandalism.

Good work, Andrew. Nonetheless, i encourage you to rename $wgTorIPs.
It's counterintuitive, as $wgTorIPs aren't the Tor IPs but the server
ones! What about $wgTorExitsMediawikiIPs ?


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 5, 2008, 1:50 PM

Post #16 of 58 (1101 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 Platonides <Platonides[at]gmail.com>:

> Then it could be configured to perform a complete block for those wikis
> which really want that (not as the default, although completely blocking
> tor is tempting).


I fear that would be much-needed on en:wp. Tor edits have been less
and less tolerated as we discover how much rubbish comes through them.

Is there a way to allow exempt IPs to edit through Tor anyway?


> It will still keep an updated Tor list, as opposed to
> having half tor edits working or not, or running a bot as sysop each X
> time to block exit nodes.


Oh yesss :-)


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 5, 2008, 1:51 PM

Post #17 of 58 (1108 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 David Gerard <dgerard[at]gmail.com>:

> Is there a way to allow exempt IPs to edit through Tor anyway?


I mean exempt usernames (I believe sysops are presently immune to IP
blocks, for example).


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dan_the_man at telus

Jun 5, 2008, 2:42 PM

Post #18 of 58 (1104 views)
Permalink
Re: TorBlock extension enabled [In reply to]

You could always create a ipblockexempt flag linked to the permission
and give that out when a Tor user with a valid reason shows up.

~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)

David Gerard wrote:
> 2008/6/5 David Gerard <dgerard[at]gmail.com>:
>
>
>> Is there a way to allow exempt IPs to edit through Tor anyway?
>>
>
>
> I mean exempt usernames (I believe sysops are presently immune to IP
> blocks, for example).
>
>
> - d.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l[at]lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Jun 5, 2008, 2:48 PM

Post #19 of 58 (1103 views)
Permalink
Re: TorBlock extension enabled [In reply to]

David Gerard wrote:
>> Is there a way to allow exempt IPs to edit through Tor anyway?
>
> I mean exempt usernames (I believe sysops are presently immune to IP
> blocks, for example).
>
> - d.

Yes, the permissions at wgTorBypassPermissions allow bypassing it, so i
suppose exempt users are being given the torunblocked right.


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andrew at epstone

Jun 5, 2008, 2:50 PM

Post #20 of 58 (1098 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Fri, Jun 6, 2008 at 6:51 AM, David Gerard <dgerard[at]gmail.com> wrote:
> 2008/6/5 David Gerard <dgerard[at]gmail.com>:
>
>> Is there a way to allow exempt IPs to edit through Tor anyway?
>
>
> I mean exempt usernames (I believe sysops are presently immune to IP
> blocks, for example).
>

See http://en.wikipedia.org/wiki/Special:ListGroupRights

You'll notice an extra permission under User, called
torblock-unblocked, or something. All that would need to be done is
for that to be reassigned to a user group given out.

However, I don't like the idea of hard-blocking tor, even when we do
give out flags to people who need to use it. I maintain that we are
best to come up with some other form of novel handling that balances
the need to prevent vandalism with other needs.

I think that, for users who don't have a certain permission, marking
tor edits as such in recentchanges would be an excellent step in that
direction.

--
Andrew Garrett

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jun 5, 2008, 2:56 PM

Post #21 of 58 (1103 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Thu, Jun 5, 2008 at 5:50 PM, Andrew Garrett <andrew[at]epstone.net> wrote:
> See http://en.wikipedia.org/wiki/Special:ListGroupRights
>
> You'll notice an extra permission under User, called
> torblock-unblocked, or something. All that would need to be done is
> for that to be reassigned to a user group given out.

Shouldn't ipblock-exempt imply torunblocked?

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 5, 2008, 3:01 PM

Post #22 of 58 (1104 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/5 Andrew Garrett <andrew[at]epstone.net>:

> However, I don't like the idea of hard-blocking tor, even when we do
> give out flags to people who need to use it. I maintain that we are
> best to come up with some other form of novel handling that balances
> the need to prevent vandalism with other needs.


Not many people do like the idea of blocking it. The hard-blocking on
en:wp is because people like the realities of not blocking it even
less.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jayjg99 at gmail

Jun 6, 2008, 7:16 AM

Post #23 of 58 (1067 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Thu, Jun 5, 2008 at 5:50 PM, Andrew Garrett <andrew[at]epstone.net> wrote:
> On Fri, Jun 6, 2008 at 6:51 AM, David Gerard <dgerard[at]gmail.com> wrote:
>> 2008/6/5 David Gerard <dgerard[at]gmail.com>:
>>
>>> Is there a way to allow exempt IPs to edit through Tor anyway?
>>
>>
>> I mean exempt usernames (I believe sysops are presently immune to IP
>> blocks, for example).
>>
>
> See http://en.wikipedia.org/wiki/Special:ListGroupRights
>
> You'll notice an extra permission under User, called
> torblock-unblocked, or something. All that would need to be done is
> for that to be reassigned to a user group given out.
>
> However, I don't like the idea of hard-blocking tor, even when we do
> give out flags to people who need to use it. I maintain that we are
> best to come up with some other form of novel handling that balances
> the need to prevent vandalism with other needs.

Why do you not like the idea of hard-blocking tor? What other needs
are you referring to?

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


ft2.wiki at gmail

Jun 6, 2008, 10:34 AM

Post #24 of 58 (1058 views)
Permalink
TorBlock extension enabled [In reply to]

Some notes on experience of tor, and IP block extension, and the use of
TorBlock on enwiki


TORBLOCK AND TOR USAGE:

Enwiki for some reason seems to get a lot of heavy duty sock usage and
editing abuse. Tor is highly abused, enough that tor has a "hard block on
sight" approach pretty much.

About a month ago, IP block extension was enabled on enwiki. This was rolled
out carefully on all sides, in view of past rollouts that had not gone
smoothly. It was a success. The developers did not enable it until there was
a clear communal consensus backed by a clear community policy. The community
created that policy and allowed it to stabilize. The issues were considered
carefully and a balanced approach created, which to date has worked very
well.

IP block exemption has broadly, two main uses -- a good-faith editor who
wishes to use their native IP, which is range-blocked for abuse prevention,
and an editor who is firewalled and cannot access WMF IP's safely other than
via an anonymizing proxy system such as Tor. Unfortunately IP block
exemption is also gold dust for account abusers - we have on enwiki regular
cases of extremely skilful sock-puppet abusers, including at least two
sock-masters who went as far as to get +sysop on a new account, specifically
in order to modify blocking of tor proxies, to enable their other socks to
edit in a manner that would defeated checkuser.

We resolved this by instigating an IP block exemption policy that was very
strict, to ensure admins wouldn't abuse the grant of the right (and could be
verified to have done so wrongly if needed) - those whose native IPs are
blocked can request IP exemption /provided/ they don't use it to edit via a
proxy (which means they remain low risk and any admin can handle granting
it), and any user wanting to edit via an anonymizing proxy has their request
discussed first by the community, to prevent admins quietly giving it to
their socks and making excuses later. So far it's worked well, a dozen or so
users on vandal ranges, two Chinese editors, a number of bots, and a user
who after discussion was agreed to be trusted not to sock, have all been
given IP block exemption.

What is relevant in all this, for TorBlock, is the communal agreement that
Tor (and other anonymizing proxies) are a special case, and that we treat
them on enwiki as ideally /not/ to be used other than under exceptional
conditions such as hard anti-vandal range blocks (if confirmed) and the
Chinese or other firewalls (subject to communal consensus). We haven't
mass-blocked them before simply because of the technical problems of doing
so.

I cannot speak for other wikis, but with IP block exemption working out so
well, we probably have no real need to keep tor open at all. The ability to
defeat CheckUser is an admin right, permits easy socking, and requires a
degree of communal trust. If there is a genuine need, then we have it in
place, now, that the request will be considered communally and if agreed,
granted. The strictness of the process has meant that this right can be
given when genuinely helpful, without major concerns over abuse.

All wikis differ, but on enwiki, the option I would expect most sensible,
would be hard blocking of all tor nodes for a reasonable time, or until they
have ceased to be tor nodes for a while. (I understand that other wikis may
find autoconfirmed or other settings more useful instead.) Enwiki checkusers
almost unanimously have a view that tor and other proxies are a major source
of disruptive editing. We have IP block exemption in place; tor seems to be
a preferred route for problem editing, and if someone does need to edit via
tor for a legitimate reason we can easily accommodate it via IP block
exemption.


MARKING OF EDITS

A second issue, the marking of edits
(revisions/diffs/contribs/history/checkuser/oversight) as having been made
via a tor node, would be extremely helpful. For enwiki, one option might be
to show this to admins or wider users, as well as checkusers. I've summed up
the emails covering this, below.


Best,

FT2



----- cu-list email #1

(Response to comment that there are many wikis with different needs)

Nobody is disputing that different wikis have different needs. The enwiki
project (as pointed out) has IP block exemption enabled, and has checkusers
who strongly feel that project would benefit from hard blocking tor in this
extension's use. Other projects (as you and others rightly point out) may
have completely different needs and views.

What I guess this means is, the tor extension needs to be per-wiki
configured, but that's hardly a surprise. Ie, same as settings for other
features that vary between projects.


----- Email #2

(Response re concern that tor is fluid)

As I understand it, the extension updates its cache of tor nodes every hour,
and edits are marked as "tor" if they come from a node that's currently
stated to be tor, not just "was a tor node some time in the last 2 months".

It's apparently very specific that at or within a very few hours of the edit
it was actively indexed as a tor exit node, hence its usefulness. Werdna has
confirmed.


----- Email #3 & #4

(Response on WMF privacy policy)

From time to time, 1/ general information such as ISP/country are in fact
placed on-wiki during the course of a checkuser case, and 2/ this is
specifically endorsed by WMF guidance/help information for checkusers.

From [[Meta:Help:Checkuser]], the main WMF guidance page, the full quote:

June 2008:

"Wikimedia privacy policy:
[...] The following information is commonly permissible. This list is not
comprehensive, and cannot replace the checkuser's judgment...
[...] the ISP edited from, if it is large enough that the information is not
personally identifiable; the country, which is generally not personally
identifiable."


The first versions of the WMF guidance/help page from October 2005 stated
the same:

Oct 2005:

"If they're on a large ISP (e.g. AOL, NTL, BT, Telstra), they're one of
millions and it's not personally identifiable."
"Revealing the country is generally not personally identifiable (e.g.
"User:Querulous is coming in from the UK, User:Sockpuppet is coming in from
Canada")."

http://meta.wikimedia.org/w/index.php?title=Help:CheckUser&oldid=226259


To support the statement that this is followed in practice as well as "on
paper", a quick search gave some specific case examples:

[[RFCU/Case/Cplot]] - "I have pinpointed a couple of Illinois Comcast
addresses" ... "The IPs come from Sprint PCS"
[[User:MER-C/Blu_Aardvark_RFCU]] - "Usual group of AOL and CenturyTel IPs"
[[RFCU/Case/JB196]] - "he has resorted to using anonymous AOL Proxies"
[[RFCU/Case/Tajik]] - "Unrelated. Anoshirawan is in the US."


If naming a country or (large) ISP would not be considered a privacy issue,
then a flag indicating "this edit was made via tor" is not a privacy issue
either. It in no way is personally identifying to say "this edit was made
via an anonymizer".

What does matter is the potential it has, for drawing attention to a user
and encouraging speculative or bad faith conclusions (eg: "they use tor so
they must be a sock/hiding something/up to no good/etc"). I'd be tempted to
limit it primarily for the latter reason rather than for privacy reasons. In
general it may not be a bad thing to let admins see that info in contribs,
diffs and edit histories, as admins do a lot of the initial multiple account
spotting for the project. Not making it public to all, and limiting it to
admins, will cut most of the problematic usage.

As privacy policy doesn't seem to be an apparent issue, the core question
about "who is safe to know" is much more about avoidance of unhelpful,
unfair, and often tenuous speculation. I think admins are probably safe on
the whole, to trust with that level of information. Worth trialling anyway;
and agreeing it may vary by wiki.


----- Email #5

(Response to impact of auto-tor blocking)

Noted that since anon IPs don't get even autoconfirmed, and Werdna's new
extension would block tor edits unless at a minimum autoconfirmed (and
optionally may hard block them on some projects), then under what
circumstances will unlogged-in IPs be able to make edits to WMF projects via
tor in future? Is the information that an anon edit was made via tor, likely
to arise, or actually be meaningful, in future?


----- Email #6

(Comment on publicity of TorBlock settings)

In any event, can we perhaps agree to keep private the exact requirements
for TorBlock extension to allow tor editing on projects, much as we do the
length of time that checkuser data is kept, for the same reason -- if it's
apparently "large", and a specific limit is not well known, then it won't be
so readily gamed.


Best,

FT2


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jun 6, 2008, 11:57 AM

Post #25 of 58 (1059 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/6 FT2 <ft2.wiki[at]gmail.com>:

> From [[Meta:Help:Checkuser]], the main WMF guidance page, the full quote:
> The first versions of the WMF guidance/help page from October 2005 stated
> the same:
> Oct 2005:
> "If they're on a large ISP (e.g. AOL, NTL, BT, Telstra), they're one of
> millions and it's not personally identifiable."
> "Revealing the country is generally not personally identifiable (e.g.
> "User:Querulous is coming in from the UK, User:Sockpuppet is coming in from
> Canada")."
> http://meta.wikimedia.org/w/index.php?title=Help:CheckUser&oldid=226259


BTW, this was text I wrote at the time as part of a quick guide to
checkuser for checkers. So it was basically my opinion - not a
Foundation rule - that revealing countries didn't violate the privacy
policy. This appears to have stuck, but it is of course subject to
change should people feel strongly and make a good case that revealing
countries does.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.