Send a cookie with each block?
Open, LowPublic

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

Details

Security
None
Reference
bz3233
bzimport set Reference to bz3233.

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?

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

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

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

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

cirt.wik wrote:

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

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.

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.

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.

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

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.

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

This comment was removed by Parent5446.

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.

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

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

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

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 on attachment 829
Attempt to incorporate cookie blocks into autoblocker

Altering attachment properties to indicate that this is a patch.

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

Please provide a patch, then.

(In reply to comment #23)

Please provide a patch, then.

(In reply to comment #9)

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

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

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

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

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.Dec 10 2014, 5:45 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.Jan 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...

@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.Jan 13 2015, 7:29 AM

Who decides?

Tgr added a subscriber: LuisV_WMF.Jan 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 set Security to None.

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.Feb 4 2015, 8:10 PM
Qgil added a subscriber: greg.Feb 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.Feb 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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 18 2015, 6:45 PM
MER-C added a subscriber: MER-C.Jul 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.

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.

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: Philippe-WMF.

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.

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

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.Aug 13 2015, 2:48 AM
DGG added a subscriber: DGG.Sep 2 2015, 2:38 AM

The people this will catch are not the ones who cause serious problems.

Implementing this - or not - is a question of costs versus benefits.

  1. Benefit: No, this won't stop everyone, or perhaps even those who cause serious problems, but it will stop some bad actors. The question is whether the number that will be stopped is trivial or a substantial.
  1. Cost to implement: small or not?
  1. Cost: to maintain: Added complexity to maintain, including compatibility issues. The question is whether this is small or not.
  1. Cost, potentially: Inappropriate blocks. The questions are (a) what is the likelihood of such blocks, and (b) how easy will it be for admins to learn that this is happening, and get the software tweaked (or, if the problem is insurmountable, to shut it down).

If the answers are (1) substantial, (2) small, (3) small, (4a) very low, and (4b) fairly easy, then the case for doing this would seem to be a strong one.

+1 MZMcBride
a culture problem will not be solved with cookies.
you are just escalating wack a mole

better solution is tightening algorithm by Halfaker
i.e. what are some behavioral signals for this problem?

Since you would be adding a cookie to someone's computer without his consent and the effect of the cookie is contrary to his interests, the cookie would be ''malware'' and probably illegal.

Jay8g added a subscriber: Jay8g.Sep 4 2015, 1:52 AM

Just to clarify, that is completely false (in regards to the cookie being "malware").

For legal perspective, please see T5233#980836 above.
For "Information We Collect" (like cookies), please see https://wikimediafoundation.org/wiki/Privacy_policy

Swpb added a subscriber: Swpb.Nov 9 2015, 9:20 PM
Dalba awarded a token.Nov 19 2015, 7:29 AM
Dalba added a subscriber: Dalba.
DannyH moved this task from Untriaged to Snackbox on the Community-Tech board.Dec 11 2015, 7:23 PM

Add Comment