Handle editathon with more style

[stwalkerster]

Rough Workflow

1) User requests tool account for editathon management, linking account via OAuth as normal. 2) User creates event using event management, specifying a key for participants to use during their creation process 3) Event is approved by a tool admin 4) User proceeds to host event, giving users a special URL to use to create their account (probably something like /index.php/event?uuid=48432608-41fc-40b4-b7ed-7198045c7510 to idle URL guessing. 5) Requester fills in the request account form, passing the extra "event key" that is setup by User 6) Request gets tagged as part of the event, and is shown to User in a cut-down version of the main request list 7) User handles requests for their event, shown in a redacted form, skipping all private data (IP data is useless if everyone shares an IP address, not much is gained from email address display anyway) 8) User hits the create button on the request, the tool uses their stored OAuth credentials to create the account. If anything like blacklist or antispoof is hit, the request is escalated to normal tool users. User can also escalate to tool users on their own.

Points of note

• Tool security will be extended to create two new user states: NewEventUser and EventUser
  • Add a radio button on tool signup to allow the user to choose between New and NewEventUser as their initial state.
  • Extend status change workflow to allow changing a user's event/not-event roles
  • Event roles will not require identification
• Event users will not be able to see any request that is not tagged for one of the events they are an organiser for. This includes untagged requests.
  • Normal tool users will be able to see all requests.
• Events have to be approved by Tool Admins, and can be disabled at any point by Tool Admins. Disabling an event removes the ability to request new accounts for that event, and removes the ability for the organiser to see that event.
• Events have a start and end time, which is the time period between which the request key will work. After the event is over, we should redirect to the main request form and create untagged requests as normal.

[cyberpower678]

Looks good.

[bluerasberry]

I read this workflow. I regularly organize Wikipedia/Wikimedia events and this is a process which would work for event organizers. What is described here would be easier than the current process in use by organizers and also would address some of the security concerns which make the wiki community anxious and afraid of group outreach events with many new account registrations.

I wish to highlight a social concern. The first step is "User requests tool account for editathon management". This tool can only be useful if the expected user is a typical event organizer. Right now, outside of interface and software concerns, there is in-wiki social pushback against granting tools to permit typical event organizers to create accounts for new users at wiki events. A typical organizer, for example, might be a librarian hosting a wiki event for 15 people who join an event at a library, and that would be a typical user of this tool. The security of this tool should be aligned with the expectation that if a person is verified (whatever that means) to be a librarian hosting a wiki event, then they should be able to use this tool to register 15 new users who join their in-person event. This tool would not be useful if such a person were not permitted to create accounts in those circumstances.

[stwalkerster]

@bluerasberry So I don't know how we can solve the general case of the smaller groups needing to create accounts like this.

If we allow "unknown" people access to bypass the threshold, we're essentially opening the door wide open to abuse here. This is also why I'm wanting to use the organiser's account to do the creations via OAuth, such that they need the accountcreator permission. I'm happy for users who can gain that to use this tool, that's not an issue.

We simply don't have a good process to tell apart a sock master from an honest librarian - this is not something I think can be solved by a technical process, which this is. As much as I'd like to solve this too, it's not something that is targeted by this solution, and should be discussed on-wiki anyway.*

The problem this is trying to solve is that where an event organiser requests account creator rights then leaves their laptop in a public place logged in for people to create accounts themselves, or where event organisers have difficulty getting the limit lifted for an IP, or where use of the existing ACC tool takes too long. All of these require some level of verification already, and are non-ideal solutions with no real auditing and abuse-prevention capabilities.

• Side note, I wonder if adding yet another creation form which is specific for events generally but isn't part of a specific event queue should be added. Creations to this form go to a separate queue on the tool and can be prioritised if they come in, and this form can be only published in event organisation circles - too wider publication would negate the benefits of the separate form, and too narrower scope means it wouldn't be found. There'd be no way for an event organiser to take responsibility for approving the accounts themselves in that case though, so it'd have to wait on the main team as currently happens. That can be done in a separate change though, once more thought has been put into it other than this quick point.

[FastLizard4]

@bluerasberry Reading your comment, I'm not sure the problem you describe exists. This document is a purely technical specification, and the standards to be used for approving event managers is flexible and can be decided later on-wiki in front of a wider audience. I see no reason why, as long as community consensus is okay with this, we can't give a "verified librarian" access to manage their events, even if they are "new" to Wikipedia.

Edit: I'd also like to add that we can't really change the social situation on Wikipedia; all we can do is provide technical solutions to problems within the existing social and political frameworks. Changes to either of the latter need to be discussed on Wikipedia in the appropriate community venues.

[bluerasberry]

@stwalkerster @FastLizard4 Okay - hmmm.

Yes, I confirm that this is a need to address.

The problem this is trying to solve is that where an event organiser requests account creator rights then leaves their laptop in a public place logged in for people to create accounts themselves, or where event organisers have difficulty getting the limit lifted for an IP, or where use of the existing ACC tool takes too long.

If this tool can increase the security in these situations, then that would satisfy the stakeholders who are concerned about security. It sounds like the point of this is not to make it easier for anyone to organize events, except possibly as a side effect of making the broader community more comfortable about the security practices at events.

What I had imagined was that this process was intended to increase security enough to justify lowering some barriers to receiving account creator rights. For as long as the barriers to getting those userrights remain high, there will be challenges for event organizers.

I see no reason why, as long as community consensus is okay with this, we can't give a "verified librarian" access to manage their events

There is a problem. The community is not okay with giving new users account creator rights. The stated reason is security concerns. One of the security concerns is that account creator rights comes with extra override abilities beyond creating accounts, so separating that override function from the account creator tool addresses some of the problem. I wish that baked-in to the development of the next thing there would be some anticipation of event organizers - almost always a professional in affiliation with a school or community center - would want to register a group of new users. I can imagine that the event organizer could get experienced Wikipedians to take responsibility to sign off on verifying their identity, but currently, the English Wikipedia account creator rights review process often challenges requests from users without significant wiki experience and that uncertainty leaves some barriers to planning outreach even if they do have support from experienced wiki users.

I am unclear if this tool is intended for me. It might be that this tool is addressing issues beyond the usual concerns that I face as an event organizer.

[stwalkerster]

@bluerasberry , from what I see here the bundling of the ratelimiting and the account creation is what you see as the primary issue here?

I think we could probably let a bot do the actual creation in some circumstances, pending community consensus (which might be hard to get). My preference would be to use the event organiser's account to do the creation in as many cases as possible for tracability, but I think we could probably push the decision to the tool admins here, as they are likely to be able to get better validation as to whether or not a user is legit. I think a good approach here would be to get the event organiser to email the tool admins from an official email address confirming the request - something they can't really do on-wiki. I don't want to go down the bot route just yet, at least until other avenues have been tried. I'd rather get this up-and-running as soon as we reasonably can in a basic version that we can have a few more-experienced users such as yourself try with a real crowd to iron out any last few bugs. Once that's explored, we can look to expand and add the bot functionality if and only if it really is required.

If a user uses the tool to create an account, the log entry should be tagged as coming from that tool. We can easily make the tool ignore the extra rights granted in that package, and we can also make it clear to the user at request time that they're only to use the tool. Verification would thus be simple - are there any account creation log entries in the time period they have the user right that are not tagged from the tool?

I can't help thinking that this is trying to solve a social problem with technology though. This point really ought to be pushed with the admins who frequent WP:RFPERM, to the point of possibly unbundling the rate limit exemption from the two extra user rights granted, and pushing the event organisers to simply request this right.

[FastLizard4]

@bluerasberry:

If this tool can increase the security in these situations, then that would satisfy the stakeholders who are concerned about security. It sounds like the point of this is not to make it easier for anyone to organize events, except possibly as a side effect of making the broader community more comfortable about the security practices at events.

That is correct. The goal here is to create a standardized, secure mechanism for creating accounts at editing events. This should have the effect of making the community more comfortable with account creation at events, as well as making the process of hosting an event simpler by virtue of standardizing the process of creating accounts for attendees.

Again, we are only capable of solving technical problems, not social ones.

What I had imagined was that this process was intended to increase security enough to justify lowering some barriers to receiving account creator rights. For as long as the barriers to getting those userrights remain high, there will be challenges for event organizers.

I believe I touched on this issue in a reply to you on-wiki some time ago; there will likely be a need for a new user right to be proposed to the community that allows for bypassing the six-accounts-per-day limit without the additional abilities to bypass things like AntiSpoof, or (as an alternative to the currently proposed OAuth-based solution) a properly privileged bot controlled by ACC doing the actual account creations (which would require no additional user rights to be conferred to the event organizers, but the bot itself would need community approval instead).

I wish that baked-in to the development of the next thing there would be some anticipation of event organizers - almost always a professional in affiliation with a school or community center - would want to register a group of new users.

You need to recognize that there are more than just technical considerations here. For example, sockpuppetry is a very real abuse problem on Wikipedia, and technical and policy measures are necessary to combat it. This is why the six-accounts-per-day limit exists in the first place - a solution of policy, not a strictly technical one (even if it is enforced by technical means). Because of the abuse, it was decided that we simply cannot allow just anyone to create however many accounts they want, so there will always be some barrier to entry for people wishing to host/manage editing events. Barring unforseen changes in the social climate on Wikipedia, this is simply a fact of life - there is nothing we can do about it from a technical aspect, and instead I would suggest proposing changes at the appropriate venues on-wiki, and working with others who coordinate editing events to determine a vetting process that can be used to work around this.

It's worth noting that I can't actually find anything on Wikipedia that is something resembling a list of recommendations and procedures for people who wish to host editing events; perhaps this is something you should pursue first before turning to us for technical solutions? (If this does exist, though, and I've simply missed it, please do provide a link.)

but currently, the English Wikipedia account creator rights review process often challenges requests from users without significant wiki experience and that uncertainty leaves some barriers to planning outreach even if they do have support from experienced wiki users.

Again, the event account creation management proposal in this issue combined with a new user right on-wiki should mitigate at least this much.

I am unclear if this tool is intended for me. It might be that this tool is addressing issues beyond the usual concerns that I face as an event organizer.

The project you are currently looking at, enwikipedia-acc, is the code currently used for WP:ACC on Wikipedia. As it is currently written, no, this tool is not intended specifically for event managers, but for trained account creators. The event management additions described in this issue, however, is written with extending ACC to event managers in mind.

I do agree with @stwalkerster though; it seems increasingly like you are trying to get us to solve with technology what is really a social problem. In addition to his suggestions, I would suggest revisiting the comment I left on-wiki on this issue a couple months ago in a talk page discussion we both participated in. Regardless, if it is in the end a social issue you wish to solve, there is only one place where that can be done - on Wikipedia, in the appropriate community discussion venues.

[FastLizard4]

@bluerasberry To add to my comment above, we are happy to make the changes described in this issue to the ACC tool in the hope that you and other event hosts will find them useful, and in the hope that it will make the community more receptive to standardizing a procedure to allow for account creations at editing events. However, no matter what, we cannot be the sole drivers of social change, and at some point, even with the changes described in this issue, you will need to propose some changes on-wiki and work with the wishes of the community if your end goal is to reduce the barrier of entry for event hosts.

[dqwiki]

I personally like the idea of an ACC Bot doing the actual creations. This also would likely be easier to support though onwiki. Any unbundling of any tools right now is a super minefield with the community and all proposals sink quite fast not because of merits, but mentality. It's not a difficult thing to include a link to a tool request in the creation and mention that it's an event.

We still get the needed information with the tool like an email address (and although the IP address is invalid, it would be anyway). This would also protect the end user from getting stiffed up by a checkuserblock cause they think there are loads of accounts being created from a (relatively) new account of a librarian or something of the sort.

There is no loss in using a bot to create the accounts no more than normal ACCing is. There is the increased benefit of offwiki review of the organizers to vet them, something that would be a benefit to the community, as it can't happen onwiki, nor is it a viable option through OTRS.

[FastLizard4]

On the subject of bot vs. OAuth API calls through the event manager's account to create accounts, I have no strong opinion either way and I can see the pros and cons of both. Either is 100% acceptable to me.

[stwalkerster]

So, as far as implementing this, I have the following general tasks to be done:

• [x] User rights changes
  • (kinda done, not confident, so going the nuclear option and implementing full RBAC instead)
• [x] Event management UI - including event workflow stuff
• [x] Customised request forms, including tagging the request with the event
• [x] Display of queued requests
• [ ] Request zoom without data
• [ ] Escalation to main team
• [ ] Automatic creation
  • [ ] via OAuth
  • [ ] via Bot

[stwalkerster]

I'm going to boldly close this, as we took so long to get newinternal into prod that the Program and Events dashboard now effectively handles this functionality.

Some of the functionality added in this will be rolled into #532.