Stewards' noticeboard/Archives/2018-12

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Closure needed

These RFCs by globally locked /compromised accounts needs a closure. Requests for comment/Global ban for WikingerRequests for comment/Jbowiktionary is all but dead.Thanks.--Cohaf (talk) 05:24, 26 December 2018 (UTC)Reply[reply]

I've deleted the first, and closed the second. The first one was just a bunch of nonsense it does not even merit to be kept around. The second one is arguably the same stuff, but I closed it instead. If somebody wants to delete it as well I won't oppose. Thanks, —MarcoAurelio (talk) 18:55, 27 December 2018 (UTC)Reply[reply]
@MarcoAurelio:.Thanks.--Cohaf (talk) 18:56, 27 December 2018 (UTC)Reply[reply]
This section was archived on a request by: Cohaf (talk) 23:26, 1 January 2019 (UTC)Reply[reply]

I was told to inform the stewards of this

My current name is Sei Noelle, but my former name used to be Skiyomi (or Sierpnia). I know my accounts were locked back in April and May, but since I have taken a break for several months now, I feel that I am ready to behave here now. I would really appreciate it if I could keep this account unlocked. Thank you. Sei Noelle (talk) 11:26, 14 December 2018 (UTC)Reply[reply]

Just an add-on: if I remember right, I can keep this account unlocked as long as I don't vandalize or be disruptive, since it has been several months since my Sierpnia and Skiyomi accounts were locked. Am I right? Sei Noelle (talk) 19:07, 15 December 2018 (UTC)Reply[reply]

You actually did not take any break. You have been vandalizing using IP and accounts throughout the past several months, and your previous account was just blocked at enwiki within a week ago. -★- PlyrStar93 Message me. 19:10, 15 December 2018 (UTC)Reply[reply]
i don't what to're right. I just tried to forget all of that and pretend that none of it happened. But I know that doesn't change the fact that those things did happen. I guess now all I can do is wait and see what happens, and try to behave better in the future. Sei Noelle (talk) 19:39, 15 December 2018 (UTC)Reply[reply]
Hello stewards, PlyrStar93 and Sei Noelle.
@Sei Noelle: if you really want to make a "clean start", you should stop multiplying accounts, lies and vandalisms. You have pushed your last lie ("I have taken a break for several months") to the stewards just above and to the administrators of the English Wikipedia (here). Honest editors such as the stewards here, or Ad Orientem and Vermont on the English Wikipedia, could have been deceived by this lie.
Moreover, mentioning your accounts Skiyomi and Sierpnia is not enough:
  • For the period until 17 June 2018, you should give a link to Steward requests/Global/2018-06#Global block for IP ranges of Topmaniac, which lists some of your other accounts (all globally locked), some of your IP ranges (all globally blocked several times), some of your numerous lies and some of your numerous vandalisms.
  • For the period after 17 June 2018, you should give a link to en:Wikipedia:Sockpuppet investigations/Skiyomi, which lists some of your other accounts. On 17 June 2018, some of your IP ranges were globally blocked until 17 September 2018:, and After that, there were enough cross-wiki vandalisms to provoke new global blocks for (until 8 October 2018), (until 21 March 2019) and (until 8 January 2019)...
Regards --NicoScribe (talk) 16:34, 17 December 2018 (UTC)Reply[reply]
To be honest, I didn't think it was necessary to mention the previous and current global blocks on my IP ranges. Or any of my additional accounts. But yes, I should have told the stewards and Wikipedia editors the whole truth. And I'm sorry for that. I guess I won't try to get any accounts back until next year after June or so. And this will be my last edit here for awhile. Sei Noelle (talk) 16:44, 17 December 2018 (UTC)Reply[reply]
@Sei Noelle: I disagree with your assessment that only half-informing was needed. Half-truths are seen as misleading when the whole story is needed.

I would suggest that you need to properly think about what sort of editing that you are wishing to undertake, and that give true value to what you are wishing to achieve, and what your skill set allows. Whether it is building encyclopaedias (Wikipedias), contributing to a file library (Commons); transcribing documents and old works (Wikisources); creating educational books (Wikibooks); building courses (Wikiversity); travel information (Wikivoyage); or Wikispecies, Wikinews or Wikidata. When a user runs into trouble here, it is often due to their not finding their right niche in the right community for their interests, and then getting out of scope, or out of acceptable edits. Stop trying too hard, and find somewhere where you can go with the flow, and feel valued.  — billinghurst sDrewth 20:36, 17 December 2018 (UTC)Reply[reply]

OP globally locked, I guess this can be closed now.--Cohaf (talk) 08:08, 7 January 2019 (UTC)Reply[reply]
:This section was archived on a request by: Cohaf (talk) 08:08, 7 January 2019 (UTC)Reply[reply]

Sysop inactivity on br.wp


Can someone look into the activity of sysops on the Breton Wikipedia? Some may still be around but most seems inactive for a long time.

Cheers, VIGNERON * discut. 21:19, 29 December 2018 (UTC)Reply[reply]

Good day. The AAR18 has just started and stewards will message the users very soon. The inactive users will be messaged shortly. Best regards, —MarcoAurelio (talk) 12:49, 6 January 2019 (UTC)Reply[reply]
Thank you MarcoAurelio! Cheers, VIGNERON * discut. 14:34, 7 January 2019 (UTC)Reply[reply]
You're welcome VIGNERON. I have started the process on brwiki today. Best regards, —MarcoAurelio (talk) 15:49, 11 January 2019 (UTC)Reply[reply]
This section was archived on a request by: —MarcoAurelio (talk) 15:49, 11 January 2019 (UTC)Reply[reply]

Spambot activity and temporary filters to manage

Hi to all. The spambots are having a merry time having created, and trying to create accounts. We have a temporary gross filter in place Special:AbuseFilter/195 to try to manage the damage, though with a filter such as this we know that it was overly effective early. We have since refined the filter with observation and testing, though know it will still have false positives. We are also seeing that a challenge alone is holding without a disallow, though that may change.

We are working with #wikimedia-operations in IRC to see if we can do anything.

If you were one of these false positives, then please try again though with a longer or shorter username.

Thanks. Please leave any comments or questions below.  — billinghurst sDrewth 14:09, 28 December 2018 (UTC)Reply[reply]

On the rate limit's supposed failure: are they all from different IP addresses? The authentication metrics show a surge in captchas displayed but not in failures, so they've clearly solved all the captcha images (which are being a pain only for humans as usual). --Nemo 14:17, 28 December 2018 (UTC)Reply[reply]
Significant resources were thrown at this yesterday for a couple of hours. The latest batch was all thrown at mediawikiwiki, and about 16k creation attempts, the latter were unsuccessful, and the script bot creation script went through some metamorphosis. We think that it is sufficiently managed. We had replicated our local filter to mediawikiwiki and it was taken more actioins than we allow the global filters to do. I have inactivated the mediawikiwiki filter as the meta global can do the same management, and I will soon look to degrade that filter to watch and not act.  — billinghurst sDrewth 06:53, 29 December 2018 (UTC)Reply[reply]

Comment Comment This filter has appeared to being effective to lessen the impact of our standard spambots, and comment has been made on my user talk page of its effectiveness, and the desire for the filter to remain. This filter was constructed to deal with emergency situation, and I would be loathe to continue it run without due consideration from the community.

The filter is aimed at a target character range of our typical spambot accounts. It was designed with challenge though it has been set to monitor more recently (other defence means were implemented which means that meta could just watch). It looks to be showing success in the logs, as accounts are shown there, though not created. This could be a bit of filter misrepresentation as I believe that the CAPTCHA test is the cause of the non-creation, as the filter should do nothing beyond record.

If we truly wish for this filter to push back against the spambots it sees, then we need to have the filter challenge the creation of the account, which would mean they get the challenge message, and have to put in password again (twice) and solve the CAPTCHA. If we do not wish to do that, then we should probably turn off the filter as its logging is not an accurate representation of its actuality.  — billinghurst sDrewth 12:13, 9 January 2019 (UTC)Reply[reply]

If I understand correctly the accounts flagged in the log by the filter that do not end up becoming accounts are in fact the result of them not being able to solve the captcha. I agree that showing these is not very helpful. But I still have the gut feeling that a significant part of our "new users" are in fact sleeping accounts of spammers. If these accounts just pose a risk to nl.wiktionary, we are probably able to cope with them. I find the risk of cross wiki spamming harder to gauge. I hope a more experienced spamfighter will enlighten me. --MarcoSwart (talk) 20:23, 10 January 2019 (UTC)Reply[reply]
@MarcoSwart: Abusefilter/195, as coded at this moment, is flagging the creation attempts for the pattern and circumstance stated in the filter. [1] Abuse filters precede the actuality, and this filter is not set to any intervention actions. [2] So if spambot/user solves the CAPTCHA the account is created,[3] and if they do not, it is not created. [4] Discussions about SUL accounts and their locations is a larger topic of conversation, though my observations about current spambots is that they are single-wiki focused and their current behaviour is not xwiki spam at the account level.[5] At the IP or IP range level, there is xwiki spam, either directly or indirectly through multiple accounts. To that latter observation the stewards are probably better able to recount their current observations.  — billinghurst sDrewth 01:01, 11 January 2019 (UTC)Reply[reply]
  1. [Noting that the actions that we choose to occur in these filters are to what I was intimating above, and at the moment it is flag with no intervention.]
  2. [What is evident is that abusefilter actions for creation therefore precede CAPTCHA actions in the mechanisms of mediawiki systems.]
  3. [and shows in RC as an account creation]
  4. [and no further evidence exists]
  5. [The current is the worse case situation, having xwiki spambots by account would actually be easier to manage IMNSHO.]
Thanks, this is useful information. If we don't need to worry about possible cross wiki spam, these sleeper accounts are merely a statistical problem inflating our user base. Due to the nature of our project, removing spam is easy and it poses probably little value to the spammer anyway. My guess is that we sometimes just serve as a testing ground. On that note, we probably are better off without any information from filter 195, because its messages crowd out the filters that do require follow-up. Of course it would be valuable to have it available against attempts to create lots of accounts in a limited amount of time, which is the original use case. --MarcoSwart (talk) 10:15, 11 January 2019 (UTC)Reply[reply]
I have deactivated the filter globally as other changes by developers has improved the problems somewhat. We can reactivate as necessary, and I would suggest that if we wish to do that, that we move to utilise the challenge setting to see how effective it can be.  — billinghurst sDrewth 10:36, 11 January 2019 (UTC)Reply[reply]
Slight change of mind, I have changed this to be a local only filter that monitors. This should then ignore the spambot creation attempts that are unsuccessful, and only then only log those that are successful.  — billinghurst sDrewth 10:55, 11 January 2019 (UTC)Reply[reply]
This section was archived on a request by:  — billinghurst sDrewth 10:43, 2 February 2019 (UTC)Reply[reply]

Special:Abusefilter/194 to limit editing of stewards' requests archives

I have noticed that there has been a little "creative" editing of the archived subpages of "Stewards requests". To maintain those archives in their preferred form, I have created an abuse filter that limits editing of those pages to users with the autopatrolled right. I have tested it against the existing recentchanges with no false positives, though I will keep an eye on it for any unintended consequences. I hope that is convenient to you.  — billinghurst sDrewth 09:38, 22 December 2018 (UTC)Reply[reply]

I have inserted a custom message fwiw, though yet to check whether the hyperlink works, will get to that when I am next in a no-permissions account, unless I find a volunteer with no permissions/test account.  — billinghurst sDrewth 15:06, 22 December 2018 (UTC)Reply[reply]
@Billinghurst: seems to work, got the link to the 'parent page' and could follow it. — xaosflux Talk 15:15, 22 December 2018 (UTC)Reply[reply]
I tried using my public account and yes, it does work as per Xaosflux.--Cohaf (talk) 07:03, 26 December 2018 (UTC)Reply[reply]
Can we get higher limit than autopatrol? Seems like autopatrol is too lenient to prevent posting on wrong venue. I'd propose limiting to sysop + bot + steward. — regards, Revi 06:18, 7 January 2019 (UTC)Reply[reply]
I have changed it and utilised "noratelimit" as described at special:listgrouprights which is a little broader than your list, though I think favourably. That may be imperfect, however, we can have that discussion, for instance we could add "rollback" if we wanted broader latitude.  — billinghurst sDrewth 09:28, 7 January 2019 (UTC)Reply[reply]
@-revi: Noting that if we are maintaining this level, I probably should just merge 133 and 194 as they are new replicating each other.  — billinghurst sDrewth 12:52, 7 January 2019 (UTC)Reply[reply]
If the above is implemented, could patroller be at least allow to edit just in case we find some hidden vandalism somewhere.--Cohaf (talk) 08:11, 7 January 2019 (UTC)Reply[reply]
I tested today on the archives of talk pages of stewards requests, I wonder why it isn't extended to them too? --Cohaf (talk) 07:20, 10 January 2019 (UTC)Reply[reply]
@Cohaf: they were not included as they are commentary rather that records of decisions. If the stewards wish for them to be included, or there is a consensus of community that they should, then it is pretty easy to do so.  — billinghurst sDrewth 10:43, 2 February 2019 (UTC)Reply[reply]
Can patroller be added along with noratelimit? There are legitimate reasons for editing that section (for example, fixing malformed formatting, an issue that has cropped up a few times recently), and I do not foresee patrollers (whose permissions are usually given only on request) accidentally editing that section. Leaderboard (talk) 19:02, 3 March 2019 (UTC)Reply[reply]
Add noratelimitsto patrollers group as we normally do lots of rollback per minute and do run into rate limits at times when LTA strikes. It will be handy at times. Just an idea.--Cohaf (talk) 08:51, 4 March 2019 (UTC)Reply[reply]
This is a philosophical question not a technical question. What the stewards wish for their archives is what we can deliver. What is driving this demand that the archives be editable? Is the demand reasonable? If the stewards decide that some imperfections are okay, or that they are willing to fix their archives, what is the issue? Since the filter introduction there has been just the single request to fix the archives, so there is a lot of noise, for little evident requirement for action.  — billinghurst sDrewth 20:14, 4 March 2019 (UTC)Reply[reply]
It is not a question of that. It is not just "the single request"; I have noticed more than just one (in fact, I fixed two such instance today). Leaderboard (talk) 21:02, 4 March 2019 (UTC)Reply[reply]
You said "It is not a question of that." Why is that so? Removing closing font tags from 8 year old archive, while very pretty, is completely unnecessary. Why do feel the need to edit the archives? What pursuit of perfection is this? Archives should be archives and only edited when there is a true necessity. Every time an archive is edited it doesn't become an archive of the time, it becomes revisionist.  — billinghurst sDrewth 21:25, 4 March 2019 (UTC)Reply[reply]
The problem is that 8 years ago there was still a bug which caused this tag issue not to be visible. So while source code-wise you are right, the appearance of these pages is more accurately preserved with fixed font tags. --Vogone (talk) 21:37, 4 March 2019 (UTC)Reply[reply]
I'm fine with someone fixing LintErrors if they hit something that makes the page to read. Copy-paste archives are a way to show the information from a point-in-time. If you want the "archive of the time" just go to the revision. — xaosflux Talk 23:37, 4 March 2019 (UTC)Reply[reply]
I think it is safe for me to say that there is consensus for that change, and will soon implement the change to rollback+noratelimit if there is no further opposition. Leaderboard (talk) 16:14, 8 March 2019 (UTC)Reply[reply]
I have changed it, taking care not to break the bot. Please feel free to change it back should it do so. Leaderboard (talk) 23:23, 8 March 2019 (UTC)Reply[reply]
This section was archived on a request by: Leaderboard (talk) 21:26, 13 March 2019 (UTC)Reply[reply]