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]
4. 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]

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]
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]

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]

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.   — Jeff G. ツ (talk) 17:24, 12 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]

• 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]

(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]