Development on BloGTK 2.0 has been very slow lately as my day job has taken priority and I’ve been dealing with an annoying problem with the account settings panel. The good news is that the code is now working (but needs more testing to be sure), and I can move on to adding more polish.

BloGTK 2.0 will use RSD introspection to try and configure most of the settings to a blog with nothing more than the address. That means that most users won’t have to worry about endpoints, blog IDs, or picking the right API. Even though BloGTK is geared towards more technical users, that saves a lot of guesswork.

In WordPress news, WordPress 2.6 is out. Those of you who are upgrading will not have a problem with BloGTK, but if it is a new install, you will need to activate XML-RPC in the settings to use BloGTK or another remote blogging tool.

Finally, once BloGTK 2.0 is in a semi-feature complete state, I’ll be putting the code up in a public Subversion repository for testing. The old BloGTK was written in a time where version control was a major pain—finally I’ve done the right thing and started using an internal Subversion repository for development.

As before, there’s no definitive ETA for release. I was hoping to have something in time for the Ubuntu 8.10 release, but that looks doubtful. With BloGTK, I pushed the app out the door, and made a lot of rookie mistakes and poor design decisions. I want 2.0 to be more polished and professional. That means taking the time to try to get it right before letting it loose.

The next version of WordPress will make it harder for external clients like BloGTK to work by disabling the APIs they use to function.

Take a wild guess as to how I feel about that one.

Granted, all this adds is one more step for users, but it also suggests making remote access a “second-class” citizen to the WordPress world. You don’t solve security issues by shuffling them under the rug. The WordPress team still has to fix security vulnerabilities — this isn’t saving them any time of effort. It may help some users on the margin by removing one vector for attacks, but it’s not going to provide a big enough benefit, especially given the myriad other ways in which WordPress can be compromised.

If WordPress wants to get serious about security, they need to apply this same logic everywhere. Malicious themes are a huge problem — so user should have to explicitly enable theme support. Malicious and poorly written plugins can open WordPress wide open to attack — so before any plugins can be used, users should have to explicitly authorize plugin support. The list could go on.

This may sound harsh, but the WordPress team is taking the Windows Vista approach to security. Adding steps for users just makes things worse because it tends to engender a false sense of security. The real security solution is doing old-fashioned things like making sure that you’re sanitizing every piece of input you get — not annoying users and the developers who depend on your ecosystem.

If WordPress can’t adapt, people will move on. WordPress flourished when MT lost its edge — and back then WordPress was not the better package, but it had the mindshare of the community. The next WordPress is waiting in the wings, and if WordPress keeps taking such a mistaken approach to security, they could easily fall behind.