I propose VolumeLimitedEdits as a simple - though partial - solution to WikiSpam and EditWars.
If each change to a page is limited to a certain size, EditWars and WikiSpam could be reduced, because
- it is no longer possible to delete the full page at once and
- replacement of a page with spam, or even addition of large amounts at once if prevented.
The size of the change should be measured as follows:
- The size of a change would be measured by the size of the corresponding QuickDiff, not the size of the page itself.
- Consecutive edits by the same IP should be grouped together, as it is done already and counted together. If the cumulative size exceeds the threshold, the last edit is rejected.
This policy naturally encourages many small changes instead on large ones, which I think is a
GoodThing. Of course, if a large page is to be refactored, this refactoring has to be done in small steps too. And to do really large changes, at least two coordinated
WikiZen are needed.
I propose a limiting diff-size of below 2000 bytes (which is rather large considering most edits). Another possibility would be to use a fraction of the page being modified, e.g. 20%. Or to use the higher of the two values.
-- GunnarZarncke
I agree on limits for adding not removing. Wiki is getting out of shape. And if one wants to add more information they can always add a hyperlink to external resource. Alas, that is precisely what the spammers are doing. A hyperlink would not hurt anybody. Especially when it's easier to delete it than add. Spammers are coming with tons of massive links+text.
The whole idea would need more thought. There would be little effect on EditWars, which are typically over quite small changes. [counterpoints merged below]
This proposal will not solve all problems, but it has nearly no disadvantages. The disadvantages, that remain - concerning huge refactoring - are quite in the spirit of this wiki: I think large refactorings should be done in many small steps (IncrementalDevelopment. IterativeDevelopment), possibly confirmed each by a fellow WikiZen (PairProgramming). -- GunnarZarncke
Counterpoints:
- There would be the undesired effect of making the restoration of sizable, but important, pages difficult, following vandalism. It's desirable that pages such as RecentChanges and TextFormattingRules can be restored easily.
- Spammers could target more pages, but with fewer links in each. And removing the spam is easier if fewer pages are spammed. The spammers already target as many pages as they can. Currently, they rarely spam more than a few dozen pages at a time on this wiki.
- Spammers have been known to use more than one ip address, which would mean they could add more than a restorer could delete using one ip address.
- I estimate 90% of pages involved in EditWars are small pages thought to be off-topic or pages (mainly small, some large) to which only small changes have been made. Also, parties in such wars are already using multiple edits under different ip addresses.
- Spammers would soon adapt - after all, they are (one assumes) paid for what they do. Also, surely time should be allowed for DelayedIndexing to "take".
- If just a single character in a paragraph is changed, the quickDiff will show the old and new versions of the paragraph, easily using 1000 bytes to do so. Hence 2000 bytes would be an absurdly small limit, and would often prevent correction of the spelling errors discovered by Wiki's SpellChecker. A count of the actual number of characters changed would make for sense.
I see here some misunderstanding of my proposal.
- The diff size would be very large for large blocks of spam. Especially if they are replacing the page (remove all+add much).
- This size would be equally large for a vandalizing change as for its restoration, therefore creating no problems here (if you can destroy it, I can repair it). [Not when more than one ip used.]
- I agree, that EditWars are often about a small change, which could not be cured with this proposal. But many EditWars are about the complete existence of a page causing huge deletions and restorations (See DeleteWar?). And these wars, could be cured. The smaller wars are less important, as they still allow for sensible changes beside the war, which leaves the page as a whole intact.
- Yes, a smart spammer could work around this proposal, this is undisputed. But the majority of spammers could be kept out. And their impact could be diminished in any case.
It's simpler and more logical to use a more specific approach, such as WikiSpamBlocker.
It seems, that WikiSpamBlocker is susceptible to the same arguments as given above: More pages with fewer links, using multiple IPs each adding one link (or a few), having much more time. But those attacks simply don't seem to occur (yet?). On the other hand, I do not see a reason, why both approaches could not be combined. Both are quite simple.
Zombie-machine spamming is a tough cookie to crack because there is no practical way to isolate them as being one person or organization. We may have to think about solutions that don't involve tracing activities to any one user or spammer. In other words, pretend that the spam will come from random sources. --top
See WikiWikiSuggestionsMedium, EditsRequireKarma
CategoryWikiMaintenance CategoryWikiEditing
Volume Limited Edits