Change Details

The design for the reverted edits feature can be found in {T254074}. It isn't merged yet, so there's still time to change a few things. When discussing the feature with @kostajh and @Catrope, we found that there are quite a few opportunities for abusing the system by vandals. === What can go wrong? //This comes from a person who has spent quite a lot of time fighting really nasty and desperate vandals. It may a bit pessimistic.// # A vandal can undo a large amount of edits, potentially even entire pages' history using the undoafter= parameter. That would be rolled back later by a moderator, but the reverted tag is permanent and the entire history would be "reverted". This would render the feature utterly useless. There is also no way for an admin to remove these tags, they are software tags. # A vandal can do //false undos//: first, start a large undo using the undoafter= param and then instead of saving, copy the top revision's content to the edit field, fix a comma and save the edit. Effectively this edit was legitimate (fixing a comma), but it was marked as an undo reverting a huge amount of edits. This is bad. # Someone doing a personal //vendetta// against a certain user can willfully undo (or false undo) their edits on many pages, even intermediate edits (undo allows that). That would make the targeted user have lots of their edits marked as //reverted//. Don't laugh, even people on Wikimedia wikis do childish stuff like this all the time. I **really** would not want this feature to become a new playground for immature editors. That would be very sad. # Not only undos can be exploited (though they are easiest), rollbacks and manual reverts leave a permanent record as well. === Why is this bad? When vandals can influence the feature heavily, it stops being useful to anyone and the communities will just give up on it. However, if the feature is only mildly abused, the communities may be tempted to use it in many areas (like hiding reverted edits in page histories and on RC, counting only non-reverted edits of users when determining their eligibility for certain user rights etc.) – in such a case abuse would compromise it and potentially lead to conflicts in the community. IMO we should only introduce it if the are sensible safeguards in place. === Possible mitigations Here I list some ideas on how to fix it, not necessarily ideas that I'd support fully :) # Allow only users with a certain user right to set the reverted tag. ** **Pros**: It would certainly limit the abuse to a minimum. ** **Cons**: This would make the reverted tag a bit inconsistent – legitimate reverts made by non-moderators would not apply the reverted tag, which seems a bit odd. It would also make writing a maintenance script for populating the reverted tag on old edits (see: T258921) close to impossible, as it would have to figure out what user rights people had in the past based on the logs. That would be a mess. # Apply the reverted tag only on relatively shallow reverts, let's say 8 edits were reverted at most. If the revert is deeper, nothing would be marked as //reverted//. The maximum depth can be configurable. ** We could even limit this to 1 edit, to cover only the most common case of reverting. That does seem very incomplete, though. ** **Pros**: This would limit how much damage can a vandal do while covering most legitimate use cases. ** **Cons**: It would be inconsistent with what EditResult says to extensions, as it doesn't have such a mechanism. It would also not solve the problem entirely, just limit the speed at which a vandal can do the damage. # Do not mark undos where the user has applied additional changes over it as reverts. Count these as regular edits. Another possibility is an additional flag in EditResult saying "this is an undo, but the user then applied some more changes and we are not sure if it's a legit undo or not", though this would make it quite confusing to extension developers, I think. ** **Pros**: It would solve issue no. 2. ** **Cons**: This will require some creative hacking in EditPage. That will be fun. # Apply the reverted tag only after the edit was somehow approved. Core could provide a special hook for cancelling job queue submission. Extensions would be responsible for re-enqueueing the job once the edit is "approved". ** If the wiki uses ApprovedRevs or FlaggedRevs, use that. Once the edit is approved, its reverted tag update is sent to the job queue. I'm not sure if Extension:Moderation would require some special treatment as well. ** If the wiki uses patrolling, use that. Users with `autopatrol` right have their reverted edit updates enqueued right away, while others have to wait for someone to patrol their edit. ** **Pros**: It would solve most issues. I think. ** **Cons**: A bit complicated to implement and requiring some additional coordination with extensions. Also: wikis that use patrolling, but not really (i.e. many changes never get patrolled) may be a bit confused by this feature. Anyway, even if the community completely ignores patrolling, this would behave like mitigation #1, which is not terrible actually. # **Or…** completely rethink how edits, reverts and page history works. Make it more like Git, less like a one-dimensional timeline. ** **Pros**: It would solve everything. ** **Cons**: This is basically a rewrite of huge parts of MediaWiki. Extremely hard (or even impossible), but I'm including this here to show that the reverted edits feature is tough to implement properly due to the way MediaWiki was designed. I would personally go with #3 and #4. They aren't the easiest, but I think they should provide minimal safeguards for the feature. This will also require considerable development time, so I'll probably have to reschedule my internship a bit. Any comments or suggestions on the topic are very welcome.

The design for the reverted edits feature can be found in {T254074}. It isn't merged yet, so there's still time to change a few things. When discussing the feature with @kostajh and @Catrope, we found that there are quite a few opportunities for abusing the system by vandals. === What can go wrong? //This comes from a person who has spent quite a lot of time fighting really nasty and desperate vandals. It may a bit pessimistic.// # A vandal can undo a large amount of edits, potentially even entire pages' history using the undoafter= parameter. That would be rolled back later by a moderator, but the reverted tag is permanent and the entire history would be "reverted". This would render the feature utterly useless. There is also no way for an admin to remove these tags, they are software tags. # A vandal can do //false undos//: first, start a large undo using the undoafter= param and then instead of saving, copy the top revision's content to the edit field, fix a comma and save the edit. Effectively this edit was legitimate (fixing a comma), but it was marked as an undo reverting a huge amount of edits. This is bad. # Someone doing a personal //vendetta// against a certain user can willfully undo (or false undo) their edits on many pages, even intermediate edits (undo allows that). That would make the targeted user have lots of their edits marked as //reverted//. Don't laugh, even people on Wikimedia wikis do childish stuff like this all the time. I **really** would not want this feature to become a new playground for immature editors. That would be very sad. # Not only undos can be exploited (though they are easiest), rollbacks and manual reverts leave a permanent record as well. === Why is this bad? When vandals can influence the feature heavily, it stops being useful to anyone and the communities will just give up on it. However, if the feature is only mildly abused, the communities may be tempted to use it in many areas (like hiding reverted edits in page histories and on RC, counting only non-reverted edits of users when determining their eligibility for certain user rights etc.) – in such a case abuse would compromise it and potentially lead to conflicts in the community. IMO we should only introduce it if the are sensible safeguards in place. === Possible mitigations Here I list some ideas on how to fix it, not necessarily ideas that I'd support fully :) # Allow only users with a certain user right to set the reverted tag. ** **Pros**: It would certainly limit the abuse to a minimum. ** **Cons**: This would make the reverted tag a bit inconsistent – legitimate reverts made by non-moderators would not apply the reverted tag, which seems a bit odd. It would also make writing a maintenance script for populating the reverted tag on old edits (see: T258921) close to impossible, as it would have to figure out what user rights people had in the past based on the logs. That would be a mess. # Apply the reverted tag only on relatively shallow reverts, let's say 8 edits were reverted at most. If the revert is deeper, nothing would be marked as //reverted//. The maximum depth can be configurable. ** We could even limit this to 1 edit, to cover only the most common case of reverting. That does seem very incomplete, though. ** **Pros**: This would limit how much damage can a vandal do while covering most legitimate use cases. ** **Cons**: It would be inconsistent with what EditResult says to extensions, as it doesn't have such a mechanism. It would also not solve the problem entirely, just limit the speed at which a vandal can do the damage. # Do not mark undos where the user has applied additional changes over it as reverts. Count these as regular edits. Another possibility is an additional flag in EditResult saying "this is an undo, but the user then applied some more changes and we are not sure if it's a legit undo or not", though this would make it quite confusing to extension developers, I think. ** **Pros**: It would solve issue no. 2. ** **Cons**: This will require some creative hacking in EditPage. That will be fun. # Apply the reverted tag only after the edit was somehow approved. Core could provide a special hook for cancelling job queue submission. Extensions would be responsible for re-enqueueing the job once the edit is "approved". ** If the wiki uses ApprovedRevs or FlaggedRevs, use that. Once the edit is approved, its reverted tag update is sent to the job queue. I'm not sure if Extension:Moderation would require some special treatment as well. ** If the wiki uses patrolling, use that. Users with `autopatrol` right have their reverted edit updates enqueued right away, while others have to wait for someone to patrol their edit. ** **Pros**: It would solve most issues. I think. ** **Cons**: A bit complicated to implement and requiring some additional coordination with extensions. Also: wikis that use patrolling, but not really (i.e. many changes never get patrolled) may be a bit confused by this feature. Anyway, even if the community completely ignores patrolling, this would behave like mitigation #1, which is not terrible actually. # Per suggestion from @DannyS712: we could allow the tag to be removed manually (and perhaps added manually in case it was accidentally removed incorrectly). ** Maybe we could allow the modification of all software tags by users with a special user right? This can currently be done only by the system administrator manually. That is beyond the scope of this task, though. ** **Pros:** This would allow admins to correct mistakes made by the software. Any kind of abuse could be mitigated manually. ** **Cons:** Would require custom handling in the ChangeTags class to allow for this with a system tag. This would also be quite annoying to admins if it was to be done routinely. Maybe we could keep it as a last resort that should only be used in rare cases? # **Or…** completely rethink how edits, reverts and page history works. Make it more like Git, less like a one-dimensional timeline. ** **Pros**: It would solve everything. ** **Cons**: This is basically a rewrite of huge parts of MediaWiki. Extremely hard (or even impossible), but I'm including this here to show that the reverted edits feature is tough to implement properly due to the way MediaWiki was designed. I would personally go with #3 and #4. They aren't the easiest, but I think they should provide minimal safeguards for the feature. This will also require considerable development time, so I'll probably have to reschedule my internship a bit. Any comments or suggestions on the topic are very welcome.

The design for the reverted edits feature can be found in {T254074}. It isn't merged yet, so there's still time to change a few things. When discussing the feature with @kostajh and @Catrope, we found that there are quite a few opportunities for abusing the system by vandals. === What can go wrong? //This comes from a person who has spent quite a lot of time fighting really nasty and desperate vandals. It may a bit pessimistic.// # A vandal can undo a large amount of edits, potentially even entire pages' history using the undoafter= parameter. That would be rolled back later by a moderator, but the reverted tag is permanent and the entire history would be "reverted". This would render the feature utterly useless. There is also no way for an admin to remove these tags, they are software tags. # A vandal can do //false undos//: first, start a large undo using the undoafter= param and then instead of saving, copy the top revision's content to the edit field, fix a comma and save the edit. Effectively this edit was legitimate (fixing a comma), but it was marked as an undo reverting a huge amount of edits. This is bad. # Someone doing a personal //vendetta// against a certain user can willfully undo (or false undo) their edits on many pages, even intermediate edits (undo allows that). That would make the targeted user have lots of their edits marked as //reverted//. Don't laugh, even people on Wikimedia wikis do childish stuff like this all the time. I **really** would not want this feature to become a new playground for immature editors. That would be very sad. # Not only undos can be exploited (though they are easiest), rollbacks and manual reverts leave a permanent record as well. === Why is this bad? When vandals can influence the feature heavily, it stops being useful to anyone and the communities will just give up on it. However, if the feature is only mildly abused, the communities may be tempted to use it in many areas (like hiding reverted edits in page histories and on RC, counting only non-reverted edits of users when determining their eligibility for certain user rights etc.) – in such a case abuse would compromise it and potentially lead to conflicts in the community. IMO we should only introduce it if the are sensible safeguards in place. === Possible mitigations Here I list some ideas on how to fix it, not necessarily ideas that I'd support fully :) # Allow only users with a certain user right to set the reverted tag. ** **Pros**: It would certainly limit the abuse to a minimum. ** **Cons**: This would make the reverted tag a bit inconsistent – legitimate reverts made by non-moderators would not apply the reverted tag, which seems a bit odd. It would also make writing a maintenance script for populating the reverted tag on old edits (see: T258921) close to impossible, as it would have to figure out what user rights people had in the past based on the logs. That would be a mess. # Apply the reverted tag only on relatively shallow reverts, let's say 8 edits were reverted at most. If the revert is deeper, nothing would be marked as //reverted//. The maximum depth can be configurable. ** We could even limit this to 1 edit, to cover only the most common case of reverting. That does seem very incomplete, though. ** **Pros**: This would limit how much damage can a vandal do while covering most legitimate use cases. ** **Cons**: It would be inconsistent with what EditResult says to extensions, as it doesn't have such a mechanism. It would also not solve the problem entirely, just limit the speed at which a vandal can do the damage. # Do not mark undos where the user has applied additional changes over it as reverts. Count these as regular edits. Another possibility is an additional flag in EditResult saying "this is an undo, but the user then applied some more changes and we are not sure if it's a legit undo or not", though this would make it quite confusing to extension developers, I think. ** **Pros**: It would solve issue no. 2. ** **Cons**: This will require some creative hacking in EditPage. That will be fun. # Apply the reverted tag only after the edit was somehow approved. Core could provide a special hook for cancelling job queue submission. Extensions would be responsible for re-enqueueing the job once the edit is "approved". ** If the wiki uses ApprovedRevs or FlaggedRevs, use that. Once the edit is approved, its reverted tag update is sent to the job queue. I'm not sure if Extension:Moderation would require some special treatment as well. ** If the wiki uses patrolling, use that. Users with `autopatrol` right have their reverted edit updates enqueued right away, while others have to wait for someone to patrol their edit. ** **Pros**: It would solve most issues. I think. ** **Cons**: A bit complicated to implement and requiring some additional coordination with extensions. Also: wikis that use patrolling, but not really (i.e. many changes never get patrolled) may be a bit confused by this feature. Anyway, even if the community completely ignores patrolling, this would behave like mitigation #1, which is not terrible actually. # Per suggestion from @DannyS712: we could allow the tag to be removed manually (and perhaps added manually in case it was accidentally removed incorrectly). ** Maybe we could allow the modification of all software tags by users with a special user right? This can currently be done only by the system administrator manually. That is beyond the scope of this task, though. ** **Pros:** This would allow admins to correct mistakes made by the software. Any kind of abuse could be mitigated manually. ** **Cons:** Would require custom handling in the ChangeTags class to allow for this with a system tag. This would also be quite annoying to admins if it was to be done routinely. Maybe we could keep it as a last resort that should only be used in rare cases? # **Or…** completely rethink how edits, reverts and page history works. Make it more like Git, less like a one-dimensional timeline. ** **Pros**: It would solve everything. ** **Cons**: This is basically a rewrite of huge parts of MediaWiki. Extremely hard (or even impossible), but I'm including this here to show that the reverted edits feature is tough to implement properly due to the way MediaWiki was designed. I would personally go with #3 and #4. They aren't the easiest, but I think they should provide minimal safeguards for the feature. This will also require considerable development time, so I'll probably have to reschedule my internship a bit. Any comments or suggestions on the topic are very welcome.