Page MenuHomePhabricator

"You've got new message" is displayed even after a revert
Open, LowestPublic

Description

Author: taw

Description:
There's a pretty serious spam problem at http://pl.wikipedia.org/ now.

One (banned) problem user pastes links to his flames on talkpages of many users.
The spam is of course quickly reverted, however the spammed users still see
"You've got a new message".
So they naturally check their talkpages, and not seeing anything new, they go to
history to check what's going on.

That way, a lot of users loss time, and a major portion of the spam gets
through, in spite of reverting, as it's seen via history links.

There are 2 solution that I think are easy to implement:

  • Remember which edit was last seen by the user (obviously done now in some

form, for newtalk flagging to work). And when the newtalk flag is positive and
the "You've got a new message" is about to be displayed, check once more - if
the current version is exactly the same as the last seen version (= spam was
reverted), clear the flag and don't report the new message.

  • Option of nuking edits, instead of just reverting them. Add a sysop option to

throw the edit directly to the archive for deleted edits, and pretend it never
happened. Whether it's easy to implement or not depends on database schema. It
would be very easy if we just considered the version with the most recent date
that has not been deleted to be the current version. In 1.4 we didn't. I'm not
sure about 1.5. Anyway, I think the first solution is the preferred one.


Version: unspecified
Severity: normal
URL: http://pl.wikipedia.org/

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:43 PM
bzimport set Reference to bz2939.
bzimport added a subscriber: Unknown Object (MLST).

angus wrote:

So, if someone writes you a message telling you to watch my edits because I've
been spamming, I can just delete that message and you'll never know... hmm...

taw wrote:

(In reply to comment #1)

So, if someone writes you a message telling you to watch my edits because I've
been spamming, I can just delete that message and you'll never know... hmm...

In this solution, the only case when someone won't see a message is if it has
been reverted and not reverted back later, that is - if no change is present on
recipient's talk page.

If you revert valid messages, someone will unrevert your revert (... and block
you), and the intended recipient will see the message.

Whatever happens to a talk page, its owner should be notified with a message.
Stopping notification on revert is open to other kind of abuses.

taw wrote:

The only abuse I see is the spam. It's happening right now, it's already a
serious problem (a few hundred users spammed on pl.wp, by just a single troll
without any help from spambots), and will only become more serious when more
spammers learn about this bug. E.g. what could we do in the current setup if
some spammer bot-posted herbal viagra ads on 1000 user talk pages ?
We're providing better spam seen:spam sent ratio than almost any other kind of spam.

So could you elaborate what kind of abuses are we stopping by notifying about
reverted messaged ?
I fail to see even a purely theoretical potential of abuse, and it's certainly
not happening now, unlike the spam.

We can leave an option for paranoid users to notify in spite of the revert, but
I'm sure hardly anyone would bother.

taw wrote:

(About WONTFIX) Why do we want to keep this bug again ?
It is a bug, it has been abused in the past, and fixing it doesn't seem to be
that hard.

The main issue is that you don't know whether a revert *should* clear
the flag or not. In this sequence for instance you would not want it to
clear:

  1. User:Alice posts -> sets new message flag
  2. User:Bob vandalizes
  3. User:Cory reverts to User:Alice's post

ayg wrote:

Well, that's not a question of whether to WONTFIX. If this is implemented at
all, it should certainly be optional per-user. As for whether it should be
(sooner or later), I think Tomasz makes a pretty good point, although I've been
interested the one or two times someone's spam to my talk page has been reverted.

I think something like this would never ever be "optional per-user".
Rather, it would have to be implemented such that it works correctly.

taw wrote:

How about an implementation where in addition to new message flag we keep
revision id
of the last version of talk page visited.
If on page request new message flag is true, we check if content of the last
seen revision is identical
to the current revision. If so, we clear new message flag.

So:
(newtalk=false, last_seen_rev_id=1, cur_rev_id=1)

  1. User:Alice posts -> sets new message flag

(newtalk=true, last_seen_rev_id=1, cur_rev_id=2)

  1. User:Bob vandalizes

(newtalk=true, last_seen_rev_id=1, cur_rev_id=3)

  1. User:Cory reverts to User:Alice's post

(newtalk=true, last_seen_rev_id=1, cur_rev_id=4)

  1. User opens some random page.

(contents of rev 1 == contents of rev 4 -> silently clear newtalk flag)

Or we could drop newtalk, as last_seen_rev_id contains all the relevant information
and newtalk is simply an optimization here.

robchur wrote:

Checking the contents of two revisions on each page view like that is too expensive.

taw wrote:

The check would only be done if newtalk was set.

It should be pretty easy to make sure it's checked no more than once per user
talk page edit.
Or we could move the check to user talk page save =>
if contents of last_seen_rev_id equal contents of the new revision, clear
newtalk flag.

robchur wrote:

*** Bug 9157 has been marked as a duplicate of this bug. ***

The check would only have to be done on set, presumably, not on every page read.
A revision number is one possibility; another might be to keep a hash of the
previous version?

If I recall correctly, throttles can be set to control how fast someone can post messages to multiple users' talk pages. It seems like throttling, combined with the various automated tools (e.g. Cryptoderk's) for keeping an eye on Recent Changes, should be enough to keep spammers in check. On a wiki with 1,000 active contributors, presumably there are people watching Recent Changes frequently enough to catch spammers before they can hit too many pages.

Even if we make it so that the reverted talk page doesn't set the new messages flag, won't the changes still show up on the recipient's (and possibly other users') watchlist? So their attention will still be drawn to it.

Closed as LATER. There is no meta data on edits being a revert.

Reopening -- rev_sha1 field is being added in 1.19 and would be usable to look this up.

Also switching notification & messaging systems will eventually render this obsolete, but if we do it first, hey neat!

Aside from rev_sha1, I think rev_text_id instead of rev_id could've been used already. A revert re-uses the same text id, right ? Limiting it to only cases like revert where the contents don't just happen to be the same but are brought back to an earlier state.

Probably won't be fixed before new notification & messaging system.

Probably invalid now that all this stuff is handled by Echo.

Echo is not part of MW, so reopening.

epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:15 AM

Tagging Editing-team as this may be of interested to them as part of the Discussion Tools being worked on.

In a nut shell: MediaWiki tracks the revision number of the talk page when you last opened it. If it has changed, then the orange bar "You have new talk page messages" is displayed to the user.

The problem: If someone leaves a message on your talk page, but then changes their mind (self-revert) or if somone reverts it as spam, then the contents are identical to what you've last seen, there is nothing new.

This could possibly be solved either by clearing the "new talk" flag for the target user during the revert, or by tracking the "new talk" flag based on the content ID rather than the revision number.

Change 761305 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/core@master] Suppress user talk page notification for reverted edits

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