Today I was looking at setting up a git repository for a little utility (which I hope to release shortly) to share code with the big old world, and I found myself googling how to use git, and other distributed source control systems, over FTP and found myself asking "why?". The first half of the why is very simple. I want to share the repository when my killer app (I wish) gets released, but I would like to host it on, rather than setting up a Google Code or Sourceforge page for it. It seems like rather too much work for a little app. This being a cheap, shared host that MCP is hosted on, the only file access is by FTP. So naturally, any source control (download or upload) will have to come over the FTP protocol. Which brings me to the second half of the why and the thrust of the whole post.

Why, at this point, do we still not have a better, widespread method of exchanging files? FTP, by default, exchanges login credentials in plain text and is, therefore, quite insecure. Yes, there is SFTP and FTP over SSL, but the vast majority of FTP setups do not and would not use these measures. And, at any rate, they are mere spackling over cracks in a poor protocol. In active mode, the idea of a duplex data connection is problematic for modern NAT firewalls.

It would be mean spirited and short sighted to declaim any of these faults as being "obviously" wrong. They may be now, but FTP dates back almost thirty years. It is an example of experimentation, both successful and not, and an example of a design that was outgrown by the demands placed on it. The dual socket design and plaintext authentication were not problems when the first RFCs were coming out. They were features. They made the protocol easy to implement and use (back in an era when the idea of a user actually entering raw protocol commands was not far fetched). Today, these things, and other like it, are a pain. A pain that has been hacked around to enable FTP to continue functioning in the 21st century, but a pain nonetheless.
So, why don't we have a better file transfer protocol than the File Transfer Protocol? Here is what I would like to see in an NFTP (new file transfer protocol):

  • Drop the whole idea of ASCII/Binary transfer mode. It's all bytes at the end. Use a MIME type, if necessary, to indicate what is being transferred.
  • No more Active/Passive mode. Like HTTP, just have a request/response.
  • Make the authentication process secure by design. No, this does not inherently solve all problems, but, at the minimum, mandate encryption for the authentication stage.
  • A standard way of representing the file system hierarchy in general. I can't remember where, but I remember reading that parsing the file listing format was often a problem when implementing an FTP client because servers differed so much on how they returned the data.

I'm sure that there are other things that could and should belong on this list. Maybe a protocol like this exists and I just don't know about it. Of course, someone will probably explain how I am an idiot for saying most of this and that's fine. I'm just rambling anyway. But even if we got this protocol tomorrow, it would matter little. FTP is everywhere, especially on cheap hosting servers. It would be quite a while before the majority of the world benefited. Just like it was a long time before anything besides PHP/MySQL was available on most shared hosting accounts, it will be a long time before anything other than vanilla FTP is offered in shared hosting. The answer to the title is simple: FTP exists because it is the lowest common denominator, which makes it too common to simply die.