Page MenuHomePhabricator

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

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 wrote on 2014-04-29 23:41:32 (UTC)

With T259: Bugzilla to Maniphest import script (tracking) created and the rest of "anti-vandalism features" being reproducible here, I'm closing this task as resolved.

Nemo_bis wrote on 2014-05-07 10:38:50 (UTC)

Possibility to delete comments in Maniphest filed upstream. What else?

At the very least, ability to:

  1. ban some email domains,
  2. throttle new users and IPs,
  3. mass delete/revert (nuke) all that a user did.

aklapper wrote on 2014-05-07 14:58:33 (UTC)

Valid requests, but just to provide a measure to compare, Bugzilla (and Gerrit, I think) do not provide any of these three functionalities either currently.

qgil wrote on 2014-05-07 15:33:51 (UTC)

It would be more useful to close this task (too generic) and then open tasks specific to any of these features.

aklapper wrote on 2014-05-16 20:18:10 (UTC)

It would be more useful to close this task (too generic) and then open tasks specific to any of these features.

+1. So the items in comment 34 should be turned into separate (upstreamed) items, I guess?

@Bawolff?

aklapper wrote on 2014-06-03 16:36:49 (UTC)

@Nemo_bis: Remaining items mentioned here:

  • ban some email domains,
  • throttle new users and IPs.

Has there been any incidents showing a need for such functionality in the past? I'm asking because I am not aware of any (maybe because I've only been around recently in Wikimedia) so please share your stories.

Right now in my humble opinion and for what I know about, I'd say we are fine here.

Rush wrote on 2014-08-27 16:49:05 (UTC)

Just a note there is an ability to do specific ip based rate-limiting (I believe it's in place by default but is pretty high). Banning email domains...what registration or emailing in or what is would be the ban behvior?

preamble script for rate limiting:

https://secure.phabricator.com/book/phabricator/article/configuring_preamble/#adjusting-rate-limiting

Unless there is an obvious 1:1 from bugzilla here I would vote we live with the default for a bit and see what we want to change.

Unless there is an obvious 1:1 from bugzilla here I would vote we live with the default for a bit and see what we want to change.

There is no 1:1 from Bugzilla and I agree with Chase: Let's wait and see.

Ragesoss removed a subscriber: Ragesoss.Oct 14 2014, 5:39 PM
Aklapper removed Aklapper as the assignee of this task.Oct 24 2014, 6:56 PM
Qgil raised the priority of this task from Low to Normal.Nov 17 2014, 3:03 PM
Qgil added a subscriber: Qgil.
revi added a subscriber: revi.Nov 24 2014, 3:44 PM
Qgil moved this task from To Triage to Need discussion on the Phabricator board.

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.

Qgil added a comment.Dec 12 2014, 9:35 AM

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).

Qgil added a comment.Mar 4 2015, 12:04 PM

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.

Tgr added a subscriber: Tgr.Mar 4 2015, 7:15 PM
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.

Tgr added a comment.Mar 4 2015, 10:39 PM

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 updated the task description. (Show Details)Jun 22 2015, 1:14 PM
Aklapper set Security to None.
Restricted Application added a subscriber: Luke081515. · View Herald TranscriptDec 28 2015, 9:34 AM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptJul 2 2016, 7:34 PM
Aklapper updated the task description. (Show Details)Aug 23 2016, 10:54 PM
Aklapper moved this task from Need discussion to Misc on the Phabricator board.Oct 7 2016, 5:12 PM

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

Base added a subscriber: Base.May 9 2017, 10:57 AM

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.

mmodell added a subscriber: mmodell.Sep 8 2017, 7:57 PM

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...

Aklapper added a comment.EditedDec 9 2017, 6:47 PM

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.

Teles added a subscriber: Teles.Jun 15 2018, 9:19 AM
jhsoby added a subscriber: jhsoby.Jun 15 2018, 9:27 AM

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

Dalba added a subscriber: Dalba.Jun 16 2018, 6:23 AM
Nirmos added a subscriber: Nirmos.Jun 16 2018, 11:55 AM
Ltrlg added a subscriber: Ltrlg.Jun 17 2018, 7:00 PM
Aklapper added a subtask: Restricted Task.Jun 20 2018, 11:18 AM
Aklapper added a subtask: Restricted Task.Jun 20 2018, 12:34 PM
Aklapper added a subtask: Restricted Task.Jun 20 2018, 12:43 PM
Qgil removed a subscriber: Qgil.Jun 22 2018, 6:53 AM
AfroThundr3007730 added a comment.EditedJul 2 2018, 1:15 AM

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.

Yann added a subscriber: Yann.Jul 4 2018, 1:23 PM
Aklapper closed subtask Restricted Task as Resolved.Jul 27 2018, 12:57 PM
Nirmos removed a subscriber: Nirmos.Jul 27 2018, 1:28 PM