Last modified: 2014-04-29 19:39:31 UTC
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.
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 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.
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.
(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
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.
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) 2) User:Bob vandalizes (newtalk=true, last_seen_rev_id=1, cur_rev_id=3) 3) User:Cory reverts to User:Alice's post (newtalk=true, last_seen_rev_id=1, cur_rev_id=4) 4) 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.
Checking the contents of two revisions on each page view like that is too expensive.
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.
*** 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.
Moving to Echo.
Probably invalid now that all this stuff is handled by Echo.
Echo is not part of MW, so reopening.
