Wikipedia:Bots/Requests for approval/MessageDeliveryBot

The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was

Approved.

MessageDeliveryBot[edit]

Operator: EdoDodo (talk · contribs)

Automatic or Manually assisted: Automated, actual runs are not supervised but messages it delivers are (see below for details).

Programming language(s): PHP (using Peachy)

Source code available: ~~Will be (partially) available later on.~~ Available on request.

Function overview: The bot will deliver messages based on requests from a web interface. These requests will be checked manually before running. Trusted users will be marked as 'confirmed' on the website, and will be able to review other people's requests, as well as their own.

Links to relevant discussions (where appropriate): Task is very similar to that of other message/newsletter delivery bots, so no discussion is necessary (uncontroversial).

Edit period(s): ~~Once a day, at non-peak times~~ ~~Four times daily.~~ Hourly, or on demand (if there are checked requests waiting to be delivered).

Estimated number of pages affected: Depends on how many requests are made, currently I really have no idea so cannot make an estimate.

Exclusion compliant (Y/N): Yes

Already has a bot flag (Y/N): No

Function details: Anybody will be able to request a delivery here. The requests will checked before the bot runs them. Regular users can register on the website, and once verified by me or another administrator will be able to help check requests, as well as checking their own. The bot will normally run once a day at a non-peak time to deliver all checked messages. If a message is marked as 'urgent' then the bot may be manually started to run out-of-schedule to deliver that message. Feel free to look around the interface to see how it works, most of the functioning should be fairly self-explanatory. Feel free to submit test requests, I won't check any of them so none of them will run. If you would like confirmed user status to look at the restricted parts of the interface then drop me a message on my talk page or talk to me on IRC. If I do give you checked user status please note that the bot IS completely functional, so if you verify a request it WILL run (at midnight UTC), so make sure you unverify it, since the bot is not approved yet.

Discussion[edit]

In case any of you are wondering why I didn't request this as a new task for DodoBot, it's because this bot will, in a sense, be operated by multiple people, since any trusted user could verify a request and the bot would run it, even without me seeing what goes on. Although I realize that I am still responsible for the bot's actions I didn't want it to have my name in its username, since that would imply that I am the bot's only operator. - EdoDodo ^talk 09:38, 7 July 2010 (UTC)[reply]

EdwardsBot does something that's roughly the same, so the idea in principle is fine. I'm curious why the source code would only be partially released. The login / register form should make it explicit that Wikimedia login credentials should not be used. How will you be verifying that the user on the Toolserver tool is the same user on the Wikimedia site? Is there going to be some sort of sanity check to ensure that some users don't abuse the bot? "Abuse" is a strong word, but sometimes people go around needlessly trying to find posts to spam, mostly because they're bored and it's summertime. --MZMcBride (talk) 15:56, 7 July 2010 (UTC)[reply]

Well, I'd be happy to publish the complete source code... but I'm a bit worried about the security of what I've developed. I'm sure the code isn't entirely bullet-proof, and there are security issues in it somewhere, and publishing it would only make it easier for malicious users to find these. I put the partially in brackets because once I've properly checked the code and I'm confident it's secure I will then make it completely available (with the exception of the files including the database connection and bot login information, of course). I will add a couple of lines to the login form to make sure users don't use there Wikimedia credentials later today. As for verifying that the user is the same, I'm not sure how I would do this - or even if it is necessary. If the message delivery is uncontroversial then there is no reason why it shouldn't be run - remember that all runs are manually checked. If it is controversial, and could be seen as spam, then there is a field to include a link to a relevant discussion that shows consensus for it. With that said, if there is consensus that it is necessary to have users confirm their identities, I can add a field to have the user provide a diff of an edit on Wikipedia confirming that he is the same person. - EdoDodo ^talk 16:56, 7 July 2010 (UTC)[reply]

Or perhaps the system could be changed so that only the approved users can request new tasks. This would go a bit against the original idea I had of a more open message delivery system, but then again it would probably always be the same few people involved with newletters requesting deliveries, so there wouldn't be too much harm in requiring registration and approval. Opinions? - EdoDodo ^talk 10:38, 8 July 2010 (UTC)[reply]

Regarding your concerns over posting the source code, read security through obscurity.

I think verifying that the username entered actually belongs to the requesting user is important; as you say, it will probably be the same few people requesting deliveries, and you wouldn't want some troublemaker to try to capitalize on the trust you will probably develop in those few by pretending to be them. This doesn't have to be anything terribly complicated; one possible method is to require each prospective submission be confirmed by having the requesting account edit a specific page in the bot's userspace to contain a non-predictable randomly-generated string specific to that submission. The submission form could then easily enough output a form with all hidden fields and a "submit" button that targets the edit form for that page with the necessary data pre-filled, and even submit that form with Javascript; see the "Do stuff for me" button on tools:~dispenser/view/Checklinks for an example of this technique.

It also needs to be possible to determine who approved the message for delivery, per WP:BOTPOL#Bots operated by multiple users; small print or even a  at the end of the delivered message should suffice, IMO. I would also recommend a fully-protected page on-wiki and linked from the bot's userpage listing all the trusted users, such that an admin can remove someone from this list to prevent any more messages approved by this user from being sent (otherwise, if someone approves bad messages then the bot will have to be blocked until you manually remove that person's access). You should also check if the requester/approver is currently blocked, and similarly refuse to post any messages requested/approved by that person. Both of these, of course, should periodically be rechecked during long delivery runs (you could probably check these in the same API request you use to check bot exclusion).

You may also want to include in your submission form the ability to specify a value for the optout parameter to {{bots}}, although at this time none of the predefined values are likely to apply. Anomie ⚔ 21:22, 9 July 2010 (UTC)[reply]

Thank you for all these excellent suggestions. I will work on implementing them all in the next few days. - EdoDodo ^talk 06:26, 10 July 2010 (UTC)[reply]

I have a small question... would a kind of blacklist (of users who's approvals should be ignored) on Wikipedia instead of a whitelist (of approved users) also be acceptable? As the system is currently laid out this would be significantly easier to implement, and also I wouldn't have to go looking for an admin every time I want to approve a new user. If it would be desirable to show a list of all approved users then I can do this on the website instead. - EdoDodo ^talk 07:20, 10 July 2010 (UTC)[reply]

That could work, yes. You could even skip that part completely, if you're willing to accept a longer wait for unblock if any of your trusted users does go rogue. Anomie ⚔ 13:15, 10 July 2010 (UTC)[reply]

Done I've implemented all of the changes discussed above, with the exception of the ability to set the optout parameter because, as Anomie said, none of the predefined values really apply anyway. As well as this the bot now follows redirects to other "User talk:" pages, leaving a note saying where it was redirected from. The bot also posts a log to the requesters talk page, either saying that everything went fine or stating which users the bot encountered errors on. The message about a successful delivery is only sent if the user chose to have it sent when he was making the request. The notification about errors is always sent (unless the requester has {{nobots}} on his page, or has it protected, in which case the error log is sent to me instead, so I can take a look at it). - EdoDodo ^talk 21:33, 10 July 2010 (UTC)[reply]

I have done some test edits in my namespace and the bot seems to function as expected. Examples:

Normal message
Redirected
Successful delivery (only if user has opted in when making request)
~~Errors delivering (page had {{nobots}}) - accidentally had one newline too much in there, has been removed now.~~ Was a malfunction, so much for functioning as expected, here's a good edit: [1]

All edits went as expected, however more suggestions on how this could be improved are always welcome. - EdoDodo ^talk 11:26, 11 July 2010 (UTC)[reply]

I'm not sure about the error reporting. I see you have a reason at the end of the message, but the reason given is rather vague and if there is more than one failed user that wouldn't make a whole lot of sense anyway. I'd rather see each list entry as something like "* Example - bot excluded" or "* Example - page protected". Also, does it need some sort of reference to the message that was being delivered? I'm not sure. Anomie ⚔ 15:04, 11 July 2010 (UTC)[reply]

Whoops, the edit I linked was actually a malfunction (the message at the end wasn't supposed to be there). I have added a note stating the reason why the message delivery failed, as well as a reference to the title, so that if the user has placed more than one request he will know which one I am talking about. For an example of how this looks see this edit - EdoDodo ^talk 15:53, 11 July 2010 (UTC)[reply]

It'd be nice if it used a standard edit summary so that you get the section anchor links (from /* foo */) in things like watchlists. --MZMcBride (talk) 19:41, 11 July 2010 (UTC)[reply]

I'm sorry, I don't think I understand what you mean. You mean have the edit summary be something like:

/* $messageTitle */ Delivering message from $requester

Because having the /* */ around the username of the requester wouldn't really help much since it would just result in a broken section link. - EdoDodo ^talk 08:44, 12 July 2010 (UTC)[reply]

I have changed the edit summaries as discussed above. As well as this I have changed the login system to use TUSC (user has to have a valid TUSC account that is approved in order to login). This ensures that all usernames are linked to a Wikipedia account of the same name, and allows better identification of approved users. I have also added a page that will list all approved users here so that if somebody needs to contact a user about their request, or an admin needs to see who can operate the bot, they will know. - EdoDodo ^talk 08:26, 18 July 2010 (UTC)[reply]

Cool. This is atypical of a bot task, so take as much time as you want for you trial, maybe a week or so of full functionality. If you need a bit more, just leave a note here explaining why. Good luck. Tim 1357 ^talk 23:15, 20 July 2010 (UTC)[reply]

Approved for trial. Please provide a link to the relevant contributions and/or diffs when the trial is complete. Tim 1357 ^talk 23:15, 20 July 2010 (UTC)[reply]

I might be sending the announcement for the end of the GOCE backlog elimination drive month (ongoing discussion here). Otherwise Mono and Xeno both expressed interest in having message(s) delivered. So, should be getting some test edits pretty soon (around end of month). - EdoDodo ^talk 20:35, 22 July 2010 (UTC)[reply]

Okay, I've done a trial run delivering WikiProject NASCAR's first newsletter ( {{Wikipedia:WikiProject NASCAR/Newsletter/201007}} ). The delivery went mostly smootly, although there was an error with an improperly handled exception that stopped the bot half way through (see the break between leaving Recury the message and leaving it to Royalbroil). This error has been fixed and should not occur again. As mentioned above, there is the possibility of more messages being delivered soon, so if you would like to keep the bot in trial to make sure that the error doesn't occur again in future deliveries, I have no objections. - EdoDodo ^talk 21:08, 25 July 2010 (UTC)[reply]

Just ran another request, for Xeno, delivering WikiProject Malaysia's newsletter. This time there were no issues (ran the bot out of schedule so I could keep an eye on it while it ran). Xeno also suggested that I run the bot more frequently than once a day, perhaps four times a day. Would anyone have an issue with this? It really shouldn't change much for Wikipedia's servers, the bot won't even log in if there aren't requests waiting. - EdoDodo ^talk 16:55, 29 July 2010 (UTC)[reply]

I don't see any issue with it attempting to run four times a day (or even more often than that). It will only run if there is something to do, so... –xeno^talk 17:23, 29 July 2010 (UTC)[reply]

Hmm... Yeah, I guess I could even have it check hourly, if there's no objections. All it's doing if there's nothing to deliver is a single database query to the Toolserver. - EdoDodo ^talk 17:34, 29 July 2010 (UTC)[reply]

Yep. Hourly is fine - I doubt the cron would place any strain on the toolserver. –xeno^talk 17:38, 29 July 2010 (UTC)[reply]

Trial complete. Have done a couple of delivery requests, and made about 50 edits. Basically done full functionality of the bot for a week, as requested, so I would say that trial is complete. See above for how the trial went. - EdoDodo ^talk 17:03, 29 July 2010 (UTC)[reply]

I found a bug: see here. —mono 15:46, 1 August 2010 (UTC)[reply]

That was just due to a minor change I made that broke the indentation of the message, fixed now. - EdoDodo ^talk 18:36, 1 August 2010 (UTC)[reply]

Have also delivered the final newsletter for the GOCE backlog elimination drive. That went very well, although it did deliver the message to a user that didn't exist ([2]). The bot has now been changed so that if a user doesn't exist, or is blocked, it will report this to the requester instead of just delivering the message anyway. - EdoDodo ^talk 18:36, 1 August 2010 (UTC)[reply]

It is now possible for users to run the bot manually, and see the output from it on a web page as it runs. Approved users can find the link under 'Run bot' at the bottom of the list of links, once they are logged in. The bot will not run if it is already running (on somebody elses web browser, or as a scheduled task), or if it severely malfunctioned (unhandled exceptions, etc.) at the last run. - EdoDodo ^talk 12:02, 2 August 2010 (UTC)[reply]

Oh, I forgot to mention, even when running "in somebody's web browser" (it's not really, they're just being sent the output real-time), complete logs of the run are kept on the Toolserver for debugging and stuff. - EdoDodo ^talk 12:07, 2 August 2010 (UTC)[reply]

I've just tested this new feature and I gotta say, it's quite slick. EdoDodo is a responsible operator and this bot seems to be chugging along quite nicely. I see no barriers to approval. –xeno^talk 19:51, 2 August 2010 (UTC)[reply]

Approved. MBisanz ^talk 15:14, 3 August 2010 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.