WikiIndex talk:Spam control policy

Level 3.5 - CAPTCHA

I've just been experiencing this over at WP. Not fun, but perhaps a reasonable compromise. But I'd rather not be forced through a whole additional screen; I might rather be served a CAPTCHA on every edit page, that I can fill in with the edit if I know I will need it. If I forget, then it can give me a nag screen. And I notice on this wiki that mostly the problem is whole page-fulls of link spam. Which makes me think, what about a whole additional CAPTCHA nag screen for each link? And then, what about "first link free"? Having the ability to fine tune such parameters might make it fit the needs of each wiki better.--69.87.193.16 17:44, 21 February 2007 (PST)

I have installed reCAPTCHA on my site, and have not suffered any vandalism since. -- Carl McBride 09:46, 30 August 2007 (EDT)

I believe reCaptcha has been cracked. Many sites that are using it are reporting increasing spam. Maybe FancyCaptcha would be a better option? (I've seen discussion of this on the mwusers.com forums) Gwsuperfan 23:38, 4 July 2011 (PDT)

Level 4 - Login to Edit

John, thanks for your efforts to organize this. My feeling is that although spam is an ongoing issue, it is under control here. The half life is short, and it seems like we are catching just about all of it, quite quickly. It is good to get this education about what mechanisms are currently in place, and what the potential tools are for improvement. (I am doing a fair fraction of the initial spam blanking. May have to eventually have more of an official role. But it is good to try to have a system that random anons can be a helpful part of.)

I urge that Level 4 - Login to Edit be resisted as long as we possibly can. This is a wiki where that would be especially undesirable, since I presume our reference standard-issue contributor would be creating one article here, about a specific wiki that they are interested and/or involved with. Any impediment to open anon editing would seriously discourage casual one-off contributions. (Casual involvement can grow more serious over time. But the higher the barrier to initial involvement, the smaller the number that will ever bother.) *** A theoretical, technical solution would be invisibly-moderated anon edits. Anyone could make any changes, as now, but if you are not logged in, all of your edits would only be visible to you, until an admin (could be just any logged-in user) approves them. Such a concept would be way too much development effort to implement just for wikiindex, I assume, but of such general utility that it seems worth pursuing, and maybe it has already been done somewhere? Seems like it would work fine for ordinary articles, esp with our low traffic here. (If time passes before the edits are approved, if the article has been changed by someone else in the meantime, the edits would have to be manually re-applied, or dumped.) Would be a problem for the meta-articles, policy etc, where you could easily get edit conflicts; so for such articles, maybe instead the articles could be locked to anon edits, but the associated talk pages open.--69.87.204.63 11:49, 19 February 2007 (PST)

I agree that we should hold off as long as possible on Level 4. I have been tweaking the controls (Level 1) over the last few days to improve the initial blocking and restarted the local list (Level 3) and checked that the WikiMedia list (Level 2) is working like it should. My experience in dealing with spam is that once it reaches a certain level people dealing with it start to burn out and my goal is not to ever reach that level. I think I prefer the Level 4 controls to moderating all edits, that would be a pain. Thanks for your input and spam killing efforts. John 13:00, 19 February 2007 (PST)

I like your "technical solution". I think it could be useful at all kinds of wiki, not just WikiIndex. So I made sure it was described at the wiki for that sort of thing: WikiFeatures:StagedCommits. (You might be interested in other anti-spam ideas at WikiFeatures:DelayedCommits and WikiFeatures:RejectDuplicate).

Please edit those pages if I've missed some crucial implementation detail.

--DavidCary 20:24, 19 February 2007 (PST)

Very interested to learn about "Wiki Features wiki"; I contributed my 2 cents to the article, and hope to explore further -- makes good complement to WikiIndex! But surprised to see no copyright clues on the edit page, at all, nor any apparent links to any such. (Also, had some problems with edits timing out. And just everything being different, not being MediaWiki...)--69.87.193.16 17:38, 21 February 2007 (PST)

Alas, WikiFeatures has moved to a new host, breaking all those links. I wish WikiFeatures were on the intermap -- then we could fix the hostname in one place, the intermap, and all those links would start working again. How do I get WikiFeatures on the WikiIndex intermap? --DavidCary 14:57, 1 February 2011 (PST)

+1 to adding WikiFeatures to the intermap. I've manually updated the URLs above --finnw 14:51, 29 January 2012 (PST)

Delayed anon page deletion

To lessen the load on admins, it would be an interesting experiment to allow even anons to delete pages. Since this would be too much power for non-loggedin users, what if blanking a page, or some other special minimal contents, started a page-delete count-down clock, say about 24 hrs, after which the page would auto-delete. If anyone did any edits to the page in the meantime, the clock would reset -- or go away, if the page were given real contents.--69.87.199.193 12:51, 22 February 2007 (PST)

I don't like the idea of this. Over on Wikipedia, there are delitionists that flood large numbers of deletion requests against specific areas of interest they dislike, in an attempt to get some of those delition requests past the constructive editors who are attempting to fix up content. If WikiIndex adopted a system, like the one you propose, a vandal (or even a bot) could flag a large percentage of WikiIndex content for deletion and cause chaos. David Shepheard (talk) 08:36, 18 February 2013 (PST)

What happens if spam slips through

Sysops can block the IP address of spammers, but is there any way that a user page could be marked as a suspected spammer, in order to get a sysop to come and check the account out? David Shepheard 04:30, 27 October 2010 (PDT)

The answer is found in the last section on the project page - what happens if spam slips through the automated systems - basically just copy and paste {{spammer}} onto their user page and this will create an automated warning banner. 78.32.143.113 01:13, 21 December 2011 (PST)

spam - do you 'undo' or 'rollback' on existing valid articles

An interesting consideration . . . looking at some edit histories of articles I update, I notice that when spam has been discovered, the edit gets reverted by using the 'undo' function. This can have a problem, in that the spam is still there in the article (by using either the 'diff' or the timestamp). This may not be a big problem to generic trivial spam, but for more contentious spam (such as illegal activities, child porn images, etc) this can be a real problem. So can I suggest that when spam is added to existing articles, the admins use the 'rollback' function instead - as this then permanently deletes the offending spam edit, and wont then show up in the articles edit history. --Hoof Hearted • talk2HH 01:39, 26 January 2012 (PST)

I don't understand this. Let me try to reflect back what I think you are saying. If you use rollback, then the spam is removed from the history of the page? Best, MarkDilley

Correct. Rollback completely deletes any 'offending' edit such as spam. For people who are 'wiki savvy', an 'undo' edit will still leave any spam in its edit history, and could still potentially be indexed in a search engine. But rollback is like 'un-inventing the wheel' - all trace is gone. It was the lack of rollback which caused Goatopedia to be shut down - a spammer posted images of child porn, but the site admins just 'undone' the offending edit, and then CEOP (a specialist division of the UKs Met Police) repeatedly found damming image, and threatened the site owner. Had the rollback function been used, Goatopedia would still be up and running. Rollback should seriously be implemented by all WikiIndex admins - Wikipedia even allow non-admins to use rollback. Hope I've made this a little clearer :) --Hoof Hearted • talk2HH 10:38, 27 January 2012 (PST)

hmm, I am pretty 'wiki savvy' and I just rolled back your edit, yet I see it in the history of the page... clearly not understanding this function as you are. Help? ~~ MarkDilley

Now I'm confused . . . rollback here on WikiIndex seems to work differently compared to English Wikipedia. Further digging, and it looks like WP used an extension called Oversight . . . but this Oversite extension was subsequently included in MediaWiki version 1.16.0. WikiIndex currently has v.1.17.0, so should include this . . . it looks like its plain english terminology is called 'HideRevision' . . . however, looking at the specific code of MW software installed here on WikiIndex, it looks different to Wikipedia software. Maybe Wikipedia uses specific and customised Wikimedia Foundation (WMF) software, whereas all other non-WMF wikis use a different software compilation, and maybe not all extensions are available to non-WMF users. :/ Anyway, as and Admin, do you see 'HideRevision' anywhere? Best, --Hoof Hearted • talk2HH 13:43, 29 January 2012 (PST)

2015 discussion

importet from Marks talk page:

---

Koavf, it seems odd to me as well. Why do we require approval for an account in order to edit if anonymous can just edit anyway? Why not just allow anyone to create an account and edit if we are going to let ips edit? One of the major forms of spam on mediawiki installations follows the pattern 1. create account, 2. upload picture, 3. edit page with picture and lots of spam, 4. go away forever. The ConfirmAccount extension puts a large dent into that particular spam strategy. A second majore form of spam comes from anonymous editing from ips. We require ip edits to pass a simple captcha to cut down on spam from them. Accounts don't have to fill in the captcha. Does that explanation make sense? BrandonCsSanders (talk) 22:21, 21 May 2015 (PDT)

In order to save this edit I had to answer the question: "What is the name of this wiki?" -- Brandon as 76.27.247.138 22:22, 21 May 2015 (PDT)

Spam filtering Nice. So the spam that we have recently received was from a human that copy and pasted it onto the wiki rather than a bot just drive-by spamming? Koavf (talk) 22:50, 21 May 2015 (PDT)

Probably automated by a human who answered the captcha once for their script. The captcha is really really simple and never changes. -- BrandonCsSanders (talk) 23:05, 21 May 2015 (PDT)

So, as it was to be expected, Mark did not make any useful input to this question. I wonder why You Koavf started this question at this deserted space wich has a long history of unanswered questions? Why not at Category talk:Active administrators of this wiki?

You can stop now It's only been a few hours--get over it. I posted here because Mark knows something about the backend of how the site works. If I just wanted to get an admin's attention, I could have done it myself as I am an admin here. You can stop posting here now unless you have something useful to say. Koavf (talk) 06:07, 22 May 2015 (PDT)

┌─────────────────────────────────┘
See WikiIndex:Community_portal/News#01_February_2014 for the related discussion. In short, many spamming technologies change over time. Once upon a time spam was crazy, but my filter was powerful enough to filter most of them out. Then spammers decided to stop. They spammed with usernames instead, which again got filtered. Then spammers decided to simply flood accounts with random names. This, however, could not be prevented. That made some admins stressed, so Confirm Account was installed.

However, things change. Spammers no longer try for accounts. They simply started spamming without account instead. I would develop some filters against this, but I see no easy algorithm to identify such edits. --YiFei | talk 05:50, 24 May 2015 (PDT)