Here's a few notions that may warrant subtasks if they don't already exist or if the functionality isn't already in Phabricator:

• Single-link ability to "undo" an action from the activity log for a task or from the activity log of a specific user. A "confirm" step may be acceptable, but it may also be that we want the equivalent of MediaWiki's "rollback" feature in addition to MediaWiki's "undo" feature
• Ability to get the full activity log for a user, not just the most recent. Currently, there doesn't appear to be a "Next >" link on this activity feed for a user (but perhaps I'm just missing something)
• Rate limiting users by default, ala MediaWiki's $wgRateLimit setting

No single vandalism fighting tool is a silver bullet. The best tools often subtlely change the balance by slowing down bad actors in ways that almost inperceptably affect good actors, and speeding up the ability to undo whatever damage is done. We don't have to have 100% automation to make life much easier for those responsible for cleaning up messes.

There are probably other ideas we can borrow from MediaWiki as well. See MediaWiki's "Combating spam" manual entry for other ideas we may want to import.

For what is worth, I think vandalism prevention should be the next area of focus after the RT / Trello / Mingle migrations, Security, and Search. We just have all our hands full now.

Upstream can help if we convince them of very specific features that fit in their view of things, but their approach so far has been 'we will act if there is a problem, but we haven't seen problems so far'. My reply is that it is easier to prevent vandalism in an intranet where all users can be fired, and this is where we are now...

Not being able to mass-revert actions in a certain timeframe associated to a certain user hit us in T91488 today (though that was not vandalism).

Some kind of throttling would have been useful as well, if not to avoid the problem, at least to reduce its impact. Chad and Yuvy reacted relatively fast, but you can't beat a bot or a batch edit.

In T84#843953, @Qgil wrote:

Upstream can help if we convince them of very specific features that fit in their view of things, but their approach so far has been 'we will act if there is a problem, but we haven't seen problems so far'.

Maybe you can just point out some past examples of Bugzilla vandalism Wikimedia had to deal with? There is no reason to think Phabricator would not attract the same amount of vandalism (it's not any harder to make mass edits), so if cleaning up would take a lot of manual effort, it is entirely reasonable to ask for preventative measures.

In T84#1089561, @Tgr wrote:

(it's not any harder to make mass edits)

It is, as not 50% of the users are members of Bugzilla's editbugs group. See the list of members in Triagers.

In T84#1090326, @Aklapper wrote:

It is, as not 50% of the users are members of Bugzilla's editbugs group. See the list of members in Triagers.

Phabricator provides a command line tool which seems pretty easy to automate. Or does that require triager membership as well?

Example: https://phabricator.wikimedia.org/p/Peter601980/ and https://phabricator.wikimedia.org/project/profile/171/ by https://phabricator.wikimedia.org/p/Bennychan2017/

Example: https://phabricator.wikimedia.org/p/Johsthao/

https://phabricator.wikimedia.org/p/Qse24h/ just mass-closed many tasks as duplicates.

2017-06-17: Registriation of dozens of accounts from a large variety of IP addresses, upload of illegal material and creation of dozens of tasks (see https://phabricator.wikimedia.org/T168142 )

For the records, first "support help desk" spam appearance on this instance in https://phabricator.wikimedia.org/T167009#3380778, from an Indian "Airtel Broadband" IP.

I could, theoretically, write a tool which walks a user's transaction history and systematically reverts every action of the user during a given time period...

More vandalism examples:
https://phabricator.wikimedia.org/p/Ptrpov mass-merged a bunch of tasks on 20171201.
https://phabricator.wikimedia.org/p/FiZie/ on 20171208
https://phabricator.wikimedia.org/p/IZoid/ setting a huge number of parent tasks by editing a single task on 20171209. Related: Could not find a way to fully delete profile images.
https://phabricator.wikimedia.org/p/Sandraramirez3888/ on 20171209.
https://phabricator.wikimedia.org/p/1978Gage2001/ massmoved tasks from one column to another column on 20171211.
https://phabricator.wikimedia.org/p/Popsicleface048/ mass-losing numerous tasks as declined on 20171213
https://phabricator.wikimedia.org/p/ithinker143/ mass-emptying open UBN tasks on 20171214 (same user as https://phabricator.wikimedia.org/p/FiZie/ )

https://phabricator.wikimedia.org/p/238482n375/ - Sweeping changes to a collection of tasks. Biggest impact was setting bugs to secure only and removing subscribers, essentially hiding bugs from projects.

In T84#3592783, @mmodell wrote:

I could, theoretically, write a tool which walks a user's transaction history and systematically reverts every action of the user during a given time period...

Please! That would be fantastic

And now the latest example: https://phabricator.wikimedia.org/p/Vvjjkkii/ - Wrecked several thousand tickets, before they were disabled on 20180630.

At least now the bot is working on reverting (T198552), although it'd be faster if the bot didn't have to wait on the new rate-limits like users do.

What are we missing here? (snuff?)

Probably Comments are OK? Since https://secure.phabricator.com/D8945

Maybe the current issue is with who can use batch edits?

@valerio.bozzolan: What is still missing is covered by this tasks' subtasks (which often are non-public because WP:BEANS).

("snuff" in this case is basically "normal standards" - https://en.wiktionary.org/wiki/up_to_snuff)