Page MenuHomePhabricator

Make CheckUser log IPs for all account creations
Closed, ResolvedPublic

Description

Author: mike.lifeguard+bugs

Description:
Currently, when one makes an account using an account, there is no IP for the 2nd account. By chaining account creation along in this manner, users can make it cumbersome to figure out which was the first account, and then check that to get the IP. When dealing with fast-moving IP-hopping (personal-information-revealing) vandals, this is quite bad indeed.

Please log the IP used for creating the account for
*the account that did the creating (as it is currently); AND
*the account that was created

Thanks.


Version: unspecified
Severity: enhancement

Details

Reference
bz19963

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:40 PM
bzimport added a project: CheckUser.
bzimport set Reference to bz19963.

How do we know the IP of the new account before they make any edits?

mike.lifeguard+bugs wrote:

(In reply to comment #1)

How do we know the IP of the new account before they make any edits?

Well, we *do* know it, so...? It is logged for the other account; it's not like I'm asking for information we don't have.

Note this is confusing even for seasoned CUs. I've been asked about this twice in the past week by other CUs. And as I say, it makes moving fast harder than it needs to be.

(In reply to comment #2)

(In reply to comment #1)

How do we know the IP of the new account before they make any edits?

Well, we *do* know it, so...? It is logged for the other account; it's not like
I'm asking for information we don't have.

We do know it, but only in the case where someone creates the second account for himself. If they create it for someone else, we can't know the other person's IP until they actually log in with the new account.

mike.lifeguard+bugs wrote:

(In reply to comment #3)

We do know it, but only in the case where someone creates the second account
for himself. If they create it for someone else, we can't know the other
person's IP until they actually log in with the new account.

That's not true: this absolutely does not depend on who is sitting behind the keyboard. We know the IP no matter who they are or what their intention is.

The IP we have is the one I'm talking about: the one the account was created with, not some hypothetical IP from the future which may be different.

mike.lifeguard+bugs wrote:

I suppose I should also be clear that these accounts should then show up in the "get users" search, that is the whole point!

josh wrote:

What would work well would be to have lines like this:
American Mascot Association (talk | contribs | block) (Blocked) created new account User:Dr. Socket

replaced by
User:Dr. Socket (talk | contribs | block) (Blocked) new user account created by American Mascot Association (talk | contribs | block)

And of course logging User:Dr. Socket into checkuser or whatever we use.

Retitling rather than opening a similar bug

We should log it for ANY account created, including those created as "sub accounts"

(In reply to comment #6)

What would work well would be to have lines like this:
American Mascot Association (talk | contribs | block) (Blocked) created new
account User:Dr. Socket

replaced by
User:Dr. Socket (talk | contribs | block) (Blocked) new user account created by
American Mascot Association (talk | contribs | block)

And of course logging User:Dr. Socket into checkuser or whatever we use.

See

https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%3ALog&type=newusers&user=&page=User%3AReedy+%28test%29&year=&month=-1&tagfilter=

vs

https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%3ALog&type=newusers&user=Reedy&page=&year=&month=-1&tagfilter=

I don't think we actually need any distinction there, both way are easily doable

The IP on registration (still) wants doing though IMHO

And can probably just hook onto

		wfRunHooks( 'AddNewAccount', array( $u, true ) );

And save something. Seems somewhat trivial (though, not idea if CU needs any/many/much changes to accommodate this)

  • Bug 29019 has been marked as a duplicate of this bug. ***
  • Bug 17930 has been marked as a duplicate of this bug. ***