This post is dedicated to Michael :)
I did a quick hack which allows sysops to ban logged-in users. This was discussed on wikien-l long, long ago, and was widely agreed to be a good idea (well, not that widely, but Jimbo was particularly keen). Basically you just type the username into the ban IP box. I changed a few messages to indicate that you could do it.
Blocking a logged-in user by IP address was slightly trickier (but still only required a handful of lines). Whenever any banned user successfully logs on and accesses a page, their IP address is automatically blocked. The reason given is 'Autoblocked because you share an IP address with "Michael". Reason: blah blah blah', and the "blocked by" field is copied. That way the "you are banned discuss this with xxxx" message still makes sense. As usual, these automatically generated entries, and the original username entries, can be unblocked by any sysop (even blocked sysops).
I know Michael has been making a nuisance of himself again, so I'm sure a lot of people will be interested in seeing this go live quickly.
I also fixed that annoying undeletion problem (mostly). It still doesn't update the search index, or user_newtalk, or site_stats, or probably a few other things. But at least the link table is fixed up.
-- Tim Starling
On Mon, Sep 01, 2003 at 12:44:20AM +1000, Tim Starling wrote:
This post is dedicated to Michael :)
I did a quick hack which allows sysops to ban logged-in users. This was discussed on wikien-l long, long ago, and was widely agreed to be a good idea (well, not that widely, but Jimbo was particularly keen). Basically you just type the username into the ban IP box. I changed a few messages to indicate that you could do it.
Blocking a logged-in user by IP address was slightly trickier (but still only required a handful of lines). Whenever any banned user successfully logs on and accesses a page, their IP address is automatically blocked. The reason given is 'Autoblocked because you share an IP address with "Michael". Reason: blah blah blah', and the "blocked by" field is copied. That way the "you are banned discuss this with xxxx" message still makes sense. As usual, these automatically generated entries, and the original username entries, can be unblocked by any sysop (even blocked sysops).
I know Michael has been making a nuisance of himself again, so I'm sure a lot of people will be interested in seeing this go live quickly.
I also fixed that annoying undeletion problem (mostly). It still doesn't update the search index, or user_newtalk, or site_stats, or probably a few other things. But at least the link table is fixed up.
That's going to give sysops waaaaay too much power. I don't think it's good idea.
Btw, Tim, try making your email less spammy ;-)
Content analysis details: (4.40 points, 5 required) FROM_WEBMAIL_ENDS_IN_NUMS6 (1.5 points) From address is webmail, and ends in lots of numbers FROM_ENDS_IN_NUMS (0.7 points) From: ends in numbers SEMIFORGED_HOTMAIL_RCVD (1.7 points) hotmail.com 'From' address, but no 'Received:' PRIORITY_NO_NAME (0.5 points) Message has priority setting, but no X-Mailer
----- Original Message ----- From: "Tomasz Wegrzanowski" taw@users.sourceforge.net To: "A mailing list for discussing about the technical organization of theWikipedias" wikitech-l@Wikipedia.org Sent: Monday, September 01, 2003 1:06 AM Subject: Re: [Wikitech-l] Sysop ability to ban logged in users;Undelete bug fixed
On Mon, Sep 01, 2003 at 12:44:20AM +1000, Tim Starling wrote:
This post is dedicated to Michael :)
I did a quick hack which allows sysops to ban logged-in users. This was discussed on wikien-l long, long ago, and was widely agreed to be a good idea (well, not that widely, but Jimbo was particularly keen). Basically
you
just type the username into the ban IP box. I changed a few messages to indicate that you could do it.
<snip>
That's going to give sysops waaaaay too much power. I don't think it's good idea.
It's necessary. Michael's actions have made it worth the tradeoff. Plus it gives us more defence against vandalbots. We can add an "untrusted user" definition if you think it's necessary, but remember that sysops are now a large (>100), heterogeneous group of people.
Btw, Tim, try making your email less spammy ;-)
Content analysis details: (4.40 points, 5 required) FROM_WEBMAIL_ENDS_IN_NUMS6 (1.5 points) From address is webmail, and
ends in lots of numbers
FROM_ENDS_IN_NUMS (0.7 points) From: ends in numbers
I had to pick something which was easy to remember, and ts4294967296 certainly is :) My real address is t-starling-physics-unimelb-edu-au, but I don't want Mozilla beeping at me every five minutes.
SEMIFORGED_HOTMAIL_RCVD (1.7 points) hotmail.com 'From' address, but
no 'Received:'
Probably GMANE's fault. Better now?
PRIORITY_NO_NAME (0.5 points) Message has priority setting, but no
X-Mailer
That's probably Outlook Express's fault.
-- Tim Starling
Hmm... My Spamassassin says:
X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_20,FROM_ENDS_IN_NUMS,FROM_WEBMAIL_ENDS_IN_NUMS6, PRIORITY_NO_NAME,SEMIFORGED_HOTMAIL_RCVD version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Jason
Tomasz Wegrzanowski wrote:
Btw, Tim, try making your email less spammy ;-)
Content analysis details: (4.40 points, 5 required) FROM_WEBMAIL_ENDS_IN_NUMS6 (1.5 points) From address is webmail, and ends in lots of numbers FROM_ENDS_IN_NUMS (0.7 points) From: ends in numbers SEMIFORGED_HOTMAIL_RCVD (1.7 points) hotmail.com 'From' address, but no 'Received:' PRIORITY_NO_NAME (0.5 points) Message has priority setting, but no X-Mailer
From: Tim Starling I did a quick hack which allows sysops to ban logged-in users. This
was
discussed on wikien-l long, long ago, and was widely agreed to be a
good
idea (well, not that widely, but Jimbo was particularly keen).
Basically
you just type the username into the ban IP box. I changed a few messages
to
indicate that you could do it.
I assume that sysops can be banned through this interface as well. The hack sounds pretty ugly. Banning by username should be done by banning through the login (i.e. the cookies) not by checking IP.
Have these changes been checked in?
This is not something that should go live without discussion on the main mailing list.
-tc
The Cunctator wrote:
I assume that sysops can be banned through this interface as well.
Yes; one sysop having fun could ban all other existing user accounts and finally him/herself. That would be a pretty silly thing to do, though.
The hack sounds pretty ugly. Banning by username should be done by banning through the login (i.e. the cookies) not by checking IP.
Username banning bans the username only, or rather it _did_. (There was no user interface for doing it, so sysops could not do so.)
Since it's trivial to log out and make a new account, Tim's patch also adds a check for the IP address when the banned user next tries to edit (and would thus discover they were banned) and add the IP address to the ban list as well. Thus a logout/login-with-new-name would be banned too.
So all one has to do is log out _and_ change IP addresses. (A few seconds, click a couple buttons for many people with dynamic IPs.) Create a new account name under the new IP, and go wild.
One might gain a slight additional protection by setting a "you're banned" note in the session data or a separate cookie instead of (or in addition to) banning the IP. The bannee could clear their cookies or restart their brower to clear it.
Have these changes been checked in?
In the development branch.
This is not something that should go live without discussion on the main mailing list.
It's been discussed before, many times. That's why Tim wrote some up, because it was discussed and many people were in favor. Of course it'll be discussed some more, and anyway this certainly isn't appropriate without also having automatic expiration of blocks.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
The Cunctator wrote:
I assume that sysops can be banned through this interface as well.
Yes; one sysop having fun could ban all other existing user accounts and finally him/herself. That would be a pretty silly thing to do, though.
Tsk tsk, don't you people read? ;) I said:
:As usual, these automatically generated entries, and the original :username entries, can be unblocked by any sysop (even blocked sysops).
Blocking by username or IP address only stops the user from editing pages, it does not stop them from blocking or unblocking people. Mav has been known to block himself at times, in an attempt to discourage himself from wasting all his time on this rather addictive website. Now he'll be able to block himself by username, he won't have to go to the trouble of looking up his IP address.
The hack sounds pretty ugly. Banning by username should be done by banning through the login (i.e. the cookies) not by checking IP.
Username banning bans the username only, or rather it _did_. (There was no user interface for doing it, so sysops could not do so.)
Since it's trivial to log out and make a new account, Tim's patch also adds a check for the IP address when the banned user next tries to edit (and would thus discover they were banned) and add the IP address to the ban list as well. Thus a logout/login-with-new-name would be banned too.
So all one has to do is log out _and_ change IP addresses. (A few seconds, click a couple buttons for many people with dynamic IPs.) Create a new account name under the new IP, and go wild.
I don't think most vandals would know how to change their IP address easily. But even if they did, this modification makes things much harder for them, and much easier for us.
One might gain a slight additional protection by setting a "you're banned" note in the session data or a separate cookie instead of (or in addition to) banning the IP. The bannee could clear their cookies or restart their brower to clear it.
That's possible, but I'm happy to wait and see how effective the current measures are. Banning with cookies could cause problems for Internet cafes, because it would be difficult to lift the ban after a complaint.
Have these changes been checked in?
In the development branch.
This is not something that should go live without discussion on the main mailing list.
It's been discussed before, many times. That's why Tim wrote some up, because it was discussed and many people were in favor. Of course it'll be discussed some more, and anyway this certainly isn't appropriate without also having automatic expiration of blocks.
Automatic expiration? Piece of cake, give me 24 hours. Any suggestions for the lifetime?
-- Tim Starling.
Tim Starling wrote:
Brion Vibber wrote:
So all one has to do is log out _and_ change IP addresses. (A few seconds, click a couple buttons for many people with dynamic IPs.) Create a new account name under the new IP, and go wild.
I don't think most vandals would know how to change their IP address easily. But even if they did, this modification makes things much harder for them, and much easier for us.
Well, this whole issue is over A Certain Person who exploits the current system by creating multiple accounts and frequently changing IPs, exactly the situation that can most easily get around this.
One might gain a slight additional protection by setting a "you're banned" note in the session data or a separate cookie instead of (or in addition to) banning the IP. The bannee could clear their cookies or restart their brower to clear it.
That's possible, but I'm happy to wait and see how effective the current measures are. Banning with cookies could cause problems for Internet cafes, because it would be difficult to lift the ban after a complaint.
The cookie or session variable could store a random-generated ID number which could sit in ipblocks and be displayed in the "you're blocked" notice, and used to unblock by if someone complains.
(Also, if one is blocked accidentally, it's not very clear how to contact anybody about it. It tells you the username of the person who made the block, but you can't leave a note on their talk page. You can't e-mail them through the "e-mail this user" function because you're not a logged-in user with an e-mail address set...)
Automatic expiration? Piece of cake, give me 24 hours. Any suggestions for the lifetime?
24 hours? :)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote in part:
Tim Starling wrote:
Banning with cookies could cause problems for Internet cafes, because it would be difficult to lift the ban after a complaint.
The cookie or session variable could store a random-generated ID number which could sit in ipblocks and be displayed in the "you're blocked" notice, and used to unblock by if someone complains.
The cookie should also expire after the same amount of time as a block. (See below.)
(Also, if one is blocked accidentally, it's not very clear how to contact anybody about it. It tells you the username of the person who made the block, but you can't leave a note on their talk page. You can't e-mail them through the "e-mail this user" function because you're not a logged-in user with an e-mail address set...)
That's why somebody added a link to [[Wikipedia:Administrators]] (at least on [[en:]]). Then they find the list of administrators. And they can't email mav, and they can't email Ilyanep ... but they can email me! (And on a few occasions, they have.)
Automatic expiration? Piece of cake, give me 24 hours. Any suggestions for the lifetime?
24 hours? :)
Everybody says a week. That's probably too long if it works, and too short if they keep coming back on another line. You might consider offering a range of options in a radio button, with the short one as the default (for new vandals).
-- Toby
"Erik Moeller" wrote
Tim-
Automatic expiration? Piece of cake, give me 24 hours. Any suggestions for the lifetime?
Should be configurable in minutes, with 0=infinite (we have permanently banned users).
Sorry Erik, I'm afraid that exceeds my "piece of cake" design brief. :) Instead, I've just committed the following to CVS:
* Lifetime for user blocks and IP blocks is configurable separately, in LocalSettings.php. The current default is 24 hours for IP blocks, and infinite for user blocks. * Blocks disappear from the table without a trace, at the end of their lifetime. A possible future improvement would be to allow them to be manually refreshed, but currently that is impossible. * The timestamp on an IP block will be automatically refreshed if a banned user accesses Wikipedia through that address. * The software can be restored to roughly its previous behaviour using $wgSysopUserBans=false in LocalSettings.php. The difference is that sysops can now unblock users regardless of the setting, whereas before only developers could unblock users. * Blocks are now encapsulated in the "Block" object, in "Block.php". The code is mostly converted over to use it. It optionally deletes expired bans on read.
-- Tim Starling.
Tim-
- Lifetime for user blocks and IP blocks is configurable separately, in
LocalSettings.php. The current default is 24 hours for IP blocks, and infinite for user blocks.
That's a reasonable solution, I think.
Regards,
Erik
From: Tim Starling Sent: Monday, September 01, 2003 9:35 AM
- The timestamp on an IP block will be automatically refreshed if a
banned
user accesses Wikipedia through that address.
What does this mean? Does this extend the block?
The Cunctator wrote:
Tim Starling wrote:
The timestamp on an IP block will be automatically refreshed if a banned user accesses Wikipedia through that address.
What does this mean? Does this extend the block?
That's what it sounds like to me. The week starts over when they come back (or when somebody comes back that we think is them because of the IP).
-- Toby
Toby Bartels wrote:
The Cunctator wrote:
Tim Starling wrote:
The timestamp on an IP block will be automatically refreshed if a banned user accesses Wikipedia through that address.
What does this mean? Does this extend the block?
That's what it sounds like to me. The week starts over when they come back (or when somebody comes back that we think is them because of the IP).
Say if Michael logs in under a banned name and accesses Wikipedia through 1.2.3.4. The address 1.2.3.4 is automatically blocked, with an expiration time 24 hours in the future. He continues to access Wikipedia for a few hours using the same name and address. Each time he access a page, the 1.2.3.4 block is extended. Now say he logs out and logs back in with a new unbanned name. He still can't make changes because he's still using 1.2.3.4, but the clock is now ticking. 24 hours after he logged out and logged back in with the new name, the IP ban expires. But by that time he's probably changed his IP address anyway. If he changes his IP address and logs back in with the banned name, a second IP ban will be created, under the same rules.
One problem with this scheme is that we can't ban static IP addresses indefinitely anymore, like we used to. Well, it's more difficult, anyway. You'd have to record the IP address somewhere, and then reban it once a day.
-- Tim Starling
On Mon, 1 Sep 2003 23:34:53 +1000, Tim Starling ts4294967296@hotmail.com gave utterance to the following:
Instead, I've just committed the following to CVS:
- Lifetime for user blocks and IP blocks is configurable separately, in
LocalSettings.php. The current default is 24 hours for IP blocks, and infinite for user blocks.
- Blocks disappear from the table without a trace, at the end of their
lifetime. A possible future improvement would be to allow them to be manually refreshed, but currently that is impossible.
May I suggest one more piece of logic? An IP block is automatically released if a non-banned user logs in on it. (which means that the IP has been reassigned away from the vandal)
wikitech-l@lists.wikimedia.org