Misplaced Pages

FAQ

What is rollback?

Rollback is a method for reverting edits with a single click. Users with the rollback privilege see a "" 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 (): Arguments and counter-arguments section added
• 4 Jan 15:01 (): Arguments and counter-arguments section rewritten as FAQ

Straw poll

Closed and archived. See Misplaced Pages: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.

Anti-vandalism bots

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 02:38, 7 January 2008 (UTC)

Support (bots)

1. As nominator. -- Cobi 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 04:23, 7 January 2008 (UTC)
7. Full support as part of WP:BAG β 04:31, 7 January 2008 (UTC)
8. Support the RC checking bots need all the help they can get. BJ 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 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 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 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 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 /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 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 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 Misplaced Pages'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 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 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 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 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  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 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)

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. β 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 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. β 04:34, 7 January 2008 (UTC)

   PS AVBs are not flagged and thus their edits do appear in the RC feed and recent changes. β 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 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. β 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 05:26, 7 January 2008 (UTC)

   Hang on, this is getting out of control here. Cobi, are you copying from IRC chats onto en;Misplaced Pages? 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 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 06:49, 7 January 2008 (UTC)

   No matter how many ways you spin it, 847 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 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 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 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 Misplaced Pages 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 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 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 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 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, Misplaced Pages 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 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 Misplaced Pages. 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 Misplaced Pages. 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 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 Misplaced Pages 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 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 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 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 Misplaced Pages 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 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)

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)

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

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)