" 
 :I saw your comments on AE, and am in basic agreement with you. We do need to find a better way of dealing with these permanent disruptive socks. But  I don't think the problem is really with SPI; most admins work according to behavioural patterns, and recognise that CU is far from infallible. Particularly when a determined sockmaster is using anonymisers and proxies in an effort to disguise theirself. I think that the real problem is Wikipedia's insistence on anonymity, and would prefer that all new editors be required to register properly, in order to prevent such abuse. I'd also like to see all BLPs semi-protected by default. But none of this is sufficient, and we really need to devise a more effective method of identifying and blocking abusive socks.    
 ::And see the  example of this problem.    
 :::I commented on my view regarding how we might deal with socks on my talk page.   
 ::::I agree with RolandR that SPI works pretty well. CU is useful but not a panacea and no help at all when you are dealing with an old puppetmaster/sock where the data is stale. The latest example above is the sort of situation where we can only go on behavior. Sometimes this is pretty clear (and some of these cases are ones where IMHO the behavior needs to be discussed privately, however unfortunate that might be, so that the puppet master isn't informed of the clues that give them away). When you only have a handful of edits it's very tricky. And then of course there's the issue of meat puppets. I'd also like to see BLPs semi-protected as default but we can't even get - damn, mind's gone again, the revision thing we had on trial - even that wasn't popular enough. There's no chance CU data is going to be revealed, I'm pretty sure that the Foundation would object to that.    
 :::::And in this case SPI resulted in a block.    

 ::::::Yes, I agree with all the foregoing, except that I wasn't at all suggesting CU data be revealed. And I also think sockmasters should be blocked for a year. To block them for a week pretty much sends the message, ""Sure, go ahead and try socking, or keep it up. We don't mind."" 

 ::::::Re ""the art of the possible"", though, what I'm suggesting is that when we see a new account that's obviously not a new user, we should have community and administrative support for saying, in the right venue: 

 :::::::This account appears to be operated by an experienced user. Please privately disclose any former accounts or IPs via e-mail to our 'possible returning users sub-committee' per request #NNNNNNNN, 

 ::::::or to ""our centralized checkuser in-box e-mail"" or whatever we want to call it. If an account failed to answer such an inquiry to the satisfaction of that trusted group's members, a wp:duck block would be issued, regardless of checkuser results, for refusal to allow proper wp:scrutiny. 

 ::::::We already essentially require admin candidates to ""inform the Arbitration Committee (in strictest confidence if you wish) of the existence of a previous account or accounts"". But the same policy from which that language is taken also tells regular editors, ""You are not obliged to reveal previous accounts"". That seems utterly devoid of sense to me; of course editors must be obliged to reveal previous accounts, when asked, to someone, albeit ""in strictest confidence"", if they wish. 

 ::::::Besides such scrutiny requests from individual editors being allowed and supported, I'd like to see this asked every time at SPI, actually, as a standard part of the process: ""Please e-mail checkusers with the IDs you've edited under previously, if any, and if the suggestion has been made, please explain why you might appear to be more sophisticated in using Wikipedia than would be expected from a new user."" 

 ::::::Or if this seems too onerous re overhead, then at least AN/I needs to be able to accept and support such requests gracefully, instead of treating them as hounding or harassment, as often occurs now. I know this would only mitigate the