Wikipedia:Quasi-protection

Problems with Semi-protection
The addition of semi-protection has proven to be extremely beneficial in fighting vandalism. However, vandals have been circumventing the restriction by creating multiple sleeper accounts - accounts that are registered beforehand and do not edit until they are needed, waiting sufficient time (currently four days) in order for them to edit semiprotected pages. Vandalbots have been doing this frequently, attacking articles linked from the Main Page continuously. The attacks continue even with semi-protection, as the sleeper accounts are greater than four days "old", and prove to be extremely damaging to Wikipedia. (For example, see this page from the history of Tenebrae (film), which was the featured article on May 27, 2006.) These relentless attacks not only force full protection at times, but are also extremely damaging to Wikipedia's reputation. The replacement of a page with an offensive image and message may offend many people who come to read the article highlighted on the main page. In effect, by creating sleeper accounts, vandals have managed to effectively circumvent semi-protection and sometimes even force full protection, both of which should be used as sparingly as possible on articles linked from the Main Page.

Reasoning
These sleeper accounts share a trait in common - the majority of them lack any edits. During the proposal and discussion of semi-protection, the number of edits was discussed as a possible criterion for semi-protection: accounts with fewer than a certain number of edits, in other words, would not be able to edit a semi-protected page. This idea was not implemented because of technical reasons; MediaWiki currently does not keep track of a user's number of edits, and implementing semi-protection with regards to the number of edits would require a change in the software. Instead, semi-protection was developed by limiting users based on the account's age, which was already tracked in the software.

Proposal
However, now that it has been demonstrated that semi-protection can be circumvented by the use of sleeper accounts, it is time to consider another change in the software to combat vandalism and offer Wikipedia more protection. This proposal would separate the current level of "registered users" into two levels: new users and distinguished users. Both would, in essence, be the same as the current registered users, but distinguished users would have the technical capabilities to edit quasi-protected pages.

Administrators would have the right to promote new users to distinguished users, and this would be done quite liberally. Anyone with a "history" of good edits - for instance, 10 non-vandalism edits - would be promoted to "distinguished user". Administrators would also have the right to remove the status of "distinguished user". In essence, a "distinguished user" would effectively limit sleeper accounts. Because most sleeper accounts, created by automated robots, have no "good" edits, administrators would know not to promote the users. In addition, because the process would not be based on techical means, administrators would be able to recognize situations where the user has vandalized or performed like a bot. This would ensure that vandalbots could not make several rapid, but trivial, edits, and automatically be promoted to "distinguished" user.

Along with the introduction of distinguished users, quasi-protection would become another level of protection to fight against vandalism. Quasi-protection would allow anyone - distinguished users, administrators, etc. - to edit the page that was quasi-protected, with the exception of new users. Quasi-protection would be used sparingly, just like semi-protection, and be reserved to cases of articles currently undergoing vandalbot attacks. This would ensure the stop of the vandalbot attack, as the sleeper accounts would not have made any prior edits and would not have been approved to distinguished user.

Considerations
Of course, this proposal also has several drawbacks. First, the proposal would require a change in MediaWiki software. However, if the community shows support for this and demonstrates that the change will be greatly useful to Wikipedia, this could be done, just as semi-protection was technically implemented after a period of discussion and strong support. Second, administrators would have the extra responsibility of promoting users to distinguished users. However, with a centralized place for such requests and the easiness of being promoted, this should not take much additional effort on the part of each individual administrator. In addition, because quasi-protected pages would be extremely rare and sporadic, requests to become such users would not be great at all times, as it offers no benefits except to edit pages that are quasi-protected. Finally, this proposal does not effectively eliminate the threat of sleeper accounts, as they could easily make several "good" edits and then be promoted to distinguished user. However, it offers a great improvement over the current semi-protection, as vandals could not automatically create accounts and have them promoted; it would require more than automation to make "good" edits, slowing down the vandal and in the process improving Wikipedia (of course, users with vandalism would not be given distinguished user status).

Thus, quasi-protection has the potential to offer many benefits to Wikipedia with few drawbacks. Please discuss this proposal on the talk page.

Other proposals
This proposal never gained consensus, but pieces of it have been implemented in Wikipedia. Becoming autoconfirmed requires ten edits in addition to four days. An edit filter can disallow changes to an article based on a user's edit count; some filters trigger for all accounts with fewer than 100 or 500 edits. A page that has been pending changes protected may be edited by anyone, but only users in the reviewer group can accept a revision to be shown to anonymous visitors.

Links

 * Semi-protection
 * Village pump (proposals)
 * Village pump (technical)

New User log stats
Add the following to your monobook (in default monobook skin) to add tabs (including edit check) to your New User log page: //New user log tools document.write(' '); //END