Change Details

In T171382 it was asserted that some IPv6 users regularly change IP addresses within a /64 block, due to SLAAC ([[https://tools.ietf.org/html/rfc4862|RFC 4862]]). As such, the existing method of attributing edits to anonymous users seems inadequate. I did some queries on recent anonymous IPv6 edits in the enwiki recentchanges table. My impression is that this does indeed happen, but the problem is worse than described: some IPv6 users use a mobile connection, and in fact routinely move around a block much larger than /64. I've long dreamed of attributing anonymous edits to a session ID instead of an IP address, since this would fix {T20981} and {T12957}, but due to abuse control considerations, it seems unlikely that this will win community support. This proposal is a compromise, fixing only one of those two bugs, by attributing edits to a session ID which is publicly associated with the first IP address used during that session. I mean the term "session" loosely, this might be an ID associated with a long-lived cookie. The proposal in detail: * On page save, if there is no existing session: * Create the session, and store the current IP address in the session * Search the actor table (T167246) for this IP address, and add a suffix to the IP address so as to make a unique username. * Create the actor row. actor_text would be the suffixed IP address and actor_user would be NULL. * On account creation, attributing the existing edits in the same session to the newly created account could be as simple as updating actor_user and actor_text in the existing actor row. * Blocks would be applied to the session via its public identifier (the suffixed IP), solving {T152462}. * When an anonymous session is blocked, an autoblock would be applied to the last IP address actually used by the anonymous user in question, exactly analogous to the way logged-in users are blocked. As an alternative, suffixing of the IP address could be omitted. In that case, to be feasible, I think you would have to have a single actor row, so you would not be able to solve T152462 or T12957. But at least you could have fewer user talk pages for anons who regularly migrate to a different IP address. This was discussed on IRC, the log is at https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-08-02-21.05.log.html

In T171382 it was asserted that some IPv6 users regularly change IP addresses within a /64 block, due to SLAAC ([[https://tools.ietf.org/html/rfc4862|RFC 4862]]). As such, the existing method of attributing edits to anonymous users seems inadequate. I did some queries on recent anonymous IPv6 edits in the enwiki recentchanges table. My impression is that this does indeed happen, but the problem is worse than described: some IPv6 users use a mobile connection, and in fact routinely move around a block much larger than /64. I've long dreamed of attributing anonymous edits to a session ID instead of an IP address, since this would fix {T20981} and {T12957}, but due to abuse control considerations, it seems unlikely that this will win community support. This proposal is a compromise, fixing only one of those two bugs, by attributing edits to a session ID which is publicly associated with the first IP address used during that session. I mean the term "session" loosely, this might be an ID associated with a long-lived cookie. The proposal in detail: * On page save, if there is no existing session: * Create the session, and store the current IP address in the session * Search the actor table (T167246) for this IP address, and add a suffix to the IP address so as to make a unique username. * Create the actor row. actor_text would be the suffixed IP address and actor_user would be NULL. * On account creation, attributing the existing edits in the same session to the newly created account could be as simple as updating actor_user and actor_text in the existing actor row. * Blocks would be applied to the session via its public identifier (the suffixed IP), solving {T152462}. * When an anonymous session is blocked, an autoblock would be applied to the last IP address actually used by the anonymous user in question, exactly analogous to the way logged-in users are blocked. As an alternative, suffixing of the IP address could be omitted. In that case, to be feasible, I think you would have to have a single actor row per IP address, so you would not be able to solve T152462 or T12957. But at least you could have fewer user talk pages for anons who regularly migrate to a different IP address. This was discussed on IRC, the log is at https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-08-02-21.05.log.html

In T171382 it was asserted that some IPv6 users regularly change IP addresses within a /64 block, due to SLAAC ([[https://tools.ietf.org/html/rfc4862|RFC 4862]]). As such, the existing method of attributing edits to anonymous users seems inadequate. I did some queries on recent anonymous IPv6 edits in the enwiki recentchanges table. My impression is that this does indeed happen, but the problem is worse than described: some IPv6 users use a mobile connection, and in fact routinely move around a block much larger than /64. I've long dreamed of attributing anonymous edits to a session ID instead of an IP address, since this would fix {T20981} and {T12957}, but due to abuse control considerations, it seems unlikely that this will win community support. This proposal is a compromise, fixing only one of those two bugs, by attributing edits to a session ID which is publicly associated with the first IP address used during that session. I mean the term "session" loosely, this might be an ID associated with a long-lived cookie. The proposal in detail: * On page save, if there is no existing session: * Create the session, and store the current IP address in the session * Search the actor table (T167246) for this IP address, and add a suffix to the IP address so as to make a unique username. * Create the actor row. actor_text would be the suffixed IP address and actor_user would be NULL. * On account creation, attributing the existing edits in the same session to the newly created account could be as simple as updating actor_user and actor_text in the existing actor row. * Blocks would be applied to the session via its public identifier (the suffixed IP), solving {T152462}. * When an anonymous session is blocked, an autoblock would be applied to the last IP address actually used by the anonymous user in question, exactly analogous to the way logged-in users are blocked. As an alternative, suffixing of the IP address could be omitted. In that case, to be feasible, I think you would have to have a single actor row per IP address, so you would not be able to solve T152462 or T12957. But at least you could have fewer user talk pages for anons who regularly migrate to a different IP address. This was discussed on IRC, the log is at https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-08-02-21.05.log.html