1065849 - Create autopromote group and setting for inactive users

Status: RESOLVED FIXED

(Websites :: wiki.mozilla.org, defect)

Comment 1

[Christie Koehler [:ckoehler]]

The purpose of this setting is to provide some protection against dormant spam accounts. We've noticed a pattern where by a spam account is created but creates no pages until several months later. 

I think the autopromote[1] setting should be:

$wgAutopromote = array(
	'inactive' => array('&',
		array( APCOND_AGE, 15768000 ),
		'!',
		array( APCOND_EDITCOUNT, 5 )
	),
);

Meaning, you'll be considered part of the 'inactive' group if your account was created more than 6 months ago and you've NOT made at least 5 edits. Both the values of 6 months and 5 edits are somewhat arbitrarily chosen. Perhaps we set APCOND_AGE to $wgAutoConfirmCount?

And then the permissions revoked[2] for this group should be as follows:

$wgRevokePermissions['inactive']['createpage'] = true;
$wgRevokePermissions['inactive']['createtalk'] = true;
$wgRevokePermissions['inactive']['move'] = true;
$wgRevokePermissions['inactive']['movefile'] = true;
$wgRevokePermissions['inactive']['move-subpages'] = true;
$wgRevokePermissions['inactive']['upload'] = true;
$wgRevokePermissions['inactive']['reupload'] = true;
$wgRevokePermissions['inactive']['reupload-own'] = true;

Users in this group will be able to edit pages, their watchlists and usercss. This preserves the functionality of the wiki for those users who simply want to follow along.

According to the documentation: "Autopromotion doesn't actually add users to a group; MediaWiki will check whether a user meets the conditions for autopromotion whenever it checks the user's rights or effective groups."

So, if a non-spam user finds themselves an implicit member of this group, all they need to do is make some legitimate edits to pages and whatever permissions are available to them based on their other group membership will apply.

[1] https://www.mediawiki.org/wiki/Manual:$wgAutopromote
[2] https://www.mediawiki.org/wiki/Manual:$wgRevokePermissions

Comment 2

[Gordon P. Hemsley [:GPHemsley]]

This seems way more generous than my original plan, but it could work.

Comment 3

[Christie Koehler [:ckoehler]]

(In reply to Gordon P. Hemsley [:GPHemsley] from comment #2)
> This seems way more generous than my original plan, but it could work.

In what way? How would you change the time window and/or number of edits?

Comment 4

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Christie Koehler [:ckoehler] from comment #3)
> (In reply to Gordon P. Hemsley [:GPHemsley] from comment #2)
> > This seems way more generous than my original plan, but it could work.
> 
> In what way? How would you change the time window and/or number of edits?

Actually, I take that back. It's less generous in its criteria, but it's more generous in its user rights.

These settings seem liable to catch a number of legitimate users, which means we have to worry about making sure that they still have some rights that they might want to use even if they don't edit.

My thought was to make it the barest of bones (just one edit) to easily catch the most obvious of spammers, and to then revoke all modification rights, including editing: That is, make it permanent without bureaucrat/admin intervention. My thought was that this would be a quick measure to prevent reactivation of existing sleeper spambots, not necessarily prevent future ones.

But that doesn't mean I think this is a bad idea. Just wanted to get that down in writing so we can think about it further. (I also want to double check that there aren't other useful statistics that we could be using to make this determination.)

Oh, and BTW, I think there's an error or two in your syntax.

Comment 5

[Christie Koehler [:ckoehler]]

Attachment: auto_promote_settings.php

Proposed settings for autopromote.

Comment 6

[Gordon P. Hemsley [:GPHemsley]]

Comment on attachment 8493917 [details]
auto_promote_settings.php

r+ per f2f discussion, with edit count dropped to 1.

Comment 7

[Christie Koehler [:ckoehler]]

Attachment: final autopromote settings

final autopromote settings

Comment 8

[Christie Koehler [:ckoehler]]

Attachment: auto_promote_settings.php

Conditions for autopromote should now be in the form that mediawiki expects. (Previous version caused stacktrace on dev.)

Comment 9

[Gordon P. Hemsley [:GPHemsley]]

Attachment: auto_promote_settings_v4.php

I'm gonna be nitpicky and say that I'd prefer it presented in this format (or something similar).

Note that no substance has actually changed (unless you count the comment text).

Comment 10

[Christie Koehler [:ckoehler]]

Comment on attachment 8495613 [details]
auto_promote_settings_v4.php

This works as intended in my local dev instance of MozillaWiki.

Comment 11

[C. Liang [:cyliang]]

This change has been pushed to dev, stage, and prod wiki environments.
This change was tested in dev.