Page MenuHomePhabricator

Add a way to extend autoblock to longer than 1 day
Open, LowPublic

Description

Especially in Korean Wikipedia, default autoblock duration (1 day) is almost not effective to persistent vandal because once blocked for inappropriate username then tomorrow he create another one easily. And the block-create loop goes for very long time. I'd suggest to make ultra-autoblock (about 30 days) option and give sysops the right to apply ultra-autoblock. Best regards.


T19929: CentralAuth account locks should trigger global autoblocks
T43479: [Spam/vandalism] Raise $wgAutoblockExpiry noticeably

Details

Reference
bz25305

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:17 PM
bzimport set Reference to bz25305.
bzimport added a subscriber: Unknown Object (MLST).

-need-review. no patch to review.

matthew.britton wrote:

Autoblocks are very limited in their flexibility -- they prevent editing as well as account creation.

If this feature request were implemented, you would have a lot of long-term autoblocks floating around affecting legitimate contributors.

The way to go in this situation is to put a long-term account creation block on the user's IP address (which liekly involves requesting a checkuser). This stops the user creating any more accounts while still allowing other users to edit from the same IP address if it is shared or dynamic.

(In reply to comment #3)

Checkusers can tell what accounts shared same IP address, but can't tell specific IP address they used. So we can't block IP address manually to stop creating more accounts. That's why this function is suggested.

(In reply to comment #4)

Checkusers can tell what accounts shared same IP address, but can't tell
specific IP address they used. So we can't block IP address manually to stop
creating more accounts. That's why this function is suggested.

From http://wikimediafoundation.org/wiki/Privacy_policy#Access_to_and_release_of_personally_identifiable_information :

Where the user has been vandalizing articles or persistently behaving in a disruptive way, data may be released to a service provider, carrier, or other third-party entity to assist in the targeting of IP blocks, or to assist in the formulation of a complaint to relevant Internet Service Providers

kyswiki951 wrote:

Korean Wikipedia is needed to this option. I think some people worry about this option because of abuse. But, this problem will be resolved by consensus. Only ultra-block option will be aroused under the consensus situation.

(In reply to comment #4)

(In reply to comment #3)

Checkusers can tell what accounts shared same IP address, but can't tell
specific IP address they used. So we can't block IP address manually to stop
creating more accounts. That's why this function is suggested.

Checkusers can tell/block specific IP addresses. On English Wikipedia we reduce the ability for the public to determine that user:A=IP:123 from the logs by different sysops performing the block, however as the disruption increases, our need to protect their privacy decreases: the disruptor is choosing to continue.

Or Korean Wikipedia can increase the setting of $wgAutoblockExpiry by consensus decision by the community.
http://www.mediawiki.org/wiki/Manual:$wgAutoblockExpiry

I think it is also possible to create a group for 'ultra-auto-blocked' accounts, and have a higher $wgAutoblockExpiry value for these accounts. If that is possible, this bug can be closed until Korean Wikipedia has consensus to implement it. However I think that it will not be effective, because any public record that an account is ultra-auto-blocked will mean that the disruptive person will use a different strategy.

Krinkle renamed this task from Make an ultra-autoblock option (about 30 days) to Add a way to extend autoblock to longer than 1 day.May 7 2017, 11:48 PM
Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l-list.