Legacy:Wiki Protection - Unreal Wiki

# Legacy:Wiki Protection

### From Unreal Wiki, The Unreal Engine Documentation Site

Wiki runs on a MeatBall:SoftSecurity principle. The doors may be wide open, but everyone's watching you walk in. All changes are saved, so persistent damage is impossible. See also the Wiki FAQ.

## Spotting Damage

Simply this: Keep an occasional eye on Recent Changes. Most Wiki regulars like to see what other people have been writing lately anyway.

## Fixing Damage

If you notice that someone has damaged a page:

1. Go to that page and click the "View other revisions" link.
2. Find the most recent version of that page that is undamaged.
3. Once you are viewing that version, click the "Edit" link.
4. Save the page. This will replace the damaged version.

If you notice that someone has damaged an image:

1. Remember the image's name.
2. Go to the Image Uploader, look for the damaged image and click the "Revisions" link.
3. Find the most recent version of the image that is undamaged and save it on your computer.
4. Go back to the Image Uploader and select the saved image for upload. Make sure you select the damage image in the "Replacing the following image" drop-down list.
5. Upload the page. This will replace the damaged version.

## Site Lock

In the unlikely event of ongoing damage to the site, admins can lock the entire Wiki. Trusted contributers have the option to do a one-way emergency lock of the Wiki; the admins have to unlock the page after it has been emergency-locked. If you would like the ability to lock the site in case of emergency, email tarquin.

1. Enter the script URL in your browser address bar and load it.
2. Notify a Wiki Admin that you've locked the site.
3. No edits will be possible until an admin unlocks the site.

## Persistent Attacks

So far we've had just a few instances of people adding crud to the Wiki, pages have been reverted quickly and whoever it was hasn't tried again. If we get repeat attacks, notify a Wiki Admin, and the attacker's IP will be banned from making edits.

Experience tells that even the most persistent and notorious troublemakers in an online community (forum, user comment system, Wiki, whatever else) lose interest after a while; the sooner they realize that their actions are vain, the sooner they leave. Best is simply not to credit them with any more than the minimum required amount of attention and to quietly revert their mess.

### Spam Posting

A number of wikis have recently been victims of spammers posting links to their sites. Because wikis are so heavily interlinked, they are attractive to spammers seeking to raise their ranking with Google. We have been spammed repeatedly, so when it happens again:

1. Fix the damage. It does not matter that the links are still in the old revisions of the page: our robots.txt file prevents search engine spiders from looking at those.
2. If the spammer persists, ask an admin to block the IP. This might not be very useful, as spammers tend to have many IPs at their disposal.
3. To hit the spammer where it hurts, use our Chongqing Page to fight back.

## Discussion

Mychaeel: I remember one guy spamming old ModSquad's user comment system with useless crud to the point where it became unusable for everybody else. The problem there, though, was that the ModSquad administrators were extremely slow at cleaning up; that guy only went on with his vandalism because he (or she) saw that it had an actual, lasting effect.

EntropicLqd: One thing that might be worth considering is preventing a completely blank page from being saved. Pages that are to be deleted will always be tagged with a Category:Legacy Delete Me tag and an explanation.

ZxAnPhOrIaN: Or with a drastic amount of characters deleted.

Mychaeel: Well... all such purely technical measures are bound to be limited in effectiveness. My recent edit of Offline Wiki was massive, yet legitimate. On the other hand it's very easy to mess up a page without deleting a huge amount of text or the entire page.

CH3Z: I was wondering if it would be possible to have the Wiki automatically allow saves but imediately restore any pages that were changed by a certain amount, or in a certain way. And somehow bring the change to someone's attention (maybe the Wiki could put a code in this summary. Then when someone clears say 40% or more of a page it would be approved by (or seconded by any other user than the the one who made the changes) and restored again to show the changes. That might be science fiction, or imossible, or not worth the effort to make the change to the the Wiki, it might be too big of an inconvenience all the way around. But it might lead other ideas so i present it anyway. be kind =P

CH3Z: and with Mych's last comment that might just say it all about my comment.
It might be best to just quickly and quietely restore behind the would be hackers. They will see there fine work dissapear and not get any validating response from anyone and get bored with doing it.

Mychaeel: I think the "smart firewall" we have here (being all the well-meaning Wikizens) is the best and most effective protection we could possibly have. Granted, it's a bit annoying when it has to be invoked, but then again it's our convenience that's at stake; I'd rather clean up manually after one or two wannabe haxx0rz once every couple of weeks than go through a ton of technical security measures every time I want to do anything on the Wiki. At least in average it is more effort to vandalize a Wiki page than to restore it, so it really doesn't pay off for the vandals.

~dUc0N: You'd have to be some wannabe to think attacking a wiki is cracking. Even bigger wannabe to think it's hacking ;)

EntropicLqd: The above is pretty fair comment and I don't disagree with it - which is why my suggested change was so limited in scope. Just thought it might save other people a bit of work (since I always seem to miss these attacks). Special case coding sucks.

ZxAnPhOrIaN: Making those security measures is "Bushlike"

Mychaeel: "We must not live in fear, for if we do then the vandals have already won." ;-)

CH3Z: Amen.

ZxAnPhOrIaN: :) :tup:

T1: The editing page says "kids". I find that insulting because most of the people "hacking" the wiki are probably older than me by one or two years (I'm 14). Though actually they're still kids, and I'm probably the only person below 17 years of age that's been productive on this wiki. So I guess it's true.

Foxpaw: I don't think it means kids as in minors, I think it means kids as in, "script kiddies," which does not neccessarily imply a certain age.

Graphik: Those who would 'hack' the Wiki are either kids or are behaving like such, so I think it's a justly condecending tone, T1.

T1: Yah, y'all are probably right, because usually it's some 15-16 year old person doing to feel like they're cool/l33t or something. And if they're kids that's implying that they're uncool.

Fearless: I wouldn't take it personally T1. I think it's safe to say that adults have their fair share of idiots too. Anyway, about documents, I think it would be very useful to have a character count being displayed somewhere to see if anything has been removed.

Mychaeel: When I was writing "kids" there, I indeed meant it in terms of "script kiddies," not to devaluate young people – I know from personal experience that age isn't an indicator for somebody's maturity or productivity. (If you take offense, feel free to exchange it for a more neutral term.) However, I suppose that most script kiddies are indeed young people – and sometimes, a script kiddy actually grows to become a mature hacker (in the actual, positive meaning of that term), but those cases are rare and there's a lot of real work between being a "skript kiddy" and a "mature hacker."

EntropicLqd: Note to remind one of the admins to ban the IP: 62.37.193.96. No username or password here at work.

### Images

Tarquin: I think we have a problem with images. There's a lot of spammy images, and those we can go through and delete. But I've also seen people replace good images with crud. Because there's no public log of image uploads, it's hard to spot when this happens. I think the simplest thing to do for now would be to have a web page or a wiki page that displays the image upload activity log (knowing Mych, I'm sure it exists on the server :). In the longer term, I think images should be brought into the wiki page structure, like on Wikipedia: each image should have its own image description page, and changes to images should appear on Recent Changes.

  Mychaeel: Actually, I've been pondering writing my own wiki engine for a while. If I do, it'll definitely allow all sorts of resources (including images and attachments) to be added and versioned just like wiki pages (actually, pages will be just one other kind of resource). I'm thinking in terms of a Subversion backend, but that's all still very vague.

MythOpus: Agreed :)

Switch`: The images page ranks pretty high in google. Maybe if it was hidden from search bots there wouldn't be so many off-topic images. Putting a big red "offtopic images will be deleted!" warning next to upload button also could help.

Mychaeel: I don't believe in appealing to people's common sense anymore (anybody reading the stuff on the image uploader main page should immediately realize how futile unwanted uploads are, but as you can see on Recent Changes, there are almost a dozen idiots a day who still try it). The `robots.txt` idea, however, is a good one – I never realized that our image uploader ranked highly in Google. (Which search terms do people use to get there?) I've now excluded the image uploader pages and all images from being indexed.

Switch`: On my box `wiki image` - 2nd place, `image uploader` - 7th.

Tarquin: That reminds me, I still have my work on a wiki engine somewhere... :) I was going to make the database side take plug-ins, so you could have the current UseMod textfile database system, or something more advanced.

Wormbo: This page has been locked due to repeated spamming. Please contact a Wiki Admin if you want to make changes.

##### Views

- Legacy
- Discussion
- Current revision

##### Search