Page MenuHomePhabricator

Limiting thanks for new users at pl.wikipedia
Closed, ResolvedPublic

Description

Polish Wikipedia is facing massive Wikinger activity, from a number of open proxy IPs and freshly created accounts. One of his activities is mass-thanking users for random edits they have made, in tens or even three-digit numbers. Therefore, Polish WIkipedia community would like to reqiest that thanking for edits for users under the autoconfirmed status be limited to, say, three per day. See e.g. https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=49623939#Wprowadzenie_ogranicze.C5.84_dla_wysy.C5.82ania_podzi.C4.99kowa.C5.84 - there has also been an admin mailing list discussion where "three per day for non-autoconfirmed users" was quoted as the most sensible number.

Event Timeline

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

To debug the configuration, I'd apply two limits, one for user, the one we
want to apply for new accounts, and one for autoconfirmed, ten / sixty.

That should work.

Change 363011 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Fix rate limit configuration for plwiki - ratelimit thanks-notification

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

Change 363011 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Fix rate limit configuration for plwiki - ratelimit thanks-notification

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

Can this be deployed right now? I've set two limits as @Dereckson advices. Thank you!

Actually, that wil not work either, because 'autoconfirmed' is apparently special and not treated as a group name by this code :/

And is there better way how to do it? For example unsetting the user limit temporary? Is it possible per wiki?

I think the only workaround is to lower the limit for all users. I proposed a patch to resolve the underlying bug at T169545 (currently that task is restricted).

Change 363011 abandoned by Urbanecm:
Fix rate limit configuration for plwiki - ratelimit thanks-notification

Reason:
Seems it won't work, see the task

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

Urbanecm removed Urbanecm as the assignee of this task.Jul 10 2017, 11:42 AM

I can't do anything else, next things are discussed on restricted task I have no access to.

matmarex closed this task as Resolved.Jul 10 2017, 10:36 PM
matmarex removed a project: Patch-For-Review.
matmarex assigned this task to Urbanecm.

The patch for the underlying bug was just deployed and I verified that it fixes the issue. My newly registered test account (https://pl.wikipedia.org/wiki/Specjalna:Rejestr/thanks/Matma_Rex_test_2017-07-11) was only able to send three thanks before getting this error message:

Dereckson reopened this task as Open.Jul 18 2017, 12:19 PM

@Wpedzich How the situation evolves?

Do you see shoot of three thanks in the logs?

Will it be fine to revert this early August?

It is getting the job done, and personally (also seeing the reaction of plwiki admins) I would not revert this, as Wikinger is likely to pick up on this soon enough. Besides, three thanks a day seems a reasonable number generally...

Urbanecm closed this task as Resolved.Jul 18 2017, 12:37 PM

There s no need to have this Opened. Let's wait for some time.

Well, first, we're going to revert this, this is only intended as a temporary measure.

Secondly, you can thank more than three times a day without creating any disruption.

So we need to know how it evolves (ie if there are still accounts created, and thanks issued).

greg added a subscriber: greg.Aug 24 2017, 4:48 PM

Well, first, we're going to revert this, this is only intended as a temporary measure.

It's been more than a month so far (https://wikitech.wikimedia.org/wiki/Deployments#Longer_term says to reevaluate in Aug, it's almost Sept).

Is there a place to ask about the revert of this change?

Should we check with the pl.wikipedia community if this issues has subsided? @Wpedzich?

it does seem to have pacified Wikinger's thank activity and there are no negative comments from fresh users who are unable to thank for edits more than they ought to. Also, the active userforce has welcomed the limitation, so if no one objects, I would leave the limitation in place.

I would propose we revert this change. If Wikinger returns then I would be in support of making this a permanent change.

Wostr added a comment.Aug 24 2017, 6:22 PM

I can only agree with Wpedzich: this limitation should be permanent on pl.wikipedia. Also, it should not be reverted without clear support from pl.wiki community.

Such restriction WON'T be permanent. I'd recommend that somebody looks into logstash and find how many non-Wikinger users touch this limit. Then we should decide about the restriction. If we are limiting 90 % newbies (who don't know they can say this to somebody) and 10 % Wikinger, this restriction have no sense.

@Dereckson, can you have a look at the logs?

Also, it should not be reverted without clear support from pl.wiki community.

It will be reverted at some day, even if the community didn't agree (and even if there will be a explicit consensus to NOT DO this). System administrators have ultimate authority regarding configuration changes, just to remember you.

kaldari removed a subscriber: kaldari.Aug 24 2017, 8:08 PM

It will be reverted at some day, even if the community didn't agree (and even if there will be a explicit consensus to NOT DO this). System administrators have ultimate authority regarding configuration changes, just to remember you.

I don't think it needs to rise to this level, nor do I think we need to rush. If it takes an extra month to figure what to do, that's ok. Probably this is something that @TBolliger / Anti-Harassment can look into?

Yes, @Legoktm, this is a very interesting case study for the Anti-Harassment team to look into.

I'll have my team look into T174191: Generate report via logstash of pl.wikipedia thanks-notification rate limiting in our next sprint, which starts next Wednesday.

saper added a subscriber: saper.Aug 26 2017, 10:14 AM

Do all those tasks really need to be restricted? it is difficult to follow what is going on...

I don't think the description of T174191 is meant to be secret, so here it is:

Generate report via logstash of pl.wikipedia thanks-notification rate limiting

Look at the logstash of thanks-notification throttling on pl.wikipedia (since June 30, 2017)

  • How many users per day hit the threshold
  • How many of these users have 0 edits vs. 1+ edits
  • How else can we determine if these accounts are Wikinger (the harasser responsible for the Thanks spam) vs 'good' accounts?

The contents of such a report are potentially sensitive information that we shouldn't release publicly (the usernames might be already hidden on the wiki by admins, and I'm not sure what the status of throttling data is but it has never been public), which is probably why the task was marked as restricted.

Ok, I understand now. Thank you!

From T174191: Generate report via logstash of pl.wikipedia thanks-notification rate limiting we can see that on pl.wikipedia for the past 30 days only 7 users hit this threshold. In my opinion this is low enough for us to revert the limit.

If the problem returns we should think about a more universal solution, such as implementing a (per-wiki customizable) limit for all Echo-enabled wikis, bundling Thanks notifications that originate from the same user in the same day, or other solutions to alleviate this problem.

Thoughts?

If the problem returns we should think about a more universal solution, such as implementing a (per-wiki customizable) limit for all Echo-enabled wikis

I'll note that this already exists and we used this very system to add the rate limit currently in place ;) Let's not implement a duplicate one.

If the problem returns we should think about a more universal solution, such as implementing a (per-wiki customizable) limit for all Echo-enabled wikis

I'll note that this already exists and we used this very system to add the rate limit currently in place ;) Let's not implement a duplicate one.

Great to hear! What I was thinking was a variable that would be customizable by admins (MediaWiki message?) without having to create a Phab ticket.

From T174191: Generate report via logstash of pl.wikipedia thanks-notification rate limiting we can see that on pl.wikipedia for the past 30 days only 7 users hit this threshold. In my opinion this is low enough for us to revert the limit.

If the problem returns we should think about a more universal solution, such as implementing a (per-wiki customizable) limit for all Echo-enabled wikis, bundling Thanks notifications that originate from the same user in the same day, or other solutions to alleviate this problem.

Thoughts?

+1, let's do it.

Change 378784 had a related patch set uploaded (by Greg Grossmeier; owner: Greg Grossmeier):
[operations/mediawiki-config@master] Revert "Limit thanks for new users at pl.wikipedia to 3 per day"

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

Change 378784 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Limit thanks for new users at pl.wikipedia to 3 per day"

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

Mentioned in SAL (#wikimedia-operations) [2017-10-03T13:34:55Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:378784|Revert "Limit thanks for new users at pl.wikipedia to 3 per day" (T176174 T169268)]] (duration: 00m 46s)

I am new to this service, so can somebody explain to me the situation in plain words and without techno-babble.
We have serious problem at PL-Wikipedia with Wikinger registering new accounts and then sending tens of dozens of "thanks" to our best editors he hates.
"Thank you" feature is a pleasant but spurious gadget, with no relation to creating useful Wikipedia content.
The limit of "thanks" was limited for newbies to 3/day, which helped to alleviate the problem. Recently the limit has been lifted, giving him again a free reign to abuse editors.

What was the reason for this decision?
Why is WMF technical team helping one of the best known Wikipedia trolls torment and attack good editors?
I understand Wikinger does not register many accounts with names like "Greg Grossmeier sucks dicks" on Phabricator and then starts sending thanks around, so the problem does not bother technical team, but still... shouldn't you guys help us, not him?

I am confused
Yours,
FD

@Felis_domestica: The reason is described in the previous comments - see for example https://phabricator.wikimedia.org/T169268#3549803 and https://phabricator.wikimedia.org/T169268#3581101 . If a specific sentence is unclear, feel free to quote that sentence and explain which parts are unclear. Furthermore, please read and follow the Etiquette as there is no reason to accuse people of "not bothering" or implying that people "help" users who show abusive behavior. Thanks.

Dcljr added a subscriber: Dcljr.Oct 9 2017, 7:32 AM

(Off-topic) @Aklapper: FWIW, I believe @Felis_domestica was quite reserved in expressing his/her views. The use of the phrase "not bother" was a purely descriptive one about the consequences of the troll's actions, not about any behaviors/attitudes of sysadmins. And the use of "helping" I took as simply a somewhat figurative description of the effect of the decision to revert the change. I don't think either of these show any lack of etiquette, nor warranted the second half of your comment. (And BTW, simply pointing someone to previous comments with no further explanation, when they have specifically asked for a simple explanation, is pretty likely to not accomplish much except annoying the questioner — it is akin to a "RTFM" type of response, which never goes over well.)

(Back on topic, more or less) The 2 comments you've highlighted, Aklapper, specifically allude to scenarios where the problem returns. Felis_domestica seems to be saying the problem has returned. So now what?

For reference, since the limitation was lifted on 3 October, I see two cases of thanks spam in the public logs (there might be more if they were oversighted)

I think it's safe to say that the issue has not disappeared.

@TBolliger I appreciate that you're working on this but I honestly think we'd be just fine here with the simple solution of lowering the rate limit. And we probably should do that anyway while we discuss other options.

Let me restate that we currently allow 10 thanks per 60 seconds, or 14400 thanks per day, per user, per wiki. This is nothing short of absurd. There is no reason for anyone ever to send 14400 thanks per day (and should anyone find a reason to do this, administrators and bots are already exempt from this rate limit). The most thanks per day that anyone in the history of plwiki legitimately sent (the account is not currently banned) was 105 and that was to multiple different users (presumably thanking them for participation in some event or something). The most thanks per day that anyone legitimately sent to a single other account was 25, which already sounds like an inconvenient practical joke to me. Abusive thanks spam goes as high as 504. And note that the proposed limit only affects non-autoconfirmed users, so if you want to playfully annoy your long-time wiki-buddy with 25 thanks you can still do it.

(Below is the query I used to get the numbers in last comment. Uncomment the various bits to query per-recipient vs general thanks, and blocked users vs not-blocked users.)

-- explain
select log_user_text, log_title, left(log_timestamp, 8) as day, count(*) as count
-- select log_user_text, left(log_timestamp, 8) as day, count(*) as count
from logging
left join ipblocks on log_user=ipb_user
left join centralauth.globaluser on log_user_text=gu_name
where true
and log_type='thanks'
-- and log_timestamp>'2017'
and ipb_id is null and gu_locked=0
-- and (ipb_id is not null or gu_locked=1)
group by log_user_text, log_title, day
-- group by log_user_text, day
order by count desc

@Aklapper I have read one of the links which you have provided, and I quote from it:
[about implemented limitation]
"it does seem to have pacified Wikinger's thank activity and there are no negative comments from fresh users who are unable to thank for edits more than they ought to." ;
"I would propose we revert this change. If Wikinger returns then I would be in support of making this a permanent change."
"I can only agree with Wpedzich: this limitation should be permanent on pl.wikipedia. Also, it should not be reverted without clear support from pl.wiki community."
"Such restriction WON'T be permanent. " [...] t will be reverted at some day, even if the community didn't agree (and even if there will be a explicit consensus to NOT DO this)."

Basically it sums up to this:
Help was needed, helps was provided, no bad side effects were observed.
Help was then withdrawn, but with proviso that if problem returns, help would be provided again
And than it was decided that: no matter what PL-wiki community says, and no matter if the (completely spurious for wiki-creation) feature is abused and creates problem help will be denied.

So please do explain to me, following all etiquette rules, why we are denied help? Why our best editors with hundreds of articles created have to suffer abuse, because user @Urbanecm says "I will revert [the protection against abuse] <<even if there will be a explicit consensus to NOT DO this>>

I am not a technical man, but I edited for 5 years without any "thanks" and it was just fine. And now I see editors being abused, but the "importance" of spurious feature is more important than their well-being.
How does it tally with much touted "create friendly working environment" strategy?

Dereckson reopened this task as Open.EditedOct 10 2017, 12:32 PM

As the user is one individual, why don't you contact ISP for AUP violation or contact their parents if it's a minor, etc.?

That solution worked in some long term vandalism cases on fr.wikipedia.

Technical solutions aren't crafted to handle ONE case, a case better solved socially through a contact to the ISP, their parents if they're minor or a legal action for harassment.

You could be in the illusion technical warfare is a solution to ask an individual to stop to harass people. or that complex issues could be solved with simple solutions like "just limit thanks". I beg to differ and would strongly recommend to act socially instead.

The user in question is not using a fixed landline anymore, since Orange has evacuated his contract. He is running off open proxies and prepaid SIM cards. Believe me, we've tried to stop him. For seven years or so - including contacting law enforcement, and such suggestions lead us absolutely nowhere (no offense meant). Harrassment at the WMF knows about it, I've talked to them recently. Yes, we've tried a number of things, let me repeat myself.

Wojciech

matmarex added a comment.EditedOct 10 2017, 1:25 PM

(this was a mid-air collision with @Wpedzich's post above, he explained it better)

I am not actively following the situation, but I believe we did that several times and got this person blacklisted in all major ISPs by now (although in some cases it took globally blocking all of the ISPs IP address space for a couple days before there was a reaction). Currently it seems he's using prepaid SIM cards (which can be bought anonymously) and editing via open proxies. Note that this has been going on since 2011 or so.

@Felis_domestica: I commented on the choice of words and tone and I tried to explain that phrasing like "why we are denied help" is not helpful at all. That's it.

@Aklapper Frankly, I am flabbergasted.

@Urbanecm says "No matter what PL-community says I will revert the patch which prevented abuse of their editors" and this is OK, this is - presumably - helpful (side comment: it is, to wikinger).

I ask "why we are denied help" - which is a fact You yourself proved, in the links provided - and such question is "not helpful at all".

I am sure there is perfectly sensible reason for such classification of words and actions, but somehow it eludes me....

Dereckson added a comment.EditedOct 10 2017, 10:49 PM

@Felis_domestica Here an example of non aggressive message to express your request:

The <date>, the thanks limitation change has been reverted. But the <date>, the user used again this attack vector to harass people on our wiki.
As such, that demonstrates the revert isn't a solution and it would be worthwhile to reconsider a more long duration / permanent limit.
The limit doesn't affect the regular users, as the threshold is rather high, but is successful to discourage the attacker and limit the harassment feeling.

This kind of message states facts and explain the situation relevant from a technical point of view, and make a concrete request.

I acknowledge this message isn't perfect: it doesn't allow you to express your frustration, your personal feelings, but the format is better suited for this part of phabricator.wikimedia.org, as this part pursues the goal to organize a Wikimedia technical work. It has also the big advantage it avoids any misunderstanding, so no reader would find it offensive.

More generally, a constructive discussion is about arguments, not about people. When you need to quote people or take them to t ask, we quit the world of pure arguments to enter in a potentially offensive discourse.

If the technical solution of limiting thanks to 3 a day is acceptable, then we should revert the revert as soon as possible and call it a day. I agree with @matmarex there's no need to overengineer this or boil the ocean.

And let's make it a permanent change. Later, if plwiki wants to change the throttle amount, they can create a new ticket and start a new discussion.

I'm not sure this is acceptable on a permanent basis, as 3 a day is a
little below the number of thanks legitimate contributors can issue daily.

@Dereckson - please note this limit would only be set for non-autoconfirmed users, of which WIkinger is a perfect example. Legitimate users, with at least autoconfirmed status, would not be affected, and Wikinger's accounts, thanking multiple times, have no edits, and are blocked before they can even reach the AC status.

According to the ticket description:

there has also been an admin mailing list discussion where "three per day for non-autoconfirmed users" was quoted as the most sensible number.

We can ask them if they'd like to adjust it, but for now let's set the limit at 3 to bring back the relief.

SPoore added a comment.EditedOct 11 2017, 4:56 PM

@Dereckson @Wpedzich @TBolliger

As Wpedzich says, the WMF Support and Safety team (my team) is aware of the long term abuse by Wikinger and it is not possible to keep Wikinger off WMF wikis.

The pl community, listening to the people who are being harassed, the admins working to stop it, as well people working with newbie, are well positioned to weight the pros and cons of setting limits for their community.

It seems reasonable (and desirable) to let a local community make this decision.

Change 383694 had a related patch set uploaded (by Greg Grossmeier; owner: Dereckson):
[operations/mediawiki-config@master] Revert "Revert "Limit thanks for new users at pl.wikipedia to 3 per day""

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

This was recently discussed on pl.wp at https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Wikinger_znowu_wszystkich_dyma.3F, I'll leave a comment there too when the change is deployed.

This was recently discussed on pl.wp at https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Wikinger_znowu_wszystkich_dyma.3F, I'll leave a comment there too when the change is deployed.

Thank you!

dmaza reassigned this task from Urbanecm to matmarex.Oct 12 2017, 8:54 PM

Change 383694 merged by Dereckson:
[operations/mediawiki-config@master] Revert "Revert "Limit thanks for new users at pl.wikipedia to 3 per day""

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

Mentioned in SAL (#wikimedia-operations) [2017-10-12T23:58:47Z] <dereckson@tin> Synchronized wmf-config/InitialiseSettings.php: Restore thanks limit on pl.wikipedia (T169268) (duration: 00m 47s)

matmarex closed this task as Resolved.Oct 13 2017, 12:05 AM
matmarex removed a project: Patch-For-Review.

The change has been deployed this evening (thanks @matmarex for testing!),
so the protection has been enabled again.