Another crosspost to wikipedia-l and wikitech-l, please follow up to one list only. Tell me offlist if you think the crossposting is useful.
I'm making some changes to user blocks. Here is the changelog entry:
* Allow blocks on anonymous users only (bug 550) * Allow or disallow account creation from blocked IP addressess on a per-block basis. * Prevent duplicate blocks. * Fixed the problem of expiry and unblocking erroneously affecting multiple blocks. * Fixed confusing lack of error message when a blocked user attempts to create an account. * Fixed inefficiency of Special:Ipblocklist in the presence of large numbers of blocks; added indexes and implemented an indexed pager.
This will require a schema update, hopefully it can be done on Wikimedia with a minimum of disruption.
A unique index will be introduced which will prevent duplicate blocks on users or IP addresses. To migrate to the new schema, it is necessary that all existing duplicate blocks be deleted. This will be done automatically during the schema update. I *think* the winning block will be the earliest one, with all others silently deleted, but we'll see for sure during the update.
If it's a problem for anyone that these blocks will be removed, please speak up. I'm not going to create a list of dropped blocks unless anyone has a really good reason why it's necessary. The original record of the duplicate block being created, available in Special:Log, will not be deleted, and there will be a backup of the ipblocks table in case anything goes wrong.
I'll aim to put this change live in about 24 hours from now. It has to be soon, because we won't be able to deploy any other updates to MediaWiki until the schema is updated.
I know a lot of people have all sorts of dreams for the perfect blocking feature, and I'm sorry to say that this won't fulfill all of them. It is a concrete step forward, it fixes some embarrassing bugs, and it implements a much requested feature. I'd be happy to hear about your ideas for a perfect blocking module, just don't expect them to be live on the site within 24 hours.
-- Tim Starling
For those of you who found that last post a bit too wordy and complicated, here's a summary in pictures:
On Mon, 10 Jul 2006 17:05:31 +1000 In article e8su7s$h8r$1@sea.gmane.org [[Wikitech-l] User block changes] Tim Starling t.starling@physics.unimelb.edu.au wrote:
during the schema update. I *think* the winning block will be the earliest one, with all others silently deleted, but we'll see for sure during the update.
How about adding "ORDER BY ipb_id" to patch-ipb_anon_only.sql's INSERT INTO ipblocks_newunique. It can force to leave each earlist block.
-----
INSERT IGNORE INTO /*$wgDBprefix*/ipblocks_newunique (ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, ipb_anon_only, ipb_create_account) SELECT ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, 0 , ipb_user=0 FROM /*$wgDBprefix*/ipblocks ORDER BY ipb_id; ~~~~~~~~~~~~~~~
Tietew wrote:
On Mon, 10 Jul 2006 17:05:31 +1000 In article e8su7s$h8r$1@sea.gmane.org [[Wikitech-l] User block changes] Tim Starling t.starling@physics.unimelb.edu.au wrote:
during the schema update. I *think* the winning block will be the earliest one, with all others silently deleted, but we'll see for sure during the update.
How about adding "ORDER BY ipb_id" to patch-ipb_anon_only.sql's INSERT INTO ipblocks_newunique. It can force to leave each earlist block.
INSERT IGNORE INTO /*$wgDBprefix*/ipblocks_newunique (ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, ipb_anon_only, ipb_create_account) SELECT ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, 0 , ipb_user=0 FROM /*$wgDBprefix*/ipblocks ORDER BY ipb_id;
Ideally, you'd want to sort them by expiration time, but I suppose this may not be trivial.
Also, would this be a good time to ensure that usernames in ipb_address are properly normalized? It seems that at the moment, on enwiki at least, some of the entries contain underscores and some spaces, the choice seeming quite random:
http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=+ http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=_
Also, would this be a good time to ensure that usernames in ipb_address are properly normalized? It seems that at the moment, on enwiki at least, some of the entries contain underscores and some spaces, the choice seeming quite random:
http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=+ http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=_
-- Ilmari Karonen
Also, there's a problem with long usernames.
Compare: http://en.wiktionary.org/w/index.php?title=Special%3ALog&type=block&... http://en.wiktionary.org/wiki/Special:Ipblocklist?action=search&limit=15...
This must have already been reported at bugzilla, but perhaps this is also the good moment to fix that.
Wildrick Steele wrote:
Also, there's a problem with long usernames.
Compare: http://en.wiktionary.org/w/index.php?title=Special%3ALog&type=block&... http://en.wiktionary.org/wiki/Special:Ipblocklist?action=search&limit=15...
This must have already been reported at bugzilla, but perhaps this is also the good moment to fix that.
It is indeed a good moment to fix it, which is why I did so. Apologies for not including it in the changelog.
-- Tim Starling
Ilmari Karonen wrote:
Ideally, you'd want to sort them by expiration time, but I suppose this may not be trivial.
It's trivial.
Also, would this be a good time to ensure that usernames in ipb_address are properly normalized? It seems that at the moment, on enwiki at least, some of the entries contain underscores and some spaces, the choice seeming quite random:
http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=+ http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=_
I'll look into that.
-- Tim Starling
I was recently thinking about how to improve the blocking system. I thought in a bit-flag for each action so a finer block could be applied. The list which came to my mind is:
*Edit pages *Create accounts *New pages *Move pages *Upload files *Patrol edits *Autoconfirmation (accounts with this block would behave like non-confirmed accounts) *Block users with that ip to edit *Will other users with the same ip get blocked? (autoblocks, only applies to blocks to usernames)
I didn't added sysop actions as they use to need a special group so the solution would be desysopping and not block deleting ability, but they could have a place in the flag too.
The SpecialBlock would present a combo or a serie of checkboxes, or-masked by the server to get the restriction. A special 'Complete' option (value -1) would behave as until now.
Of course your interface seems nicer and less complicated, but this kind of feature could be prepared on the schema update, although not available for use.
Some combinations are probably useless (block user from edit but allow move pages ? ) and i have only heard requesting bug 550 and upload block but i think this more complete.
Platonides
On 10/07/06, Platonides Platonides@gmail.com wrote:
*Autoconfirmation (accounts with this block would behave like non-confirmed accounts)
That sounds ridiculous and useless, and defeats the idea of being autoconfirmed. That isn't an appropriate means to go about it.
Rob Church
On 7/10/06, Rob Church robchur@gmail.com wrote:
On 10/07/06, Platonides Platonides@gmail.com wrote:
*Autoconfirmation (accounts with this block would behave like non-confirmed accounts)
That sounds ridiculous and useless, and defeats the idea of being autoconfirmed. That isn't an appropriate means to go about it.
After being bit by autoconfirm on itwiki (I couldn't upload over SVG that had syntactical errors) I wished that there was some sysop button to speedy autoconfirm me...
I agree that a deautoconfirm would be silly... We've already got de-autoconfirm.. it's called block.
On 7/10/06, Platonides Platonides@gmail.com wrote:
I was recently thinking about how to improve the blocking system. I thought in a bit-flag for each action so a finer block could be applied. The list which came to my mind is:
*Edit pages *Create accounts *New pages *Move pages *Upload files *Patrol edits *Autoconfirmation (accounts with this block would behave like non-confirmed accounts) *Block users with that ip to edit *Will other users with the same ip get blocked? (autoblocks, only applies to blocks to usernames)
I agree that de-autoconfirmation wouldn't be terribly useful, since it would basically just mean you're barred from a certain set of privileges, which under this scheme you could block specifically anyway.
Logically, the list should probably include most $wgGroupPermissions: createaccount, edit, createpage, createtalk, move, upload, reupload, reupload-shared, minoredit, delete, deletedhistory, editinterface, import, importupload, patrol, protect, rollback, trackback (?), userrights. Plus, perhaps, a new editowntalkpage permission.
This kind of modular block might be neat, but on the other hand banning someone from doing the activity and threatening a general block if the ban is violated is probably just as effective, so it might not be a very useful expenditure of dev time.
On 7/10/06, Simetrical Simetrical+wikitech@gmail.com wrote: [snip]
This kind of modular block might be neat, but on the other hand banning someone from doing the activity and threatening a general block if the ban is violated is probably just as effective, so it might not be a very useful expenditure of dev time.
Right. ... and socially wasteful... Right now we can tell someone to stop doing a bad thing, and if they ignore, we block. Problem solved. With a more fine grained system we may well waste our time removing permissions one at a time. ugh.
If someone can't cooperate they are lost to us and we should just block, if they can then there is no need for fancy technical measures.
The need for anon editing/account creation control is to provide a work around where good users and bad users share an address because of factors beyond their control. It's not a new behavior modification tool.
Well, global blocks may be just as useful sometimes :) But then, why do we have autoconfirmation and semi-protection? Wasn't it also a waste of our time semi-blocking and then blocking? ;)
And you have also to remember some problems like user-complaining (not really resolved when they can answer on its discussion page).
A more fine grained system can be better, as you have more abilities. If you don't want to remove permissions one at a time, make a complete block. Soft-blocks and upload-only blocks, *are a requesting*, so more graining doesn't seem so useless.
About a expenditure of dev time, it doesn't seem difficult to me. Simply change the IsBlocked() for IsBlockedEdit(), IsBlockedUpload()... They only need to have a and-mask on the blocked flag (more complicated would be the blocking amounting). This is the moment to do it, when several changes to blocks are being added and there is a schema update.
Tim 'would be happy to hear about our ideas'. I simply speak what had been thought about. If it's not a good idea, well... it can be dropped. I will still be able to sleep at nights :-)
Platonides
A couple of people asked me about interaction between various kinds of blocks and block options, and indeed, in some cases the behaviour was undefined or accidental. I've now implemented the following rules:
* The "anon only" and "prevent account creation" options will be silently ignored on username blocks. * The precedence of blocks in cases of conflict, from highest to lowest, is: * Username block * Single IP block * Range block * Autoblock
This holds regardless of the anon-only option. This means that anon-only range blocks or IP blocks can be used to mitigate the effects of autoblocks on shared IP addresses, because an anon-only block will allow logged in users to edit regardless of the presence of a matching autoblock. This has a potential to be counterintuitive -- unblocking someone's IP can in fact cause them to be blocked. But I thought it was better than the other solutions.
-- Tim Starling
On 7/11/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
- The precedence of blocks in cases of conflict, from highest to lowest, is:
- Username block
- Single IP block
- Range block
- Autoblock
Wouldn't it be more intuitive to just say "blocked" takes precedence over "unblocked"? I'm not clear on what the problem is with that, although I'm pretty tired at the moment. Certainly that's how every other blocking system I know of (message board, IRC, etc.) works. Of course, IRC also has excepts, invites, and voices to stop range-blocks from affecting regulars.
Do we actually need to worry about range-blocks affecting regulars, though? After all, range-blocks are almost always useful only to target dynamic IPs, so there's no point exempting a specific IP from the range; but even if there were, the range block could just be broken up into a few smaller range blocks. So unless there's an additional problem, I'd just give blocked status precedence over unblocked status.
Simetrical wrote:
Wouldn't it be more intuitive to just say "blocked" takes precedence over "unblocked"? I'm not clear on what the problem is with that, although I'm pretty tired at the moment. Certainly that's how every other blocking system I know of (message board, IRC, etc.) works. Of course, IRC also has excepts, invites, and voices to stop range-blocks from affecting regulars.
Do we actually need to worry about range-blocks affecting regulars, though?
Er, yes -- that's the whole issue. Blocks of ranges such as big ISPs frequently caught regulars who are stuck with that ISP.
-- brion vibber (brion @ pobox.com)
On 7/11/06, Brion Vibber brion@pobox.com wrote:
Er, yes -- that's the whole issue. Blocks of ranges such as big ISPs frequently caught regulars who are stuck with that ISP.
But that's not helped by the new code anyway, except that you can allow registered users from that ISP to edit (which is independent of blocking precedence). Tim mentioned autoblocks, which apparently always affect even logged-in users, as his reason for adding the precedence.
Perhaps a more intuitive solution would be to enable the anon only and no account creation options for username blocks, and just apply them to autoblocks? It's slightly less powerful, in that if someone from a shared IP made a bunch of sleeper accounts before getting blocked they could use those unless you blocked other users of the IP, but in such a (probably uncommon) case blocking the clones wouldn't be hard and would probably be desirable. Plus, not autoblocking preregistered users by default has the advantage of avoiding the autoblock in the first place, rather than allowing it to be lifted more easily.
Simetrical wrote:
Perhaps a more intuitive solution would be to enable the anon only and no account creation options for username blocks, and just apply them to autoblocks?
This is not a particularly effective solution, since it would require admins blocking registered users to guess in advance whether the user is using a shared IP or not. That said, I wouldn't really oppose having this feature _in addition to_ the precedence system.
The new precedence system seems quite good, but it would be further improved by the ability to mark IPs and/or IP ranges as completely exempt from autoblocks, essentially creating an "anti-block" that would take precedence over any coincident autoblocks.
Also, the interface really needs to be changed so that one can change the block length and/or type without first removing the previous block (possibly with a confirmation dialog like the one used when reuploading images). Right now a fast vandal (such as a vandalbot) could easily slip in several edits between the unblock and the subsequent reblock, particularly if the admin isn't careful or suffers from connection lag.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling schrieb:
A couple of people asked me about interaction between various kinds of blocks and block options, and indeed, in some cases the behaviour was undefined or accidental. I've now implemented the following rules:
- The "anon only" and "prevent account creation" options will be silently
ignored on username blocks.
If the "prevent account creation" option is ignored on username blocks, it has not to be mentioned in the log (List of blocked IP addresses and usernames), isn't it?
Example from deWP today:
21:36, 11 July 2006, D (Talk) blocked BgMgBgMgBgMg (contribs) (infinite, account creation blocked) (unblock) (kneipenschläger)
Raymond.
wikitech-l@lists.wikimedia.org