> 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.
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.