TBolliger (WMF)

Extending global blocks to named accounts

I noticed that you didn't list the wish list survey suggestion I created for extending global blocks to named accounts instead of globally locking users, does this have a particular reason? This concerns your request for comment. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 14:16, 9 December 2017 (UTC)

We're watching a lot of the Wishlist proposals that are related to Anti-Harassment work, but those three I specifically linked were closest to the top 10. — Trevor Bolliger, WMF Product Manager 🗨 17:57, 11 December 2017 (UTC)

Blocks based on hardware

As you may know, Nipponese dog calvero is a very long term vandal. Is it possible perhaps for a wmf hardware block on his devices? I mean, block any edits based on his personal computer and phone? --Artix Kreiger (Message Wall) 00:28, 17 January 2018 (UTC)

For any requests about cross-wiki vandalism, please contact Stewards. (For the record, hardware blocking is not possible with current MediaWiki software.) — Trevor Bolliger, WMF Product Manager 🗨 00:40, 17 January 2018 (UTC)

Flow

Hello! May I leave some feedback on flow? --Artix Kreiger (Message Wall) 18:19, 3 March 2018 (UTC)

@Artix Kreiger: I'm not involved with the Flow project, I would recommend you discuss on Talk:Flow. — Trevor Bolliger, WMF Product Manager 🗨 19:53, 5 March 2018 (UTC)

What happens after lock of page expires?

Hi TBolliger!

Disclaimer: Yes, I know there is probably better place to write about this, but in last 10 years I saw a lot of mediawiki tinkering which surely spent a lot of man-hours, really man-years and not so much of improvement to end users, meaning Wikipedia volunteers. This is, the first really good idea I saw in years, and now I think I have idea for another one good improvement. :)

• Description of problem/current mediawiki behavior: after lock of page expires, page is unlocked, meaning - no protection at all.
• Description of wanted mediawiki behavior: after lock of page to sysop level expires, page should either go to previous level of protection, if such exists, or it should be possible to set state of page lock after sysop lock when actually locking to set period of time.
  • Comments: this could be circumvented with bot and tasklist page.
  • Answer to above comment: that is not good software design. It should be set better, smarter, in the first place. (Yeah, right. :)

Maybe this idea already is written somewhere, maybe not. I have no clue. But it's written here and now. I kind of thought to write above on page: Grants:IdeaLab/Inspire, but before doing that, it would be wise (or ideal) that I find time to read, or at least skim other ideas. But there are a lot of ideas... Regards! SpeedyGonsales (talk) 10:25, 7 August 2018 (UTC)

@SpeedyGonsales: Yes, we've received this request before too, but we cannot find ways to connect it to Anti-Harassment work, and it would take a few months for us to work on, so my team (the Anti-Harassment Tools team) will focus on other project when we're done with Partial Blocks. The phabricator task is phab:T41038 for future reference. — Trevor Bolliger, WMF Product Manager 🗨 21:04, 7 August 2018 (UTC)

New message re WCNA 2018

Hi Trevor! Left you a message on the WCNA wiki. Thanks, ~SuperHamster Talk Contribs 18:03, 10 September 2018 (UTC)

The Community Wishlist Survey

Hi,

You get this message because you’ve previously participated in the Community Wishlist Survey. I just wanted to let you know that this year’s survey is now open for proposals. You can suggest technical changes until 11 November: Community Wishlist Survey 2019.

You can vote from November 16 to November 30. To keep the number of messages at a reasonable level, I won’t send out a separate reminder to you about that. /Johan (WMF) 11:24, 30 October 2018 (UTC)

Comments on software mitigating LTA

Proposed metrics

Many of these measures of success are indistinguishable from admin burnout and the LTAs getting better at evading detection - if we have less admins or the LTAs get stealthier, then it is likely that there will be:

• a decrease in sockpuppet blocks
• fewer volunteer hours are spent addressing LTA cases

The problem with the worst of LTAs is that it is difficult to determine whether they have disappeared for good, hibernating or just changed their tactics. You'll probably find that the decrease in less hardcore abuse is more pronounced.

Software development

• The title blacklist should be private by default. Harassing usernames should not be repeated in public. For spammers, a public machine readable entry could serve as an additional form of sanction.

• We could have some blocks be “shadow blocks” which do not allow the user to edit but also do not show them that they are blocked.

In other words, they get the normal edit screen, hit the "save page" button and nothing happens?

• Consider how much LTA documentation is out in the open. Consider putting it behind

Incomplete sentence. WP:DENY would be useful to link here.

• Promote the use of role accounts (e.g. the blocks and messages come from User:WikipediaAdministrators instead of User:Bob123

How does this interact with the revision history, signatures and block messages on talk pages and the block message itself? It could be a useful block option, but this is is probably little more than a speed bump. Definitely helps against "clueless brigade" type vandalism from Reddit - some percentage of that brigade might send harassing messages to the blocking admin.

• Persistent cookies -
  • Can you get Checkuser to record and filter by the already existing session IDs? (This is a passive defense only.)
  • Can you throttle account creation by this session ID?

Sure it's easy to evade, but if you want to create ten accounts things may start to get annoying.

• Other things worth considering -
  • deliberate performance degradation. Run the logic about minimising page load/save times in reverse.
  • the Abuse Filter could do with a second look at some point.
  • Don't forget the API! Actions like https://en.wikipedia.org/w/api.php?action=help&modules=titleblacklist , https://en.wikipedia.org/w/api.php?action=help&modules=spamblacklist , and https://en.wikipedia.org/w/api.php?action=help&modules=antispoof need to be restricted to trusted users only. We can't have LTAs validating potential usernames/spam links offline rapidly.

While any individual measure might not do much, in combination they can be quite annoying. I'll be happy to comment in depth about LTA spammers. MER-C (talk) 15:04, 2 March 2019 (UTC)

@MER-C: Thank you for the comments, MER-C. I really appreciate that you are engaged and my team's work has not just been posted into the abyss.

Shadow blocks could be implemented in a few ways, but the crux is that the content the abuser attempts to publish is never saved on our servers or shown to another user. Some websites go so far as to spoof that the comment/transaction/event successfully occurred to deceive the abuser. This also includes deliberate performance degredation.

I'll forever be ashamed of that truncated "Consider putting it behind" sentence. :) And I agree that WP:DENY aligns perfectly with our intention of that recommendation.

Role accounts could be as simple as multiple people sharing a password to an account (which is poor security, but that's a whole separate topic) or we could build new software to have shared accounts which can have logging which shows which associated accounts perform the role actions (e.g. "User:Admin1 logged into User:RoleAccount, User:RoleAccount edited XYZ page, User:Admin1 logged out of User:RoleAccount.)

We did not do any technical investigations into CheckUser or account throttling. We believe development of CheckUser would be slightly less expensive (as an extension and not MediaWiki core) but not trivial.

Good point about auditing the APIs. We'll get that done in the coming weeks: phab:T217613. But beyond that and dropping cookie blocks on API-based edits (phab:T196575) we will be pivoting from blocking tools to the user reporting system, as our team is expected to start focusing on tools that will be used directly by users who receive unsavory messages or interactions. — Trevor Bolliger, WMF Product Manager 🗨 00:28, 5 March 2019 (UTC)

I was thinking of an option on the block form to that effect, but the role account being available for all actions is better.

The argument for auditing the APIs is exactly the same as making the title blacklist private. I don't think you'll be able to get buy-in without doing so.

I'll have a look at the reporting system as well when I have the chance. The reason why some incidents get neglected boils down to 1) we're volunteers and 2) dealing with this stuff is difficult, not fun and has potential negative consequences, so why bother? If you can make it technically easier by improving the quality of reports, preventing incidents then I'm all for it. If you make it easier to report harassment, there will be bigger backlogs and more admin burnout, all other things being equal. MER-C (talk) 20:35, 5 March 2019 (UTC)