Send a cookie with each block?
OpenPublic

Description

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


Version: unspecified
Severity: enhancement

bzimport set Reference to bz3233.
Dragons_flight created this task.Via LegacyAug 23 2005, 12:09 AM
dungodung added a comment.Via ConduitAug 23 2005, 12:15 AM

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?

Dragons_flight added a comment.Via ConduitAug 23 2005, 6:41 PM

(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.

Dragons_flight added a comment.Via ConduitAug 25 2005, 2:50 AM

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

Attached: User.php

werdna added a comment.Via ConduitOct 24 2008, 12:40 PM

Is there any interest in this, or should it be closed as WONTFIX?

Seewolf added a comment.Via ConduitFeb 23 2009, 12:45 PM

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.

Tgr added a comment.Via ConduitFeb 23 2009, 1:58 PM

[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.

bzimport added a comment.Via ConduitFeb 24 2009, 11:55 PM

cirt.wik wrote:

This really is a very very good idea and should be implemented.

bzimport added a comment.Via ConduitFeb 25 2009, 12:13 AM

J.delanoywiki wrote:

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.

MZMcBride added a comment.Via ConduitFeb 7 2013, 11:16 PM

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.

Mattflaschen added a comment.Via ConduitFeb 7 2013, 11:18 PM

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.

Parent5446 added a comment.Via ConduitFeb 7 2013, 11:21 PM

(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.

Mattflaschen added a comment.Via ConduitFeb 7 2013, 11:30 PM

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.

Parent5446 added a comment.Via ConduitFeb 7 2013, 11:33 PM

(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).

Parent5446 added a comment.Via ConduitFeb 7 2013, 11:34 PM
This comment was removed by Parent5446.
Bawolff added a comment.Via ConduitFeb 7 2013, 11:39 PM

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.

Mattflaschen added a comment.Via ConduitFeb 7 2013, 11:43 PM

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

Parent5446 added a comment.Via ConduitFeb 7 2013, 11:46 PM

(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.

Mattflaschen added a comment.Via ConduitFeb 7 2013, 11:48 PM

It's not the most likely case, but it happens. Institutional proxies can have multiple exit nodes, or be reassigned between them.

Parent5446 added a comment.Via ConduitFeb 7 2013, 11:55 PM

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.

Krinkle added a comment.Via ConduitFeb 8 2013, 2:36 AM

Comment on attachment 829
Attempt to incorporate cookie blocks into autoblocker

Altering attachment properties to indicate that this is a patch.

Parent5446 added a comment.Via ConduitFeb 8 2013, 7:01 PM

@Krinkle You made the attachment a patch, but it's actually not a patch, just a copy of User.php with changes made. :P

Krinkle added a comment.Via ConduitFeb 12 2013, 11:26 AM

Please provide a patch, then.

Parent5446 added a comment.Via ConduitFeb 12 2013, 2:26 PM

(In reply to comment #23)

Please provide a patch, then.

(In reply to comment #9)

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

Jdforrester-WMF added a comment.Via ConduitMar 5 2013, 11:24 PM

[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?

gerritbot added a comment.Via ConduitNov 18 2014, 1:38 PM

Change 48029 abandoned by Krinkle:
Send a cookie with autoblocks to prevent vandalism.

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

gerritbot added a comment.Via ConduitNov 19 2014, 5:12 AM

Change 48029 restored by Parent5446:
Send a cookie with autoblocks to prevent vandalism.

Reason:
Why was this abandoned?

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

werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:45 PM
gerritbot added a project: Patch-For-Review.Via ConduitDec 12 2014, 5:29 PM

Change 48029 had a related patch set uploaded (by Qgil):
Send a cookie with autoblocks to prevent vandalism.

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

Patch-For-Review

Qgil added a subscriber: Qgil.Via WebJan 9 2015, 10:37 PM

@Parent5446, this is one of the oldest tasks assigned to someone. Please consider rebasing your patch and solving this task. It looks like you were close...

Parent5446 added a comment.Via WebJan 11 2015, 2:58 AM

@Qgil I wasn't just close, it was working. However, it appears this task has a high likelihood of being WONTFIXed (or, rather, Declined). Unless there has been a change of opinion, it is not worth the effort to continue maintaining the patch.

Qgil added a comment.Via WebJan 13 2015, 7:29 AM

Who decides?

Tgr added a subscriber: LuisV_WMF.Via WebJan 13 2015, 8:27 AM

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?

@LuisV_WMF, can you have a look at this?

LuisV_WMF added a subscriber: Mpaulson.Via WebJan 13 2015, 4:53 PM
LuisV_WMF set Security to None.
Mattflaschen removed a subscriber: Mattflaschen.Via WebJan 15 2015, 4:06 AM
Mpaulson added a comment.Via WebJan 15 2015, 11:30 PM

From a legal perspective, this proposal is in compliance with our privacy policy and terms of use. However, I would like to echo the cautionary comments already made on this thread of overly broad blocks occurring as a result of this cookie, particularly in multi-user scenarios.

-Michelle

Krinkle removed a subscriber: Krinkle.Via WebFeb 4 2015, 8:10 PM
Qgil added a subscriber: greg.Via WebFeb 14 2015, 3:21 PM

After all the discussion and all the work done, there are no legal blockers, and what we have is a doubt of the effectiveness and potential side effects. Is there a way to A/B test this or plan a progressive deployment, so we can try a sample, and go for more / less based on results?

Next August this task will be ten years old. Unless we try something practical, we will continue discussing based on theoretical scenarios.

Tgr added a comment.Via WebFeb 14 2015, 9:01 PM

What would you A/B test for? Block length? That doesn't tell you whether the new autoblocks hit the right targets.
IMO it's easier to just enable and ask admins to be on the lookout and see what happens.

Glaisher added a subscriber: Glaisher.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldJul 18 2015, 6:45 PM
MER-C added a subscriber: MER-C.Via WebJul 24 2015, 1:50 PM

This can also be combined with something like Evercookie (minus Flash, Java and Silverlight) to make blocks a lot more difficult to circumvent. To address concerns about collateral damage, the ability to use such a measure could be restricted to the checkuser (or similar) group. Stronger blocking tools are sorely needed because of stuff like this.

Bawolff added a subscriber: Bawolff.Via WebJul 24 2015, 1:55 PM

This can also be combined with something like Evercookie (minus Flash, Java and Silverlight) to make blocks a lot more difficult to circumvent. To address concerns about collateral damage, the ability to use such a measure could be restricted to the checkuser (or similar) group. Stronger blocking tools are sorely needed because of stuff like this.

You're going to have to accept, that in a site designed like Wikipedia, there's going to be a small number of adversaries that are impossible to block in a rigorous manner. There is no way around this unless you want to start making people submit photo-id before being allowed to edit.

Interesting moral delima with evercookie, given they actively hack people's computers to make the cookie hard to delete. To quote their page:

Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive.

LuisV_WMF added a comment.Via EmailJul 24 2015, 1:58 PM

Without endorsing this particular solution, there are of course going to be
sophisticated attackers, but we also get plenty of unsophisticated
attackers. If we can get creative about how to handle those, we should.

Philippe-WMF added a subscriber: csteipp.Via WebJul 24 2015, 2:07 PM
Philippe-WMF added a subscriber: Philippe-WMF.
Bawolff added a comment.Via WebJul 24 2015, 3:02 PM

Without endorsing this particular solution, there are of course going to be
sophisticated attackers, but we also get plenty of unsophisticated
attackers. If we can get creative about how to handle those, we should.

Arguably, users who can change their IP address are not unsophisticated adversaries.

LuisV_WMF added a comment.Via EmailJul 24 2015, 3:26 PM

Yes, many things are arguable. It'd be nice to be able to experiment and
base the discussion on data.

McZusatz added a comment.Via WebJul 24 2015, 5:51 PM

I did a quick test with no flash/silverlight/java (people are actually still using those?) and could delete the test evercookie created by http://samy.pl/evercookie/ by simply deleting all firefox history; So before using evercookie in addition to the standard http cookie, someone should do a test with the most commonly used browsers on wiki* sites and see if evercookie may even yield substantial advantages.

Aside, I consider evercookie a follow-up enhancement after the current patch got merged.

Tbayer added a subscriber: Tbayer.Via WebThu, Aug 13, 2:48 AM

Add Comment