Page MenuHomePhabricator

Send a cookie with each block
Closed, ResolvedPublic8 Estimated Story Points

Assigned To
Authored By
Dragons_flight
Aug 23 2005, 12:09 AM
Referenced Files
F2539109: signature.asc
Sep 4 2015, 5:12 AM
F2236: User.php
Nov 21 2014, 8:46 PM
Tokens
"Love" token, awarded by MarcoAurelio."Doubloon" token, awarded by RandomDSdevel."Like" token, awarded by Ladsgroup."Like" token, awarded by Jdforrester-WMF."Mountain of Wealth" token, awarded by Dalba.

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

Related Objects

Event Timeline

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

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

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

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

Samwilson subscribed.
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!!

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/

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.

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.

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"!

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

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

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?

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!)

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