I'm not sure what could have been done to make a new FTP that was better than SFTP. FTP had a couple of edge cases that were very nifty (like connect to server 1; connect to server 2; tell server 2 to listen; tell server 1 to send to server 2's port; voila, transfer from server1 to server 2 without ever transferring the data to your own host!) but I don't know that anyone ever actually used them.

SFTP came along as basically a working, feature-complete replacement. Once it became production-ready, I don't think there was anywhere for FTP to go.

Cross-sending is called FXP in video and is(was?) used extensively by all broadcasters, TV channels, etc. So much that it's a must-have functionality for any storage system in this domain.

I remember it more from the times when illegal releases were raced to ftp servers to be downloaded by everybody, pre torrent.

Given SFTP is ssh based, it seems like it could support agent forwarding + an FXP-like mechanism to jump from server to Server w/o transferring to the controlling host ...

> I'm not sure what could have been done to make a new FTP that was better than SFTP.

Or HTTPS, IMO; it supports file download/upload, user/pass access control, and encryption. It's a little annoying to have HTTP subsume yet another thing, but it's actually pretty decent at this one.

The problem with HTTP is that it’s too generic to be a drop-in replacement. You have to get people to agree on a single app/protocol that uses HTTP as transport.

That’s what WebDAV was for.

> SFTP came along as basically a working, feature-complete replacement

The FTP standard has a number of features that SFTP doesn't include, such as record-oriented file transfer (STRU R, MODE B), store-unique (STOU – you upload the file, the server picks the name instead of the client). Many of these features are rarely used, and many clients/servers don't even implement them, but SFTP is not a feature-complete replacement for FTP. But there are some environments (e.g. mainframe environments) where these features are used, and these feature gaps make it difficult or impossible to replace FTP with SFTP

It's definitely not just fintech. FTP is commonly used in any industry that complies with EDI standards... which is most of them. Back when EDI formats were first implemented, FTP was the gold standard for sending files across a network, and so that's what basically every large company implemented. Now, many years later, the network effect keeps those systems in place.

I was using FTP in AdTech in Q2 of last year. We always had a bit of a chuckle when the onboarding client was so strict about security and obfuscation, but the platform they wanted the data deployed at didn't have any security for uploads. I've moved to a new industry, so I don;t know if this is still the case, but when I left the platform in question had no intention of changing.

> I think FTP is being kept-alive only by legacy fintech (doesn’t the US ACH depend on banks exchanging CSV or TSV files over FTP?) and low-end shared webhosting services that are too afraid to offer SSH to their customers.

FTPS is still used in mainframe and minicomputer systems as well. This is because FTP has native support for transferring record-oriented files – STRU R and MODE B/C. Those features are generally not implemented by FTP clients or servers on Linux/macOS/Unix/Windows/etc. Unlike FTP, SFTP does not have native support for record-oriented file transfer.

I understand that GridFTP is still used in high-performance computing applications. GridFTP extends FTP with features such as parallel data transfers targeted at transferring massive data sets (terabytes, even petabytes in size) over very high bandwidth links. (Aspera performs better but is proprietary; GridFTP is an open standard with open source implementations.)

It's still used quite heavily in research also (medical is what I'm familiar with). NCBI puts a lot of critical data on FTP, as do individual researchers.

In the case of NCBI, the actual transfer protocol usually used is Aspera, but you use the FTP server to find what files you are going to download using Aspera (which is CLI only AFAIK). Thus in this workflow, browser support for FTP is actually important.

I would say that the reason it hasn't changed is that it does its job fine. It serves files. It's one of the simplest ways to do so, and I lament that in my sphere the biggest apparent replacement is Dropbox. I agree with one comment above that "legacy" code for FAANG is apparently "features which we can't monetize".

...and centralize.

Also every enterprise business that I have heard of - FTP isnt going away anytime soon.

I think the use case for WebDAV as an opt-in HTTP extension for managing files on a web server is different from FTP-in-browsers which I understand to be mainly FTP downloads rather than asset uploads.

Why reinvent SFTP?

The main reason is FTP is often used with untrusted external third parties and configured by enterprise IT staff who only half know what they're doing, and SFTP is really SSH. That makes it really easy to misconfigure it in such a way that the SFTP users can get a shell, which is a giant footgun.

Meanwhile the biggest problem with FTPS is just that people misconfigure their own firewalls to prohibit outgoing connections to arbitrary ports for no good reason. (Spoiler alert: All the bad outgoing stuff these days is on TCP/443). Which fails by getting your users to complain to you to fix it, instead of failing by silently giving attackers instant RCE.

I wonder if you can run sftp over Https.