janhelgewolf wrote:

Seems useful to me, in this special case even 20 edits in the Article Namespace would be enough, I think

mattj wrote:

Wouldn't just restricting the createaccount right to autoconfirmed work?

MAtt, no because you still want ips to be able to create accounts (otherwise, the request is very similar to have $wgGroupPermissions['user']['createpage'] = false; and $wgGroupPermissions['autoconfirmed']['createpage']= true; but with $wgGroupPermissions['*']['createaccount'] = true;);

The checks for $wgAccountCreationThrottle to avoid too many accounts being created from the same source should be taking care of it.
Maybe a new type of $wgRateLimits should be added?

kl wrote:

Not to mention, that you can get autoconfirmed without ever editing (another bug).

gnu1742 wrote:

Matt: No, the problem is that you can become autoconfirmed just by waiting a few days

That's configurable. On enwiki you need 10 edits to be autoconfirmed (in addition to the default 4 days wait), and in arwiki, eswiki and zhwiki 50.

janhelgewolf wrote:

Nevertheless, in my opinion there should be new, independent criteria for the "createaccount" right.

Won't then they just log out and create the accounts? I don't see how an editcount restriction on registered users will make a difference when you are restricting something that unregistered users can do with no such restrictions. I think Platonides's rate limits idea would be more effective.

kl wrote:

that would break out patient a lot...

(In reply to comment #8)

Won't then they just log out and create the accounts?

And they would be even harder, at least you can block anything created from account Foo as you know it is the same vandal.

I don't see how an editcount restriction on registered users will make a difference when you are
restricting something that unregistered users can do with no such restrictions.
I think Platonides's rate limits idea would be more effective.

The limits *are* there. The bug report seems to imply they are not being followed or they are too low. Sysops and bureaucrats are not ratelimited, but users don't have that right.

PS: Why don't you block those usernames on MediaWiki:Blacklistedusername? 'Sumpf' seems to be a good candidate.

janhelgewolf wrote:

(Comment #8) Additionally, in the moment the IP range of the vandal can't create account at
all

mike.lifeguard+bugs wrote:

If your project has checkusers, they may wish to investigate. You can alternatively request a check from stewards at http://meta.wikimedia.org/wiki/Steward_requests/Checkuser

I suspect this can be adequately managed without new coding.

kl wrote:

We REALLY don't have a problem to find out, who it is - afaik even his Real-Life-address is known.. But: That doesn't stop him (since 2 or 3 years...)

Block the user + account creation. He shouldn't be able to login and create accounts at that point :)

If he logs out and creates via IP, then this bug wouldn't solve it anyway (applying the edit-count requirement to a logged-in user). Counting edits of IPs isn't an option, as they don't have a row in the User table (and creating such a row would be a baaaaad idea). Plus, dynamic IPs, etc etc etc).

Requiring a certain number of edits to do something is the reason autoconfirm exists. It allows us to set auto-rights based on simple criteria (x edits and/or y days), which is what many wikis have set for the upload right, etc. When you've got an anonymous access allowed wiki (such as dewiki), setting rights to denied for normal users but allowed for anons and autoconfirmed rather defeats the purpose. Setting the following:

$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['user']['createaccount'] = false;
$wgGroupPermissions['autoconfirm']['createaccount'] = true;

...wouldn't make any sense, for createaccount or any other permission, really.

Suggest WONTFIX.

kl wrote:

he normally creates 5 accounts in a row; this could be reduced to only one with this fix...

(In reply to comment #15)

he normally creates 5 accounts in a row; this could be reduced to only one with
this fix...

That's because $wgAccountCreationThrottle is 6. So he creates one creater account plus 5 vandal ones. You can request to low that number to 1, so only one account can be created each 24h from each ip (a point not too clear in the docs: it applies equally to the ips of anons and users, sysops are exempted).

janhelgewolf wrote:

This would be possible, but than we still have the same problem, just smaller...I think, the way via autoconfirmed and rising the requirements for autoconfirmed (account creating is not possible without XX edits and 4 days) will be the best.
If we combine that with one account per IP and 24 hours *and* block his IP ranges if it's necessary, we could at least make it pretty difficult to him.

But I stay with my first opinion: A new class "MayCreateAccounts" would be even better.

(In reply to comment #17)

[snip]

But I stay with my first opinion: A new class "MayCreateAccounts" would be even
better.

We already have this, it's called 'createaccount'. It's enabled for all users by default, except when blocked. Like I explained above, it makes _no_ sense to disable account creation for normal users but enable it for autoconfirm when a user can just logout and create via IP.

janhelgewolf wrote:

It makes, because sometimes we block the vandalizing IP ranges so that they can't create accounts. In this occasions, our friend usually uses old accounts with normal names to create accounts with names insulting other users or related to toilet, excrements and similar stuff.

When you block said offending accounts, do block account creation as well? It seems like a good checkuser and some proper blocks should stab this problem, rather than changing the default user rights around.

kl wrote:

We doesn't find all of his accounts before he can use them to create even more accounts.

Closing as INVALID for now. I honestly think a thorough checkuser and some elbow grease should sniff out all his hidden accounts and get them blocked. Even if he can make 5 accounts/day, a sysop should be able to block faster than that.

If he's creating them faster than can be blocked, then we have a rate-limiting problem which can be configured.
If dewiki decides to cut off account registration for normal users and only let autoconfirmed users register (which is odd, but w/e), then that's also a configuration change that can be done.

If dewiki shows consensus for either of these changes, then you should open a new bug for a Site Request. This isn't really a bug or an enhancement request, as all the required software is in place and works just fine.

janhelgewolf wrote:

How would us help the CU? We know his range, we block it when it's necessary, but then he uses his old, "normal" accounts. And we can't block his range for ever, as we would block too many other IPs. But every time we open his range again, at first he creates "normal accounts to use them the next time we block his range. Or do you want us to checkuser all new accounts to see if it *might be* him?

Request to lower $wgAccountCreationThrottle to 1.
So, whenever you open the range, he will be able to create one account per 24h.

Sure, he can still create a 'normal account' to use it next week, but that account will only be able to create one account per 24h (and not the same day it was created!). That should slow it enough. Now, for each 'good looking' account he creates, he can create up to six bad looking ones. Then, for each 'good looking' account he will only be able to create another (and not the same day), so he will lose the bad name one plus the good looking. He will end creating good accounts and will just create bad name accounts as an ip (at least it would be less effort).
You still need to avoid bad name account creations, using MediaWiki:Blacklistedusername. But that's a different issue.

janhelgewolf wrote:

Where do we request this? Here, or local, just talking to Raymond?

conrad.irwin wrote:

Once you have an on-wiki consensus open a new bug under "Wikimedia" requesting the change and linking to that consensus.

(In reply to comment #23)

How would us help the CU? We know his range, we block it when it's necessary,
but then he uses his old, "normal" accounts. And we can't block his range for
ever, as we would block too many other IPs. But every time we open his range
again, at first he creates "normal accounts to use them the next time we block
his range. Or do you want us to checkuser all new accounts to see if it *might
be* him?

Checkuser his IP and you should find related accounts? Block those, and he'll be severly limited in how he can create an account, especially if the range is blocked.

For what it's worth, this is why we need per-role blocking. Blocking account creation _only_ for an IP range but allowing edits is something that is long overdue.

janhelgewolf wrote:

Which kind of users aren't affected by $wgAccountCreationThrottle? Just admins or also autoconfirmed?

mike.lifeguard+bugs wrote:

(In reply to comment #28)

Which kind of users aren't affected by $wgAccountCreationThrottle? Just admins
or also autoconfirmed?

Any user with the noratelimit right - normally sysops and only sysops have this right. (Global rollbackers do too)

Further discussion should happen off bugzilla.

Bureaucrats also have noratelimit by default (but bureaucrats are also sysops almost everywhere).