[Foundation-l] Stewards acting locally

Aaron Adrignola aaron.adrignola at gmail.com
Sun Aug 8 22:29:11 UTC 2010


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 at gmail.com>wrote:

> 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 at rochester.edu
> jamesofur at gmail.com
>
>
> On Sun, Aug 8, 2010 at 12:40 PM, Federico Leva (Nemo) <nemowiki at gmail.com
> >wrote:
>
> > Jesse (Pathoschild), 08/08/2010 16:53:
> > > On Sun, Aug 8, 2010 at 9:04 AM, Aaron Adrignola
> > > <aaron.adrignola at 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 at lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>


More information about the foundation-l mailing list