community server admin web 2.0

Low-cost publishing = easy-to-kill content

One great achievement of the web is the huge reduction in barriers to publishing. But the flipside is that we now see extremely low incentives for publishers to keep content “live”. Back when it cost money to publish info, you had good reasons to *keep* your content live once it had been published; you had a revenue stream to protect.

Nowadays, with publishing costing nothing, it’s often un-monetized. All it takes is the slightest increase in hassle for the publisher, and they’re better off killing the content entirely.

That’s the case with a site I just shut down. A small, incomplete – yet moderately valuable – resource for iPhone Developers, with a few thousand unique visitors a month. Too small to be worth monetizing, so I hadn’t. I was eating the (very small) hosting and support costs, until someone abused the site, and those “support costs” became non-trivial.

iPhoneDevelopmentFAQ – history

I created this site at the start of 2009, because there was no good FAQ for iPhone Development (AFAIAA there still isn’t; even today, the nearest you can get is StackOverflow. SO is great, but … a lot of subjects are “forbidden” under the site terms, and the site-search is very weak).

I set it up to be low maintenance, and to allow multiple people to moderate it (very similar lines to SO, but slightly less open, and a lot more “niche”).

In the past two weeks, after more than a year of “no active moderation”, we saw forged posting credentials and then pointless offensive questions. First rule of running a passive website: leave it configured to report (surreptitiously) on all unusual activity, so you can see if it gets out of hand / abused / attacked / etc.


Deleting offensive content requires only a couple of minutes (to remember the password, login, and hit delete).

Checking what happened with the forged credential (probably unrelated) is more like half a day to a couple of days. I could audit the code, audit whatever 3rd-party PHP libraries were being referenced, and almost certainly plug the hole (or holes).

Or … I could do what I actually did: two lines of typing, and Apache kills the site. In a way, it’s a bit sad – it had background traffic of a few thousand uniques a month – and the whole thing is now gone.

The fragility of niche interests

At the end of the day, I get *zero benefit* from this site. I pay a tiny amount for the web-hosting and the domain-hosting, so it’s almost free, and I’m happy to leave it running for the benefit of the thousands of visitors each month.

But if it’s going to start costing me hundreds (or thousands) of dollars in lost time when I would otherwise have been doing paid contract work (every hour not working is an hour’s salary lost) … then the balance switches and (as in this case) I’m obviously going to kill the site.

I expect that the people who abused the site were just being thoughtless, and probably wouldn’t have ever gone back anyway. But I can’t afford the time to make sure.

Ultimately: Who has the time for this? A handful of callous acts just killed a repository of info.

2 replies on “Low-cost publishing = easy-to-kill content”

I understand why you killed the site — but couldn’t you have let it stay in read-only mode? That way at least the information already collected would’ve been available for future use.


In theory, yes. And I’d have preferred to do that.

But with a “possibly” compromised accounts system, I would have still had to go and alter (hack?) the PHP to remove the auth-layer on accessing the DB.

It’s possible (probable?) that there’s some config flag somewhere that would achieve that, or that it’s just a couple of lines of code …and then I’d have to test it. Five minutes becomes an hour, becomes half a day.

Comments are closed.