Just a page for general OrbiterWiki discussions (for keeping the Talk:Main Page related to the main page).
Server move and stuff
- OrbiterWiki has moved servers. Please report any and all issues you observe, preferably by email.
- I am planning to upgrade to the most recent MediaWiki version shortly. Will notify when that's done.
- I'd like to try out the new default MediaWiki skin, which is the skin Wikipedia uses now. Any objections should be expressed here.
- I'm still hoping to switch case-insensitivity for titles back on. One day...
--RaMan 12:50, 16 February 2011 (UTC)
- Updated to MediaWiki v1.16.2; a couple of extensions got upgraded too. --RaMan 03:54, 20 February 2011 (UTC)
- Enabled Vector skin. Old skin vs New skin. Hope you like! --RaMan 18:00, 20 February 2011 (UTC)
Loose gun policy for bans from a special subnet
I just noticed some more similarities among the recent spambot activity here: Ten spambot accounts with two name patterns since December came from 188.8.131.52/16, one half of the Internet provider "TELEKOM MALAYSIA BERHAD" (There is no spam from the other /16 of this provider). I suspect that we have a single source behind varying IP addresses there. Since this still means a 640/650 chance that somebody is not a spammer from this network, I would propose the following guideline for next 3 months: All new user accounts that are registered from this network with the pattern
<Letter> + <Random First Name> + <Random Common Family Name> + <Letter>
should be banned instantly and for infinite time. IP-Bans should be avoided, since a /16 network of DHCP addresses seems like a poor target for IP-bans. Better target the business model and prevent search engine optimization. I don't see any reason to use this user name pattern here anyway. Another pattern had been the "-Steamer" type, but I don't think this alone is a good way to identify a spammer. If it comes from the same subnet though, it would be with very high certainty a spammer. We have no legal edits from the whole /16 subnet (Booo!).
Urwumpe 18:23, 30 January 2012 (UTC)
PS: Yes, that means that new users should better not use this name pattern, if they would like to prevent getting under general suspicion here. It is not nice, but since 2 hours of reaction time is enough to infect a few thousand PCs with malware, a fair price IMHO. "JohnSmith" would still be legal. "GJohnSmithj" would be dubious.
- I suppose this sounds reasonable. No problem with this. Good effort noticing this! RaMan 13:34, 2 February 2012 (UTC)
About another special customer here, can I suggest being a tiny bit more unfriendly to IP addresses belong to hostnoc.net? They are getting a bit annoying and banning them for one year would be long enough until things escalated far enough to remove these guys from the IP range. The current main ranges for them are 184.108.40.206/16, 220.127.116.11/17 and 18.104.22.168/20. But there seem to be a lot more, judging the whois records. The lack of any company presentation or new customer registration is a bit strange there. Urwumpe 07:07, 10 March 2012 (UTC)
- OK, let’s do it. RaMan 09:50, 10 March 2012 (UTC)
Increase Autoblock time
I just noticed that the automatic IP block when blocking a registered user and his IP is just 24 hours, which explains why it was so ineffective against spambots in the past. I would suggest increasing this timespan to a week. That is still pretty short for our cases, and should also work against retries from dedicated hosts. Urwumpe 17:52, 24 February 2012 (UTC)
- OK, I think I've changed it now - let me know if this doesn't seem to have effect. By the way, do you want to receive an email every time someone edits anything at all? That's a lot of emails, but nothing a filter rule can't fix :) --RaMan 22:07, 24 February 2012 (UTC)
- The RSS feed for Recent Changes does the job well for me. :D Urwumpe 23:59, 24 February 2012 (UTC)
Filter for uploads
Would it be possible to have a filter for the uploads, so that all files like "Epsom salt 9999.jpg" would be refused and logged? I don't yet know why such images are included by the spambots, but I fear the worst, if they could be droppers. Not having them uploaded in first place, could be better than erasing the files. Urwumpe 12:38, 10 March 2012 (UTC)
- Seems to work. Full documentation here, feel free to add new rules. The current configuration includes the rules from this list. RaMan 10:38, 11 March 2012 (UTC)
- Damn, that tool sure looks powerful. Should help getting a few spam bots out of business here, luckily we have a very limited dictionary. Urwumpe 12:03, 11 March 2012 (UTC)
Filter "https?://" in article name?
Would it be possible to simply forbid creating pages with "http://" in them, like by the regular expression "https?://"? We don't really have them except as spam, why delete them if it is impossible to create them in first place... Urwumpe 15:09, 13 July 2012 (UTC)
- Good idea, should be blocked now. Also, I suggest we start blocking first-time spammer IPs for 1 month initially, and if we see a second offence we block it for 6 months straight away (earlier blocks are displayed when you try to block the IP). Given the low volume of real edits we get, chances of blocking a legitimate one are really low I reckon. --RaMan 15:31, 13 July 2012 (UTC)
- Sadly yes, but that is also a problem with the advertisement department... I should be selling the wiki more on O-F. :S Urwumpe 15:35, 13 July 2012 (UTC)
No idea why we've started getting so much spam after upgrading to v1.19.2 - all the measures seem to be working as before. I think we need a new plan. How about this:
- Disable editing for new users until they've confirmed their email (but still allow edits from IP)
- Install FlaggedRevs
- Create a "known good users" group
- Allow known good users to edit directly and confirm pending edits
- All edits by unknown users will be "pending edits", not visible until moderated. If the edit is not spam, we immediately mark the user as "known good user".
- From now on, new users have the same rights as anonymous users. This means they'll be asked to solve the captcha to do most things. They will no longer be bugged after a certain number of days + edits. An alternative is to confirm the email address, which will stop the captchas straight away. --RaMan (talk) 12:25, 26 October 2012 (UTC)