Page MenuHomePhabricator

Mark accounts that hit limit of account creation in one IP for functionaries
Closed, DeclinedPublic

Description

We have noticed some trolls that make several user accounts at the same time to later use for vandalizing on Wikipedia. Even though current software restrictions only allow creating up to 6 accounts in 24 hours per IP, it is still being used by certain trolls.

There should be an option for functionaries to be notified whenever several user accounts are created by the same IP address in a short period of time. This can help with identifying this type of trolls.

Please note that many projects don't have local CUs and identifying this type of trolls through CU is difficult anyway.

An example is provided below, of a vandalizing troll in fa.wikipedia, for demonstration purposes.

https://en.wikipedia.org/wiki/Category:Wikipedia_sockpuppets_of_%D8%AC%D9%88%D8%A7%D8%AF_%D8%B1%D9%85%D8%B6%D8%A7%D9%86%DB%8C_%D8%B4%D9%88%D8%B1%D8%A7%D8%A8

19:44, 31 July 2015 User account Fgyhkluorftghyl (Talk | contribs | block) was created
19:43, 31 July 2015 User account Uolajokl (Talk | contribs | block) was created
19:42, 31 July 2015 User account Karmo123 (Talk | contribs | block) was created
19:40, 31 July 2015 User account Marmadokilo (Talk | contribs | block) was created
19:39, 31 July 2015 User account Karmoeri (Talk | contribs | block) was created


[Note: Title and description changed, replacing "sysops" with "functionaries", per discussion below. - June 2016]

Event Timeline

Yamaha5 created this task.Aug 1 2015, 9:13 AM
Yamaha5 raised the priority of this task from to Normal.
Yamaha5 updated the task description. (Show Details)
Yamaha5 added a project: CheckUser.
Yamaha5 added a subscriber: Yamaha5.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 1 2015, 9:13 AM
Yamaha5 updated the task description. (Show Details)Aug 1 2015, 9:15 AM
Yamaha5 set Security to None.
Yamaha5 updated the task description. (Show Details)

I'm not sure I understand what this task is requesting. Do you mean that sysops should be able to retrieve accounts that are made by the same IP address in a given time period?

Ladsgroup renamed this task from Marking Sock_puppetry and trolls which are made their acount by an Ip on limited period to Mark accounts that hit limit of account creation in one IP for sysops.Aug 1 2015, 12:55 PM

There is a limit for creation of account from each IP (6 accounts per day) and vandals are creating account and then attack Wikipedia the day after. If admins can know these accounts are created by one IP and reached the limit somehow. It would be useful for counter vandalism efforts.

Yamaha5 added a comment.EditedAug 1 2015, 1:21 PM

It is much safer than CU becuse it shouldn't show any IP and only show the list of newbies which used the same IP for creation their user account (not edit) at last 24 hours on a spicial page like Abuse filter log.

Huji added a subscriber: Huji.Aug 1 2015, 2:01 PM
Meno25 added a subscriber: Meno25.Aug 1 2015, 2:08 PM
Huji updated the task description. (Show Details)Aug 1 2015, 2:08 PM
Huji added a comment.Aug 1 2015, 2:15 PM

The counter argument here is a privacy one:

If the system shows to sysops that User:A and User:B are created by the same IP, and activities of User:A later reveal he was a sock of User:Trolll, all sysops will already know for sure that User:B and User:Troll use the same IP. Now if the IP of User:Troll is already publicly known (e.g. as a result of a previous check that also involved anonymous users); this means all sysops will know the IP for User:B.

This is not desirable if User:B was an unrelated user who happened to have used the same IP (IP sharing is pretty common across the world). In particular, the fact that sysops (who are NOT among the groups approved for accessing personal information) will gain this knowledge can be problematic.

To my understanding, it is WMF's policy that users who are privileged with access to personal information are first identified by the Foundation (by sending a copy of their photo ID). This process is currently done only for oversighters and checkusers. Unless a similar process is established for sysops, it would be against our current practice to establish a procedure (read: create and enable a software feature) that would expose that group (sysops) to personal information.

Now, I know MW is not just about Wikimedia projects, but as a member of the OC I had to the devil's advocate.

Yamaha5 added a comment.EditedAug 1 2015, 3:42 PM

@Huji: as you know the CU results at meta or local wikis don't say the IP of any user and only Cu members can see these IPs. so normal users and sysops can not know the user's B IP.

The counter argument here is a privacy one:
If the system shows to sysops that User:A and User:B are created by the same IP, and activities of User:A later reveal he was a sock of User:Trolll, all sysops will already know for sure that User:B and User:Troll use the same IP. Now if the IP of User:Troll is already publicly known (e.g. as a result of a previous check that also involved anonymous users); this means all sysops will know the IP for User:B.
This is not desirable if User:B was an unrelated user who happened to have used the same IP (IP sharing is pretty common across the world). In particular, the fact that sysops (who are NOT among the groups approved for accessing personal information) will gain this knowledge can be problematic.
To my understanding, it is WMF's policy that users who are privileged with access to personal information are first identified by the Foundation (by sending a copy of their photo ID). This process is currently done only for oversighters and checkusers. Unless a similar process is established for sysops, it would be against our current practice to establish a procedure (read: create and enable a software feature) that would expose that group (sysops) to personal information.
Now, I know MW is not just about Wikimedia projects, but as a member of the OC I had to the devil's advocate.

or we can limit this feature for OC member or Stewards, anyway this users attack is now beyond a sigle project,

Glaisher added a subscriber: Jalexander.
Huji added a comment.Aug 1 2015, 7:48 PM

The counter argument here is a privacy one:
If the system shows to sysops that User:A and User:B are created by the same IP, and activities of User:A later reveal he was a sock of User:Trolll, all sysops will already know for sure that User:B and User:Troll use the same IP. Now if the IP of User:Troll is already publicly known (e.g. as a result of a previous check that also involved anonymous users); this means all sysops will know the IP for User:B.
This is not desirable if User:B was an unrelated user who happened to have used the same IP (IP sharing is pretty common across the world). In particular, the fact that sysops (who are NOT among the groups approved for accessing personal information) will gain this knowledge can be problematic.
To my understanding, it is WMF's policy that users who are privileged with access to personal information are first identified by the Foundation (by sending a copy of their photo ID). This process is currently done only for oversighters and checkusers. Unless a similar process is established for sysops, it would be against our current practice to establish a procedure (read: create and enable a software feature) that would expose that group (sysops) to personal information.
Now, I know MW is not just about Wikimedia projects, but as a member of the OC I had to the devil's advocate.

or we can limit this feature for OC member or Stewards, anyway this users attack is now beyond a sigle project,

I think it should be limited to Stewards, if it is ever implemented. And then the assumption would that Stewards would frequently check the "multiple user creation" log/list and take action if necessary. Again, only speculations.

Rubin16 added a subscriber: Rubin16.Oct 3 2015, 3:36 PM

Hello. :) I was asked to comment on this and also sought feedback from Jacob Rogers on the legal team.

This tool seems like it has really good possibilities for helping to combat sockpuppetry, which is an issue we all deal with. We do understand the privacy concerns, as we have a commitment to keeping location information secure generally. While vandalism fighting may sometimes lead to publishing information we'd prefer to keep private (in accordance with our Privacy Policy), we think that it's very much in the spirit of the Privacy Policy to keep the information as confidential as possible and thus strongly support limiting access to identified users.

Gnom1 added a subscriber: Gnom1.Dec 14 2015, 10:42 PM
Barras added a subscriber: Barras.Dec 15 2015, 9:07 AM
Huji added a comment.Dec 20 2015, 3:30 PM

Thanks Maggie. Since some of the terms you used are common knowledge to experienced WMF users, but not necessarily to all MediaWiki users, I am going to beat the dead horse by saying that (as far as I understand) what you mean is this:

The legal team of the WMF believes this tool is great for fighting vandalism, but because it may lead to obtaining or publishing private information, it falls under the same category of tools like CheckUser. And that WMF prefers only those can have access to this that are "identified users" (meaning they have gone through the same identification process as CheckUsers and Oversighters).

I'd say that's pretty much it. :) Not perhaps entirely the same category, but similar enough.

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptApr 14 2016, 12:57 AM
ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.Apr 14 2016, 12:57 AM
Quiddity renamed this task from Mark accounts that hit limit of account creation in one IP for sysops to Mark accounts that hit limit of account creation in one IP for functionaries.Jun 12 2016, 8:28 PM
Quiddity updated the task description. (Show Details)
Slaporte removed a subscriber: Slaporte.Jul 25 2016, 6:14 PM

When I first read this ticket, it sounded like a good idea, but the more I think about it, the more I doubt that it would actually be useful. First of all, you're going to get a high number of false positives from classes and edit-a-thons (which already have enough problems to deal with). Second, if the output of this tool is going to be limited to people with CheckUser rights (as suggested by Mdennis), it's basically superfluous. It's a lot easier to just run a CheckUser on a problematic editor than to keep track of all the users that have been flagged by this tool and look for matches.

Huji closed this task as Declined.Sep 29 2016, 11:30 PM

I am going to be bold and mark this as declined. Between the practical issues (e.g. see kaldari's comment) and access issues (e.g. see Mdennis's comment) I think this feature request is not going to be fulfilled.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptSep 29 2016, 11:30 PM
Meno25 removed a subscriber: Meno25.Oct 3 2016, 5:13 PM
MarcoAurelio moved this task from Backlog to Closed on the CheckUser board.Jan 22 2017, 4:31 PM