This is not the page to request an account on Wikipedia. This page is for discussion of the Request an account page and its process. Please go back to the request an account page to read how to request an account. This page is automatically archived by MiszaBot II. Any sections without comment in at least 18 days will be moved to the archive.

Archives

Archive 1: Feb 07 - Nov 07 Archive 2: Nov 07 - Feb 08 Archive 3: Feb 08 - Aug 08 Archive 4: Aug 08 - Dec 11 Archive 5: 2012 - 2019 Archive 6: 2019 - 2021

This page has archives. Topics inactive for 18 days are automatically archived by Lowercase sigmabot III.

It seems like only a handful of CheckUsers have ACC Toolserver usage authorization, and about a couple are reasonably active. Do all CheckUsers have ACC authorization? If it isn't true, I would think they should automatically get authorization. Just a thought. -- Luke (Talk) 16:09, 28 December 2011 (UTC)[reply]

I think this proposed is a really good idea. A few months ago we had a big backlog of account requests which needed a CU, luckily I'm a bit familiar with some because of some chats in different IRC channels. Since then we have "a new CU" helping us out (and luckily very active atm). mabdul 20:56, 28 December 2011 (UTC)[reply]

Right now we actually as I've seen it had 2 very active CUs if not three. All Checkusers are entitled to flags once they register for their own account, otherwise, we can't force them to have an account. I know for a fact that not all CUs want to register either, so we have to let them do it on their own. But I am happy to approve all CUs and poke Stwalkerster for the Checkuser flag for them. -- DQ (t) (e) 00:24, 29 December 2011 (UTC)[reply]

It may not be necessary for all CUs to have access, like you said, but it can useful if there is a backlog of requests. They don't have to be active, either. -- Luke (Talk) 00:28, 29 December 2011 (UTC)[reply]

see proposal at Wikipedia:Village pump (proposals)#ACC_e-mail feature. mabdul 00:26, 15 January 2012 (UTC)[reply]

hi

i want to ask you guys somthing

i creat an account befor maybe 5 or 6 months "i think " anyway i would like to creat a new account and remmber that i have another account .

please give me clear answer ,thakkkkkkkkkkkkkkksssssss

please help guys and thank you — Preceding unsigned comment added by 79.179.170.235 (talk) 18:59, 27 February 2012 (UTC)[reply]

yes you are allowed to create a new account as described here WP:CLEANSTART as long as you only use one of your accounts. Regards, mabdul 19:55, 27 February 2012 (UTC)[reply]

Hi

thank you but i need to tell me how to do a new account or at least a link ...

thanksssssssssssssssssss help pleaseeeeeeeeeeeeeeeeeeeee — Preceding unsigned comment added by 79.179.170.235 (talk) 20:19, 27 February 2012 (UTC)[reply]

FYI

 – copied from Wikipedia:Village pump (proposals), mabdul 20:30, 27 February 2012 (UTC)[reply]

I have created a proposal at Meta, to complete unified login for all eligible accounts. Unified login is a relatively new feature to the WMF wikis, allowing each user to have a single combined account in every project. Users that only have an account on one wiki would extend that to all wikis, and users that already have accounts on multiple wikis would have them combined. It was initially an opt-in for existing users, but it is now done by default for all new users. This leaves us with three groups of users: those with UL, those that cannot complete UL because of a naming conflict on another wiki, and those with no conflict that have simply not completed the process. I am proposing that account unification be completed for all eligible accounts without requiring the user to take any additional steps. This would make UL the rule rather than the exception that it currently is, and bring us closer to the goals of universal watchlists, recent changes, interwiki page moves, etc. This would be especially helpful on Commons, which has so many images that were originally uploaded at another WMF wiki, enabling better attribution without interwiki links. I propose that it be carried out as a one-time process rather than a continuous automatic software process, allowing users to still adjust ULs as they see fit.

If you have any opinion one way or the other, please reply at the proposal at Meta. ▫ JohnnyMrNinja 01:01, 23 February 2012 (UTC)[reply]

Hey guys. I've been speaking with Sumana Harihareswara, Brandon Harris and a couple of other WMF people about the ConfirmAccount extension, which was formally requested four years ago following a discussion here on enwiki. For those of you who weren't in the original discussion; ConfirmAccount is a MediaWiki extension that creates a new process for account creation, in which accounts are requested and authorised by someone with a specific user-right rather than merely created through the registration scheme. This is most useful in situations where the "normal" registration process doesn't work - for instance, when CAPTCHA issues make it difficult to fill out our standard form. This may sound similar to the Account Creation interface currently hosted on the Toolserver. In fact, the idea is that this extension would completely replace it, moving ACC functionality "in house" and clearing up the need to go off-site to use it.

Nothing was done at the time because of a dearth of developer time, and soon after, the ACC system on the toolserver was developed, which removed much of the need for this extension. However, it has been mentioned that:

with the current setup at [the toolserver] there is an external server dependency, an entirely separate user interface, a separate user auth and permissions system, and the possibility for unwittingly leaked data like IP addresses of users requesting accounts. This is undesirable and unacceptable.

Putting in the ConfirmAccount extension would completely clear up these issues, if they exist. However, we still (and probably forever will) have less developer time than we do things to do. The consensus reached in 2008 is now stale, and we need to know, broadly-speaking, if there is a strong feeling in the community that this extension should be enabled. We don't want to waste our time reviewing code for something that isn't wanted, when we could be working on other, necessary bugfixes that improve the editing and reading experience :).

So, TL;DR: I would be very grateful if people could indicate, in the sections below, whether they think this is necessary. If so, we can prioritise switching it on: if not, we won't. It is worth noting that the need to identify to the Wikimedia Foundation will still apply, and we will have to create a new user group; I imagine the process will work along the lines of "a user requests the permission, submits identification to the WMF, the WMF confirms the identity, a bureaucrat gives the user the appropriate user group status". Obviously, there's no reason that people who already use ACC and have identified shouldn't get this new right automatically. Okeyes (WMF) (talk) 12:58, 12 April 2012 (UTC)[reply]

1. tools:~acc is a bad hack. Most of the original authors later agreed with this. One or two were even granted commit access to MediaWiki's code repo to work on an extension to replace it. The tool is an unnecessary external server dependency, it has separate user authentication, it has data storage and management issues (IP addresses, e-mail addresses, and whatever other personal info gets input), etc. It's also become a mini-bureaucracy within Wikipedia. It should be in an extension. --MZMcBride (talk) 13:32, 12 April 2012 (UTC)[reply]

   Replied to this comment below. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)[reply]

2. An extension that does the exact same thing as the current system is already a big improvement because it does not have the disadvantages that the current system has. If we (as a community) send good feature requests to the developers it will be an ever bigger improvement. Von Restorff (talk) 13:34, 12 April 2012 (UTC)[reply]

   The proposed extension does not do the exact same thing as the current system, not really even all that close. It is more like stripping away every check and giving out accounts just because someone asks - who cares if they have a block or are banned or are a company looking to advertise or if the name conflicts with an account in FR and DE and IT languages, or if it is their 17th request of the day. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)[reply]

3. I used the toolserver version which was a lot better than the way the process used to be (mailing list, wiki page). The extension is overdue and would it would just make more sense now to have it built-in. Rjd0060 (talk) 16:23, 12 April 2012 (UTC)[reply]

1. I gather the resources that go towards ACC development do not overlap with the resources that go towards MediaWiki coding given one is Toolserver-based and the other is not. As long as the ACC developers are willing to continue to maintain it, we can avoid hitting up our more limited MW developing resources. The security/privacy risk is a concern, but the Foundation seems fine with it. MBisanz ^talk 13:35, 12 April 2012 (UTC)[reply]

   Re privacy, everyone with access to IP and email data on the current tool is identified to WMF and is supervised minute-by-minute by tool admins on IRC.   — Jeff G. ツ (talk) 04:01, 13 April 2012 (UTC)[reply]

2. Very very hesitant and opposed right now to switch. I've worked with the ConfirmAccounts extension offwiki, and it's not anywhere close to what ACC is. You can't leave comments, it's a one reviewer system (which is the same problem that came up on unblock-en-l), I don't remember much of a log of actions for this. Also the requested info on the extension by default contains very limited use for us. I basically want to see a good plan on this and a coding change before I support any MW extension on this. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)[reply]
3. The extension that is proposed is fundamentally useless for the objectives it is seeking to serve. Simon listed off many things that would need to be changed before he would support anything of this sort. I would simplify it to say that THIS EXTENSION is a NO, a new extension is a possibility. If we don't know that it is a person's 3rd or 23rd request for an account in a day (or ever) then there is no reason to refuse. If we don't get IP data then how would we know a person is not simply bouncing between hotmail yahoo gmail and a few others making multiple requests for accounts. If IP data is not available then we have no idea if there is a block in place and if there is a pattern of abusive behaviour existent from (possibly) the person now asking for an account. If the CU at ACC didn't have UA access they wouldn't be able to tell if the person who is the cause for a range block is now asking for an account.
   What MZM and Okeyes are pushing here is an extension that is a simple 'can i have an account? yes/no' and with no reason to say 'no' we would be compelled to create new accounts for community banned users, people wanting dozens of accounts to screw around with, and people who genuinely are having issues with the captcha. But we wouldn't have any idea who is who.
   A bad hack that works is better than a non-hack that is useless; revive when you have a useful extension to propose. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)[reply]

   Deliriousandlost, I'm not "pushing this" at all. I have no opinion either way; I was asked to gather more information on what the community felt, and have done so. Okeyes (WMF) (talk) 15:27, 12 April 2012 (UTC)[reply]

   I'm curious why such a bureaucracy has built up around account creation requests. Can you elaborate a bit further about this? I imagine there must be a reason. For example, you mention the ability of (bad) users to bounce between Hotmail and Gmail accounts, etc. as though it isn't possible for nearly any user to create a many accounts as they please right now at Special:UserLogin. It was my understanding that the original purpose of account creation requests was mostly as a means of bypassing the CAPTCHA (for users with disabilities) and others who had been wrongly blocked from account creation based on their IP. There are undoubtedly improvements needed to the current extension, but what about this whole process requires more than a simple yes/no interface for account approvals? --MZMcBride (talk) 16:44, 12 April 2012 (UTC)[reply]

   We have some very creative vandals. Once blocked, they have been known to try to create many accounts from one IP with one email address, from one IP with different email address, from different proxy IPs with the same email address, from different proxy IPs with different email addresses, with names similar to or identical to names on other projects and SUL, and/or promoting their websites and other globally unique intellectual property. Sadly, proxy IPs above include all AOL customers.   — Jeff G. ツ (talk) 18:22, 12 April 2012 (UTC)[reply]

   I am curious why you have such a fundamental hatred of the toolserver and why you persist until you get your way. This was a dead issue 3 years ago and you didn't like it so you re-opened it 19 months later and waited for someone to notice.
   Mostly it is to help those who have issue with the captcha but it also serves as a means to ask if a user name that someone isn't sure about would be acceptable. Victims of range blocks do come up fairly often. With restricting IP data we would be able to do shit all about it when they would come up. Occasionally the email address will hit on another request or 3 and unless you think giving someone a 4th account is a good idea then knowing is better than not. You are correct that someone can game the system in the short term by simply creating a few accounts each day for themselves. But doing so for themselves will associate those accounts with the IP address they use to create them. And they will get caught fairly easily. Not as many people think to have someone else create those collections of accounts for them but when they do try it it is nicer to catch it early rather than find oneself subject to a CU investigation because subsequent behaviour of seven accounts one created has linked them together and to you as their creator. And if those 7 accounts were created by 7 different people at ACC who had no means of knowing of any connexion betwixt them then there is the ultimate gaming of the system: various other people from a multitude of IP addresses creating a collection of accounts to be used in the long term for abusive purposes and no way to link them until the abusive behaviour was committed and no way of knowing just how many times we had been fooled. To go back to an earlier point, the causes for range blocks do tend to try to bypass them once in a while hoping we consider them simply another innocent victim. Since the range blocks are anonymous only if they can get an account from us they have succeeded in bypassing their own block. For that reason we have a few CU who have access to the UA data of the requests. If you are in favour of blocked users bypassing their blocks so easily and being puppets ourselves in helping people collect dozens of accounts then we could simply ignore all of that and grant accounts based on how we feel. Which seems to be what you want.
   Then there are the schools which have classes involving Wikipedia and say there are 20 students in the class and 18 haven't already got accounts then after 6 create an account for themselves the other 12 are left waiting for another day or two. Sometimes we get advance notice and sometimes we look at the requests and assess it as such a situation.
   If you hadn't walked away from it four years ago you might have some more understanding of what is done today at ACC. But hey, you gamed the bugzilla system in getting this all going again so congrats for being proof how easily manipulated things can be and for why the checks are a good thing. At least you were honest about it being you who was doing it. delirious & lost ☯ ^~hugs~ 18:25, 12 April 2012 (UTC)[reply]

   Yes, I hate the Toolserver so much I have an account there with a number of active bots and tools. Your post is riddled with such a mountain of factual inaccuracies and general nastiness that it simply isn't worth my time to reply to it in full.

   I've come across you a few times previously and I always considered you rather sensible and clueful. This reply of yours is simply shameful. :-( --MZMcBride (talk) 18:31, 12 April 2012 (UTC)[reply]

   No. Except for her opening and closing statements (which I won't comment on) she is actually quite right with several of the things that go on with ACC. If you take the time to actually look at it, then maybe we can get some where positive. -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)[reply]

4. I don't want to repeat what others have already said, but, basically, the ACC interface works. It allows an account creator to run various checks to make sure he's not helping a wannabe spammer or a banned user trying to evade his sanction. That's why unless and until this interface allows for such checks, I'll oppose implementing it. Salvio ^{Let's talk about it!} 16:36, 12 April 2012 (UTC)[reply]

   What checks does Special:UserLogin provide against such bad users? Or put another way, how stupid would a wannabe spammer or banned user have to be to use the account creation tool rather than making their own account through the standard built-in form? --MZMcBride (talk) 16:53, 12 April 2012 (UTC)[reply]

   Per the lede at Wikipedia:Request an account, "In most cases, users can create accounts without assistance. However, where problems arise (such as with the CAPTCHA image or the desired username), users may request an account be created for them." Thus, Special:UserLogin only checks for CAPTCHA and similar/existing local usernames.   — Jeff G. ツ (talk) 18:11, 12 April 2012 (UTC)[reply]

   Special:UserLogin will note the IP addy used in creating the account though it doesn't display it. You make 6 that way and all 6 are easily linked. Create 6 more tomorrow from a different IP and those 6 are linked. Eventually the combination of the behaviours from the accounts will link them all together. But if you can get someone else or 3 other people to make those accounts for you it scrambles a bit of the association and makes linking them based on behaviour less likely. If they don't know of how easily caught they would be some do think going through ACC is the best way to get three dozen unassociated accounts which they can use to disrupt things for months to come. When they get caught on the second request most back off. There are ways to game ACC today but i don't think publicly going on record about how to do it would be a good thing. delirious & lost ☯ ^~hugs~ 18:25, 12 April 2012 (UTC)[reply]

5. I am opposed per all of the above in this section. The following links and checking functionality in the tool on the toolserver (as borrowed from Wikipedia:Request an account/Guide#IP_Address_links) would be lost:
   • Talk Page links to the IP's talk page (helps guard against vandals and block evaders)
   • Local Contributions links to the IP's contributions on the English Wikipedia (helps identify vandals and block evaders)
   • Deleted Edits link to edit counter showing deleted edits (helps guard against page creation vandals)
   • Global Contributions links to the IP's contributions across all Wikimedia projects (helps guard against vandals and block evaders from other projects)
   • Local Blocks links to the IP's block log on the English Wikipedia (helps guard against vandals and block evaders)
   • Local Range Blocks checks for any applicable IP-range blocks on the English Wikipedia (helps guard against vandals and block evaders)
   • Global Blocks links to the IP's global block log on Meta (helps guard against vandals and block evaders)
   • Global Range Blocks checks for any applicable global IP-range blocks or locally disabled global blocks (helps guard against vandals and block evaders)
   • Whois runs a WHOIS on the IP (helps guard against physical location and domain COI via correllation with Google results)
   • Geolocate Geolocates the IP (helps guard against physical location COI via correllation with Google results)
   • Abuse Filter Log shows all actions from the IP that tripped an Edit Filter (helps guard against vandals and block evaders)

   Also lost would be the granularity of the tool's responses to the requester, which currently include "Created! | Similar | Taken | SUL Taken | UPolicy | Invalid | Password Reset | Custom | Drop", as well as the specialization hierarchy of Users, Flagged Users, and Checkusers, the creation history for the IP and the email address, comments, IRC discussion, and mailing list discussion. I shall remain opposed until a proposed extension or other on-wiki fix has similar safeguards.   — Jeff G. ツ (talk) 17:24, 12 April 2012 (UTC)[reply]

   You're opposing because of the lack of a link toolbar? Do you understand that would take maybe a minute to re-create in the extension? --MZMcBride (talk) 17:41, 12 April 2012 (UTC)[reply]

   Not just the link toolbar, I just elaborated above.   — Jeff G. ツ (talk) 17:53, 12 April 2012 (UTC)[reply]

6. No thank you. ACC is a great system for many reasons mentioned above. ConfirmAccount is a great tool for small projects (I use it on mine) but, this is only because I don't need such a system in place, Also can you imagine the backlog this would create, Now not just the requests that are having problems creating an account but, now "All" new accounts would require review ? and if not then why break something that's working ? Mlpearc (powwow) 17:43, 12 April 2012 (UTC)[reply]

   Where did you get the idea that all new accounts would go through this process? Only a very limited number of accounts should be going through any supplemental account creation process (in an extension or on the Toolserver or anywhere). Most users should be creating their own accounts. --MZMcBride (talk) 17:47, 12 April 2012 (UTC)[reply]

   I'm sorry then, If all account creations are not going to go through ConfirmAccount (This is what this extension is used for) then why are we even talking about changing to it ? Mlpearc (powwow) 21:08, 12 April 2012 (UTC)[reply]

7. Oppose - we want to make it easier for good-faith editors to register, not harder. I'd support it if the extension were modified to only affect blocked users.--Jasper Deng (talk) 17:53, 12 April 2012 (UTC)[reply]

   Sorry, I'm not following this comment at all. What about this extension do you think makes it more difficult to register for an account? This is not intended as a replacement for the built-in registration form at Special:UserLogin, you realize? --MZMcBride (talk) 18:00, 12 April 2012 (UTC)[reply]

   I've seen this extension used before. Do you even know how this extension works? It explicitly asks for the disabling of anonymous account creation - the extension is intended to replace Special:UserLogin, and as a matter of fact it does. When I registered, I liked the fact that I was able to use my account immediately. This would be a waste of time for good-faith editors.--Jasper Deng (talk) 18:07, 12 April 2012 (UTC)[reply]

   Why do you believe the previous uses you've seen would match what's used here? As the documentation notes, you can re-enable account creation for all users using $wgGroupPermissions, which of course would be done here. I'm still not following your line of reasoning at all. --MZMcBride (talk) 18:12, 12 April 2012 (UTC)[reply]

   Huh? That would completely defeat the purpose of this extension. The point about the ACC process is to help blocked users, and I know there is a setting to allow blocked users, but I find it pointless to try something intermediate between normal account creation and fully requested creation because the extension isn't designed for that.--Jasper Deng (talk) 18:16, 12 April 2012 (UTC)[reply]

   The idea is to move the tools:~acc process back in-house, which has a number of benefits. You seem to have ignored those benefits in favor of railing against using an extension in a way you simply don't like. :-/ --MZMcBride (talk) 18:18, 12 April 2012 (UTC)[reply]

   ...and this extension won't do that. I know there are a number of benefits, but I cannot support the extension in its current form because it does not serve ACC's purpose of only doing requests for blocked users.--Jasper Deng (talk) 18:23, 12 April 2012 (UTC)[reply]

   "ACC's purpose of only doing requests for blocked users"? What are you talking about? I believe ACC serves more than just blocked users. Did you really intend to use "only" there? --MZMcBride (talk) 18:25, 12 April 2012 (UTC)[reply]

   Then why else would we have such a process? Legitimate users who aren't blocked (including on the IP level) can simply use Special:UserLogin without a hitch. If they have problems with CAPTCHA, they can also request, but I feel that we don't have a big enough audience to warrant that.--Jasper Deng (talk) 18:27, 12 April 2012 (UTC)[reply]

   AntiSpoof, TitleBlacklist, and ConfirmEdit are three exaples besides being blocked. [stwalkerster|talk] 18:31, 12 April 2012 (UTC)[reply]

8. So far, the arguments hold against the existing Toolserver ACC page, but not for converting to the CreateAccount extension. CreateAccount is not an on-wiki equivalent to ACC, but outdated and unsuited to our needs. In my view, only an extension (based or not on CreateAccount) that has all of ACC's features could be acceptable. AGK [•] 23:58, 12 April 2012 (UTC)[reply]
9. Not just now. While it would be a great advantage to move all this back onto Wikipedia and off the Toolserver - especially considering the Toolserver is about as reliable as a rock is soft lately - for the security of the site as well as the benefit of the requesting users, we need at least all of the functionality provided by ACC to be provided by this extension. Namely the email address (at least the domain, as in UTRS - this will indicate if it's a business address), useragent, IP address, links to other requests from the same IP and/or email, ability to discuss requests with other reviewers, etc. and so forth and on and on. With this information, we can prevent most of the sneakier sockpuppeteers from getting more accounts, and counsel editors with potential conflicts of interests regarding relevant guidelines and policies before they edit and risk getting blocked for spamming. Once it's clear that this functionality is available, I'd be all for adding an extension such as this. Hersfold ^(t/a/c) 00:07, 13 April 2012 (UTC)[reply]
10. Oppose - CA was designed for (a) standard smallish MediaWiki installs that have trouble dealing with spam accounts and (b) Citizendium. It would take a lot of work to get this polished and in to shape for this use case. We can't afford to take staff time on this. There is way more work that people as is. If toolserver volunteers are doing a decent job separately, then we can, and should, continue make use of that work. I'm not *terribly* worried about toolserver and privacy, though it's not ideal at the moment. Aaron Schulz 02:45, 13 April 2012 (UTC)[reply]

• Good idea. Von Restorff (talk) 13:28, 12 April 2012 (UTC)[reply]

  Could you indicate how good/bad by elucidating or !voting? :). Okeyes (WMF) (talk) 13:29, 12 April 2012 (UTC)[reply]

• Of course. The toolserver workaround has major disadvantages (insecure, offsite, separate user auth and permissions system et cetera). We've used this dirty hack for a long time already. Let's fix it. Von Restorff (talk) 13:51, 12 April 2012 (UTC)[reply]

• It would be good to get it back onto Wikipedia, however before indicating my personal preference, I'd want to be sure that the extension was capable of performing as we would want it to. (I've not had chance to look at the extension specifically yet.) We'd want some way of at least the following: a) seeing the email address of a request (for cases such as marketing@somecompany.com ), b) seeing the IP address to check contribs/block log/etc, c) checkusers seeing the useragent, d) being able to check against the results of antispoof and titleblacklist, e) being able to close requests with different messages (upol, too similar, etc), f) make notes on different requests for internal use, g) a log of all actions, h) some way of marking a request as being dealt with. There's probably more, but that's what I can think of offhand. Without this, there is a strong possibility that accounts for known blocked malicious users would be created accidentally, and would be a step backwards. The current system is a bad hack, yes, but it's worked so far, and hasn't caused any major issues. [stwalkerster|talk] 13:56, 12 April 2012 (UTC)[reply]

  Good points :). I'll try and find out. Okeyes (WMF) (talk) 14:18, 12 April 2012 (UTC)[reply]

  Stwalkerster: I asked deliriousandlost this above, but regarding an example such as marketing@somecompany.com, wouldn't we presume that most such accounts are simply created through the standard Special:UserLogin form? I'm not sure why this extension is being held to such a high standard when it's really meant as a tool of last resort, isn't it? Most people should be creating their own accounts (and can do so with any kind of e-mail address they want—or none at all). Can you clarify what you view as the purpose of the account creation process? --MZMcBride (talk) 16:49, 12 April 2012 (UTC)[reply]

  To continue the example, spammy accounts are created as normal, but should a problem user spam enough to get the IP blocked (likely an autoblock), and we then get a request for an OK username from that IP, what's to say we aren't just creating an account for the spammy user? If it's a yes/no thing, then we're all but negating the affect of disallowing account creation on the Special:BlockIP in some cases. It's a tool of last resort, yes, but these data (read: these features) are needed, otherwise it's just going to cause more problems than it solves. At no point should we be directing users to ACC before directing them to Special:UserLogin/signup, but iff they are unable to create an account (for whatever reason, be it accessibility, technical issues, or otherwise), then they can come to ACC. It also gives us a chance to give a user a bit more of a helping hand with any possible issues that we may spot before they start even editing ("I just want to put my bio up" => mention N/COI etc), especially since they'd have (theoretically) had to jump through hoops already to even get an account. [stwalkerster|talk] 18:13, 12 April 2012 (UTC)[reply]

• It sounds like this request and what the extension actually do are different. Are we wanting to convert the old tool hack to an on-site method, or are we removing autonomy from non-account holders so that all accounts must go through this system? –meiskam (talk•contrib) 14:42, 12 April 2012 (UTC)[reply]

  The former; the extension would be implemented in parallel to the existing registration process, rather than to replace it. Okeyes (WMF) (talk) 14:52, 12 April 2012 (UTC)[reply]

I have no strong opinion on the merits of this, but I do wish to register an issue which I've discussed with Okeyes off-wiki. Currently, there is an account creator user group, which is granted to non-admins who are active in the ACC process. Those with the account creator flag, and admins, are exempt from the new account limit (six, if I recall correctly). The ACC process, or the ConfirmAccount process if we do decide to switch, gives users access to non-public information, and they need to identify to the Wikimedia Foundation in order to get access to said information: you have to do this already to get access to ACC. Now, if this were brought back on-wiki, a user group would probably have to be used to specify users who can have access to the private information held in the ConfirmAccount system. This is where it gets slightly complex. I see a number of possible options:

1. A new user group could be created for "account confirmers" (or some better name), which would basically be anyone who currently has access to ACC. Account confirmers have access to the ConfirmAccount tool.
2. The existing user group, account creator, is co-opted and anyone who is a member of account creator can access the tool. Admins who are interested in doing ConfirmAccount work simply request this user right after identifying with the Foundation.

The latter of these two options is obviously simpler, but I would argue that whatever we decide, we need to allow admins that do not have the account creator flag, and are not active in ACC/ConfirmAccount and are not identified to the Foundation, to continue being able to create accounts without the daily IP limit. There is a clear and simple need for it in outreach work: editathons, GLAM etc. If you are introducing a roomful of new people to editing Wikipedia, often you need to be able to create lots of accounts for them all, and this is something admins can do without hitting the IP limit.

If ConfirmAccount means that admins who haven't identified and aren't active in ACC cannot create new accounts, I'd suggest that wider consultation with both the admin community and the wider Wikipedia community might be necessary. Changes to what admins expect to be able to do may have unforeseen consequences: for instance, do we know whether OTRSers create accounts? How about people who help on #wikipedia-en-help? What about campus ambassadors in the various education programs? I'd suggest whatever we do with ConfirmAccount, don't change the status quo of exemption from account creation limit for admins. (And, hopefully, this message will be completely unnecessary and overcautious. } —Tom Morris (talk) 13:52, 12 April 2012 (UTC)[reply]

I think there's a distinction to be made between user groups and user rights here. We could totally continue to have the IP-limit-exempt function remain linked into the "admin" group regardless of what happens to Account Creator as a group. Okeyes (WMF) (talk) 13:56, 12 April 2012 (UTC)[reply]

Oliver, I have no clue what the ip limit exempt function is...it could be one of two things, could you clarify please? -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)[reply]

Technically it's "noratelimit"; the function that allows for what Tom is talking about (creating 20+ accounts from a single IP, say) Okeyes (WMF) (talk) 14:51, 12 April 2012 (UTC)[reply]

Thanks, that clears it up :) -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)[reply]

(ec) Admins have all the rights associated with accountcreator at the moment anyway, so while I see where you're coming from, for admins it's a non-issue. Other users however... [stwalkerster|talk] 13:58, 12 April 2012 (UTC)[reply]

I see the problem that if we model what ACC is going to do, that whole identification thing is going to be a huge hassle. Because only identified users would then be able to add the "new acc flag" what ever it is, and admins will have to not be able to see the data presented in the interface. In a way, then were going to need another user group of trusted users to add only those identified to the foundation. I'm going to poke Philippe and his team on this, but we need a clear draft on what is going to be visable and to whom, then who can add/remove that access, before we can even consider things. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)[reply]

• @MZMcBride: the issue you raise above about ACC having it's own bureaucracy is replicating right here. User flags. Just as it would at ACC. -- DQ (ʞlɐʇ) 14:29, 12 April 2012 (UTC)[reply]
  • LOL @ how true that is. delirious & lost ☯ ^~hugs~ 15:21, 12 April 2012 (UTC)[reply]
  • DeltaQuad: In some ways, yes. But I'm not the one advocating for a lot of additional user groups and user rights. I think the whole process should be used very rarely and should be much simpler. We already have a user system here. What I'd like to eliminate is the completely separate user system within this tool, as I think the benefit is nowhere near the cost. Most people should be creating their own accounts, shouldn't they? The number of requested accounts per day should be very low and it should only be a tool of last resort. Given the privacy implications of collecting e-mail addresses and IP addresses, some bureaucracy is inevitable, but there's surely a difference between re-using MediaWiki's infrastructure and completely duplicating it, no? --MZMcBride (talk) 16:51, 12 April 2012 (UTC)[reply]
    • Ok, so what your advocating for is a userrightless system, that needs people only identified to the foundation to access, or your going to take away the tools we actually have to fight vandalism and give legit people accounts. You have failed to comment on all the sockpuppets (that's the 1 of many issues) that could get through if everyone was "able to create their own account". Then there is also something called Collateral damage on our blocks where we catch innocent users, but without the data provided at ACC, we can only call it a guess, instead of an educated guess. This new "system" that is being proposed is a solution looking for a problem, when there is a problem with the solution already. Also I would like to mention the unblock ticket response system (UTRS) in which I am a developer at, and we are looking to be able to forward several of our requests for unblock (the collateral damage) into the hands of ACC people who know what they are doing. With us taking away ACC, that would eliminate that option and would force our administrators to take more time to review the dozens of appeals we get a day, and deal with what ACC easily deals with now. -- DQ (ʞlɐʇ) 22:36, 12 April 2012 (UTC)[reply]
      • "You have failed to comment on all the sockpuppets (that's the 1 of many issues) that could get through if everyone was "able to create their own account"." ← This is a joke, right? God help me. --MZMcBride (talk) 03:30, 13 April 2012 (UTC)[reply]

I've been asked to comment here - this is someone who used to be active with account requests several years ago but I'm no longer active. Personally I think it would be better to reduce bureacracy as much as possible - I know when I handled requests it was quite rare to see someone actually trying to abuse the system - most declined requests were because of simple mistakes or incomplete information and people rarely bothered to follow them up.

In my view the best solution would be for an account request to be accepted/declined immediately and automatically, so when someone tries to create an account all of the similar usernames are checked and if any have over x edits, most recent being y years ago (or some other algorithm defined in a mediawiki: page somewhere) then you get an error message saying to pick another name, otherwise it creates the account. Also audio captchas should be used. And the throttle on creations from one IP address should be removed and replaced with some sort of notification to checkusers for them to review. If there's abuse going on then the IP can be blocked.

Any usernames that violate policies can be handled like any other username, after they're created. If someone tries to create a username that hits a filter somewhere after all this then they should be told to just pick another username. They're probably used to getting this message as so many websites would need to reject a username for whatever reason when you try to sign up.

Obviously all this requires developer time but if developers are prepared to commit time to this then I think it would be the best solution. And it eliminates any risk of private information being leaked bacause no humans handle the requests. Tra (Talk) 17:25, 12 April 2012 (UTC)[reply]

• @MZMcBride: Maybe I'm not reading this right but didn't you just confirm what ACC is "it's really meant as a tool of last resort", yes it is to the prospective users where this is there last resort in getting an account ? Sorry if I misunderstood your meaning. Mlpearc (powwow) 17:57, 12 April 2012 (UTC)[reply]
  • I have no idea what you're asking here. I was saying that most users should be creating accounts on their own and that using any supplemental process (such as tools:~acc) should be a step of last resort. As such, requests made through this (or any other supplemental tool) should be very rare. --MZMcBride (talk) 17:59, 12 April 2012 (UTC)[reply]
• I agree with Tra. Mato (talk) 00:15, 13 April 2012 (UTC)[reply]

To elaborate, I'm not in support of the proposed extension - the ins and outs are not clearly explained in the proposal and from the comments it seems that many features will be lost. However there are, IMO, many problems with the current system: primarily, the treatment of personal/sensitive information; secondarily, the issues of beauracracy which Tra mentions above. Mato (talk) 00:34, 13 April 2012 (UTC)[reply]

I haven't noticed any bureaucracy at the ACC tool, especially as compared to how it works at WP:PERM here on the wiki. People request access and it's usually granted without ceremony unless the person has limited experience on wiki or appears to be hat collecting. Access to the tool is as easily revoked and if you can provide a reasonable explanation access is once again easily given back. There is actually very little fanfare at the ACC tool as far as I can tell; we just process requests all day sometimes ask around if we get a tricky one. As for privacy, we've all identified to the foundation, which is more than admin have to do. — Bility (talk) 01:22, 13 April 2012 (UTC)[reply]

I wasn't referring to bureaucracy relating to getting access, I was referring more to how so much is handled manually when it would be possible to do it automatically. For instance, someone posted a list in bold of links they would want to see added. Many of these relate to blocks - surely the simplest solution would be to reject the request automatically if they're blocked from en.wiki and let them through if they're not? I also don't agree with checking for any prior vandalism on the ip before the account is created - it could have been anyone doing it and it would be better for people to be judged by the edits they make under their account. Tra (Talk) 02:45, 13 April 2012 (UTC)[reply]

@ Tra, I have been involved with ACC for little over two years on a daily basis and have created over 1600 accounts and I have never denied a request on IP vandal editing alone, It takes a much bigger red flag(s) for any user at ACC to even consider doing that. Mlpearc (powwow) 03:11, 13 April 2012 (UTC)[reply]

That's pretty much my point - that if requests cannot be rejected based on an ip's contributions then I'm ok with that. Tra (Talk) 09:41, 13 April 2012 (UTC)[reply]

Ok I've read the various pages, and this discussion.

I'd like a bit more concrete data:

• 1.) which options would be set on Wikipedia (and other WMF wikis)? For example, would this be limited to bureaucrats?
• 2.) There seems to be a difference of opinion whether the tool server is the same as this extension. What would be the difference?
• 3.) Someone above said this will replace the regular account creation process as well? (self creation through the log-in page) How and why?
• 4.) How is this related to userrights? (The discussions above appeared a bit of a jumble to me.)

(I know some of this has been touched on here and there, but trying to figure this out as a cohesive whole). - jc37 05:27, 13 April 2012 (UTC)[reply]