The latest feature drop is a parental controls infrastructure. You can find out more on (towards the bottom of) the help page. One of the key components is a tool to allow you to turn any of the site features on or off - either for you or for your children. This combined with subscriptions lets you fine tune exactly what you wish to see when you visit. I've been using this immediately to provide different feature sets to the music portal vs. the community portal vs. software engineering portals.

As always, this is just a hint at the types of things you can do. Any member for instance can turn off chat, the photo ratings, guitar chord charts, or anything else they don't care about.

I think I'm finally running out of website features to implement... 

I've been watching the whole bruhaha at Seattle911.com with some interest. This is a homegrown website that takes live 911 feeds and puts them on a Google mashup. Cute and clever use of technology. The Seattle Fire Department responded by changing the logs to image format rather than text.

That's the background. Reading some of the articles pointed me to 'gocr' which is a free OCR package. Now this is useful - I wasn't earlier aware of its existence. It basically takes an image and tries to distinguish text in the image and gives you the text. If you saw my article on comment spam, you'll realize that 'captcha' images to prevent spam are doomed. This is where you type into a box the letters you see in the picture. Most of these are annoying anyway, but it's pretty hard to get them through a clever command-line driven OCR program. If you make it so hard to read that gocr can't read it, chances are that none of your audience will be able to either.

But I have an even deeper interest in this stuff.  Gocr is a framework for finding recognizable stuff in images. Something the world has needed for a while now is something that can filter porn. In theory there isn't much difference between distinguishing the letter 'b' in a picture (in any of 600 different fonts) and say a breast (in any of 600 different sizes/shapes). I'm being polite. Any anatomical feature. 

Some folks worked on this problem back in the '80's, correlating the prevalance of what could be termed 'skin tones' in an image.

The tools and concepts are out there. It shouldn't take much more than a man month or three to put them together into a porn filter. There's probably a market for such a thing.

OK, gocr is probably encumbered with the GNU General Public License. So maybe there isn't much of a market unless one just uses the general pattern recognition concepts (but not the code) and starts from scratch. I don't have anything against the GPL. It serves its purpose, but it does make it hard to re-use code in the workplace. It's a bummer to always have to start from scratch, when the software already exists and has been pretty much debugged. If I'm releasing code into the public domain, I always use either the Berkeley/Stanford license or no license at all. Free, no warranty, blah blah. The GPL is basically a self-replicating virus - which was written by lawyers instead of geeks. 

Actually I think the bug is in Apache, but whatever.

Let's say you've got a site like this that uses clean URL's. 

http://someplace.somewhere/something/more/stuff

Now let's say you wanted  to insert a category name in the middle of this URL, and the category name contains a slash. Let's say 'more/less' instead of 'more'. But you can't change the number of slashes, because in the example 'stuff' isn't a category, it's something else.

So what you would normally do in PHP (and many other languages) is urlencode() the name. This gives you a category that looks like 'more%2Fless'. Now you can just urldecode() it and turn it back into a legal category name without messing up the URL.

But the problem is that if you use mod_rewrite to support clean URL's, it currently decodes the URL in the process of doing its work - before you ever see it. So there's no way of knowing if a category has a slash or not. Ditto for hash and several other characters. It turns out the bug is actually in Apache, which is decoding the URL before it hands it off to mod_rewrite, but that part doesn't matter. If you don't use mod_rewrite you won't see the bug. Some of us have to use it though. 

This violates the primary law of encoding information - you must have one and only one decoder for every encoder. Apache/mod_rewrite is decoding something it has no right to touch.   

Fortunately, there's a way out of this mess, but it's very non-standard. You have to further encode the URL so that it can't get automatically decoded by the middle software layers. You could just double encode it which works today, but then if they ever fix the bug, you'll end up with a bad decoding. I'm currently turning %2F into ^2F, since ^ is one of the few characters which isn't normally used in a URL. This then gets encoded by the browser to be %5E2F. It doesn't matter if the %5E part is turned back into a ^, or even decoded more than once (the second and subsequent decodes will essentially be a no-op). All that matters is that the slash remains encoded all the way through this hostile communications channel.

What an ugly hack.

I'd go into apache and fix it, but that won't help me in the short term. I'd have to wait for the patch to get rolled into a future release, and then wait for my service providor to pick up the later release. ...That could be a year or more unless  some urgent security bug pops up. So I guess I'd better get used to living with this hack.  

Started the new job today. I'm working for a large PC security firm doing web stuff.

That's about all I can tell you right now.