FTP is still pretty much alive in research as well (well, until now). I also used it in the past week. I understand it has flaws, but... I don't know, this seems yet another nail in the Old Web coffin.
"Has flaws" is an understatement. FTP does not play well with the current way the web is set up. Any firewalling or NAT is a pain unless you have the firewall introspect the FTP commands, which is easy for plain FTP because it's plain text and unencrypted, but once you start encrypting the transport it gets more complex, and you need to add support for that in the firewall. There's also often two connection channels, one for control and one for data.
Just be aware that any FTP upload capability offered is likely a serious pain for the admins on the other side. Even if they finally get it configured well enough to mostly forget about, they'll have to dive back in every time they upgrade any infrastructure along the path to it. It's much easier to just pass a TCP port though, which is what scp/sftp (the SSH variant, not the misnamed ftp/s variants some clients used to advertise as it) is much easier, and if you use rsync, includes easy recovery.
> FTP does not play well with the current way the web is set up. Any firewalling or NAT is a pain unless you have the firewall introspect the FTP commands,
That is true only for active mode FTP. Firefox (and many other clients) already used passive mode FTP by default, which passes through NATs and firewalls just fine without need for special help.
Active FTP is a problem if the client is firewalled or behind NAT. Passive mode is a problem if the server is firewalled or behind NAT. The client makes both connections to the server, but still using a second arranged port, so any firewalling on the server has to either be aware of the specific port requested, or a wide range of ports needs to be directly passed through. This is what I was talking about with FTP aware firewalls.
This is what the ip_conntrack_ftp and ip_nat_ftp Linux kernel modules are, a way to make iptables more FTP aware by supplementing iptables at the kernel level.
This is also what OpenBSD's ftp-proxy utility is for, a way to deal with this without resorting to privileged specialty packet processing code, and a way to bypass not being able to see into encrypted traffic.
The fact that these workarounds exist is a testament to how hard FTP has been to deal with in the modern era of the web.
