Page MenuHomePhabricator

Make sure anti-vandalism features are up to snuff
Open, MediumPublic

Description

Tasks filed upstream:

We should verify that anti-vandalism tools are available. Ideally we would be able to get rid of the notion of "editbugs" that we use in bugzilla

Details

Reference
fl146

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil raised the priority of this task from Low to Medium.Nov 17 2014, 3:03 PM
Qgil added a subscriber: Qgil.

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

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.

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?

Aklapper set Security to None.

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.

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.

Aklapper closed subtask Restricted Task as Resolved.Jul 27 2018, 12:57 PM
mmodell closed subtask Restricted Task as Resolved.May 14 2020, 1:33 AM