Last modified: 2014-01-03 16:15:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15782, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13782 - Install ConfirmAccount extension on Wikimedia wikis
Install ConfirmAccount extension on Wikimedia wikis
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Low enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
https://en.wikipedia.org/wiki/Wikiped...
: design
Depends on: 25732
Blocks: 31235 13498
  Show dependency treegraph
 
Reported: 2008-04-18 00:57 UTC by Alex Z.
Modified: 2014-01-03 16:15 UTC (History)
25 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Alex Z. 2008-04-18 00:57:29 UTC
Please install the ConfirmAccount extension on enwiki. http://www.mediawiki.org/wiki/Extension:ConfirmAccount. The discussion in support of this is at the URL.

The settings to be used should be:
$wgAccountRequestExtraInfo = false;
$wgAllowAccountRequestFiles = false;
$wgConfirmAccountSaveInfo = false;
$wgAccountRequestWhileBlocked = true;
$wgMakeUserPageFromBio = false;
$wgUseRealNamesOnly = false;
$wgAccountRequestMinWords = 0;
$wgAccountRequestToS = false;
$wgGroupPermissions['*']['createaccount'] = true;  
$wgConfirmAccountNotice = false;
$wgAccountRequestTypes = array(
  0 => array( 'users', 'user' )
);
$wgGroupPermissions['*']['createaccount'] = true;  
$wgGroupPermissions['bureaucrat']['lookupcredentials'] = false;
$wgGroupPermissions['bureaucrat']['confirmaccount'] = false;
$wgGroupPermissions['bureaucrat']['requestips'] = false;

A new user group should be created to use the system. It should be assignable by sysops (like rollback) and give the 'confirmaccount' and 'requestips' rights. ('lookupcredentials' isn't needed)
Comment 1 Aaron Schulz 2008-04-18 01:08:17 UTC
Why 'requestips'? We don't release data that easily?
Comment 2 Aaron Schulz 2008-04-18 01:35:18 UTC
Looks like another variable is needed, $wgConfirmAccountCaptchas. Should be set to false.
Comment 3 Chris 2008-04-18 04:32:48 UTC
(In reply to comment #1)
> Why 'requestips'? We don't release data that easily?
> 

In all of the toolserver account request systems admins could view the requesting user's IP address and no objections were raised. That said I didn't really consider an IP's contribs to be a deciding factor to grant an account. I just found it useful to check if an IP had any hard blocks that would stop a user for being able to edit. 
Comment 4 JeLuF 2008-04-19 13:15:48 UTC
According to the policy announced on
http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&diff=183483606&oldid=183483319 there has to be a formal voting, an ArbCom decision and a decision of the WMF in order to implement this.

=> Closed as "LATER".
Comment 5 Aaron Schulz 2008-04-19 17:09:59 UTC
Note, this only *adds* the request form, it does not disable regular account creation. This is for the Requests for Account page, for people with screen readers and such, that cannot otherwise make an account.
Comment 6 JeLuF 2008-04-19 20:30:06 UTC
Yes, I've read your request. 

The reason for Jimbo's resolution was the adding of a group on enwiki. The group creation didn't change anything, enwiki community was not forced to use this group at all. Nevertheless, people wanted to open a case against me at the ArbCom. Then Jimbo passed the resolution (see link above) for all future enwiki changes.
Comment 7 Brion Vibber 2008-04-20 00:37:19 UTC
Installation would be a regular technical decision, pending my review of the software and any issues that arise from it.
Comment 8 Casey Brown 2008-04-20 01:46:56 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Why 'requestips'? We don't release data that easily?
> > 
> 
> In all of the toolserver account request systems admins could view the
> requesting user's IP address and no objections were raised. That said I didn't
> really consider an IP's contribs to be a deciding factor to grant an account. I
> just found it useful to check if an IP had any hard blocks that would stop a
> user for being able to edit. 
> 

Well... the toolserver isn't governed by the Wikimedia Foundation's policies and resolutions, its projects are.
Comment 9 Casey Brown 2008-04-20 01:56:53 UTC
(In reply to comment #8)
> Well... the toolserver isn't governed by the Wikimedia Foundation's policies
> and resolutions, its projects are.
> 

Ignore that comment, it's only /slightly/ right and would need more explanation. :-P
Comment 10 FunPika 2008-05-10 15:15:11 UTC
Brion said it would be a normal technical decision, and the Account Creator group has already been added (and no one has attempted to open any enwiki ArbCom cases against Brion over that yet I think). 

Reopening request (won't bother reopening again if JeLuf resolves as later again though). 
Comment 11 Cometstyles 2008-05-11 09:40:41 UTC
I would like to really Thank Brion for doing this since the other devs were taking their time to implement this and the request for accounts were rising drastically (300 requests by then) and if any devs or the arbcom disagrees with Brion or JeLuf for that matter, they have to go through the [[WP:ACC]] team first..thanks Brion for doing this :).. You are the man !!! :p
Comment 12 Tyler Romeo 2008-06-18 04:45:54 UTC
To tell you the truth, as one of the people at [[WP:ACC]], this tool is not really as useful as the one we are using now. For one, the current tool gives a whole array of tools, allowing account creators to auto-email users whose usernames violate username policy, etc. Furthermore, I believe the new account form does not give any IP information, which is a big let down.
Comment 13 Tyler Romeo 2008-06-19 14:03:21 UTC
Actually, ignore the IP information stuff, I was just too blind to notice the requestips right. As for a comment Casey Brown said earlier, I believe the tool server is subject to the same Privacy Policy as any of Wikimedia Project.
Comment 14 Siebrand Mazeland 2008-08-18 19:57:41 UTC
Keywords: need-review
Comment 15 Mike.lifeguard 2009-03-19 18:35:18 UTC
(In reply to comment #14)
> Keywords: need-review
> 

Until that's done, nothing to do on shell - removed that keyword.
Comment 16 Ryan (Rjd0060) 2009-03-19 19:23:46 UTC
I'm not sure that the community wants this anymore.  They have been using a process via the toolserver which eliminates the need for this extension (http://stable.toolserver.org/acc/).  This request can probably be closed.
Comment 17 Mike.lifeguard 2009-03-19 21:12:29 UTC
(In reply to comment #16)
> I'm not sure that the community wants this anymore.  They have been using a
> process via the toolserver which eliminates the need for this extension
> (http://stable.toolserver.org/acc/).  This request can probably be closed.
> 

Closed then.
Comment 18 MZMcBride 2010-10-10 20:23:14 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > I'm not sure that the community wants this anymore.  They have been using a
> > process via the toolserver which eliminates the need for this extension
> > (http://stable.toolserver.org/acc/).  This request can probably be closed.
> > 
> 
> Closed then.

Re-opening.

I don't think it's really a community's decision to implement such a poor hack like this.

With the current setup at http://toolserver.org/~acc/ 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.

I don't see a reason to limit this extension to the English Wikipedia and I don't see any need for individual project consensus for something that's a technical issue. Broadening the bug summary as well.
Comment 19 Aaron Schulz 2011-09-29 00:17:31 UTC
This will go on labs console first. Nothing should be enabled on any wmf sites before that (if enabled at all).
Comment 20 Aaron Schulz 2011-11-28 18:58:36 UTC
(In reply to comment #19)
> This will go on labs console first. Nothing should be enabled on any wmf sites
> before that (if enabled at all).

Actually it won't anymore, so disregard that.
Comment 21 Sumana Harihareswara 2012-04-04 13:56:44 UTC
What is the current community consensus on this, and are there technical problems with the extension or other reasons it should not be deployed?
Comment 22 Sumana Harihareswara 2012-04-10 11:20:32 UTC
Adding design keyword -- needs product management/user experience design review before we deploy (cc'ing Howie and Brandon).  Edited https://www.mediawiki.org/wiki/Review_queue to reflect this.
Comment 23 Sumana Harihareswara 2012-04-11 20:44:44 UTC
A few of us talked about this in IRC today https://toolserver.org/~mwbot/logs/%23wikimedia-dev/20120411.txt .  It seems like it's unclear whether any WMF community still wants this, as the current solution might be good enough.  CC'ing Oliver.  Ironholds, do you have time to assess things by asking around about this and figuring out whether en.wikipedia still wants it?  Thanks.
Comment 24 Oliver Keyes 2012-04-11 20:54:29 UTC
(In reply to comment #23)
> A few of us talked about this in IRC today
> https://toolserver.org/~mwbot/logs/%23wikimedia-dev/20120411.txt .  It seems
> like it's unclear whether any WMF community still wants this, as the current
> solution might be good enough.  CC'ing Oliver.  Ironholds, do you have time to
> assess things by asking around about this and figuring out whether en.wikipedia
> still wants it?  Thanks.

Shall do :). I can get the conversation set up tomorrow morning, if that works for you?
Comment 25 MZMcBride 2012-04-11 22:22:56 UTC
(In reply to comment #23)
> A few of us talked about this in IRC today
> https://toolserver.org/~mwbot/logs/%23wikimedia-dev/20120411.txt .  It seems
> like it's unclear whether any WMF community still wants this, as the current
> solution might be good enough.  CC'ing Oliver.  Ironholds, do you have time to
> assess things by asking around about this and figuring out whether en.wikipedia
> still wants it?  Thanks.

Did you read comment 13 (quoted below)?

> With the current setup at http://toolserver.org/~acc/ 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.
Comment 26 Oliver Keyes 2012-04-12 13:15:58 UTC
Hey guys; I've started a discussion at https://en.wikipedia.org/wiki/Wikipedia_talk:Request_an_account#Account_Request_extension.2C_revisited to assess how strongly the community feels about this extension, one way or another. If people want to participate, please do so we can get a feel for which way the needle is swinging :)
Comment 27 Jessica 2012-04-12 14:12:02 UTC
The proposed extension appears to be a joke of a feature that offers almost noting of actual use compared to the toolserver setup of ACC. If you want banned users getting new accounts simply by asking for them then this extension is the way to go.

As for the paranoid "the possibility for unwittingly leaked data like IP addresses" it is true of anything run through toolserver or any Check User too. If you want to say the potential for accidents is greater i would really like to know how. If you mean there is more opportunity for malicious use of data then i think your assessment is skewed to inherent distrust of folk like me and trust of the people with the CU right and we really need to shut down everything that makes use of such data. O damn, that would be EVERYTHING. ACC is subject to the same WMF privacy policy that the person with the CU right is subject to. 

ACC exists on the Toolserver to aid those who DO NOT YET HAVE AN ACCOUNT so asking those who ALREADY HAVE ACCOUNTS AND ARE IN SOME POSITION OF REPUTATION AND TRUST if it is helpful and of any value is like asking hard core committed Mountain Dew drinkers what they think of the new flavour of Dr Pepper.  I know everything here runs on consensus but you are asking the community to say whether they like this and the relevance to them is nearly nil and the ignorance level i would guess is fairly high. You will get those who don't understand and are outraged. You might get someone who 'came up through the ranks' having requested an account through ACC three years ago who will be grateful for it. But the ignorant opposition would out-weigh the informed support. If you think that is the kind of consensus that is acceptable then the issue runs much deeper.

MZMcBride processed a whopping 3 requests and had his account at ACC suspended nearly 4 years ago for inactivity. Ironholds has an account at ACC but never used it and was suspended for inactivity a little over 3 years ago. If you are going to request a public solicitation of opinion could maybe someone who is at least a bit up-to-date on things be the person asking the question(s).
Comment 28 Oliver Keyes 2012-04-12 14:13:57 UTC
Jessica, as my comment above indicates, there is a wide solicitation of opinion going on. I'm not commenting either way as to its usefulness; I'm here as part of my job with the Wikimedia Foundation, not as an editor. We're primarily asking existing and active ACC users; if you go to the discussion I have already linked, you can comment there.
Comment 29 Sumana Harihareswara 2012-04-19 15:30:59 UTC
The discussion at https://en.wikipedia.org/wiki/Wikipedia_talk:Request_an_account#Account_Request_extension.2C_revisited finished as follows:

"So, it seems fairly clear that there is no real enthusiasm for enabling this extension. This seems to be based around the fact that ConfirmAccount actually lacks a lot of the features that ACC connects, although it was an improvement over the tools available in 2008 when the initial discussion happened. It would require far more developer resources than initially thought. We're going to be trying to work out if there are actually security issues that need to be worked through, and will start a new bug to deal with those specific problems if information dictates that we should; in the meantime, please do contact us if you're aware of specific problems with ACC.

If any of you have programming experience or skills and want to work with us on fixing ACC problems, please do come to either the Berlin Hackathon 2012 https://www.mediawiki.org/wiki/Berlin_Hackathon_2012 or the Hackathon at Wikimania this year; we'd love to have a group to extend and improve ACC, although I know that a lot of people are already (and have been for a long time!) helping make the software better. In the meantime, do give us a shout if you can point to specific rather than general issues, and drop me a message if you want to be kept in the loop. Okeyes (WMF) (talk) 20:22, 13 April 2012 (UTC)"

I am alerting Chris Steipp, Wikimedia Foundation's new Software Security Engineer <http://lists.wikimedia.org/pipermail/wikitech-l/2012-April/060148.html>, of this discussion so that he knows of this discussion.  You can let him know of any security issues in the current ACC setup and practice - csteipp, at wikimedia dot org.
Comment 30 p858snake 2012-04-25 05:48:57 UTC
Reopening, ACC is hosted on a third party system [The Toolserver] (which is not covered by our Privacy Polices) and we should be trying to move services, that handle user details (especially private data), such as this onto our systems.

If there are features lacking in E:ConfirmAccount people should be filing bugs so we/everyone knows what needs to be worked on (and ideally marking them as blocking this bug).
Comment 31 mabdul 2012-04-25 08:53:24 UTC
Can we get then a server with a test system to check/verify what is needed and thus to create bug reports? At the moment, I only saw images and heard some reports...
Comment 32 Simon Walker 2012-04-25 12:23:50 UTC
(In reply to comment #30)
> If there are features lacking in E:ConfirmAccount people should be filing bugs
> so we/everyone knows what needs to be worked on (and ideally marking them as
> blocking this bug).

I'm looking at building a new extension which gives the functionality needed, I've previously not mentioned it because it's only being written as a proof-of-concept, and my current lack of time. When I have something basic to demo and more time, my plan was to open dialog with Howie/Sumana about it per http://www.mediawiki.org/wiki/Writing_an_extension_for_deployment, and carry on from there.
Comment 33 Sumana Harihareswara 2012-07-27 19:19:02 UTC
Simon, how's that going?
Comment 34 Tyler Romeo 2012-07-27 19:40:57 UTC
If development has stalled on this, I'd be happy to help out. I'm not working on anything and am looking for something to do.
Comment 35 Simon Walker 2012-07-28 00:44:57 UTC
It stalled a little (re-writing a puppet manifest on my own servers...), but when I get settled into my new job next week I'm hoping I'll be able to pick it up again. It was never going to be a quick job though.
Comment 36 Sumana Harihareswara 2013-03-15 13:14:47 UTC
Simon, how's this going?
Comment 37 Greg Grossmeier 2013-08-22 21:24:11 UTC
Hello all,

This is a long and old bug. From my understanding, there is still some process in place, whether or not that process is ideal for everyone can be debated. There is, however, no longer a consensus of installing this specific extension (ConfirmAccount) on Wikimedia Wikis.

If there is a new extension to review, then that should be a new bug (this one is too jumbled to do that effectively anymore).

If there needs to be a review of whatever current system is in place, that should also be a separate bug/issue.

For now, I'll assume this bug can be closed as WONTFIX given that this specific extension is not being deployed. This isn't to say the issue in general is a WONTFIX.

Please reply here if I am incorrect with the above, otherwise I will close this request next week.
Comment 38 Greg Grossmeier 2013-08-30 22:24:23 UTC
Closing. Please read comment 37 first if you want to reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links