Daniel Jalkut is the creator current developer and owner of Mac blog application MarsEdit (a great one, by the way), so it should come as no surprise that he’s a bit pissed about the fact that XMLRPC will be disabled by default in WordPress 2.6. For those who doesn’t know, XMLRPC is the way outside applications can communicate with WordPress.
Naturally, disabling XMLRPC in WordPress 2.6 isn’t done in a swipe at outside applications, there is a reason of course.
Peter Westwood, aka Westi, explains:
We have choosen to disable Atom Publishing Protocol and the variety of XML-RPC protocols by default as they expose a potential to be a security risk. So from WordPress 2.6 onwards you will need to go into the Settings->Write page and enable them individually if you want to use them.
I’m a bit surprised by the hurrah’s in the comments to Peter’s post. Sure, security issues is something everyone want addressed, but obviously this will leave a lot of users stranded and frustrated as to why their desktop blogging application of choice suddenly won’t be able to authenticate with their newly upgraded WordPress blog. Or will perhaps XMLRPC be turned on per default if you’re doing an upgrade?
Daniel Jalkut’s post is worth a read, and it is not just bashing but also pointers for a different solution to this problem. This, however, is key for the whole XMLRPC decision, and why I personally believe that it is a bad one:
Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!
If XMLRPC is such a security issue right now, then by all means disable it by default, and tell the users that they need to enable it. And by telling the users I mean flash it in their face, because a lot of people won’t understand that they need to turn it on, not all users are sure what they’re doing. But in the long run, I completely agree with Daniel’s statement above. Disabling isn’t a solution, fixing it is.
