Why 'requestips'? We don't release data that easily?

Looks like another variable is needed, $wgConfirmAccountCaptchas. Should be set to false.

chrisgrantmail wrote:

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

jeluf wrote:

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".

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.

jeluf wrote:

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.

Installation would be a regular technical decision, pending my review of the software and any issues that arise from it.

bugs wrote:

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

bugs wrote:

(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

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).

cometstyles wrote:

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

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.

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.

Keywords: need-review

mike.lifeguard+bugs wrote:

(In reply to comment #14)

Keywords: need-review

Until that's done, nothing to do on shell - removed that keyword.

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.

mike.lifeguard+bugs wrote:

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

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

This will go on labs console first. Nothing should be enabled on any wmf sites before that (if enabled at all).

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

sumanah wrote:

What is the current community consensus on this, and are there technical problems with the extension or other reasons it should not be deployed?

sumanah wrote:

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.

sumanah wrote:

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.

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

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

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 :)

jessica wrote:

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).

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.

sumanah wrote:

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.

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).

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

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

sumanah wrote:

Simon, how's that going?

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.

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.

sumanah wrote:

Simon, how's this going?

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.

Closing. Please read comment 37 first if you want to reopen this bug.