taint.org: Justin Mason’s Weblog

Here’s a new trick used by the web spammers — attachments on a Moin Moin wiki. The taint.org/wk RecentChanges list illustrates it well:

2007-05-07  set bookmark
[UPDATED]       UserPreferences         04:17   Info    ?StepStep [1-21]        
  #01 Upload of attachment ‘big-cocks.html’.
  #02 Upload of attachment ‘big-cock.html’.
  #03 Upload of attachment ‘big-boobs.html’.
  #04 Upload of attachment ‘big-ass.html’.
  #05 Upload of attachment ‘bdsm.html’.
  #06 Upload of attachment ‘bbw.html’.
  #07 Upload of attachment ‘bang-bros.html’.
  #08 Upload of attachment ‘bangbros.html’.
  #09 Upload of attachment ‘baby.html’.
  #10 Upload of attachment ‘asian-porn.html’.
  #11 Upload of attachment ‘asian-girls.html’.
  #12 Upload of attachment ‘anime-porn.html’.
  #13 Upload of attachment ‘anime-girls.html’.
  #14 Upload of attachment ‘angelina-jolie.html ‘.
  #15 Upload of attachment ‘amature.html’.
  #16 Upload of attachment ‘amatuer.html’.
  #17 Upload of attachment ‘adult-videos.html’.
  #18 Upload of attachment ‘adult-stories.html’ .
  #19 Upload of attachment ‘adult-games.html’.
  #20 Upload of attachment ‘69.html’.
  #21 Upload of attachment ‘3d.html’.

Great. Lots of spam. This first started appearing on Feb 27 2007, in a multi-upload attack on a single page (”FindPage”), from IP address 212.26.129.162; then reoccurred on Apr 27 and May 7 from the (insecure open proxy) proxy.drevlanka.ru.

Annoyingly my “subscribe to wiki changes” patch doesn’t catch this – these aren’t gatewayed through as “changes” via mail for review. I need to fix that in my copious free time. :(

Also, the RecentChanges RSS feed doesn’t list them, although the HTML form does.

So unfortunately, the only way I can see to block this is either to review by visiting the RecentChanges page in a web browser regularly (how retro!), and delete them retrospectively, or simply to turn off attachments entirely – which is what I’ve done, by editing “wikiconfig.py” and adding:

    actions_excluded = ['AttachFile']

It looks like quite a few other wikis around the web are running into the issue too :(

Tags: anti-spam, attachments, moin, moin-moin, spam, web, wiki

A useful Moin Moin anti-spam tip, via Upayavira at the ASF: adding ACLs to pages so that only certain users can edit them. This is an easy way to interfere with the wiki spammers who get past the existing (quite good) Moin Moin anti-spam subsystems. They tend to aim for the common Wiki pages, such as WikiSandBox, RecentChanges, and FrontPage, so if you make those pages uneditable, that’ll cause them more trouble — and hopefully cause them to move on to easier targets, instead of defacing your wiki. Here’s how to do it (at least for Moin Moin >= 1.5.1).

Open a shell on the machine where the Moin Moin software is installed. Edit your “wikiconfig.py” file (in my case this is at /home/moinmoin/moin-1.5.1/share/moin/jmwiki/wikiconfig.py), and change the “acl_rights_before” line to read:

    acl_rights_before = u"JustinMason:read,write,delete,revert,admin"

Replace “JustinMason” with your wiki login name, of course.

Create an administrative group of trusted users. Do this by creating a page called “AdminGroup” containing

#acl All:read
These are the members of this group, who can edit certain restricted pages:
 * JustinMason

Now, for the sensitive pages (like FrontPage etc.), edit each one and add an access-control list line at the top of each page containing:

#acl AdminGroup:read,write All:read

That’s it. Users who are not in the AdminGroup will no longer be able to edit those pages. That should help… at least for a while ;)

Update: you should also use this in wikiconfig.py:

    acl_rights_default = u'Known:read,write,revert All:read'

This blocks non-logged-in users from writing to pages.

Tags: anti-spam, moin, moin-moin, web, web-spam, wiki, wiki-spam

This post on the Wikipedia/Seigenthaler spat at Corante.com contains this excellent comment from Wikipedia’s Jimmy Wales:

Imagine that we are designing a restaurant. This restuarant will serve steak. Because we are going to be serving steak, we will have steak knives for the customers. Because the customers will have steak knives, they might stab each other. Therefore, we conclude, we need to put each table into separate metal cages, to prevent the possibility of people stabbing each other.

What would such an approach do to our civil society? What does it do to human kindness, benevolence, and a positive sense of community?

When we reject this design for restaurants, and then when, inevitably, someone does get stabbed in a restaurant (it does happen), do we write long editorials to the papers complaining that “The steakhouse is inviting it by not only allowing irresponsible vandals to stab anyone they please, but by also providing the weapons”?

No, instead we acknowledge that the verb “to allow” does not apply in such a situation. A restaurant is not allowing something just because they haven”t taken measures to forcibly prevent it a priori. It is surely against the rules of the restaurant, and of course against the laws of society. Just. Like. Libel. If someone starts doing bad things in a restuarant, they are forcibly kicked out and, if it”s particularly bad, the law can be called. Just. Like. Wikipedia. I do not accept the spin that Wikipedia “allows anyone to write anything” just because we do not metaphysically prevent it by putting authors in cages.

Tags: social-software, steak-knives, web, wiki, wikipedia, workflow

Freevo: so I’m planning to build myself a PVR, of the home-built, running Linux with mythTV or Freevo, mini-ITX variety.

So far I’m still at the hardware planning stages, but the price looks good – around $455 (plus shipping) for a working, thoroughly hackable, silent, set-top PVR system.

(Silence is a key aim here — last thing I want is something noisy taking over the room. But silence typically seems to cost the dollars, once you get into Shuttle gear and the like.)

If anyone wants to follow along, or provide some tips — I’m going to track progress (very slowly) on this wiki page. Like all wiki pages, it’s editable — although you’ll need to create an account to edit pages there (sorry, anti-spam measure).

BTW, lately, there’s been a lot of talk about using a Mac mini as a media center. So I took a quick look — but wow, it’s pricey! $499 + $329 for an EyeTV 200 tuner? Dude, that’s over 800 dollars, not include shipping or sales tax. Given whatever extras turn out to be appropriate, I wouldn’t be surprised if it hits double the mini-ITX’s price.

Tags: freevo, itx, linux, mythtv, planning, price, pvr, silence, variety, wiki

Web: Almost every project and organisation has, at some stage, bemoaned having stale data on their website, and wished there was a better way to keep it up to date; or wished their FAQ was more complete; or wished they had the time to HTML-ize all their know-how and get it up there.

Well, here’s what we did in SpamAssassin to deal with this problem. (Seeing as I’ve talked about this three times in the past month, I’ll write it up here so I can just point at the URL next time!)

First off, we experimented with having the site checked into CVS, FAQ-o-matic, and the Python FAQ software (which was pretty good). All were OK, but very specific in format, using the traditional question-answer FAQ layout — that’s good for FAQs, but not so good for a lot of other stuff — and keeping it updated was still limited to a small group, therefore the info got stale again.

So we moved to a Wiki. Here’s my tips for Wiki-izing your website so that the end results are better than what went in.

Use good wiki software: unusable software will be a pain to use, and the info will still go stale. We used Moin Moin - http://moin.sourceforge.net/ - partly because I like Python (it’s nearly perl! ;), it can produce RSS, and it was pretty easy to install.

Don’t worry: people won’t vandalise it (much). It turns out that vandalism and people throwing up crappy info isn’t a serious problem at all. You should increase the barrier, in the following ways:

Require user accounts: set the security policy so that a user account must be set up before editing is possible. This means you won’t get wiki-spammed, and also has the side effect of imposing a pretty big barrier to casual vandals.

Send changes to a list: set all changes to be mailed to a mailing list as diffs. This is the most important tip. If you already have a mailing list with the knowledgeable part of the community on it, use that list — because they’re the ones who’ll be able to recognise if erroneous info is put up, and will be annoyed about this enough to bother fixing it. There’s a bonus side-effect of this; even if some people didn’t like the wiki to start with, they’ll eventually be needled into using it by wanting to fix stuff they perceive as wrong. And then they get sucked in ;)

Use diff for the mailed changes: Moin by default will only send out change messages saying ’something changed on this page!’. That’s not good enough, unfortunately — you want to mail out what the new text looks like, and highlight exactly where the change happened. Moin can do this nicely, with this patch, which adds a mail_commits_address, where all diffs on every page are sent, using the normal diff mechanism.

Ensure the wiki software can revert quickly: If someone does make a bad change, Moin supports one-click reversion of the page to what it was beforehand. That’s great for dealing with spam, or clueless vandalism.

Keep one or two static pages: If you’re worried about some script kiddie thinking that defacing a wiki makes them look cool, then keep one or two of the primary user-facing pages as static data. For example, take a look at the link-bar at the top of http://spamassassin.apache.org/ ; five of the ten links are to static pages, the other five are now wiki-ized. In particular, our front page and our downloads page are both static, but our docs are predominantly Wiki’d.

Publicize Mozex: most techie groups will have techie users, and we hate using browser text-boxes to edit text. Mozex — http://mozex.mozdev.org/ — saves the day here — it’s a godsend.

Shepherd new changes: in the early stages, you want one or two people who tidy up changes from Wiki newbies, as they go in. They need to keep it looking pretty, and perform Refactoring of stuff that could be laid out better or should become multiple pages. Eventually, others will get the hang of that (and do a much better job than you do ;).

That’s the lot. Most of these are to, essentially, migrate aspects of your already-existing and already-working community into this new outlet. In our experience, it’s worked really well — our Wiki is now the most reliable source of info about SpamAssassin, and is extensive and up-to-date.

Tags: faq, info, list, problem, python, software, time, use, web, website, wiki

Spam: Good Salon article on the new forms of spamming, such as Wiki and referrer-log spamming etc. Here’s a good quote:

‘The adult industry will likely be married to spam and its attendant distribution methods long past the evolution of man into beings of pure energy,’ jokes Domenic Merenda, vice president of business development for Edge Productions, a company that operates adult-media properties.

There’s a good deal of crossover — I’ve seen both email and referrer-log spam advertising the same porn sites.

Tags: adult, article, attendant, distribution, good, industry, quote, salon, spam, wiki

Web: the June part of the contest is over, but given that there’s a July part still to go — here’s a ‘Nigritude Ultramarine‘ link to Anil Dash.

I wasn’t really bothered at all about this, until I came across this guy, whose technique involved spamming third-party Wiki sandboxes with backlinks. His excuse? ‘A Sandbox (is) a part of a system in which everybody is urged to play around freely. Usually for testing purposes. You can post headings, paragraphs, lists and links here. The content in return will be indexed by Google.’

As this forum thread points out — ‘The SandBox page is there for a purpose: to allow users of the wiki to learn to use the software. It is
not meant to be “a place where anyone can create backlinks.”‘

Sorry, that’s spam in my book.

Tags: anil, contest, july, june, link, nigritude, part, sandbox, ultramarine, web, wiki

Literature: So, more on this entry — believe it or not, there’s a Japanese Sourceforge project implementing a Wiki called ‘mrkrgnao’. Japanese Joyce fans!

Tags: entry, japanese, literature, mrkrgnao, project, sourceforge, wiki

Software: Joel on Biculturalism: ‘What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers.’

I’m not sure I agree; I’ve met lots of Windows programmers who take what Joel calls the ‘UNIX’ orientation, and even a few Unix people who are as user-oriented in their coding as what Joel calls the ‘Windows’ way.

But, talking of the Unix/Win divide — it seems that Ward Cunningham, inventor of the Wiki, is joining MS, who have something called SharePoint Team Services, an editable-web group sharing system as part of Front Page.

If you ever wanted to see an illustration of a Windows-Unix divide in the web age, it sounds like this is it: Wiki has quick-and-dirty links in FuglyBouncingCaps, is text-heavy, has obscure text markup formats, has little in the way of roles, access control, or a workflow model, and has some odd magic pages that live in the same namespace as everything else despite being different.

SharePoint, by contrast, is integrated with everything in Office, is a great success where the MS Kool-Aid is viewed as tasty, uses role-based security and a workflow, and seems to be generally reviled elsewhere.

No better illustration. The only thing that could improve that would be if SharePoint has a talking paperclip I’ve missed.

Tags: code, culture, everything, part, sharepoint, software, the, unix, way, wiki, workflow