Wikipedia talk:Sockpuppet investigations

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:SSP)
Jump to: navigation, search

"Clerk assistance requested" status[edit]

While we have a template for this, it would be a good SPI status of its own. I'm sure it's technically feasible, but I wanted to hear others' thoughts. GABgab 23:05, 29 January 2018 (UTC)

@GeneralizationsAreBad: What would be that status used for? Doesn't every open SPI case need clerk assistance? Vanjagenije (talk) 23:23, 29 January 2018 (UTC)
Since most open case can also be processed by a patrolling administrator, I think it might be useful to have a status for cases that require attention from a clerk specifically, where, for example, page moves or merges are required. We don't seem to have a consistent way of categorizing cases like this. At time of writing, there are four pending cases that require merges: three are marked for admin assistance, one is on hold. Sir Sputnik (talk) 00:14, 30 January 2018 (UTC)
Sir Sputnik - as usual - summed it up better than I could have. GABgab 01:04, 30 January 2018 (UTC)
Well, merging indeed needs admin assistance, as ordinary (non-admin) clerks can't do history-merge. This "clerk needed" status wouldn't be useful for cases needing merge. Vanjagenije (talk) 03:09, 30 January 2018 (UTC)
We are lucky to have many awesome admins who regularly patrol SPI, but in general we want want admin clerks specifically to do the merging. I see so many cases sit untouched for days because they require merging from an admin clerk and it's not like we have an abundance of those. I think a new status could be a good idea. Sro23 (talk) 19:56, 30 January 2018 (UTC)
Although most of the time when I use the template, it's addressed reasonably quickly, I agree that a new status would be useful.--Bbb23 (talk) 17:51, 4 February 2018 (UTC)
I guess the next step here is figuring out how to implement it. @Amalthea: might have some thoughts as the person running the bot that updates the case table. Sir Sputnik (talk) 22:31, 7 February 2018 (UTC)
Three technical changes, as far as I can tell: {{SPIstatusentry}} and {{SPIstatusentry/color}} need to be extended, and the bot must be told of the new status and how it should sort. I'll look into it, should be quick to do, but may still need a day or two ... Amalthea 10:18, 8 February 2018 (UTC)
@Sir Sputnik:: adding a new status should now be easy to do, you need to add it in four places: {{SPI case status/core}}, {{SPIstatusentry}}, {{SPIstatusentry/color}}, {{SPIstatusentry/order}}. Amalthea 11:33, 12 February 2018 (UTC)
That all looks pretty straight forward. @GeneralizationsAreBad:, @Bbb23: could one of you do the honours? Two of these templates are full protected. Sir Sputnik (talk) 16:45, 12 February 2018 (UTC)
I don't do windows templates.--Bbb23 (talk) 17:43, 12 February 2018 (UTC)
@Sir Sputnik: I'm not entirely sure how I'd go about adding this status. Apologies for my technical ineptitude. GABgab 17:09, 19 February 2018 (UTC)
I've gone ahead and added the new status myself, called 'CLERK', see documentation in Template:SPI case status. The wording I've added is really basic, the icon is the same as others use, the color might be a bit jarring ... please feel free to change as needed (or request the change on the talk page), that should really be straight forward now. Amalthea 18:45, 20 February 2018 (UTC)
@Amalthea: Thank you! I just used the status for the first time. Great fun, and I like the color.--Bbb23 (talk) 23:16, 20 February 2018 (UTC)
This is very useful. Thank you, Amalthea. ~ Rob13Talk 18:43, 22 February 2018 (UTC)

CU request[edit]

I'm making a report here as Ponyo suggested. I'd like a clerk to open a case on meta, since I'm an anonymous user and can't open CU requests. My report is about a very very likely cross-wiki vandal using open proxies and abusing sockpuppets besides, recently, normal IPs. The proxies were used from december to january, in some wikis they were blocked. The suspected accounts have been created about one month ago after the proxy blocks and each one was used in different wikis, some of them have already been blocked for sockpuppetry. It's possible that other accounts and IPs belong to the same user, but I could find just the following:

  • Socks: Baka Líte, Fulgencio Kokomeci, Myeuurn, Onpuryvgr.
  • Proxies: 66.160.128.0/18, 72.52.64.0/18, 74.82.0.0/18, 204.246.56.71.
  • IPs: 151.18.0.0/16, 151.34.0.0/13, 151.65.0.0/14, 151.82.0.0/16.

If for any of these 4 accounts was used the same IP as for another one, that would mean they were used by the same user, isn't it? These socks, as the proxies, were used to deceive and mislead other users, so that the person behind them couldn't be recognised nor detected, unless with a check like the one I'm asking for. I suspect this because these accounts and IPs were used in the same pages of several projects to do similar or even identical edits, some of them just useless, some inappropriate and some others disruptive. I'm providing here a few evidences about the nature and identicalness of edits by both the previous accounts and IPs belonging to the previous ranges:

Some of the edits concern final accents in Italian names, while the others are just inappropriate and disruptive as shown here:

Be that as it may, such a use of open proxies and abuse of sockpuppets is forbidden. The socks, once they've been proven to be socks, should be blocked like the proxies, but I think that also the other IP ranges should be locally blocked where they've been used in place of socks and proxies or the vandal wouldn't stop. This is the material I'd like to be brought to meta. I hope that after reading this detailed report and this list of evidences you'll be glad somebody signaled this issue. In case you need more information feel free to demand. Actually there's one more thing, even if at the moment I'm not asking to include it in the CU request. It's a little suspect, but it's not impossible that the user behind all that, that is the sockmaster, is an old registered Italian user I'm not naming right now. I suspect him because the dynamic IPs used are from Northern Italy, because that user from Northern Italy had already made similar edits, because a certain static IP which is linked to him had already made similar edits, and because of this single edit where the sign by that static IP was replaced by the sign by one of the other dynamic IPs: see here. As I've just said, I'm not including any other identities in the check for now, perhaps I'll do it if the check I'm asking for is positive. 151.48.208.208 (talk) 10:21, 7 February 2018 (UTC)

I'm not sure that Ponyo was suggesting that an enwiki clerk would file a report on meta for you, but in any case:
  1. Anon users can open cases on enwiki by filing them per the instructions given on WP:SPI, but as Ponyo noted, a local case won't do much to combat disruption elsewhere.
  2. As far as I can tell, there is no prohibition against anon users starting reports at meta:SRCU, so you really should make your case there rather than here.
​—DoRD (talk)​ 13:16, 7 February 2018 (UTC)
Exactly. As I noted on my talk page a case could be opened locally, but it would not help with the cross-wiki aspect of the case, which would be better handled at Meta.--Jezebel's Ponyobons mots 16:34, 7 February 2018 (UTC)
I misunderstood what you told me Ponyo. Okay, if it's as you both said, I'll try asking directly on meta. In case instead they shouldn't accept request from anonymous users nor from user who registered just for that, as I fear, would any of you take my report there? 151.48.208.5 (talk) 09:44, 8 February 2018 (UTC)
I can't see any Steward dismissing a report that is supported by strong evidence solely because it was made by an IP or new account.--Jezebel's Ponyobons mots 18:10, 8 February 2018 (UTC)
Actually it's exactly what's already happened to me when I tried last month: see here. I really would like one of you to bring my report there so that it'll be taken in consideration. I've told you all the information you need about the cross-wiki vandal, the problem I've reported is real, and if you need further details you have just to ask me. Or is there any problem for this request of mine? Tell me sincerely, please. 151.48.213.231 (talk) 11:51, 13 February 2018 (UTC) @DoRD and Ponyo:

Colocation providers / webhosts[edit]

I've recently made lists of non-locally blocked IP ranges for AWS, Microsoft Azure, Google Cloud, OVH, and Digital Ocean. The method of finding ranges varies a little by provider, where possible I use lists published by the provider (google, amazon, azure) - elsewhere I list every IP range owned by the provider (docean, OVH). Are there any other common webhost-only / colocation-only providers that slip thru that could use blocking? SQLQuery me! 14:36, 8 February 2018 (UTC)

You know that OVH can be a bit tricky, right? I'd be interested to hear what you can do with Powerhouse Management, AKA Giganews, AKA lots of other stuff, for example 178.208.176.215 (talk · contribs · WHOIS). Other problems at this time, though I don't guarantee they're colo-only, include M247, Psychz Networks (e.g. AS40676), Netzbetrieb (e.g. AS201011), and CDN77 (e.g. AS60068), IMO. -- zzuuzz (talk) 15:15, 8 February 2018 (UTC)
Hmm, No - wasn't aware of issues with OVH. I've been a customer of theirs for years, and can't see any services available outside of hosting (colo/web/vps/etc). What kind of issues are there? Also, if there are specific AS'es - usually it's pretty easy to see what ranges are associated with those. SQLQuery me! 15:26, 8 February 2018 (UTC)
I don't remember specifics about OVH, but I think all that's labelled OVH is not all hosting, particularly when it comes to France. -- zzuuzz (talk) 15:56, 8 February 2018 (UTC)
I definitely remember issues with OVH ranges in France that included residential allocation not associated with their webhosting services.--Jezebel's Ponyobons mots 18:15, 8 February 2018 (UTC)
I have reached out to OVH to ask what ranges are French residential customers. Hopefully, they'll be happy to respond to me so I can unblock those ranges. SQLQuery me! 04:46, 10 February 2018 (UTC)
Linode is a big one. Might be worth looking through Category:Cloud computing providers and Wikipedia:Database reports/Range blocks. I sometimes go through the database report and reblock any colo facility whose block is expiring. NinjaRobotPirate (talk) 15:31, 8 February 2018 (UTC)
User:SQL/Non-blocked Linode Ranges I've added Linode to the list generator. I'll look at some of the others in that category as well - thanks! SQLQuery me! 15:52, 8 February 2018 (UTC)
HostGator, DreamHost, Rackspace, SoftLayer, and 1&1 Internet are pretty popular. NinjaRobotPirate (talk) 18:33, 8 February 2018 (UTC)
I'd also point to SoftLayer and LeaseWeb as two other providers where one should exercise some caution. -- zzuuzz (talk) 18:50, 8 February 2018 (UTC)
Thanks, I've added hostgator, dreamhost, rackspace, and 1&1 (Combined everything into one place at User:SQL/Non-blocked webhost ranges for simplicity's sake). As zzuuzz mentions above, I think I'll avoid softlayer or leaseweb. SQLQuery me! 20:04, 8 February 2018 (UTC)

Script issues[edit]

I've been having trouble with the SPI helper script over the past few days. About half the time, the script's function either won't load in the "More" drop down or are unresponsive when clicked. Opening the case page in a new window seems to fix the problem. Has anyone else encountered this before? Sir Sputnik (talk) 16:32, 12 February 2018 (UTC)

I haven't, at least not recently and not that I can remember.--Bbb23 (talk) 18:07, 12 February 2018 (UTC)
No problem for me. Maybe you have a conflict of scripts. If you installed some new script recently, try disabling it. Vanjagenije (talk) 22:04, 12 February 2018 (UTC)

Bot malfunctioning[edit]

Is someone doing something with the Amalthea (bot)? Several cases are classified incorrectly. For example, this case is classified as "closed" in the main table, although it has been open for more than a month. Vanjagenije (talk) 22:03, 12 February 2018 (UTC)

A new error, it got confused when multiple case statuses on one case page were present; Fixed now, thanks! Amalthea 22:51, 12 February 2018 (UTC)

Identical sandboxes in multiple accounts...[edit]

In cleaning up Wikipedia:Database reports/Polluted categories, occasionally I'll run into multiple (in some cases as many as five) accounts with the same "article" in their sandbox (so User:ABC12Fake/sandbox is the same as User:Somethingdifferent/sandbox and User:Theotherone/sandbox which is *not* a copy of an existing article in article space. Does this represent enough for a SP Investigation? If not, is there somewhere else that it should be reported?Naraht (talk) 15:52, 20 February 2018 (UTC)

I assume those three are just examples and not actually pages you found? I would say yes, it's worth looking at. Especially if the duplicated article is about a person or business, it's probably undisclosed paid editing and may be related to an article that has already been deleted; the challenge is identifying the master to file a case. Post here or at AN/I, I guess? Although it could just as well be a school project, but we don't know if we don't investigate. Ivanvector (Talk/Edits) 16:06, 20 February 2018 (UTC)
Yes, they are just examples, it has been a week or more since I found one and I do a *lot* of edits "coloning" out categories, so I'm not sure that I could locate them again. :( They didn't seem like a school project, so I'll post here if I find that again. Note, I do also find a good number of cases where the same user has multiple sandboxes which are more or less identical, but that isn't for SPI, at worst, it is FAKEPAGE.Naraht (talk) 16:13, 20 February 2018 (UTC)