Last modified: 2014-11-19 05:12:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5233, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3233 - Send a cookie with each block?
Send a cookie with each block?
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 6 votes (vote)
: ---
Assigned To: Tyler Romeo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-23 00:09 UTC by Robert Rohde
Modified: 2014-11-19 05:12 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Attempt to incorporate cookie blocks into autoblocker (52.02 KB, patch)
2005-08-25 02:50 UTC, Robert Rohde
Details

Description Robert Rohde 2005-08-23 00:09:03 UTC
I would like to propose an extension of the autoblocker.  The goal is to limit an attacker's 
ability to continue their bad behavior by obtaining a new IP address (i.e. by redialing an ISP 
or resetting a DSL connection).

Whenever someone logs into a mediawiki wiki from an account that has been blocked, in addition 
to autoblocking their IP address, send their browser a cookie identifying the block in 
question.  Then every time someone tries to edit anonymously or create a new account, look for 
this cookie and if it exists, see whether the block it references is still active and if so 
block the new IP as well.

Such cookies would need to be temporary (just as auto-blocks are temporary (is it 24 hours?)) 
to avoid catching good people on public computers.

Of course, some black hats would be able to find ways around such cookies (its not all that 
hard), but I would be willing to wager that most of the people engaged in juvenile vandalism 
are not all that computer savvy.

Two possible conflicts come to my mind.  One, if someone is blocked for having an 
inappropriate username, it is not obvious that we would necessarily want their IP blocked from 
creating a new account.  (How is this handled in the present autoblocker?)  Though for most 
inappropriate usernames, being forced to sit down for 24 hours might not be a bad thing.

The other possible conflict is when a user has multiple accounts.  If a sockpuppet account is 
blocked, should that necessarily impose a short block on the other accounts as well?  Maybe 
so.  This could be avoided by only checking for the cookie when someone is acting anonymously, 
or we could just decide that a block on one should lead to a short block of all (is this the 
effect of the current autoblocker?).

Anyway, anything to slow down returning persistent vandals is in my mind a good thing.

-DF
Comment 1 Filip Maljkovic [Dungodung] 2005-08-23 00:15:10 UTC
I think that's a really good idea and the 2 problems could be solved by a simple
checkbox - i.e. the sysop can choose if the cookie should be sent or not (in
case of bad name and sockpuppeting). Or am I missing something?
Comment 2 Robert Rohde 2005-08-23 18:41:06 UTC
(In reply to comment #1)
> I think that's a really good idea and the 2 problems could be solved by a simplecheckbox -
 i.e. the sysop can choose if the cookie should be sent or not (incase of bad name and 
sockpuppeting). Or am I missing something?

That sounds like a fine solution to me.
Comment 3 Robert Rohde 2005-08-25 02:50:13 UTC
Created attachment 829 [details]
Attempt to incorporate cookie blocks into autoblocker

If you want something done, sometimes you have to do it yourself...  So I
decided to try.

The attached file is a modified version of User.php from the most recent 1.5
version.  It adds a field mLastIP to user and utilizes corresponding session
and cookie variables.  I have added a section to the blocking code that checks
mLastIP against $wgIP and if they are different then tests whether mLastIP is
presently blocked.  If so, it proceeds to block $wgIP with the same expiration
time.

Looking at the code, this seemed the easiest way to get what I was after.  All
blocks and autoblocks still work the same as they always have, just a cookie
keeps track of the last IP address the server recieved from the user and if it
changes it will then apply the same block to the new IP address.

Or at least that is the intention anyway.  I don't have anywhere that I can
practically install MediaWiki so I am working blind on this without anyway to
test or debug my changes.  Perhaps some nice developer would like to try this
out, see if it working, and fix any bugs?

One thing that maybe should be changed before this goes live...  Right now the
reason for the new block is simply copied from the old block.  I didn't want to
use the autoblocker message as that could quickly become tangled nested
nonsense if someone jumped through several IPs.  This means there is nothing
identifying an IP change block as an autoblock, which could confuse admins.  On
the other hand, I'm not entirely sure I want the block reason to explain that
someone's IP was tracked either.  Thoughts on this?

Anyway, I hope this proves useful, though if someone has a reason why this is
somehow a horribly bad idea, please speak up.  As I said before, it won't catch
everyone, and it is pretty easy to turn off cookies, but if it slows down the
juvenile vandalism even a little I'll be happy.

-DF
Comment 4 Andrew Garrett 2008-10-24 12:40:48 UTC
Is there any interest in this, or should it be closed as WONTFIX?
Comment 5 Harald Krichel 2009-02-23 12:45:40 UTC
Of course there is a very strong interest in this.
We have much more vandals than vandals who even know to change their IP. We could track and ban daily vandals for maybe a month or more. And we could separate student's and teacher's computers which may have the same IP.

Maybe we could set flash cookies for the more sophisticated vandals. I esteem that far more than 50% of our vandals could not handle either standard or flash cookies. 

who is using aFurthermore we could reduce the collateral damage of the hardblocking/autoblocking feature when blocking a vandal who is using a mandatory proxy.

Comment 6 Tisza Gergő 2009-02-23 13:58:34 UTC
[https://developer.mozilla.org/en/DOM/Storage DOM storage] / [http://msdn.microsoft.com/en-us/library/ms531424.aspx userData] is another tricky tracking method that most vandals probably aren't aware of. But even the most basic cookie-based blocking would be very useful for vandals accessing the net through quickly changing dynamic adresses or large proxies.
Comment 7 Cirt 2009-02-24 23:55:05 UTC
This really is a very very good idea and should be implemented.
Comment 8 J.delanoy 2009-02-25 00:13:19 UTC
Speaking as someone who primarily fights vandalism, I would be extremely grateful if this bug were acted on. It is tedious and frankly annoying to have to deal with people who only have to reset their router or switch proxies to continue their spree. 
Comment 9 Tyler Romeo 2013-02-07 22:01:12 UTC
https://gerrit.wikimedia.org/r/48029
Comment 10 MZMcBride 2013-02-07 23:16:20 UTC
When this bug was filed (in 2005), Web browsers didn't commonly have an "incognito" or "private browsing" mode. Given that this cookie feature is intended to target users who are capable of changing their IP address (i.e., users with some degree of technical competence/clue), I feel it's reasonable to assume these same bad users are equally capable of using their Web browser's incognito mode or disabling JavaScript or clearing their cookies as a means of bypassing this cookie.

I'm inclined to support marking this bug as resolved/wontfix, but I'd like to hear what others think.
Comment 11 Matthew Flaschen 2013-02-07 23:18:45 UTC
I'm concerned about this, particularly with the cookie duration used in Tyler's Gerrit.

First of all, this will obviously have ramifications on shared computers, particularly in libraries in schools, where there's a lot of vandalism but also where some constructive people do their only editing.  That alone gives me pause.

Robert suggested 24 hours, which would definitely mitigate this.  However, the proposed implementation (https://gerrit.wikimedia.org/r/#/c/48029/3/includes/User.php) uses the default cookie expiration (since setCookie with duration 0 uses that).

The default default (https://www.mediawiki.org/wiki/Manual:$wgCookieExpiration) is now 180 days, which is an entirely different matter from a day.

I also think if we do this, it should be controlled by two separate wg config variables:

1. Whether to do it at all, defaulting false.
2. (Ignored if 1 is false) Duration, defaulting to 24 hours or something else very short like that.

MZMcBride is also right that it's now much easier to clear your cookies and local storage (private browsing/incognito is relatively well publicized), so we might be mostly targetting the good guys.

I realize there are some casual vandals (ignorant of cookies) who randomly get assigned IPs (e.g. through a bad proxy) and keep on rolling.  But I'm skeptical it's a worthwhile tradeoff.
Comment 12 Tyler Romeo 2013-02-07 23:21:52 UTC
(In reply to comment #10)
> When this bug was filed (in 2005), Web browsers didn't commonly have an
> "incognito" or "private browsing" mode. Given that this cookie feature is
> intended to target users who are capable of changing their IP address (i.e.,
> users with some degree of technical competence/clue), I feel it's reasonable
> to
> assume these same bad users are equally capable of using their Web browser's
> incognito mode or disabling JavaScript or clearing their cookies as a means
> of
> bypassing this cookie.
> 
> I'm inclined to support marking this bug as resolved/wontfix, but I'd like to
> hear what others think.

It should be noted, though, that incognito mode does not ignore cookies, it simply deletes them upon going out of incognito mode. So if a user logs into a blocked account incognito, but doesn't open a new window when switching IPs, the cookie will still be there.

(In reply to comment #11)
> I'm concerned about this, particularly with the cookie duration used in
> Tyler's
> Gerrit.
> 
> First of all, this will obviously have ramifications on shared computers,
> particularly in libraries in schools, where there's a lot of vandalism but
> also
> where some constructive people do their only editing.  That alone gives me
> pause.
> 
> Robert suggested 24 hours, which would definitely mitigate this.  However,
> the
> proposed implementation
> (https://gerrit.wikimedia.org/r/#/c/48029/3/includes/User.php) uses the
> default
> cookie expiration (since setCookie with duration 0 uses that).
> 
> The default default
> (https://www.mediawiki.org/wiki/Manual:$wgCookieExpiration)
> is now 180 days, which is an entirely different matter from a day.

The cookie should last however long the block lasts. That's how autoblocks work even outside of this case. It's the autoblock that needs to be short (and it is short), not the cookie expiration.
Comment 13 Matthew Flaschen 2013-02-07 23:30:20 UTC
> The cookie should last however long the block lasts. That's how autoblocks work
> even outside of this case. It's the autoblock that needs to be short (and it is 
> short), not the cookie expiration.

However, if I understand correctly, you're effectively broadening the scope of the autoblock, so it seems reasonable to consider a different cookie duration than $wgAutoblockExpiry.

If someone vandalizes from a shared computer that occasionally changes external IP, before the block would only be tied to the shared IP (unless someone tried to log in).  Now, it is broader, since it is tied to *both* the shared browser and the shared IP.
Comment 14 Tyler Romeo 2013-02-07 23:33:41 UTC
(In reply to comment #13)
> However, if I understand correctly, you're effectively broadening the scope
> of
> the autoblock, so it seems reasonable to consider a different cookie duration
> than $wgAutoblockExpiry.
> 
> If someone vandalizes from a shared computer that occasionally changes
> external
> IP, before the block would only be tied to the shared IP (unless someone
> tried
> to log in).  Now, it is broader, since it is tied to *both* the shared
> browser
> and the shared IP.

Yeah, but that's existing functionality. When a user is blocked with autoblock, whenever they login, the new IP they login from is also autoblocked. The only difference between what we have now and this patch is that if the blocked user tries to edit anonymously they'll also trigger the autoblock (since right now the only way of telling if a blocked user tries to edit is if they log in under their blocked account).
Comment 15 Tyler Romeo 2013-02-07 23:34:25 UTC
(In reply to comment #13)
> However, if I understand correctly, you're effectively broadening the scope
> of
> the autoblock, so it seems reasonable to consider a different cookie duration
> than $wgAutoblockExpiry.
> 
> If someone vandalizes from a shared computer that occasionally changes
> external
> IP, before the block would only be tied to the shared IP (unless someone
> tried
> to log in).  Now, it is broader, since it is tied to *both* the shared
> browser
> and the shared IP.

Yeah, but that's existing functionality. When a user is blocked with autoblock, whenever they login, the new IP they login from is also autoblocked. The only difference between what we have now and this patch is that if the blocked user tries to edit anonymously they'll also trigger the autoblock (since right now the only way of telling if a blocked user tries to edit is if they log in under their blocked account).
Comment 16 Bawolff (Brian Wolff) 2013-02-07 23:39:08 UTC
>MZMcBride is also right that it's now much easier to clear your cookies and
>local storage (private browsing/incognito is relatively well publicized), so we
>might be mostly targetting the good guys.

No kidding, but was it ever hard? All browsers had a single button "clear my cookies" since the dark ages (aka pre IE 6), they're just a little more prominent now.

from comment 1
>Of course, some black hats...

If that's all it takes to be a black hat...

-----

>First of all, this will obviously have ramifications on shared computers,
>particularly in libraries in schools, where there's a lot of vandalism but also
>where some constructive people do their only editing.  That alone gives me
>pause.

You think blocking someone with a cookie is going to have more fallout than blocking their IP? In the case of a school (that's probably behind a nat) the IP block might block the entire school. Worrying about this sort of thing is a social, not a technical issue. If the admins think it is worth the loss of potential editors, they will block the user with autoblock on. If they don't, they won't block the user with autoblock on. The ability to screw over shared computers already exists in software ;)

I agree that a long lasting cookie is undesirable, but if this was implemented as:
*24 hour cookie (at most)
*Only enabled when autoblock is on (which is not all blocks)
The fallout on innocent users (relative to the previous fallout) would be almost 0 as far as I can tell. The effectiveness might be questionable, but I doubt it would hurt anything.

Keep in mind that while clearing cookies has become easier, it has become even easier to change your ip. Simply change which neighbour you're stealing wifi from.
Comment 17 Matthew Flaschen 2013-02-07 23:43:20 UTC
>> Yeah, but that's existing functionality. When a user is blocked with autoblock,
>> whenever they login, the new IP they login from is also autoblocked. The only 
>> difference between what we have now and this patch is that if the blocked user 
>> tries to edit anonymously they'll also trigger the autoblock (since right now
>> the only way of telling if a blocked user tries to edit is if they log in under
>> their blocked account)."

That's not the only difference.  If someone edited from a shared browser that someone else used to vandalize on a different IP (with a current autoblock), before they got lucky.  Now, they're still blocked for $wgAutoblockExpiry
Comment 18 Tyler Romeo 2013-02-07 23:46:19 UTC
(In reply to comment #17)
> That's not the only difference.  If someone edited from a shared browser that
> someone else used to vandalize on a different IP (with a current autoblock),
> before they got lucky.  Now, they're still blocked for $wgAutoblockExpiry

The case you're making is one where a shared browser (which implies a shared computer) is able to change its IP address, which IMO is not a very likely case.
Comment 19 Matthew Flaschen 2013-02-07 23:48:42 UTC
It's not the most likely case, but it happens.  Institutional proxies can have multiple exit nodes, or be reassigned between them.
Comment 20 Tyler Romeo 2013-02-07 23:55:59 UTC
OK, but the likelihood of the case is important. Right now there are numerous cases where autoblocks accidentally block innocent editors (such as the very simple case of a blocked user logging on using a shared computer and causing everybody else who uses that computer to be blocked). Like was said before, it's more of a social issue, i.e., is the blocking user willing to risk accidentally blocking good users.
Comment 21 Krinkle 2013-02-08 02:36:49 UTC
Comment on attachment 829 [details]
Attempt to incorporate cookie blocks into autoblocker

Altering attachment properties to indicate that this is a patch.
Comment 22 Tyler Romeo 2013-02-08 19:01:19 UTC
@Krinkle You made the attachment a patch, but it's actually not a patch, just a copy of User.php with changes made. :P
Comment 23 Krinkle 2013-02-12 11:26:50 UTC
Please provide a patch, then.
Comment 24 Tyler Romeo 2013-02-12 14:26:05 UTC
(In reply to comment #23)
> Please provide a patch, then.

(In reply to comment #9)
> https://gerrit.wikimedia.org/r/48029
Comment 25 James Forrester 2013-03-05 23:24:32 UTC
[Comment also on the code, but it applies to the bug more widely.]

I'm concerned that this adds still further to the (not short) list of cookies that MediaWiki in general, and WIkimedia's cluster in particular, can/will add. Has this gone through legal to approve it - e.g. are there issues with the privacy policy/Terms of Use?
Comment 26 Gerrit Notification Bot 2014-11-18 13:38:16 UTC
Change 48029 abandoned by Krinkle:
Send a cookie with autoblocks to prevent vandalism.

https://gerrit.wikimedia.org/r/48029
Comment 27 Gerrit Notification Bot 2014-11-19 05:12:05 UTC
Change 48029 restored by Parent5446:
Send a cookie with autoblocks to prevent vandalism.

Reason:
Why was this abandoned?

https://gerrit.wikimedia.org/r/48029

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links