Apparently this firm wants crackers to tell them about 0days they find so that they can jointly develop and patent a fix. They then want to license that fix to the original software vendor and sue anyone who uses knowledge of the fix without a license.
Now I am not a lawyer and I am certainly not an intellectual property lawyer, but I do know (or at least Wikipediatold me) that patents have to be:
Useful or industrially applicable
Let's look at those in reverse order. Useful or industrially applicable would be pretty easy to demonstrate. Fixes to security bugs are certainly helpful in maintaining system security and industry requires security these days. Great work, Intellectual Weapons.
Inventive is going to be a tough one. This is also described as non-obvious. If you look at most buffer overflow flaws in applications the fix consists of "replace gets() with fgets(). That isn't terribly inventive, nor non-obvious. Some more subtle bugs might need to have more involved fixes, I suppose, but the most common security flaws have pretty standard fixes and unless whole new algorithms had to be invented I don't suspect these fixes will be terribly inventive.
Finally "new" is a real killer for this idea. As mentioned above, there are plenty of examples and patterns for fixing security bugs so there is going to be a tremendous amount of prior art out there.
They have an FAQ with all sorts of answers why the glaring flaws in their idea can be worked around but most of this looks like bunk. I have dealt with the US Patent and Trademark Office before and they are almost unbelievably slow. Even their simple and expedited services are too slow for this idea to be workable.
This has to be a hoax. It did serve to get me all riled up on a Friday, though. Bravo!
Today IBM announced that they will be purchasing Watchfire. Press release is here. It was interesting to see that Watchfire's tools were slated to find a home with the Rational development tools rather than the business unit that was formerly ISS. Personally I think that is a great idea because it give the application security tools to the application developers.
Google has announced their Google Gears tools for making online/offline web applications. This is a great idea and I am looking forward to looking into it further.
From a features standpoint that allows you to make much more interesting applications. Maintaining local-disk state that lives across browser lifetimes is super-helpful. From a security standpoint, however, this opens up a whole can of worms. If this framework is going to require a user to run local code attackers are not just limited to breaking current browser security protections. They can also attack the local code that Google Gears will rely on. This is a huge difference so we will see how things turn out.
However I was encouraged to see that they have a fledgling security page that talks about design and coding issues that could affect Google Gears applications' security. They have a little bit of talk about their security model and a little bit of talk about things like SQL injection. This is a good start but with such a new mentality for building web applications and so much new code in the frameworks I suspect that there will be more than a few security issues to work out - both in the framework and in the application built on top of it.