It is irritating to continually see stewards making local blocks at the English language Wikibooks with the comment "crosswiki abuse <! --globally locked[1]; about bot[2]-- >". This has been occurring since March. In every case I've checked the user in question has a unified account and in nearly all cases they have not made any edits locally, much less done anything for a local block. If there are cross-wiki issues, their account should be locked as is already the case, but the making of these local blocks on top of that is counter to what I've come to expect. English Wikibooks has a dozen admins, with about half active. Stewards will not rename users there because there are local bureaucrats and they will not CU users there because there are local CheckUsers. Why are they making local blocks when there are administrators? These weren't local emergencies because, as stated above, in nearly every case there were no edits. I don't expect that they are aware of local policies and with the exception of one steward, none of them have been made local admins. English Wikibooks opted in to global sysops, but in none of these cases were the people blocking members of such a group; even if they were, the block would have to be for local disruption. Local blocking by stewards for accounts that have already been globally locked is not only redundant, but undermines local project autonomy. Please stop.
--User:Adrignola
On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola aaron.adrignola@gmail.com wrote:
It is irritating to continually see stewards making local blocks at the English language Wikibooks with the comment "crosswiki abuse <! --globally locked[1]; about bot[2]-- >".
These local blocks are made when the account has been globally locked by a steward (see http://meta.wikimedia.org/wiki/SH#lock ). There can be no further undermining of local community autonomy, because the local account is blocked with or without an explicit local block. The local blocks are implemented automatically as a way for local communities to know the user is blocked, since there is no other local indication of the implicit block. (The bot scans for unreverted edits on each wiki, so blocking them while it's there is no trouble.)
Would you prefer the bot explicitly ignore your wikis? I can modify it to skip them, although local blocks will still be used when necessary to globally suppress attacks names.
-- Yours cordially, Jesse (Pathoschild)
That would be an acceptable solution. Thanks.
--User:Adrignola
On Sun, Aug 8, 2010 at 9:53 AM, Jesse (Pathoschild) pathoschild@gmail.comwrote:
On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola aaron.adrignola@gmail.com wrote:
It is irritating to continually see stewards making local blocks at the English language Wikibooks with the comment "crosswiki abuse <!
--globally
locked[1]; about bot[2]-- >".
These local blocks are made when the account has been globally locked by a steward (see http://meta.wikimedia.org/wiki/SH#lock ). There can be no further undermining of local community autonomy, because the local account is blocked with or without an explicit local block. The local blocks are implemented automatically as a way for local communities to know the user is blocked, since there is no other local indication of the implicit block. (The bot scans for unreverted edits on each wiki, so blocking them while it's there is no trouble.)
Would you prefer the bot explicitly ignore your wikis? I can modify it to skip them, although local blocks will still be used when necessary to globally suppress attacks names.
-- Yours cordially, Jesse (Pathoschild)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Jesse (Pathoschild), 08/08/2010 16:53:
On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola aaron.adrignola@gmail.com wrote:
It is irritating to continually see stewards making local blocks at the English language Wikibooks with the comment "crosswiki abuse <! --globally locked[1]; about bot[2]-- >".
These local blocks are made when the account has been globally locked by a steward (see http://meta.wikimedia.org/wiki/SH#lock ). There can be no further undermining of local community autonomy, because the local account is blocked with or without an explicit local block. The local blocks are implemented automatically as a way for local communities to know the user is blocked, since there is no other local indication of the implicit block.
I'm ok with those block, but if this is all you want, why isn't a short block enough? It would leave a trace in the local logs, although it wouldn't be displayed on [[Special:Contributions]].
Nemo
While I've had my own issues with Stewards reaching into local communities I actually think these blocks are important and very useful for our xwiki abusers. While the transparency reasoning that Pathoschild mentioned is true and important just as if not more important is the autoblocks (where at least a day or so block makes sense).
Global locking does not have any autoblock like feature and we have a large portion of our xwiki abusers (and even a growing number of those who only attack only one or two sites and have figured out the global login system) who will take advantage of this and go to another wiki, create the account and SUL over to whatever project they want to attack. This is also the issue with abusive names (they often don't even edit, that isn't the point).
If the stewards can't implement these autoblocks it is easier for abusers to use wikibooks as a starting point for abuse, just because they didn't edit there doesn't mean that they didn't use the project as a spring board or that they couldn't in the future since it is obvious they know the project exists and will now try it when they go trying to create new accounts. Globally locking active xwiki vandals is almost useless if they are able to just recreate accounts continually or at least until they SUL onto a wiki without local CUs so that a Steward can check and a global IP block can be implemented.
James Alexander james.alexander@rochester.edu jamesofur@gmail.com
On Sun, Aug 8, 2010 at 12:40 PM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
Jesse (Pathoschild), 08/08/2010 16:53:
On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola aaron.adrignola@gmail.com wrote:
It is irritating to continually see stewards making local blocks at the English language Wikibooks with the comment "crosswiki abuse <!
--globally
locked[1]; about bot[2]-- >".
These local blocks are made when the account has been globally locked by a steward (see http://meta.wikimedia.org/wiki/SH#lock ). There can be no further undermining of local community autonomy, because the local account is blocked with or without an explicit local block. The local blocks are implemented automatically as a way for local communities to know the user is blocked, since there is no other local indication of the implicit block.
I'm ok with those block, but if this is all you want, why isn't a short block enough? It would leave a trace in the local logs, although it wouldn't be displayed on [[Special:Contributions]].
Nemo
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I appreciate your detailed explanation. If a page at Meta could be created to explain this and linked to from the edit summaries this would do much to eliminate confusion amongst local administrators. I do have a concern, however. I've checked the SUL statuses for many of these accounts blocked locally and usually the local blocks only affect less than 20 wikis. What's to say that a mischievous individual couldn't register at one of the other 700 wikis without blocks/autoblock in place and do the same thing? This seems to be a problem in need of a technical solution rather than one that creates the situation that prompted my original message. As it is, it seems that even if local blocks for global locks are performed at Wikibooks (and elsewhere), you are still going to need to do a CU regardless.
-- User:Adrignola
On Sun, Aug 8, 2010 at 12:17 PM, James Alexander jamesofur@gmail.comwrote:
While I've had my own issues with Stewards reaching into local communities I actually think these blocks are important and very useful for our xwiki abusers. While the transparency reasoning that Pathoschild mentioned is true and important just as if not more important is the autoblocks (where at least a day or so block makes sense).
Global locking does not have any autoblock like feature and we have a large portion of our xwiki abusers (and even a growing number of those who only attack only one or two sites and have figured out the global login system) who will take advantage of this and go to another wiki, create the account and SUL over to whatever project they want to attack. This is also the issue with abusive names (they often don't even edit, that isn't the point).
If the stewards can't implement these autoblocks it is easier for abusers to use wikibooks as a starting point for abuse, just because they didn't edit there doesn't mean that they didn't use the project as a spring board or that they couldn't in the future since it is obvious they know the project exists and will now try it when they go trying to create new accounts. Globally locking active xwiki vandals is almost useless if they are able to just recreate accounts continually or at least until they SUL onto a wiki without local CUs so that a Steward can check and a global IP block can be implemented.
James Alexander james.alexander@rochester.edu jamesofur@gmail.com
On Sun, Aug 8, 2010 at 12:40 PM, Federico Leva (Nemo) <nemowiki@gmail.com
wrote:
Jesse (Pathoschild), 08/08/2010 16:53:
On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola aaron.adrignola@gmail.com wrote:
It is irritating to continually see stewards making local blocks at
the
English language Wikibooks with the comment "crosswiki abuse <!
--globally
locked[1]; about bot[2]-- >".
These local blocks are made when the account has been globally locked by a steward (see http://meta.wikimedia.org/wiki/SH#lock ). There can be no further undermining of local community autonomy, because the local account is blocked with or without an explicit local block. The local blocks are implemented automatically as a way for local communities to know the user is blocked, since there is no other local indication of the implicit block.
I'm ok with those block, but if this is all you want, why isn't a short block enough? It would leave a trace in the local logs, although it wouldn't be displayed on [[Special:Contributions]].
Nemo
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Sun, Aug 8, 2010 at 6:29 PM, Aaron Adrignola aaron.adrignola@gmail.comwrote:
I appreciate your detailed explanation. If a page at Meta could be created to explain this and linked to from the edit summaries this would do much to eliminate confusion amongst local administrators. I do have a concern, however. I've checked the SUL statuses for many of these accounts blocked locally and usually the local blocks only affect less than 20 wikis. What's to say that a mischievous individual couldn't register at one of the other 700 wikis without blocks/autoblock in place and do the same thing? This seems to be a problem in need of a technical solution rather than one that creates the situation that prompted my original message. As it is, it seems that even if local blocks for global locks are performed at Wikibooks (and elsewhere), you are still going to need to do a CU regardless.
-- User:Adrignola
There is a lot of truth to that and I totally agree. It would be very nice to find a way to get an autoblock feature in to global locking at least for a short bit (which may well both help limit the need of CUs and help to make things easier on the stewards). Actually I'll see if there is a bug filed and if not I'll file it from talking to Pathoschild it sounds like it may not be technically easy but is always worth trying to find better meathods. I totally understand your concern about them using the other 700 wikis, I have similar ones. There does seem some truth to the idea that they often seem to just use the easiest to find projects or the ones they have already found but that is obviously not always the case.
James
Aaron Adrignola wrote:
I appreciate your detailed explanation. If a page at Meta could be created to explain this and linked to from the edit summaries this would do much to eliminate confusion amongst local administrators. I do have a concern, however. I've checked the SUL statuses for many of these accounts blocked locally and usually the local blocks only affect less than 20 wikis. What's to say that a mischievous individual couldn't register at one of the other 700 wikis without blocks/autoblock in place and do the same thing? This seems to be a problem in need of a technical solution rather than one that creates the situation that prompted my original message. As it is, it seems that even if local blocks for global locks are performed at Wikibooks (and elsewhere), you are still going to need to do a CU regardless.
-- User:Adrignola
Autoblocking suppressed accounts (Bug 23114) is implemented (r64982,r65184,r65185). It just needs to be reviewed and deployed.
On Sun, Aug 8, 2010 at 7:12 PM, Platonides Platonides@gmail.com wrote:
Aaron Adrignola wrote:
I appreciate your detailed explanation. If a page at Meta could be
created
to explain this and linked to from the edit summaries this would do much
to
eliminate confusion amongst local administrators. I do have a concern, however. I've checked the SUL statuses for many of these accounts
blocked
locally and usually the local blocks only affect less than 20 wikis.
What's
to say that a mischievous individual couldn't register at one of the
other
700 wikis without blocks/autoblock in place and do the same thing? This seems to be a problem in need of a technical solution rather than one
that
creates the situation that prompted my original message. As it is, it
seems
that even if local blocks for global locks are performed at Wikibooks
(and
elsewhere), you are still going to need to do a CU regardless.
-- User:Adrignola
Autoblocking suppressed accounts (Bug 23114) is implemented (r64982,r65184,r65185). It just needs to be reviewed and deployed.
Ah ha! globally suppressed accounts only I gather? (so not normally locked
ones) May be beneficial to have it as an option for stewards while locking any account and not just ones that need to be suppressed.
James Alexander james.alexander@rochester.edu jamesofur@gmail.com
On 09/08/10 03:17, James Alexander wrote:
Global locking does not have any autoblock like feature and we have a large portion of our xwiki abusers (and even a growing number of those who only attack only one or two sites and have figured out the global login system) who will take advantage of this and go to another wiki, create the account and SUL over to whatever project they want to attack.
Is there a request in Bugzilla to fix this?
-- Tim Starling
Tim Starling wrote:
On 09/08/10 03:17, James Alexander wrote:
Global locking does not have any autoblock like feature and we have a large portion of our xwiki abusers (and even a growing number of those who only attack only one or two sites and have figured out the global login system) who will take advantage of this and go to another wiki, create the account and SUL over to whatever project they want to attack.
Is there a request in Bugzilla to fix this?
I think he's referring to bug 17929 ("CentralAuth lock/hide should trigger global autoblocks").[1]
Related bugs are 15294 ("Allow blocking of global accounts") and 23114 ("CentralAuth: global suppression with this extension should use autoblock").[2][3]
Bug 23114 is marked fixed, though I don't know if that means it's live on Wikimedia wikis and I don't know if "global suppression" is treated the same as "global locking."
MZMcBride
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=17929 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=15294 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=23114
wikimedia-l@lists.wikimedia.org