Wikipedia:Non-administrator rollback

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Introduction

Background

• WP:Rollback - Explains the existing rollback feature, which is limited to administrators only
• Wikipedia:Requests for rollback privileges (Talk) - A similar proposal, first proposed June 2005, declared rejected Sep 2006

Recent events

• Wikipedia:Rollback for non-administrators (Talk), page moved from User:Ryan Postlethwaite's personal space to project space 9 January 2008.
• Wikipedia:Rollback for non-administrators proposal (Talk), page created 9 Dec 2007

This page

• Began as a single proposal
  • Currently titled "Main proposal" below
  • Original form (it has evolved somewhat since then)
  • Included a straw poll
    • Around 450 total top-level responses (not counting replies) and over 200 kilobytes of text
• Various alternate proposals, which have been archived.
• An attempt ideas for a new proposal was started (current status unclear)
• Some discussion which originally took place on this page was later moved to the matching talk page, and was later archived.
• Some specific counter-proposals may still be undergoing discussion on this page.
• See the talk page for current general discussion.

Original proposal

The rollback feature allows intentionally unconstructive contributions to be reverted quickly and more efficiently than with other methods. (User scripts have been written which mimic the functionality of rollback, but they merely hide details from the user, and are much less efficient, both in terms of bandwidth and time). Rollback links are displayed on page histories, user contributions pages, and diff pages.

Clicking on the link reverts to the previous edit not authored by the last editor. An automatic edit summary is provided and the edit is marked as minor. (An error message is returned if there is no last editor to revert to).

Rollback is currently only available to administrators. However, many non-administrators now deal with vandalism regularly, but do not have access to this tool – and either do not wish to be administrators or do not meet the expected standards, yet are unquestionably experienced and trustworthy. This proposal would implement a process by which the rollback feature could be granted to, and revoked from, non-administrators.

The point has now come where we have a rough consensus as to what the restrictions should be in place, and the community is now asked to look at forming a consensus as to its implementation. See past discussion at Wikipedia talk:Rollback for non-administrators proposal and Wikipedia:Rollback for non-administrators. Your questions or concerns may already have been considered there.

The way it works

Users may request the rollback button should they suffice in having the minimum requirement as detailed below.

1. They should first put a request in at the section below.

   (In what section below? All I see here is votes and discussions, what I would expect to see on a talk page. --Stéphane Charette (talk) 19:42, 4 January 2008 (UTC))

2. Administrators should check the history of the contributor to see if they can be trusted with the tool.

   (What exactly are admins checking for? I worry lack of any statement or consensus on this will cause confusion. —DragonHawk (talk|hist) 21:02, 4 January 2008 (UTC))

   Isn't this how RFA started? We checked users contribs to check if they could be trusted? How is this process going to differ? What happens when two admins disagree? For example, if I give user:foo rights but admin z doesn't think they are trustworthy? Do we then have a discussion, and then we've reinvented RFA, this time as RFR? - Hiding T 12:53, 8 January 2008 (UTC)

3. If the administrator is satisfied, they can then go to Special:Userrights (see $wgAddGroups and $wgRemoveGroups) and this will add the user into the rollback usergoup, giving them the rollback tool.
4. The tool will be the same as the administrator rollback tool, with no limitations.

   Should there be a consensus of admins before this is implemented since it will radically alter their role? - Hiding T 22:28, 8 January 2008 (UTC)

Requirements for users to have rollback

There are no prerequisites per se for getting the tools, although a user should not have a history of edit warring and should show a need for the rollback permission (i.e. lots of vandalism reversion). Although it may not be easy to determine this, administrators should evaluate requests for rollback on individual merit and review a user's edit history before granting them the permission.

Usage

This tool is provided to qualified editors for fighting vandalism. Usage is limited to rolling back vandalism and reverting one's own edits. Editors using the rollback tool for other purposes or who make repeated errors will be subject to having the rollback tool removed.

Removal of the permission

In the event of abuse, any administrator may remove the tool by going to Special:Userrights. Non-administrators may report abuse to Wikipedia:Administrators' noticeboard/Incidents. Administrators should be careful to give such an action the same due care and attention as a block, and the usual expectations with respect to administrative actions apply. If they only get removed because of abuse, just give them to all editors. - Hiding T 22:59, 8 January 2008 (UTC)

FAQ

What is rollback?

Rollback is a method for reverting edits with a single click. Users with the rollback privilege see a "[rollback]" link appear on diffs, and next to edits on Special:Contributions pages and in page histories, providing that the edit is the most recent edit made to the relevant page. Rollback will revert to the most recent version of the page not contributed by the most recent editor.

How does rollback differ from other reverting methods?

Traditional reverting involves loading the revision of the page that one desires to revert to, opening the edit tab and then immediately saving the page. The page's contents will be replaced with the contents of the old revision. Reverting with the undo feature involves loading a diff and clicking on the "undo" link; the changes made in the diff will be undone, provided there are no conflicts with later revisions of the page. There are a number of user scripts available for reverting, which typically involve automating the traditional reverting method.

By contrast, rolling back an edit does not involve any such intermediate steps. As such, it offers a slight performance benefit for both server and client. Because it can be done directly from a Special:Contributions page, it makes reverting all the edits made by a given account or IP address relatively simple.

What are the limitations of rollback?

Rollback is limited to reverting only the most recent edits made to a page. Users will still need to learn and use another method in order to revert any other edits.

Because rollback does not necessitate the user to actually view the edits that they are reverting at any stage, there is a greater risk that users can mistakenly perform reverts. The undo feature, by contrast, shows the user the changes they are about to effect for confirmation.

The rollback feature supplies an automatic edit summary when rolling back an edit, which cannot be changed or supplemented by the user. Both traditional reverting and undoing allow an edit summary to be supplied, as do most user scripts for reverting.

Rollback's speed can also be a disadvantage if it is misused, since it can greatly speed up edit wars.

How do these pros and cons relate to giving rollback to non-administrators?

Many non-administrators are regularly engaged in vandalism reversion, and the rollback feature can make this task far more efficient, since it is a one-click operation, as opposed to methods which require the loading of intermediary pages.

However, because rollback does not allow users to check what they are reverting (not true; see popups) or provide an edit summary, it presents the risk of accidental misuse, and because it is a one-click operation that allows all the contributions of a user or IP address to be quickly reverted, it presents the risk of intentional misuse. These risks naturally increase in a user base that is larger and/or less experienced in identifying and dealing with vandalism.

Are these problems unique to the rollback tool?

No; other methods of reverting can be similarly misused. However, as long as rollback is used for its intended purpose - reverting simple vandalism - there should be no problems. The issue is making sure that a potential rollback user can reliably distinguish simple vandalism from other edits and can be trusted to use rollback only on the former.

Revision history

Significant changes to this proposal are recorded below. The total number of top-level Support/Oppose comments at the time of the change is indicated in parenthesis.

• 30 Dec 22:58 (0): Created
• 30 Dec 22:58 (4): Specific criteria for rollback grant removed
• 30 Dec 23:56 (8): Limit rollback usage to vandalism only
• 31 Dec 10:28 (27): Remove strong warning concerning admins granting/revoking rollback rights
• 31 Dec 10:40 (28): Require "lots of vandalism reversion" to get rollback
• 4 Jan 04:51 (74): Arguments and counter-arguments section added
• 4 Jan 15:01 (155): Arguments and counter-arguments section rewritten as FAQ

Straw poll

Closed and archived. See Wikipedia:Non-administrator rollback/Poll for results.

Alternative Proposals

These alternative proposal discussions have been moved to an archive, and can be found here.

Count the Mistaken

This discussion has been moved to the talk page, and can be found here.

Scripts and other tools

proposal originally made by Gracenotes

Nearly everyone here has no objection to tools like Twinkle being broadly used, but many have objections to adding the [rollback] button to the user interface. So give autoconfirmed users the technical ability to rollback, an action which requires a unique token, but do not include the rollback button on diff, history, or user contribution pages (i.e., do not include it at all). In this case, rollback can only be accessed with a third-party tool like Twinkle, which everyone seems to agree is fine. The I/O speed and bandwidth issues are solved, and since custom summaries are possible with the rollback permission, there is no loss in the functionality of Twinkle (or other anti-vandalism tools).

Support (tools)

1. Per my comments on Wikipedia talk:Non-administrator rollback#Another idea. -- Ned Scott 08:58, 9 January 2008 (UTC)
2. Per my response at Wikipedia talk:Non-administrator rollback#Another idea and Amidaniel's and my comments at #wikimedia-tech on freenode. -- Cobi^(t|c|b) 10:58, 9 January 2008 (UTC)
3. As I've stated before, the requirement that users "switch on" the tool for themselves and have some technical knowhow regarding it beforehand is a good safeguard. Equazcion •✗/C • 11:35, 9 Jan 2008 (UTC)

   Safeguard against what exactly? Not the vandals, surely... Миша13 23:32, 9 January 2008 (UTC)

   People who wish to intentionally make mass disruptive edits could just as easily use a script or a bot. -- Ned Scott 00:18, 10 January 2008 (UTC)

4. Strong suppport pending the feasibility of such a feature (can a script "unlock" or access a server feature?). Well done. I think that this proposal will have more of a chance to pass. Ultimately, nothing changes, but efficiency. As TWINKLE requires no authorization, this proposal will not create any new bureaucracy, and will not give any extra power to admins. Actually, I will be surprised if this feature receives more than a few select votes for oppose. This would also solve the Bot proposal, which seems to have large consensus (see below). It would cover a need for credentials, in that the user would have to be experienced enough to know how to use user scripts, and what they can be used for. So long as TWINKLE et al exists, rollback abuse will never go away, so the argument of rollback abuse is null. In my opinion, this is what we have been looking for, the solution to all issues. (Sorry if I seem so enthusiastic, but it just seems so simple, and yet so brilliant).--Vox Rationis (Talk | contribs) 14:41, 9 January 2008 (UTC)
5. No new bureaucracy? You have my (unexpected) support. You might just have cut the Gordian knot.--Doc^g 20:10, 9 January 2008 (UTC)
6. Support. Really this is change deep in the sausage making. It's a technical improvement, not really a policy change. Perhaps it would just be better to accept that bad people can be disruptive with or without and just give it out.. but if people won't accept that, at least this is a step forward. --Gmaxwell (talk) 20:21, 9 January 2008 (UTC)
7. Support this or an option in user preferences that has to be turned on by the user (I thought amidaniel was working on that...) Mr.Z-man 20:34, 9 January 2008 (UTC)
8. Support Good idea, Majorly (talk) 20:39, 9 January 2008 (UTC)
9. Support addresses my concerns with the original proposal. Concerns that this could facilitate vandalism are overblown. --Haemo (talk) 23:10, 9 January 2008 (UTC)
10. Pomte 13:33, 13 January 2008 (UTC)
11. Hell yes! As I've said before, we need tools like these. Two One Six Five Five ^{discuss my greatness} 15:13, 17 January 2008 (UTC)
12. Strong Support for the simple reason that it eases everyone in editing. It is not a security threat because, although it also eases editing for would be vandals, vandals can still do what the rollback function does, it just takes them more time. And it is not only them whose time are being inefficiently used, it is also those vandal-fighters. -- Felipe Aira 08:46, 30 January 2008 (UTC)

Oppose (tools)

1. Hell no! Regardless whether it's doable or not (see my question in discussion section), it's "security" through obscurity at it's purest, which I loathe by definition. No, thanks - if doable with Twinkle then it's just as doable with Greasemonkey (which you can't shut down for a user) and then welcome to Wikipedia where each vandal has access to rollback if he pleases. Hey, why bother with scripts at all? Just make the link class="rollback-hidden" which defaults to .rollback-hidden { display: none; } in sitewide CSS. Then it's just one line in your .css to enable it - call hacking your monobook "credentials" if you will. Миша13 21:01, 9 January 2008 (UTC)

   It would still be removable when abused, so it's actually better than such scripts alone. -- Ned Scott 22:11, 9 January 2008 (UTC)

   Um, excuse me? CSS can just as well be overridden with a one-liner GM script that does (roughly) document.write('<style type="text/css">.rollback-hidden { display: inline; }</style>') or something to that effect (or I could just disable CSS in my browser altogether). Sorry, but hiding features != disabling them. Whatever is hidden can be uncovered and you have no control over what the client does. Миша13 22:34, 9 January 2008 (UTC)

   Rollback can be removed from a specific account completely. If anyone is abusing it, be it via TWINKLE or their own CSS modification, we can turn it off for them. -- Ned Scott 00:14, 10 January 2008 (UTC)

   I understand your concern about "security through obscurity," and I believe that it is a valid one. However, since user scripts already have rollback, every vandal could potentially have access to rollback anyways. All this proposal does is make it more efficient. Also, do we have any reported cases of vandals user TWINKLE et al for vandalism? My experience, is that most vandals are IP addresses, and those who make accounts rarely get into any sort of intelligent vandalism (the kind that does a lot of harm, like mass page moves, etc). Also, assuming a vandal does get his hands on this, it will be easier for people to revert him, because others will have rollback as well. Now, assuming the above statements, this feature would bring us a very small number of elite vandals armed with a slightly more efficient rollback, against a large number of RC patrollers, with a slightly more efficient rollback. By sheer numbers, this efficiency has a large multiplier, compared to the small multiplier of the vandal. Again, this assumes we have ever had a case of rollback-user-script-assisted vandalism in the past, which, while I (obviously) can not know for sure, in my experience I haven't seen such a thing done.--Vox Rationis (Talk | contribs) 22:19, 9 January 2008 (UTC)

   No, such outbreaks have not occurred in the past (at least not to my knowledge) simply because, as some put it, Twinkle-like methods take ages to do a single revert, which coupled with the server latency makes such en masse disruption unfeasible. However, what this proposal puts forward is basically making it entirely possible for a vandal to make reverts at rates of hundreds per minute (just open someone's contribs, fetch rollback tokens and start Ctrl-clicking rollback links). And don't say we can afford that because we have more patrollers - when 10s of them suddenly start fighting and conflicting over reverting the vandal, it won't be pleasant for the servers. Миша13 22:34, 9 January 2008 (UTC)

   I just blanked my sandbox, and then reverted it. It took 1.8 seconds, (I timed it on my stopwatch, so some inaccuracy, accounting for reaction time, probably 1.5 seconds). Assuming they use a firefox plugin like Linky, which can open all links on a page in a new tab at once, presto, they created a massive reversion, already doing 500(maximum number of articles viewed at once on user contribs page) in well under a minute (assuming their internet connection holds, the WP servers hold, and their RAM holds). Long-story-short: TWINKLE is not all that slow, and so the performance boost would not be all that notable for it to affect WP's vandalism quantity.--Vox Rationis (Talk | contribs) 23:07, 9 January 2008 (UTC)

   Thank you for those estimations. Unfortunately, this makes things only worse - what if (given that rollback tokens are prefetched) rollback can run at, say, 5000 per minute - care to verify that? Do you also keep in mind that revert summaries are editable? Can be faked? "Reverted edits by <insert IP> to last version by <insert admin>" - this looks like I'm reverting pesky IPs to admin-approved versions! Who will suspect any mischief? Oh, wait, I could run that on 10 different usernames to further blend the disruption. Yes, we're talking quite "elite" vandalism here, but if I am capable of this, so can be any determined and technically-inclined vandal. My main point is, don't give the vandals our own weapons against them. At all. Миша13 23:26, 9 January 2008 (UTC)

   Rollback can only run at five per minute for non-admins, and five per two minutes for non-autoconfirmed users. This rate is imposed by the software, and cannot be overridden. Security through obscurity is not the objective of this proposal; unintentional misuse of rollback by newcomers is. Gracenotes^T § 16:14, 11 January 2008 (UTC)

   No comment on the rest, but to jump in, vandals have used twinkle in the past to vandalize more quickly/efficiently. The first time I saw it was Undercity (talk · contribs) who used twinkle to revert back to his vandalized page, then warn those who reverted him.[1] - auburnpilot talk 00:30, 10 January 2008 (UTC)

   My main concern about giving the rollback to all autoconfirmed users is that not very many new editors are aware that twinkle exists. Most users who would use it for disruptive purposes are blocked and have left or moved on to another sockpuppet before they have a chance to learn that twinkle even exists. Vandals are too busy replacing pages with "he is gay homo with a small dick" to bother learning about how to contribute constructively, and tools which can aid in that process. By including it as part of the default account you make it so it is visible, directly under a vandals nose. Its like leaving your car unlocked on a busy street and leaving your wallet and your rolex on the seat. It is very much a security through obscurity system as Misza mentioned above. That is why I opposed both the proposals similar to this one, and will likely oppose this one unless someone can explain to me how this is likely not to be abused. --Nn123645 (talk) 05:52, 10 January 2008 (UTC)

• Object - simply because it seems silly. Enable a feature but hide it? Might as well just give it to everybody if the feature is there -Halo (talk) 17:09, 11 January 2008 (UTC)

Neutral (tools)

Discussion (tools)

Please excuse my ignorance with regard to MediaWiki's inner workings, but is the rollback token really computable on the client side (given a diff URL, for example)? I was delving into this issue (and MediaWiki code) quite some time ago and came up with a conclusion that it is based on a salt that is only stored on the server-side. Was that conclusion incorrect? Quite frankly, if it were computable on the client side, I fail to see the token's purpose at all. Миша13 20:29, 9 January 2008 (UTC)

I assume it's meant that this would operate on the API level only. I'd assume, that'd require at least one pre-fetch, for the rollback token (I.e. something like http://en.wikipedia.org/enwiki/w/api.php?action=query&prop=revisions&rvtoken=rollback&titles=User:SQL ). This already works, btw, check it out... It'll give you a valid rollback token :) SQL^{Query me!} 20:51, 9 January 2008 (UTC)

Hmm, so we're basically talking about using rollback to cut down on server requests from 3 (fetch diff, fetch edit form using &action=undo, post reverted content) to 3 (fetch diff, fetch rollback token, "click" rollback URL)? :) Oh wait, we're saving some bandwidth by not having to post the reverted content. Yay, did I miss something? </sarcasm> Oh, and I'm still waiting for a definitive reply whether the token is computable client-side. Миша13 21:10, 9 January 2008 (UTC)

Present steps to rollback (Let's say... WP:ACC, at random).

1. Grab diff (45956 bytes)
2. Grap undo url (81946 bytes)
3. Send previous page text (4643 bytes)

For a total of: 132545 bytes

Proposed steps (if I follow you correctly, same page)

1. Grab diff (45956 bytes)
2. Grab rollback token (372 bytes)
3. Send rollback URL (151 bytes)

For a total of: 46479 bytes

That's a 65% savings in bandwidth, assuming the cookies and whatnot are the same between requests, assuming I've got all this right. SQL^{Query me!} 21:51, 9 January 2008 (UTC)

Anti-vandalism bots

I'm closing this, because it's already been acted on: [2] [3] . —Random832 19:49, 10 January 2008 (UTC)

Whether or not the original proposal passes (I hope it does):

I propose we give rollback to the anti-vandal bots (ClueBot, VoABot II, CounterVandalismBot, and the currently defunct MartinBot). There is no chance of abuse, and no one would be able to tell the difference because the bots would give their own edit summary when requesting rollback (currently an obscure feature of rollback). It would just be easier on the bots and the servers (both the WMF servers and the servers the bots run on) as these bots make thousands of reverts every day. -- Cobi^(t|c|b) 02:38, 7 January 2008 (UTC)

Support (bots)

1. As nominator. -- Cobi^(t|c|b) 02:38, 7 January 2008 (UTC)
2. Support if only the bots get rollback Alexfusco⁵ 02:45, 7 January 2008 (UTC)
3. Support both ways. Portia1780 (talk) 02:53, 7 January 2008 (UTC)
4. Support If anyone needs the rollback tool to improve server strain, then these bots certainly do... just think how much more work we'd have to do if they were not beavering away all hours of the day and night. -- Geoff Riley (talk) 02:55, 7 January 2008 (UTC)
5. The bots are going to do the rollback whether they have this or not, so some of the opposition based on bots messing up doesn't make much sense. Mr.Z-man 04:09, 7 January 2008 (UTC)
6. Support Bots needs this function to reduce server's bandwidth usage. Carlosguitar ^{(ready and willing)} 04:23, 7 January 2008 (UTC)
7. Full support as part of WP:BAG β^_command 04:31, 7 January 2008 (UTC)
8. Support the RC checking bots need all the help they can get. BJ^Talk 04:44, 7 January 2008 (UTC)
9. Strong Support anything that makes the all-mighty ClueBot work better is something that should implemented. --Nn123645 (talk) 05:37, 7 January 2008 (UTC)
10. (BAG member) Conditional Support. I support granting this priv to these accounts if there is a system in place for granting and revoking this priv. I do not support creating a new method just to accommodate these accounts at this time. (I also do not support just making them +sysop at this time either). — xaosflux ^Talk 06:06, 7 January 2008 (UTC)
11. Support. I can't think of any likely drawbacks. If there were any, it would be pretty easy to revoke the privileges of a grand total of three bots. Rivertorch (talk) 06:48, 7 January 2008 (UTC)
12. Strong Support regardless of whether the main proposal is implemented (which it should be, IMO) -- this is a brilliant idea, and it should be implemented as speedily as possible. Ashdog137 (talk) 08:32, 7 January 2008 (UTC)
13. Conditional support, only in case it's stated in the edit summaries reverts were made by bots and not common users. --Angelo (talk) 09:30, 7 January 2008 (UTC)

    The edit summary will be exactly the same as it is now (Reverting possible vandalism by Special:Contributions/USER_REVERTED to version by USER_PREVIOUS. False positive? report it. Thanks, ClueBot. (MySQL-ID) (Bot)), using the obscure feature of rollback to provide the bot's own edit summary. -- Cobi^(t|c|b) 10:00, 7 January 2008 (UTC)

14. Support If there's a group that most definitely deserves the rollback, it's these anti-vandal bots. No reason not give them an extra performance boost. Spellcast (talk) 13:40, 7 January 2008 (UTC)
15. Support - I don't see any problems with this. Burzmali (talk) 13:41, 7 January 2008 (UTC)
16. Support --Quintote (talk) 14:16, 7 January 2008 (UTC)
17. Support, seems obvious to me... SQL^{Query me!} 16:37, 7 January 2008 (UTC)
18. support arguments against this are silly. —Random832 16:42, 7 January 2008 (UTC)
19. Comment Presumably, any admin can do this. That is, this proposal is moot, unless there is some provision that does not allow the granting of permission to bots, in which case, I support removing that restriction. It's an admin decision, and the admin is responsible for it. --Abd (talk) 16:46, 7 January 2008 (UTC)
20. Support I think this is a given, if any regular user can be given the tool by an admin then a trusted bot would be too. 1 != 2 16:50, 7 January 2008 (UTC)
21. Support Obvious. Anti-vandalism bots are already using their own rollback system - giving an already used API won't cause any further harm. Benefits include faster rollbacks without the negative effects of having to calculate edit conflicts. --Sigma 7 (talk) 19:11, 7 January 2008 (UTC)
22. Support No reason not to. We already trust them to do a helluva lot of rollbacks every minute. Might as well let them do it more efficiently. There would be no change as far as which articles get rolled back, or when, or under what conditions. As for the hacking concern posed below, I don't think rollback access is going to incite more interest in hacking these bots. The usefulness to a hacker for controlling a bot is pretty much still there even without rollback access. As a side note, Franamax needs to watch fewer movies. Equazcion •✗/C • 20:17, 7 Jan 2008 (UTC)
23. Support Regardless of overall rollback debate. As I said to Cobi, I've never seen AVB cause significant content problems, so this just seems like a good thing. MBisanz ^talk 21:39, 7 January 2008 (UTC)
24. Support. Spebi 22:05, 7 January 2008 (UTC)
25. Support 99of9 (talk) 23:10, 7 January 2008 (UTC)
26. Support but why give it to MartinBot? Marlith ^T/C 23:13, 7 January 2008 (UTC)
27. Support The bots need the tools more than anyone else here. Captain panda 23:15, 7 January 2008 (UTC)
28. Support Now this - I can see. Bots aren't to be run without approval from BAG. and the bots are the ones that can bog down server resources at their speed. Security holes? yeah there's some - ultimately bots are watched (by owner or admin) and should be deactivated upon problem. (with resolution leading to possible reactivation down the road.)  — master son^{T - C} 23:26, 7 January 2008 (UTC)
29. Support SJMNY (talk) 00:14, 8 January 2008 (UTC)
30. Excellent idea. Acalamari 00:17, 8 January 2008 (UTC)
31. Support. I can support this despite opposing it with humans. Master_son stated all of my points well. Those accounts have some of the highest amount of reverting, so their effiency would impact the servers the most. They can always be blocked if they run afoul. I would support having the revert flag be automatically awarded when the bot flag is obtained. Royalbroil 01:05, 8 January 2008 (UTC)

    The only problem with rollback being assigned to the bot flag is that anti-vandal bots are not flagged. This is done so their edits are not hidden ("hide bot edits") in recent changes. -- Cobi^(t|c|b) 01:31, 8 January 2008 (UTC)

32. slakr asks below if they need it. No one needs it, but it is useful. –thedemonhog talk • edits 01:40, 8 January 2008 (UTC)
33. Support Bots are needed to help with vadals too. SuperGodzilla2090 4 TACOZ! 01:45, 8 January 2008 (UTC)
34. Support – Bots may not need this tool, but it sure would do some good, even if ClueBot would be practically unbeatable with admin rollback. —Animum (talk) 02:17, 8 January 2008 (UTC)

    COMMENT -- how can do you justify giving uncontroled unaccountable robots this much pwoer over how wikipedia works if you admit that it isnt needed? Smith Jones (talk) 02:31, 8 January 2008 (UTC)

    Smith Jones, this will not change what the bots do at all. They currently work the same way, but this lets them tell Wikipedia's servers "Please revert edit(s) by User:xxxxxx on article yyyyyy" instead of "Give me the list of changes for article yyyyyy.", "Ok, now give me the data for revision zzzzzzzz on article yyyyyy." "Ok, now give me the edit form for article yyyyyy." "Ok, here is the text (which the server gave the bot earlier) for the post to article yyyyyy." As you can see, the former is much better than the latter. -- Cobi^(t|c|b) 02:48, 8 January 2008 (UTC)

    thanks, i think i udnertstand the issue better now. i sitll oppose this though, because through recent ordeals with bots i have learned that they cannot be ngegiatoted with or reasoned with without the help of an admin. Smith Jones (talk) 02:52, 8 January 2008 (UTC)

    ... Yet you have never had a run-in with ClueBot ;) -- Cobi^(t|c|b) 03:10, 8 January 2008 (UTC)

35. Support The only thing changing here is the way it reverts edits. I can only see this as positive. Majorly (talk) 03:45, 8 January 2008 (UTC)
36. Support As before, my opinion has not changed. --Charitwo ^talk 05:16, 8 January 2008 (UTC)
37. Support this seems reasonable. As long as they continue to provide the edit summaries and talk page notifications that they do, these bots should be made as efficient as possible. Eluchil404 (talk) 05:30, 8 January 2008 (UTC)
38. Support --ClanCC _(Talk) 05:36, 8 January 2008 (UTC)
39. Support. Of course anti-vandal bots should be granted rollback! Bots don't edit war, they are extremely unlikely to "go rogue" or vandalize, and it won't change their behavior in the least. Giving bots rollback will simply make them more efficient and easier on the servers. Pyrospirit (talk · contribs) 05:53, 8 January 2008 (UTC)
40. Strong Support - show me a reason that bots should not get rollback and I'll reconsider. It doesn't much affect the speed of the bots so if they are going to mess up, they would have anyway at the same speed. The only difference that will be made by this change is reduced server load which has my approval. James086^{Talk | Email} 06:00, 8 January 2008 (UTC)
41. --Rschen7754 (T C) 06:05, 8 January 2008 (UTC)
42. Support A very small group that can be easily monitored, and since they make a large number on contributions this will provide a greater advantage. --Falcorian ^(talk) 06:27, 8 January 2008 (UTC)
43. Support: General consensus has been that bots provide an invaluable resource towards vandalism and other cleanup procedures on WP, and the rollback feature may potentially give them another tool to aid in their efforts. Some bots have a rollback feature already in-effect, although. Seicer (talk) (contribs) 07:01, 8 January 2008 (UTC)
44. They already rollback the slow way. As for stuffing up faster, the limiting factor on the bots edits is the amount of vandalism, not the speed at which they can revert it. MER-C 10:55, 8 January 2008 (UTC)
45. Support, but quite frankly it can be done within existing policy - permission granted by 'crats by positive recommendation of BAG. Миша13 11:26, 8 January 2008 (UTC)
46. Strong support - This won't give them any power they don't already have, only reduce the server load when they do it. עוד מישהו Od Mishehu 12:12, 8 January 2008 (UTC)
47. Support - per Od Mishehu. -- Anonymous Dissident^Talk 12:38, 8 January 2008 (UTC)
48. Support. Makes sense, they already do the same thing. Coemgenus 13:46, 8 January 2008 (UTC)
49. Support Especially ClueBot. —Preceding unsigned comment added by Dolive21 (talk • contribs) 16:00, 8 January 2008 (UTC)
50. Support. I can't think of any plausible reason why bots should be prevented from operating on the servers in a more efficient way when they're peforming the exact same task as before. --ais523 16:19, 8 January 2008 (UTC)
51. support as a request for operation similar to the way bots are approved now, it just becomes one of the regular things that can be approved. --Rocksanddirt (talk) 17:32, 8 January 2008 (UTC)
52. Support. I see no reason not to allow the anti-vandalism bots to operate more efficiently, provided the end result of their actions remains the same (which by all accounts they will). - AWeenieMan (talk) 19:39, 8 January 2008 (UTC)
53. Support common sense. the wub "?!" 21:37, 8 January 2008 (UTC)
54. support. There is no tangible downside to this request. -- JamesTeterenko (talk) 21:58, 8 January 2008 (UTC)
55. Support., per the nom and per Od Mishehu (talk · contribs). Cirt (talk) 23:29, 8 January 2008 (UTC).
56. Support, under the condition that the approvals are maintained by the BAG, not this policy page, as they have a better technical know-how to properly address whether such a bot needs it. It has been shown here that a performance boost would be significant. Some argue that this would allow more edits, and thus more server strain, but as these bots check every diff (as far as I know, correct me if I'm wrong) there would be no change in the number of reverts, it would jsut make said actions easier, cleaner, and so on. Also, the argument that this would give bots too much power, is, as I see it, invalid. These bots are already able to edit at inhuman speeds, and could probably go faster, assuming that the RC page goes by faster (in other words, WP traffic is boosted significantly). Therefore, this would not change the amount of power they already have. --Vox Rationis (Talk | contribs) 00:01, 9 January 2008 (UTC)
57. Pomte 00:57, 9 January 2008 (UTC)
58. Support. Not as subjective, time-consuming, and bureaucratic as the previous proposal. This just adds a an option to bot approvals to make some servers hogs more efficient. Although I don't see a large net performance boost as above, there is not much to loose here over the current way of doing things, so it's worth it. Voice-of-All 06:48, 9 January 2008 (UTC)
59. Joke oppose, because ClueBot beats me to too many reverts. Just kidding, support. shoy 16:01, 9 January 2008 (UTC)
60. Support. Anytime you can do the same work while using fewer resources it's a good thing. The bots will continue to do their work in a way that's less demanding of limited (large, but limited) resources. Xymmax (talk) 17:49, 9 January 2008 (UTC)
61. Support: bots are already capable of vast amounts of damage, so this shouldn't be a big deal. —Ashley Y 21:09, 9 January 2008 (UTC)
62. Support Per Betacommand.--Phoenix-wiki 21:48, 9 January 2008 (UTC)
63. Support — they're going to revert anyways; why not reduce the server load while they do it? Edit restrictions prevent "run-away bot" syndrome quite easily. --Haemo (talk) 23:07, 9 January 2008 (UTC)
64. Support Makes sense. -- Ned Scott 03:21, 10 January 2008 (UTC)
65. Strong Support - Why ever not! Many reasons why they should - Most of which are mentioned above. Tiddly-Tom 18:56, 10 January 2008 (UTC)

Oppose (bots)

1. There is question that actual humans should have the capability, but an automated process should be given the authority? The whole point of bots is that they are rigorously examined for their ability to make mechanized judgements on a case-by-case basis - this now proposes to allow the bot to judge one edit and based on those results to rollback more edits without evaluation? Lawnmower Man or Terminator, take your pick. Also, aren't bots already coded for minimum server load? Can we have some official BAG input on this? (No offense to any BAG-er's already present) Franamax (talk) 03:49, 7 January 2008 (UTC)

   Thinking a little more - bots can already pretty easily request the page history and pick any edit they wish to revert to once they have identified vandalism, they just aren't doing it yet. It seems like a matter of extending and validating the code. If BAG wants to extend the functionality, is this the right place to ask for it? On consideration, this may be an entirely separate issue needing entirely separate community input. :( Franamax (talk) 04:11, 7 January 2008 (UTC)

   As a Member of the the bot approval group, let me make a few points. AVBs (anti-vandal bots) require a massive amount of resources to run, both on the wikimedia servers and on the host system. The standard method of reverting takes 3 calls to the server. get the diff. get the edit box, and then send the updated text. on a small scale that does not mean much. But when you have a bot that is checking every diff and reverting a large amount of data that adds up to a lot of data transfer (in the gigabyte range) on a weekly basis. Rollback on the other hand is very nice to the servers. with rollback, get diff, send rollback token. reversion done. there is no need to re-load the page, or re-send the page contents. As for how the bots operate if a vandal makes more than one edit, they should be all reverted. As for editing judgment the same thing happens, they still check the diff. very very few vandals to anything near constructive edits and all of the edits they make in a row should be reverted. rollback for AVBs is a veru very very good idea. its nicer on the servers and nicer on the bot. there is no need to fear the terminator, type bots. they dont exist. β^_command 04:19, 7 January 2008 (UTC)

   While, I'm not positive, I think that's essentially how they work. That's just a manual revert done automatically. Mr.Z-man 04:15, 7 January 2008 (UTC)

2. Oppose — ...but do they need it? It's again, the question I ask, and again, don't worry about performance. We're talking about a pretty big permissions change to accommodate a total of 3 active bots. And, remember, we have a toolserver for this exact reason— so that bots can run on it and not consume excess bandwidth/SQL hits. Additionally, heuristic-based bots mess up, and rollback would let them to mess up a lot faster. Moreover, I'm not sure if I feel comfortable giving every bot in the bot group rollback ability— particularly considering their edits are by default hidden from both RC and vandalism feeds in the first place. Present a solid reason why there is a need for it and I'll reconsider. --slakr^\ talk / 03:57, 7 January 2008 (UTC)

   you want a solid reason for using rollback? WP:PERFORMANCE is meant for the average user. Bot operators have to be a hell of a lot more careful and choose when to run the bot, as not to affect the servers as much. before I perfected some of my current methods I did cause a few database locks because I was running my bot too fast and causing too much stress on the servers. Brion and the other devs are good but as bot operators we realize we have extra issues that regular users do not have to worry about. also as a bot operator it is our job to figure out the best and least intensive methods that we can. rollback will reduce the amount of stress caused by AVBs by 66%. From almost any perspective a 66% performance improvement is a good thing. As a additional note the toolserver is useless for fighting vandals, and users do not have access to the database, only a live mirror of it that does not contain page text. β^_command 04:34, 7 January 2008 (UTC)

   PS AVBs are not flagged and thus their edits do appear in the RC feed and recent changes. β^_command 04:40, 7 January 2008 (UTC)

   There is a fundamental difference between your bot an anti-vandal bots in their server load. The cause of your database lock was likely due to too many edits at one time, which causes a replication lag. So, by that logic, giving bots rollback would actually increase replication lag, as they are able to commit UPDATEs and INSERTs a lot faster. Second, I'd like to see where the 66% performance gain comes from, or is that an arbitrary number? Finally, regardless of content availability, the toolserver is still located on the wikimedia intranet, so it still reduces external bandwidth consumption. The latter should be the first course of action to try for a bot like ClueBot (before something as drastic as giving it and other bots rollback). --slakr^\ talk / 05:11, 7 January 2008 (UTC)

   Where I got the 66% from? diff GET() 30Kb, old version GET() 30Kb, POST() of reverted text 30Kb, total server/bot transfer 90Kb. with rollback: diff GET() 30Kb, send rollback token 1KB. total server/bot data transfer 31KB. that is 59KB less or 65.555555% improvement. As for your idea that the toolserver and bandwidth is BS. (I have a toolserver account) the actual servers of the TS are in Amsterdam and the wikimedia servers are in Tampa Bay, Florida. all the toolserver is really useful for is as a stable, secure server. and for running basic queries on the database. As for the risk that with rollback the bots are more harmful? bullshit. Rollback and proper bot coding prevent that. rollback is like I said, at least a 66% increase, (for a single edit rollback) for a multi-edit rollback its even nicer on the servers. Please stop talking about things you have absolutely no clue about. It just makes you look bad. β^_command 12:52, 7 January 2008 (UTC)

   Cobi: The idea that rollback is more resource intensive than manual rollback is craziness — amidanial, IRC

   Cobi: sounds pretty silly to me — brion, IRC

   I rest my case. -- Cobi^(t|c|b) 05:26, 7 January 2008 (UTC)

   Hang on, this is getting out of control here. Cobi, are you copying from IRC chats onto en;Wikipedia? I don't agree with anything slakr has said, but that might not be the best strategy. You're getting into a whole different area now, much better to let those people just comment directly. Franamax (talk) 05:52, 7 January 2008 (UTC)

   Actually, I'd much rather brion, et al.'s input on the matter. Of course, the problem is that I've never argued a point as simple as "rollback is more resource intensive than manual rollback," so while they might have actually said that, it might have been taken out of context; for, my point was not that rollback is more resource intensive, but rather that bots having rollback would possibly be more resource intensive according to betacommand's logic. I'd rather you simply link them to my comments and then we'll go from there rather than playing messenger; or, alternatively, they can simply post their comments here personally. --slakr^\ talk / 06:21, 7 January 2008 (UTC)

   Slakr, this is free advice so it's worth what you paid for it, but I would suggest you drop it - manual rollback less intensive than automated rollback - IMO you're gonna lose that one big time :) Lets just stop quoting from IRC, if they want to comment here, they will, if you want to contact them for a direct discussion, I'm sure you can do that too. Franamax (talk) 06:33, 7 January 2008 (UTC)

   Actually, the main reason I commented back is that my point was taken out of context, just like you've now accidentally done. :P My original point was a simple response to Betacommand's assertion that Bot X's resource use reflects Bot Y's resource use, which is not necessarily the case. I know that rollback is 99.9% of the time more resource-friendly than manual reverting; however, in the situation he stated, it could constitute the 0.1% percent— that is, the exception to the rule, because in the sole case of database locks due to replication lag, in theory more rollbacks by automated scripts (i.e. bots) could exacerbate the problem due to the nature of lots of UPDATEs and INSERTs at one time being more of a bottleneck due to the speed at which they can be executed in a finite period of time. I appreciate your advice, though. --slakr^\ talk / 06:49, 7 January 2008 (UTC)

   No matter how many ways you spin it, 851 admins using rollback is going to cause considerably more stress (and potential for replication lag) than 3 bots ever could. Certainly, should the above proposal take place, even assuming 20% of all editors use the rollback feature the possibilities are nearly endless as far as database load goes. That being said, you make far too many assumptions, but the most notable is fundamental (yet missing): simply because bots will have the rollback tool, it will result in increase in mutator queries against the servers. More efficient queries (in time and load) doesn't necessarily translate to more queries (in quantity). I think your original claim is flawed for a variety of reasons, but this seems to most relevant. Justin ^chat 04:10, 8 January 2008 (UTC)

3. Oppose. i agree with statement #1, above. bots aren't great as you might think. they can be annoying sometimes. And some times they--preceding has been blanked by cluebot. if this is erroneous please report to Indoctrination Committee so we can blank you too. :-) just kidding. all kidding aside, I do oppose this idea. thanks. --Steve, Sm8900 (talk) 04:00, 7 January 2008 (UTC)
   1. Comment what sense does that make? If bots don't have rollback they will just use more resources not stop running. BJ^Talk 04:44, 7 January 2008 (UTC)

   (ec) You do realize that regardless of whether rollback is given to the bots, the bots will operate the exact same way at close to the same speeds. Rollback will just alleviate a bit of stress on the bots and the servers. Right now, when ClueBot decides to revert, it grabs the meta history of the page, finds the last edit by a user other than the user it is reverting, requests the data for that entry, requests the edit form, and posts that data back to the server. This is exactly the same thing that rollback does except rollback is done completely on the server without the 4-way negotiation, thus it is much less resource intensive on both ends. ClueBot will also revert in parallel if need be, so the argument that "but, it slows it down" is invalid, ClueBot will revert 10 vandalism edits in the same time it reverts 1, we are just talking about speeding up that 1 and making it easier on the servers. -- Cobi^(t|c|b) 04:51, 7 January 2008 (UTC)

4. OPPOSE!!! NO! automated bigotry should NEVER become a feature of wikipedia. Smith Jones (talk) 00:18, 8 January 2008 (UTC)
   • You do realize this is not about whether or not there should be bots on wikipedia? This is simply a question of whether they should be allowed to have a more efficient version of a tool which they already have and use daily. --Nn123645 (talk) 06:48, 8 January 2008 (UTC)
5. Oppose No, period. For all the same reasons as listed at RfA's for bots, and the recent discussion at the VP. (I'm not digging it up out of the archives, if you haven't read it then go look) No, no, no. How the fuck did this go from a "poll" for granting trusted users the rollback, to including the anti-vandal bots in this? (Don't answer that it's rhetorical - point being aren't we branching out a bit?) KnowledgeOfSelf | talk 11:34, 8 January 2008 (UTC)
6. Oppose per KOS. miranda 00:42, 9 January 2008 (UTC)

Neutral (bots)

1. There are advantages and disadvantages to this one. First of all, all of my objections regarding the vetting process and the inevitability (is that a word?) of a vetted user going vandal go out the window when we're talking about bots. That's a good thing. But on the flip side, the fact that bots are created by users makes them susceptible to user bias. That's not really a huge issue, however - creators of bots are assumed to have enough invested in their bots and in Wikipedia not to abuse their creations based on their personal biases. What I'm really worried about is the potential for mass, automated rollback on the part of bots. We all know bots aren't perfect (annoying, sometimes), and because of this, sometimes (rarely, but sometimes) bots do make mistakes or mis-identify a legitimate edit or whatever as something inappropriate. While this is unlikely, a bug in the bot or a flaw in its design could cause it to identify a large swath of edits incorrectly (either vandalism as valid or legitimate edits as vandalism) and automatically revert a large number of edits (including those that were trying to correct the incorrectly-classified vandalism), at a much faster rate and with much more scope than any human editor or vandal. This is my only objection - it would be removed (and then I would approve) if bots were tested and proven to be not susceptible to these sorts of mistakes.Ecthelion83 (talk) 06:24, 7 January 2008 (UTC)

   Did you read my response to oppose #3 right above your comment? Specifically about doing things in parallel. -- Cobi^(t|c|b) 06:46, 7 January 2008 (UTC)

   Yes, I did - I don't think I said anything about a reduction in the speed of the edits - what you said about the bots was that a bot could do all of these edits/reverts in tandem or simultaneously, which is what I am assuming; your referenced comment does not address the objection that prevents me from supporting this idea. What you are essentially saying in that comment is that the bots revert 1 edit in the same time it takes them to revert 10 of them, and that this applies to rollback as well. This is not my concern. My concern here is not that the bot would have problems catching up with vandals (because they would have no trouble at all in doing so), but the possibility that the bots themselves could be mis-classifying information and therefore revert many legitimate edits at a much faster rate than could be humanly corrected, or they could revert edits to vandalism that the bots identified (incorrectly) as legitimate.Ecthelion83 (talk) 07:37, 7 January 2008 (UTC)

   The error rate would not change from what it is now. The only programming change will be to use rollback instead of the current method. Mr.Z-man 08:23, 7 January 2008 (UTC)

   Right - but there still is an error rate. Being able to use rollback, especially when a bot does (I know this isn't often) make a mistake or series of related mistakes, is still a reservation that I, and others, will continue to have.Ecthelion83 (talk) 08:51, 7 January 2008 (UTC)

   So, a bot should be forced to use a slower, less efficient method because it is not completely accurate? What if I told you that rollback would reduce random errors? There is a split second window after ClueBot gets the old revision text and before ClueBot gets the edit form. This window exists because it is two different interactions. Rollback would eliminate this window as it is 1 transaction and it can create a write lock on the database for the milliseconds required to complete the transaction (this is the standard lock on any write operation on a database, not the MediaWiki error message saying that the database is locked). -- Cobi^(t|c|b) 09:18, 7 January 2008 (UTC)

   So can you clarify - does ClueBot currently look at the most recent change, decide it is vandalism, then blindly revert all the immediately previous changes by the same editor? Or does it look at each change by that editor and decide whether each one is vandalism? Trying to figure this out... Franamax (talk) 10:06, 7 January 2008 (UTC)

   It does. Just like every other rollback script. This is done so as not to lock in subtle vandalism. This happens very frequently: Vandal edits a page, changes a number, or inserts very subtle vandalism that the bot doesn't detect. Vandal then edits the page again, and does something very radical, and ClueBot reverts in a matter of seconds. If ClueBot reverted 1 edit, then someone would say "Oh, ClueBot already reverted it," and not look at it, assuming it to be vandalism free. -- Cobi^(t|c|b) 10:17, 7 January 2008 (UTC)

   Thanks - that makes excellent sense, when I see a rvv. I do assume the reverter has properly checked it out, although if I see "reverted edits by 1.2.3.4 to previous version by 1.2.3.4" I pretty much always go look anyway. Of course, if I was trying to do vandalism, I would do the big one first, then the second smaller change after. Actually I would do the big one in the first edit farther down in the article with a smaller change above where the back-looking reviewer would just be looking at the first browser screen, I would save that mess, then make a second innocuous change and save that version too. So in the reverse situation to the scenario you describe above, would ClueBot catch my first bad change? Franamax (talk) 10:30, 7 January 2008 (UTC)

2. This is a technical measure that should be decided on technical grounds. I see no reason why the community needs to be involved in it. --Carnildo (talk) 09:32, 7 January 2008 (UTC)
3. Neutral per Carnildo above. Since this wouldn't add more functionality to the bots, but will (or may?) just take some load off servers, I'd leave it to the technical group. Artyom (talk • contribs) 14:26, 7 January 2008 (UTC)

Neutral; strongly leaning towards oppose. Would reconsider if it were possible to provide a nonstandard edit summary (bot shouldn't just say "I don't like ur ugly edits"), encoded in URL or POSTed in the request. But it ain't. Миша13 22:39, 7 January 2008 (UTC)

1. The default rollback summary indeed can be changed on a case-by-case bases. If someone takes the rollback url and appends &summary= followed by the edit summary, that is used instead of the default rollback edit summary. And, of course, ClueBot will take full advantage of this ability, as I have stated in this section before. Thanks. -- Cobi^(t|c|b) 23:32, 7 January 2008 (UTC)

   Good to know - an obscure feature indeed. Changing to support. Миша13 11:26, 8 January 2008 (UTC)

in case this horrible idea goes through, who is int charge of ClueBot and will be responsible for any accidental mistakes/glitcehes that MAY occur after the bots are radically empowered? i aks for future referenc eo only?!!! Smith Jones (talk) 03:33, 8 January 2008 (UTC)

Cobi is in charge of ClueBot. But these bots are already running, Wikipedia has not imploded and they have not grown intelligent and pushed a POV. This is just changing the technical method used to rollback vandalism, not the reasons it reverts it. Mr.Z-man 03:50, 8 January 2008 (UTC)

thank you for claring that up for me. its so surprisingly to get an answer around her e insted of be ing asked to read a thosuand pages of block text. Smith Jones (talk) 03:54, 8 January 2008 (UTC)

Discussion (bots)

Security concerns

The other really important thing I forgot to mention: if bots have rollback they're potentially at an increased risk of being targeted by "teh hax0rs" due to the literally awesome power of mass-rollback. It's likely most bot passwords are stored in cleartext, potentially world-readable, and on a shared server. It's only a matter of time before someone exploits that— especially if the bots are given enhanced editing abilities like rollback. I'm possibly just being over-paranoid on this, but whatever. :P --slakr^\ talk / 09:29, 7 January 2008 (UTC)

cobi@Abscissa:~/wikibots$ ls -aslh cluebot/cluebot.config.php
4.0K -rw------- 1 cobi g-users 1.1K 2007-11-18 16:42 cluebot/cluebot.config.php

Furthermore, the password is a completely random alphanumeric string. It is on a relatively private server. I.e., I own the server and a few of my friends have an account. The password is stored in cleartext on the disk, but there is no effective way around that. It can't be hashed because then ClueBot couldn't send it to Wikipedia. Encrypting it with a symmetric or public/private key encryption would yield little use because ClueBot still has to have a way to decode it to send it to Wikipedia. Besides, rollback is not a "literally awesome power of mass-rollback." That right there is the flaw in the rest of this page. Rollback is simply a faster, better way to revert an article with less chance of error. How about SineBot? Is it on a shared server? And wasn't it you who suggested I put it on the highly-shared toolserver?  ;) -- Cobi^(t|c|b) 09:53, 7 January 2008 (UTC)

We have a bot approvals group for a reason, and that reason is that most people don't understand bots. Asking if rollback should be given to bots here is not productive and leads to concerns about Skynet or lawnmower man, and other concerns not based in the reality of what bots really are. The fact is that anyone who understood how bots actually edit Wikipedia will know that the only difference rollback makes to a bot is a reduction of server load. It is not even for the bots but for the server as the bot can do the same thing with no extra effort without the tool, just using more server resources. Polling unqualified people on the issue will not lead to the most accurate results. 1 != 2 16:54, 7 January 2008 (UTC)

This is just getting silly. I'm willing to bet a shiny nickel that all three of the current AVB's are running on considerably more secure systems than the overwhelming majority of admin accounts, which have real awesome powers of delete, block etc. I simply don't understand why you make so many security assumptions about bots, when realistically, humans tend to cause more security problems than any automated process I've seen. Claiming that passwords are "potentially world-readable" or that shared servers are inherently less secure than, say, an admins account borders on insulting to any bot writer. If security is truly that big of a concern, take it up with the devs, since passwords are sent in plain text to WP anyway. I'm with 1 != 2 on this one. BAG should handle this or were going to hear one Argument ad metum after another. Justin ^chat 05:53, 8 January 2008 (UTC)

Rather than dismiss concerns as silly fear-mongering and talk about people who just don't understand, it might be a better strategy to patiently and politely deal with the issues raised, no matter how trivial and repetitive they are. You never know when it might be a top-line IT person asking the dumb questions trying to understand the situation - dismissing the things that make you impatient might alienate the people who could turn out to be your best supporters and certainly won't calm the people with genuinely furrowed brows. One of the top concerns I've seen on WP with bots and bot advocates is with their level of communication skills. Could you rephrase that post to make the same valid point in a less dismissive way? We are all really pursuing the same goal after all - a better encyclopedia. Franamax (talk) 07:31, 8 January 2008 (UTC)

The security concerns raised come from paranoia. I can't speak for CVB, VoABot II, or MartinBot, but I can speak for ClueBot. ClueBot is run on the ClueNet servers, specifically, Abscissa.ClueNet.Org, a server run by me. The top two ClueNet administrators are what some would call "security freaks". ClueBot has never been compromised despite having the source code publicly available. ClueBot's private config file (which contains the passwords) is readable only by me. Abscissa.ClueNet.Org is not a very public server. Only people who have been checked out and approved by one of the top two ClueNet administrators have accounts. ClueBot's password is very long and comprised of completely random (printable) characters. As for the argument that "rollback is an awesome power" ... well ... it isn't. It can't do anything that normal editing can. It is just easier on both the bot and the WMF servers. It can be reversed by any user with editing privileges (i.e., anyone not blocked). I would agree with some of the others that this should be handled by the BAG, but the developers wanted community consensus, so here it is. I have no doubt that the BAG wouldn't have a problem at all with this request. But, the developers wanted community consensus. I hope I have alleviated your concerns. Thanks. -- Cobi^(t|c|b) 08:03, 8 January 2008 (UTC)

ClueBot is run on the ClueNet servers, specifically, Abscissa.ClueNet.Org — now see, therein lies where my paranoia comes from: people literally asking to be hacked/dDOSed by wrecklessly posting public server IP information. For the record, I actually am both a *nix/bsd/solaris junkie and self-proclaimed coding nerd, so I'm fairly confident I know what I'm talking about when it comes to stuff like this. I'm not a BAG member (nor do I need to be) to understand that there are fundamental issues of security when it comes to bots that run on one of the most visible and highly trafficked sites on the internet. This should be a rational discussion about the pros and cons of giving bots a powerful ability— not a forum to call people paranoid simply because they raise dissenting opinions; and, I assure you, security is nothing to be smug, overconfident, condescending, or dismissing about— regardless of the size of a site or company.

That said, a reality check: is it likely that the bots will be hacked? Probably not— at least, so long as people don't go around posting their public IPs. What happens if they do get hacked, though? Pain in the ass due to the non-rate-limited nature of rollback as it's currently implemented in Mediawiki. And, it would be ideal if people got out of the habit of calling well-meaning, well-founded paranoia "fear-mongering." If you'd rather I and others not attempt to curb group think when it comes to decisions potentially affecting the safety and security of the community, then I'll be happy to oblige, as there's always a considerable backlog of other things— both here and in real life—that I'll be happy to do instead. --slakr^\ talk / 09:24, 8 January 2008 (UTC)

Exactly my point, the first paragraph you made it sound inevitable. Now it's "probably not likely". And the reason I was a little bitey, was because Slackr's userpage indicates he has more than enough knowledge on the intricacies of programming to not be making wild claims of the "inevitable" hacked bot. And the paranoia may be well-meaning, but inventing absolute worst case scenerios and implying they are inevitable isn't well-founded. That falls under the jurisdiction of excessiveness. And you only make it worse by implying that giving public server information is such a terrible thing. So, let's make a few counter-points to your argument:

(A) An IP address is not "private" by any stretch of the imagination. I personally wouldn't give out an IP unless there were good reason to do so, but that in of itself is not even remotely a "security concern"

(B) a DDoS, should it occur, would do nothing more than slow down (or potentially make ClueBot stop) editing. Using that as a "security concern" in relation to Wikipedia is absolutely absurd.

Dissenting opinion is a "good thing". Which is why those that have opposed for a variety of reasons weren't even taken to task on their oppose. A lack of understanding on the on the concept of bots is both expected and natural. People fear processes that run "automatically". That being said, someone who makes the claim that he and/or she is at the very least competent (if not a professional) isn't going to get the same consideration. If you want to advocate security concerns, that's GREAT... you'll be my new best friend. But advocating them via scare tactics, and the use of words that don't really apply (read DDoS) is going to HURT the process more than help it. Justin ^chat 17:01, 8 January 2008 (UTC)

Cobi, in the course of defending your bot's security, you've already revealed at least three attack routes plus your vulnerability to social engineering. Prove the security of the specific file you've listed above by showing us the contents of /etc/passwd and ls -al ~/wikibots - or better yet, can you login and run a quick "rm -r ../*" and post the output? The thing about boasting about your security is that it's kind of like picking fights in a bar - sooner or later there's going to be a bigger, tougher guy. And you're speaking for your bot but also bringing in the names of your buddies, the other anti-vandal bots quietly sipping a beer at their table. I'll refer to my post above - much better to just patiently explain to us idiots why we're wrong, you don't have to tell us we're idiots, we already know we are, that's why we make so much money, because we ask about everything. Cool down and you will get farther. :) Franamax (talk) 13:12, 8 January 2008 (UTC)

The main concern here seems to be the privacy of the plain-text password stored in the file. Because the file is not world-readable, there are only 3 possible attack categories. A hacked root account on the server, that particular hacked user account on the server, and social engineering to directly get the password by other means. The system in question runs Debian stable and is regularly updated. This greatly minimizes any possibility of the root account or user account being "hacked". In this case, only one person (Cobi) will have access to the password, and he would never give the password to anyone, as he knows enough not to be succeptible to social engineering. In response to your question about listing /etc/passwd, that would do no good, as you are assuming that the system's PAM is using a default configuration, which it is not. Actually, account authentication is done via Kerberos5 (Heimdal). Account information (with NSS) is stored in an LDAP directory, and the PAM configuration disallows Kerberos authentication (or LDAP authorization) for system UIDs. I'm not sure what your question about "rm -rf" is supposed to prove, or what the cwd is in which you want it to be executed. If it's executed from the home directory, it will remove only that user's home directory, and no privileged information would be released. If the concern is about unencrypted admin passwords in general, there are probably larger concerns along that same line. How many admins have browsers storing unencrypted passwords to be automatically filled in? Sure, some probably use some kind of password-protected keyring, but many systems don't use that. What if one of their machines is "hacked"? —Preceding unsigned comment added by Crispy1989 (talk • contribs) 01:07, 9 January 2008 (UTC)

- plain-text password - why isn't it encrypted and unlocked when the bot is launched?

- not world-readable - depends on the permissions of the parent directory, that's one chmod away.

- system runs Debian - thank you for the exact OS, you have been social-engineered. How do I know it's the current version? Wait, don't tell me the version number!

- /etc/passwd - to look for other unames with the same uid.

- auth method - again, thanks for the detailed description posted online.

- "arr-emm-space-minus-arr/space-dot-dot-slash-star" - that's a rhyming joke, maybe only support-deskers get it, I'll retract it now. :)

- yes, admins around the world have cookies and all kinds of spyware from the last weird site they clicked at, that's another huge social vulnerability that will never go away.

- we can go on and on with this, my original point before was that we should NOT discuss security by means of laying out the fine points on the 6th most popular website in the world. And I assure you it will not be me who proves the point about vulnerabilities, I'm just concerned about other interested persons who are watching. I won't be unhappy if we stop the technical discussion now :) Franamax (talk) 08:16, 9 January 2008 (UTC)

Admin accounts have been hacked in the past. They go on a rampage for a few minutes, get emergency desysopped, and everything is back to normal within an hour. A hacked bot would get even less done because it would only need to be blocked to stop it, we wouldn't need to get a steward. Mr.Z-man 03:12, 9 January 2008 (UTC)

The concern here is not the same as with admin accounts. A bot account has that +bot flag, thus it flies a little more under the radar. A bot account is expected to make high-rate edits, when you guys watching activity see the bot flag, you relax a bit - am I right? That's what I gathered from my much earlier discussions at T_RFBA anyway. So, two scenarios here - a bot login is hijacked and goes wild with a rollback spree, well fine, it's gonna be spotted a little later than usual for hacked accounts and it can be rolled back - but whoa, in the meantime there are a few thousand other people trying to repair the damage themselves and a few thousand other people just trying to add stuff, and they are all getting confused because they just naturally respect "Bot" at the end of the username; and then there is the far worse possibility of a compromised bot pwd in the hands of a skilled pilot, now it's a stealth bomber. I purposely didn't ask above how often the password is changed. YES this is apocalyptic nonsense - until it becomes reality. And yes, since at least ClueBot already does the same thing with these existing vulnerabilties, this rollback proposal is not directly relevant - I was ready to change my !oppose to !support yesterday but I didn't see the kind of patient and calm responses from the bot-side that I would have hoped for. 'Course, I count for nothing in the grand scheme :) Cheers! :) Franamax (talk) 08:38, 9 January 2008 (UTC)

I don't believe the anti-vandalism bots are flagged, so their edits will show up in recentchanges and watchlists. Also, when someone does notice a bot acting strangely (if ClueBot did anything other than rollback of blatant vandalism or something that looks like it), they are blocked much faster than users because the possibility of offending the blocked user in the case of an unneeded block is minimized. Mr.Z-man 20:47, 9 January 2008 (UTC)

I see the relevance of having the rollback procedure having a separate approval process for bots than for users, since if one does not get approved, the other still could be. But all this talk of bots being hacked or going wild? It's not like someone has a magic remote control that can make all bots break Wikipedia. Granting this feature to bots does not effectively make them any more "powerful" or prone to failure. Any further discussion of that nature needs to take place elsewhere; it's distracting from the relevant topic. Coreycubed (talk) 16:56, 8 January 2008 (UTC)

Ummm - it would seem that bot rollback is being requested here as a related-but-separate part of the Non-admin rollback feature for selected editors, precisely because previous attempts to get that ability through RFA have failed. It would also seem fair that the same concerns might be presented here - bots get a special pass to do things and they have a certain imprimatur when we see them make edits - so yes, they should get extra scrutiny. The argument to grant rollback to bots rests on greater efficiency, either 66% or 10:1 by my reading. Two ways to look at that: we're being asked to grant a right in order to save 33-90% of - what? No case has been presented as to how many fewer servers WMF will need; and there is now a conceivable argument that the increased efficiency will let the bot work between three and ten times faster - so isn't the potential for damage also going up at the same rate? At any rate, the bot discussion is off in its own corner and security is even more removed, I doubt that we're distracting anyone but ourselves :) Franamax (talk) 09:06, 9 January 2008 (UTC)

The number of pages that will be "damaged" would be higher - it just does rollback, so the page will always be edited to some version from its recent history - but the error rate should remain the same, and is lower than the error rate for most users doing the same task. Mr.Z-man 20:47, 9 January 2008 (UTC)

Admin question, moved

Why are admins the ones entrusted with granting the rights?—Preceding unsigned comment added by Hiding (talk • contribs) 00:31, 9 January 2008 (UTC)

Because they are admins. Snowfire51 (talk) 00:45, 9 January 2008 (UTC)

How redundant. At least we have an answer we can add to the FAQ though. Hiding T 02:15, 9 January 2008 (UTC)

Admins are (or would have been) entrusted with the granting of rollback rights because they have proven that they can be trusted with such power during their time here, and have also recieved the ability to protect and delete pages, block editors and rollback their edits. They are not, as commonly percieved, a group of arrogant and selfish editors here to inflict misery those who come to wikipedia to "contribute constructively", or create autobiographical articles full of spam and copyrighted material. The position of administrator on the English wikipedia is not one to be envied — it involves lot's of shouting and drama, is generally just difficult and occasionally causes depression. Many of them must be glad this proposal was rejected, it could only have added to their already long list of problems--Phoenix-wiki 22:05, 9 January 2008 (UTC)

I hope I am never asked to be an admin. I have enough problems being who I am! Igor Berger (talk) 09:14, 10 January 2008 (UTC)

No one is force to be admin. if you feel you don't want to be admin, then simply reject it if you are ever nominated Nil Einne (talk) 18:12, 11 January 2008 (UTC)

• "Admins are (or would have been) entrusted with the granting of rollback rights because they have proven that they can be trusted with such power during their time here..." - No they haven't. Bureaucrats on the other hand, have. To my knowledge, admins have never had the right to grant userrights. That's always been the purvue of bureaucrats on-wiki. And even bureacrats didn't have the right to remove access except bot flags. So no, I wholly disagree with that statement. - jc37 12:05, 10 January 2008 (UTC)

• Though that was intended to be slightly humourous, Admins are much easier to trust with stuff like this than non-admins.--Phoenix-wiki 20:04, 10 January 2008 (UTC)
• Also, according to this:

• Wikipedia administrators are trusted members of the community and are expected to follow all of Wikipedia's policies and guidelines to the best of their abilities. Occasional mistakes are entirely compatible with this–administrators are not expected to be perfect–but consistently poor judgement may result in reapplication for adminship via the requests for adminship procedure or suspension or revocation of adminship. If revoked, the user may have a temporary or permanent limitation placed on reapplying.
• Administrators have been granted the power to execute certain commands which ordinary users can not execute. This includes the power to block users, to protect pages, to edit protected pages, and to delete and restore pages. All of these abilities must be used in accordance with policy (the blocking, page protection, and deletion policies, respectively), and must never be used to "win" a content dispute.
• One aspect of the responsibilities of an administrator is to attempt to prevent disruption to the Wikipedia site and its users. Administrators are authorized to use their best judgment in accordance with accepted principles in order to do this.

Phoenix-wiki 21:18, 10 January 2008 (UTC)

Perhaps (to the above), except that if your postulation was true, there wouldn't be bureaucrats, and their abilities would be given to all admins. That's however not the case. And the granting of userrights (and associated tasks) is just about all there is to being a bureaucrat. And what's this? Why it's granting a userright. It would seem like a no-brainer to me, but then I guess sometimes I presume too much... - jc37 04:21, 11 January 2008 (UTC)

This is a pointless discussion — admins are trusted to do this now, so let's move on and edit somewhere useful :-)--Phoenix-wiki 22:17, 11 January 2008 (UTC)

Ah, I see, all the talk of trialling it and working out kinks and perhaps coming up with a better idea was just flannel. Thanks. Those of us who feel it was more in line with our principles, traditions, purpose and nature that this be a featured awarded through technological rather than human means, with the block tool used in the case of disruption should just accept the fact that we were never allowed the time to propose and discuss that option. Thank god consensus can't change. Hiding T 20:36, 13 January 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.