OK, so I stirred up a few bees in the last post :)

I would have VERY much preferred if it (captcha as implemented in major blogging engines) were more solid. But it *cant* be. Blogs are made to be open and accessible. Thats the whole point, the ability to post comments is a big part of that. Like you say, blogs without comments enabled are highly inconvenient.. they are nothing more than traditional "programming" - one way communication. So, we *want* them to be accessible. Obviously, captcha throws a speedbump in that, the whole idea of captcha is to be a speedbump.

And that would be OK *if* it actually WERE a speedbump. As soon as I saw the implementation (always 6 letters, easy contrast, fixed character set - actually it's plainly just 3 hex values, background always a fixed pattern) I knew instinctively that it would be incredibly easy to circumvent. I don't even think you need an AI engine to do it... I can think of a few algorithms that have zero Neural Network components that could achieve a 50% success rate. My point is this is just a very brief escalation in an arms race, which buys us very little time but throws up a significant deterrent to valid comment posters.

I would also point out that as far as I can tell, the Web Service comment APIs do not even support it. And these are the most visible and obvious spammer attack vector. After all, they are using automated tools... its easier to just call a web service than scrape a web page exchange. And of all the blogs I read, only two that I can think of right now (Shawn's and Daily WTF) have proprietary comment submission API (or no WS API) that is not exposed here.

This guy's work is not going to give spammers any kind of leg-up. You can bet they were well on the case long before... it's just too enticing for them. They are fully willing to send out email spam just to get the one in 10,000 who will click the links... blogs are a gold mine compared to that... even the comment links. As far as I know, they still havent breached it yet (en masse), but it's only a matter of time.

The reason I say I think this guy did a good thing here is that he is making it very clear to his peers (he only spammed MVP's) that they do not have as much security as they think they do with this. It's easy to get mad at him for "opening the pandoras box", but he didn't really open it so much as he said "hey, everyone open your eyes, the box is already open!".

I would personally like to see a real solution to the spam problem (I hate it as much as anyone else). But this wasn't it. This was too easy to circumvent in an automatable way... and once a spambot is made for ONE dasBlog site, it works for ALL of them, same goes for the other platforms.

The only way to give yourself real relief is to implement your own captcha (or other confirmation process) so that you won't become vulnerable by virtue of your platform. It's one situation where "roll your own" security may actually be better - since we dont have a "standard" that is solid enough. Thats too much work for me though (maybe for others it is not), I just dont have the time for it. It's less hassle to just delete the garbage as it comes in at this point.

As soon as I heard dasBlog and other blog engines had implemented CAPTCHA tests on the comment forms, I knew it was only a matter of time before it was shown to be irrelevant. But Casey Chesnut has defeated it even quicker than I thought would happen.

He simply spent a few minutes studying the implementation, figuring out it's limits and patterns, then wrote a bit of AI to decypher the images. His routine only has a success rate of 50%, but thats more than sufficient to perform comment spam. To prove his point, he ran it against over 90 blogs on msmvps.com.

This is the precise reason I never even considered enabling this feature of dasBlog. It is easily circumventable, and really does nothing more than interfere with your real readers' ability to contribute.

This emperor has no clothes.

Hats off to you Casey, this false security needed to be called out.

It's just not threaded properly. It can't be.

I noticed long ago that it uses worker threads to update feeds, and often when a feed fails to update, that worker thread (most likely a pool thread) becomes a zombie. Over time, this further degrades performance until the pool just runs out of available threads (not to mention the memory consumption is just insane by then). The only remedy is to shut down the program completely and restart it... giving you a day or two before having to kill it again.

And now this - I have noticed what can only be described as "anomalies" in my downloaded feeds before... things like seeing comments attached to the wrong posts, and so on. I always assumed this was just due to bugs in the RSS feed producer I was subscribed to. But today, on a pair of blogs, both had a post with a title of "{...}". Each had a jumble of intermixed text from recent posts in the other blog. In order to get the feeds sorted out properly, I had to delete them from my opml, restart RSS Bandit, and add them back. And of course, there are no posts on either blog titled "{...}".

I suppose the corrupted posts could be due to buggy local storage code, but it sure looks a whole lot like the updater threads are just poorly monitored and synchronized.

I guess it's time to try NewsGator. I am not thrilled about packing my RSS feeds into Outlook, but guess I will get used to it.

At least they have a free trial period though. I hate paying for something and tossing it out shortly after.

Three new specs were released as W3C recommendations today...XML-binary Optimized Packaging (XOP), SOAP Message Transmission Optimization Mechanism (MTOM), and Resource Representation SOAP Header Block (RRSHB).

They are all interrelated... XOP is the XML mechanism that is the building block for MTOM (SOAP implementation of XOP which does not dictate wire protocol binding), and RRSHB is an expansion of the SOAP HTTP binding to support MTOM/XOP.

In a nutshell, all of this stuff has one essential purpose: Freeing you from having to encode binary data into base64 when you serialize a SOAP message. Basically, base64 is a really heavyweight encoding scheme, that adds a TON of fat. By allowing binary octet data to actually be transmitted unencoded (and under certain circumstances, relayed across SOAP processors unencoded) instead of taking the serious encoding hit, the bandwith requirements of moving large messages around is reduced significantly. Not only that, but the CPU overhead of doing the base64 encoding/decoding is also alleviated. And yet another, though smaller, benefit is that less buffer resources are required on both ends of the pipe (assuming both ends can deal with the data in it's raw format). Of course, some operations may require access to the data in base64, so a SOAP sender or reciever may have to encode/decode it anyways (I think XML-Signature requires binary data to be addressable in base64?)... but it still gets the bandwidth reduction when it is transmitted over the wire.

I can see a lot of benefit to this.

For example, this makes digital media transmission over web services a whole lot more appealing (as opposed to scrapping together a proprietary protocol). SOAP-routed media could turn out to be quite interesting. I know folks have tried to do it with Web Services, and gave up in frustration due to the bandwidth hit... but now the hit isnt there... it's now basically raw media data wrapped in some dandy XML metadata... fascinating...

Another use I can see is just around the corner when ADO.NET 2.0 datasets support REAL binary serialization instead of the "serialize to pseudo-xml, and call it 'binary'" serialization of ADO.NET 1.x. In a purist sense, we know it's bad form (argue it here, here, and here) to send datasets over web services "Data on the Inside vs. Data on the Outside" and all that. But I tend to agree with the opinion that in most cases once we commit to sending a dataset in a message, it becomes "opaque" like an image or any other binary data would be... and doesn't really break the purist view (come on, squint real hard with me). So passing a large dataset in binary format is perfectly acceptable to me, and these new specs will make it significantly more viable. One of the major debate points against datasets over webservices has been the bloat it causes... but with binary serialization and XOP/MTOM, that arguement fades fast.

Of course like anything else, I am sure someone somewhere will find a way to abuse the specs and I will be griping about it later.

The word this week is that on Friday there should be a set of new application blocks released on the MSDN patterns and practices site. We can expect a new Data Access and Logging block, as well as a Cryptography block, and a few other treats. Sounds like a pretty good pack of reusable blocks, so I for one will be keeping my eye on MSDN tomorrow.

[update:] The new blocks are now online at this url: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp

This one is great...

http://wizbang.mirror.unitedemailsystems.com/vw_20_b3.mov