987187 - Require wiki.mozilla.org users be confirmed before they can edit or create pages

Status: RESOLVED DUPLICATE of bug 1051201

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

Description

[Christie Koehler [:ckoehler]]

This is a temporary measure to address the huge volume of spam and vandalism currently happening on wiki.mozilla.org. The Wiki Working Group[1] is actively addressing this issue. See bug 986832 for more information, particularly bug 986832 comment 4.

Please update LocalSettings.php to require the "confirm" flag / user right [1] in order to edit or create a page.

BEFORE doing this, please let's confirm the process for how users can be confirmed.

[1] https://wiki.mozilla.org/Contribute/Education/Wiki_Working_Group

Comment 1

[Brandon Burton [:solarce]]

* Potential options
 * default group read-only, manual promotion to "editors" group
 * extension: http://www.mediawiki.org/wiki/Extension:ConfirmAccount
 * disable new user account creation for now and require manual intervention from IT/WWG

Comment 2

[Jason Crowe [:jd]]

Hi,

Just checking in to see if there has been any progress on the process of verifying new users. To be clear, we are simply holding off on making changes until we hear from you or the working group about this.

Thanks
Jd

Comment 3

[Christie Koehler [:ckoehler]]

I like the first option best (default group read-only, manual promotion to "editors" group).

The next steps seem to be:

1. create editors group
2. adjust user groups rights accordingly (e.g. remove create/edit from 'all' and possibly other groups)
3. identify which group can promote users to "editors" group and ensure there are enough users in that group who are prepared for regularly verifying users

Does that sound about right?

Comment 4

[Jason Crowe [:jd]]

Yes, that sounds quite right. Step one is technical in nature and quite quick. Step two can likely be done in short order if we all work together. It is step three that needs to be sorted, and in my estimation this needs to be sorted prior to implementing the first two steps.

Does this seem correct to you? If so how can we go about actualizing step three?

Comment 5

[Jason Crowe [:jd]]

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['user']['edit'] = true;
$wgGroupPermissions['user']['create'] = false;
$wgGroupPermissions['user']['move'] = false;
$wgGroupPermissions['user']['upload'] = true;
$wgGroupPermissions['user']['reupload-own'] = true;
$wgGroupPermissions['user']['reupload-shared'] = false;
$wgGroupPermissions['autoconfirmed']['create'] = true;
$wgGroupPermissions['autoconfirmed']['reupload-shared'] = true;
$wgGroupPermissions['autoconfirmed']['patrol'] = true;
$wgGroupPermissions['confirm']['create'] = true;
$wgGroupPermissions['confirm']['reupload-shared'] = true;
$wgGroupPermissions['confirm']['patrol'] = true;
$wgGroupPermissions['canmove']['move'] = true;
$wgGroupPermissions['canmove']['canmove'] = true;
$wgGroupPermissions['sysop']['move'] = true; 
$wgGroupPermissions['sysop']['rollback'] = true; 
$wgGroupPermissions['sysop']['canmove'] = true; 
$wgGroupPermissions['sysop']['autopatrol'] = true;
$wgGroupPermissions['sysop']['upload_by_url'] = true;
$wgGroupPermissions['sysop']['deleterevision'] = true;
$wgGroupPermissions['sysop']['deletelogentry'] = false;
$wgGroupPermissions['bureaucrat']['usermerge'] = true; 
$wgGroupPermissions['bureaucrat']['userrights'] = true; 
$wgGroupPermissions['bureaucrat']['browsearchive'] = true; 
$wgGroupPermissions['bureaucrat']['deletedhistory'] = true; 
$wgGroupPermissions['bureaucrat']['deletedtext'] = true; 
$wgGroupPermissions['bureaucrat']['move-subpages'] = true; 
$wgGroupPermissions['bureaucrat']['suppressredirect'] = true; 
$wgGroupPermissions['bureaucrat']['deletelogentry'] = true;
$wgGroupPermissions['bureaucrat']['tboverride'] = true;


$wgAutoConfirmAge =  5 * 3600 * 24; // 5 days to pass isNewbie()
$wgAutoConfirmCount = 10;   // and have ten edits

Comment 6

[Robert Kaiser]

:jd, is comment #5 current settings or a proposal?
I guess this would at least mitigate the spamming somewhat - it would not help against the defacing we have also seen recently, as those are edits from new users on existing pages.
That said, I almost find edits to existing pages worse than creating new pages, if in both cases irrelevant content is being inserted, as edits might also remove valid content at the same time.

Comment 7

[Jason Crowe [:jd]]

(In reply to Robert Kaiser (:[e-mail]) from comment #6)
> :jd, is comment #5 current settings or a proposal?
> I guess this would at least mitigate the spamming somewhat - it would not
> help against the defacing we have also seen recently, as those are edits
> from new users on existing pages.
> That said, I almost find edits to existing pages worse than creating new
> pages, if in both cases irrelevant content is being inserted, as edits might
> also remove valid content at the same time.

That is current settings. I posted that for ckoehler yesterday as we managed to have a face to face meeting. These settings are designed to give folks an idea of where things stand now so we can determine the best way to move forward in the short term.

Sorry for not posting any comment yesterday, the afternoon got away from me.

Regards

Comment 8

[Gordon P. Hemsley [:GPHemsley]]

Perhaps it would be helpful to bring the page patrolling to the forefront: Then, changes that are made by unconfirmed users would have to be patrolled and confirmed before they are made the default view of an article. That way, we have less of a risk of good content being surreptitiously removed.

Also, a reminder that full User Group Rights are available on the wiki:

https://wiki.mozilla.org/Special:ListGroupRights

Comment 9

[Gordon P. Hemsley [:GPHemsley]]

Also, here are the docs for user rights, including all the stock user rights that we have available to us:

https://www.mediawiki.org/wiki/Manual:User_rights

Comment 10

[Alison Wheeler [:AlisonW]]

> $wgAutoConfirmAge =  5 * 3600 * 24; // 5 days to pass isNewbie()

Whilst some spammy accounts get used the same day they are created, many are not; first getting used months afterwards (their intent to get AutoConfirm flag), thus any use of autoconfirm flag is pretty meaningless on wiki.m.o

> $wgAutoConfirmCount = 10;   // and have ten edits

Again, very easy to game and some spam accounts do do this. The opposite is also true - that many _real_ users (esp SuMo) will only edit a couple of times.

Basically, neither of these are practical tests for 'realness' on wiki.m.o (which is, yes, annoying)

Comment 11

[Jake Maul [:jakem]]

Do we still want this, or should we WONTFIX/INCOMPLETE this bug in favor of bug 1008487? The latter is good to go, pending a team to be in place to vet/vouch/confirm new accounts. :)

Comment 12

[Alison Wheeler [:AlisonW]]

Although part of bug 1008487 could solve the issue for new registrations it doesn't affect the 328k+ accounts already registered (figure from https://wikiapiary.com/wiki/MozillaWiki ) so I'd recommend we use the explicit confirm flag alongside other improvements.

Comment 13

[Christie Koehler [:ckoehler]]

Here's how I interpret the current settings:

user: edit and upload media but not create
autoconfirm: create
confirm: create

Is that correct? 

What is the difference between 'autoconfirm' and 'confirm' in this context? By what are users added to each of those groups under the current configuration?

The information on this page is unclear:
https://wiki.mozilla.org/MozillaWiki:Autoconfirmed_users

Is there an exception for userpages? It seems like a lot of spam is being generated there.

Comment 14

[Christie Koehler [:ckoehler]]

Okay, this explains Autoconfirmed_users:
http://www.mediawiki.org/wiki/Manual:Autoconfirmed_users

Comment 15

[Christie Koehler [:ckoehler]]

Okay, it seems like we should disallow all editing and uploading for the 'user' group as well as 'autoconfirmed' and add it to 'confirm'. Does that sound about right?

Comment 16

[Robert Kaiser]

I'm actually not sure if it's a good idea to not let new users create new pages. How does this play together with bug 1008487?

Comment 17

[Christie Koehler [:ckoehler]]

(In reply to Robert Kaiser (:[e-mail]) from comment #16)
> I'm actually not sure if it's a good idea to not let new users create new
> pages. How does this play together with bug 1008487?

Bug 1008487 only addresses new accounts, not existing ones. We have 300k+ accounts, many of which were created for the sole purpose of spam. If we don't change the settings for non-confirmed but logged in users, those accounts could still be used to create spam. I'm happy to find another way to deal with those accounts. Any suggestions?

Comment 18

[Robert Kaiser]

Hrm, hard issue as we also have some of those new users that are legitimate people who created their Firefox Club pages or just registered an account without doing much yet.

Comment 19

[Alison Wheeler [:AlisonW]]

This is, basically, why I created the entirely separate "confirm" flag; the auto-confirm is utterly ineffective as it is applied automatically (ie to a majority of spam accounts). 

New accounts *which we personally add/authorise* are probably fine to let create new pages (we'll immediately see if they spam so can block, though hopefully that won't be required).

I haven't been through and checked / updated the 'confirm' list for a while, but I can put some time aside tomorrow (hopefully) to catch the last month's worth of valid newcomers. 

Summary: "User" and "autoconfirmed" are redundant for our purposes - ie can read but nothing else
"Confirm" is added as a manual task, and should allow editing and creating of article and talk pages.

Comment 20

[Alison Wheeler [:AlisonW]]

On the perms:
$wgGroupPermissions['*']['createaccount'] = true;
so that someone can create the account they want to request permissions for (unless an out-of-band creation route is used)

All these should become 'false'
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['upload'] = false;
$wgGroupPermissions['user']['reupload-own'] = false;
$wgGroupPermissions['autoconfirmed']['create'] = false;
$wgGroupPermissions['autoconfirmed']['reupload-shared'] = false;
$wgGroupPermissions['autoconfirmed']['patrol'] = false

I'd suggest the following:

$wgGroupPermissions['confirm']['edit'] = true;
$wgGroupPermissions['confirm']['create'] = true;
$wgGroupPermissions['confirm']['move'] = false;
$wgGroupPermissions['confirm']['upload'] = true;
$wgGroupPermissions['confirm']['reupload-own'] = true;
$wgGroupPermissions['confirm']['reupload-shared'] = false;
$wgGroupPermissions['confirm']['patrol'] = false;

at least initially. If everything goes ok then reupload-shared can be OK'd. "patrol" is probably redundant on mozwiki as most content is by/for specific sets of users, so only they would know whether the content was accurate.

Comment 21

[Robert Kaiser]

I hope the same flags restrict creating or editing user pages. Probably at least half of our spam pages are user pages at this point.

Comment 22

[Alison Wheeler [:AlisonW]]

We could separate out the ability to create user pages from main pages, but going the manual confirmation route for all users should solve these both at the same time. (The usual OP for a spammer is to create a spammy user page then some moments later a spammy article page)

Comment 23

[Alison Wheeler [:AlisonW]]

As an update, the change to requiring registrations has improved the number of *new* accounts (though it remains to be seen what they do once they have access, of course) but does nothing for those many thousands who are already registered. We need to switch on use of the 'confirm' flag to step them (and they are still spamming)

For the record, sfaict all users who have validly edited since I started creating the confirm flag last year now have it set against their user account: I updated the flags yesterday using https://wiki.mozilla.org/index.php?title=Special:ActiveUsers . You can see the list of confirmed users at https://wiki.mozilla.org/index.php?title=Special:ListUsers&group=confirm

Comment 24

[Gordon P. Hemsley [:GPHemsley]]

Moving this back to us until we decide how we want to proceed here.

Comment 25

[Gordon P. Hemsley [:GPHemsley]]

Duping this is favor of the greater overhaul going on in bug 1051201.