xml-rpc protocol is basically used to expose a set of API implemented by a site/server which enables other software to interact with the site/server in a way which is easier to program then trying to mimic user interaction. WordPress currently (version 3.5) expose API for publishing pingbacks, and content. Software like windows live writer by Microsoft uses the content publishing API supplied by WordPress to create a non browser editing environment, but the main users of the protocol right now are smartphones because the small screen size makes the WordPress web interface almost unusable.
Upto WordPress version 3.4 the remote publishing by XML-RPC was disabled by default, and the text explaining the option in the admin was technical and said nothing about smartphones.
With the rise of smartphone use, and the number of smartphone apps that use XML-RPC to publish content to wordpress, it is only a logical move to enable XML-RPC by default, but the development moto of “decisions not options” was taken too far as in this case the option has enough importance to justify having it.
The reasons are mainly security related
- It doesn’t matter how robust is WordPress code there is always a chance of a security bug that might relate only to the XML-RPC code
- Plugin authors will probably start supporting XML-RPC opening more attack vectors, and user will not even know about it because it will not have any GUI indication, and you will not know that unless you read the plugins documentation.
- There is no knowledge base on how to defend against brute force/dictionary attacks from XML-RPC. Current plugins might work,but will they give you a notice like “You failed to login 3 times, please wait 5 minutes till the next attempt” on the XML-RPC layer, and how the app will display that notice?
It might be that core developers are right and there is no risk added by having XML-RPC on all the time, but I think that a more conservative two step approach like
- Make it default to on, leave the option in the admin
- In two releases look at the experience of running WordPress that way and decided whether to eliminate the option as well
The reason it should work that way is that most user just leave the default setting on, so there will be a big enough user base to field test the feature even when the option to turn it off exist.