The WordPress developers have decided that, starting with WordPress 2.6, access to the XMLRPC and AtomPub-based remote publishing interfaces will be disabled by default. Users who wish to use a remote client such as MarsEdit will have to go out of their way to enable the required functionality in their blog’s settings.
There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.
But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.
First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.
Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.
WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.
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!
A Real Solution
If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.
In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.
If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.
Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.
If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.
If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.