Send a cookie with each block
Closed, ResolvedPublic8 Story Points

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

Details

Reference
bz3233

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Tgr: What do you think of that proposal? i.e. cookie expiration will match the block expiration unless it is longer than $wgCookieExpiration, in which case it will be set to $wgCookieExpiration. Since the cookie always points back to the original block and the original block's expiration is always checked when applying the cookie block, I think this should be OK. Also, there is far less potential for collateral damage here than a regular IP autoblock, so I don't think we need to be as conservative.

Tgr added a comment.Nov 15 2016, 12:58 AM

Sounds fine to me, although T5233#2779033 sounds fine too, it just doesn't match the current patch.

$wgCookieExpiration is 30 days btw, the login cookie uses $wgExtendedLoginCookieExpiration.

What is $wgExtendedLoginCookieExpiration set to on WMF wikis? (It's null by default, meaning it uses $wgCookieExpiration).

I think it makes sense to stick with $wgCookieExpiration rather than $wgExtendedLoginCookieExpiration, as the latter is specifically about the login cookie.

I'll update the patch now.

Tgr added a comment.Nov 15 2016, 1:45 AM

Huh, apparently default MediaWiki has 180 days for cookie expiration and the login cookie uses that; Wikimedia has 30 days for cookie expiration and 365 days for login. That seems wrong. Probably the huge default cookie expiration time was set before there was a separate variable for login cookies.

Anyway, using $wgCookieExpiration for a cookie is the natural thing to do. The MediaWiki default should probably be fixed.

Change 48029 merged by jenkins-bot:
Send a cookie with autoblocks to prevent vandalism.

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

kaldari closed this task as Resolved.Nov 16 2016, 7:15 PM
kaldari moved this task from Needs Review/Feedback to Done on the Community-Tech-Sprint board.
matej_suchanek updated the task description. (Show Details)
Niharika moved this task from Backlog to Archive on the Community-Tech board.Nov 28 2016, 11:00 AM
DannyH reopened this task as Open.Jan 30 2017, 7:22 PM

Reopening so that this can be a tracking ticket as we continue to work on refinements...

kaldari closed subtask Restricted Task as Resolved.Feb 13 2017, 11:45 PM
Samwilson removed Samwilson as the assignee of this task.Feb 14 2017, 10:56 PM
Samwilson added a subscriber: Samwilson.
MusikAnimal closed this task as Resolved.Mar 30 2017, 3:54 PM
MusikAnimal claimed this task.

Deployed to English Wikipedia and working beautifully :) Those with access to EventLogging data can monitor eventlogging_CookieBlock to see how often blocks are being enforced by the cookie. We've also been keeping a close eye on the autoblock list and all seems well. We'll deploy to other wikis soon. Huge thanks and congrats to @Samwilson, and all who helped with this!!

Xeno added a subscriber: Xeno.Mar 30 2017, 6:15 PM

This has been made live on English Wikipedia. It has been suggested to provide the ability to control whether a cookie block is placed separate from the autoblock option due to potential personal liability that could be acquired in countries with "cookie laws".

Where can I find the eventLogging data? I would like to look at the cookieBlock extension.

I looked at the eventlogging data. As of right now, there have been 1134 cookie-based blocks on enwiki. Woah!

Where can I find the eventLogging data? I would like to look at the cookieBlock extension.

It's private data so not everyone can access it. To look at the code you don't need to access the eventlogging data. CookieBlock is not an extension but a part of MediaWiki core. See https://gerrit.wikimedia.org/r/#/c/48029/

Yoshi24517 added a comment.EditedMar 31 2017, 3:20 AM

I didn't mean the code. I meant the eventLogging data. (Scratch that comment.)

Ah never mind. I see that I have to be a Wikimedia Foundation employee. Thanks anyway. I think it would be really cool to watch though. Anyway thanks for telling me.

TheDJ added a subscriber: TheDJ.Mar 31 2017, 8:01 AM

due to potential personal liability that could be acquired in countries with "cookie laws".

Can you link those discussions ? It seems rather exceptional if there would be personal liability for that. But maybe WMF-legal could weigh in.

I looked at the eventlogging data. As of right now, there have been 1134 cookie-based blocks on enwiki. Woah!

Yeah... I'm questing if that was set up correctly. If that figure were true we should see a large influx of active autoblocks, which I have not noticed. I shall investigate!

In T5233#3144570, @Xeno wrote:

This has been made live on English Wikipedia. It has been suggested to provide the ability to control whether a cookie block is placed separate from the autoblock option due to potential personal liability that could be acquired in countries with "cookie laws".

I've spoke with legal and they should comment on the discussion soon.

jrbs added a subscriber: jrbs.Apr 1 2017, 9:26 AM
jeblad added a subscriber: jeblad.EditedApr 3 2017, 6:23 PM

In some countries we have short dynamic lease of IP addresses, that means a block will start to propagate. We have also some admins that belive blocking IP ranges is a good thing. That means blocking parts of the network for ISPs. When you add this on top the IP block then you effectively block the whole IP-range for that ISP.

Sorry, but this idea is utterly stupid! I'm just waiting for articles about "the new internett-virus spread by Wikipedia"!

Tgr added a comment.Apr 3 2017, 7:21 PM

The EU data protection working group advisory WP-194 section 3.3 ("cookies set for the specific task of increasing the security of the service that has been explicitly requested by the user") clearly applies here, as long as the cookie is only set on edit attempts (IIRC not the case with the current implementation, but would be a trivial change).

Kjetil added a subscriber: Kjetil.Apr 3 2017, 7:22 PM
jeblad added a comment.Apr 3 2017, 7:41 PM

I doubt that interpretation hold for this task, but it surely will not hold at all for T152462 and definitely not for T152953.

jeblad added a comment.Apr 3 2017, 7:48 PM

Given the statement in T5233#980836 and how this will behave, I can not see how this should be claimed to not be interfering with a multiuser environment. It is used for blocking of IP addresses where the blocked user itself may not be active, but other users might be active. In T152462 there isn't even made any attempt to check if there is a single user? In T152953 multiple users will be involved, possibly an unlimited number?

In T5233#3151976, @Tgr wrote:

... as long as the cookie is only set on edit attempts (IIRC not the case with the current implementation, but would be a trivial change).

One problem with only setting the cookie on an edit attempt is that it relies on the person being blocked then attempting to edit after being blocked but before changing their IP address. That might be quite okay though; I guess most blocked people try to edit after being blocked?

Akeron added a subscriber: Akeron.Apr 4 2017, 8:13 AM
Jeff_G added a subscriber: Jeff_G.May 1 2017, 10:41 PM
Chicocvenancio added a comment.EditedMay 2 2017, 1:27 PM

Is there a Timeline for this to be set on other WMF wikis? Specifically in ptwiki it would be particularly useful right now. (May 8, from the comment bellow. Thanks!)

Zppix removed a subscriber: Zppix.May 2 2017, 1:32 PM
DannyH moved this task from Epic/Tracking to Archive on the Community-Tech board.May 9 2017, 1:46 AM

Can't we start sending cookies for ip blocks as well?

In T5233#3151976, @Tgr wrote:

... as long as the cookie is only set on edit attempts (IIRC not the case with the current implementation, but would be a trivial change).

One problem with only setting the cookie on an edit attempt is that it relies on the person being blocked then attempting to edit after being blocked but before changing their IP address. That might be quite okay though; I guess most blocked people try to edit after being blocked?

The cookie could be added as soon as the user requests an edit page or gets a notice that they are blocked, even on a different WMF project or another wiki that runs this code, effectively crowdsourcing the cookie addition, given a global realtime distributed database of IP addresses to be sent cookies.

Can't we start sending cookies for ip blocks as well?

If you meant blocks of individual IP addresses, I thought that was a good idea and already included. If you meant rangeblocks of IP address ranges, I think that is a good idea.

Can't we start sending cookies for ip blocks as well?

See T152462

greg removed a subscriber: greg.May 20 2017, 8:53 PM