Now look at your own list. You've pointed out thrice as many cons as pros, and one of the cons is: In default config/install, easily hackable

I agree; this is a major badness. However, I said default config/install. With some hacking, you can make things much less easy to hack. Simply moving and renaming most of the config files/dirs alone adds quite a lot. Simply moving away from the default locations and names will keep most of the cracker-kiddies away.

Now, I'm not saying that YaBB is a safe system. This is by no means true. However, it's perfect for an intranet system or a limited extranet. Not every Web site has to be bullet-proof.

Summary point: YaBB is not a great system, it just appears to be one of the better ones available. It has several flaws, most of which involve how it's programmed and security. However, it's about as good as it gets right now, and a lot of its flaws can be masked and patched with a little work.

In merlyn's words, it's better to have a non-functional, secure site than a functional, insecure site.

I disagree in some cases. Philosophically, the purpose of any Web site is to function. As long as you don't house sensitive information on your site, if you get hacked, you may loose service; worse case scenario: crackers use your platform to bounce into something more vital. A non-functioning site has no value. I posit that a non-functioning site is effectively equivilent to a formerly functioning hacked-and-taken-down site.

More specifically, though, is the choice between installing a security-challenged bulletin board system or nothing at all. In the latter case, there is no added value, but your site is more secure. In the former case, the added value must be measured against the potential risk and harm from successful hacking. It's not always the case that the potential risk and harm is all that great, and it may be considerably outweighed by added value to the average end-user.

Does this mean it's OK to write sloppy Web applications? No, of course not. Always use strict, warnings, and tainting; and always code with security in mind. I would never use PHP for any major public production Web site application for this very reason, but I'm fine with using PHP in an intranet enviornment. If Amazon asked me to setup a bulletin board system, I would not use YaBB; I'd take the time and code up my own. However, for the audiences and locations my bulletin boards needed to serve, the value-add of YaBB vastly outweighed the security risk.

gryphon
code('Perl') || die;