FTP Fadeout | Hacker News Reader

FTP Fadeout

tedium.co

42 pointsuptown34 comments

FTP will only "disappear from the internet" in the sense that it will be eclipsed by alternative, better options like SFTP.

The browser was always a piss-poor FTP client and I honestly don't believe that there are large number of people who were "on-boarded" to FTP because they first used it in the browser. It was simply a convenience if you needed to grab just 1-2 files and were already in the browser. Also browsers never implemented SFTP yet it had no issues with adoption. Lastly if people really want a FTP client in their browser I'm sure there will be an extension for them, I found SFTP extensions in <5 seconds of googling, if there is a demand I'm sure we will see FTP extension (if they don't already exist).

FTP fading away seems about as unlikely as SCP fading away. SCP is pretty much exactly RCP (from approximately 1980), but over an SSH channel instead of TCP sockets. SCP occupies the #2 spot on the "transferring files quickly" list, #1 is tarpipes (SCP ping/pongs once per file/directory, tarpipes don't), #3 is SFTP (ping/pongs about three per file, and ping/pongs per write call, which is limited to ~256 kB).

(People say SCP is an ugly, outdated protocol, but it's actually rather nice, simple and pretty efficient, if what it does is what you need)

By the way, big point of confusion: SFTP is "POSIX-like IO via RPC over SSH" (so, in a way, a lot like NFSv3, but over SSH, and generally done from userspace), FTPS is "FTP, but over SSL".

Unfortunately, no file transfer protocol built atop ssh (scp, sftp, etc.) can have high throughput rates over high-latency links because ssh has a small, fixed TCP window size. There are high performance forks available like HPN-SSH but they are rarely used in practice.

Currently, the highest performing remote file transfer that I’m aware of for most situations is HTTPS.

True, and even on relatively good connections (e.g. gigabit with 10-20 ms latency) the difference between tarpipe, SCP and SFTP is quite telling.

WWW browsers are definitely poor clients now, and they have been since at least 2016/2017 when I was adding some verbs to Bernstein publicfile's FTP server.

* http://jdebp.uk./FGA/web-browser-ftp-hall-of-shame.html

But they actually used to be much better than they are now. Netscape Navigator, and WWW browsers of the 1990s such as IBM's WebExplorer for OS/2, were quite happy with (the original) publicfile and other FTP servers, far more so than WWW browsers were in 2017 and are today.

This is definitely not an "always" thing.

The author claims that FTP is disappearing from the Internet because Chrome is going to drop support for it in a future update. The article cites another piece that says that Firefox dropped FTP support earlier this year. Both cite security concerns for the reason. Neither mention either SFTP or FTPS. Further, web browsers never needed to be FTP clients, so it makes sense to axe support for them in principle.

There is still a demand for FTP. New FTP-only hosting providers have been popping up in recent years. Companies are also setting up FTP servers to store whatever they need because it's cheap and easy to implement. I even personally incorporated an FTP server in a project that I started on this year. Of course, the author doesn't mention this, nor does he offer any alternatives to it.

Browsers being able to download ftp protocol links is a really useful function.

Security it an odd reason to me to remove this feature as anonymous ftp doesn’t really have much of an issue.

Eh, FTP protocol is a mess, especially in a NAT based world.

Would like to understand what you mean. Care to elaborate

It requires a separate port for transferring data. And unless the FTP server supports passive transfers (and they're still out there to this day) that connection is in the opposite direction.

Thanks!

I agree about its usefulness. Personally, when I'm using FTP, I seek out a native client anyways. As long as the browser will open up the client when an FTP link is clicked, I think it would be fine. Let the HTTP browsers focus on HTTP. I mean, browsers don't tend to have built in functionality for things like email or phone calls.

Even if your connection doesn’t have credentials to steal, anyone who can observe your network traffic can snoop on what files you’re downloading, and a MitM attacker can serve you altered versions of those files. This is especially problematic given that one of the most common remaining use cases for anonymous-FTP-in-browser is downloading software, so there’s a good chance you’re about to execute those potentially-altered files as code.

Of course, unencrypted HTTP has the exact same problems – but browsers are trying to deprecate that too, even if they can’t actually remove support anytime soon.

I’m aware of this risk and don’t care. The files I FTP down are things I don’t care about.

I don’t think there’s a “good chance” of someone altering the files I download. It’s certainly possible, although unlikely based on the number of times it’s happened to me (0) vs the times I’ve served or retrieved an ftp file (millions, perhaps billions).

In the case you're downloading Tor Browser in some countries

> Neither mention either SFTP or FTPS

They mention SFTP at the very bottom but I agree with everything else you said:

> Some of its more prominent use cases, like publicly accessible anonymous FTP servers, have essentially fallen out of vogue. But its primary use case has ultimately been replaced with more secure, more modern versions of the same thing, such as SFTP.

Good catch. I'm not sure how I managed to miss that

> Further, web browsers never needed to be FTP clients

I think historically the FTP support existed so you could set up a web site on an FTP server rather, rather than having to run a HTTP server.

Early on, having a single browser that could browse HTTP sites, gopher sites, and ftp sites, was a powerful argument.

There were a fair amount of ftp urls to software archives at one time, so it was convenient for browsers to be able to use them.

We have integrations with almost every of our non-trivial customers. The vast majority of those integrations involve files being read/written and transferred.

A very popular choice among our customers for transferring these files has been FTP, either via intranet or internet.

For a couple of years now FTP usage has fallen dramatically. Our customers now want SFTP, and this demand is not driven by browser support or similar.

> Further, web browsers never needed to be FTP clients, so it makes sense to axe support for them in principle.

Came here to say this. Browsers were always terrible FTP clients. Good riddance!

Drag and drop file uploads always worked very well via FTP. Would be sad to see a degradation on something that was quite inter-operable and stable regardless of Javascript and its various Browser APIs.

Super pedantic comment...

The Teletype shown in the picture is of a 5 bit model (ASR-32) not the 8 bit ASCII model (ASR-33) used for the early computer networks. The simple keyboard with Letters and Figures shift keys give it away.

FTP has been superseded by better alternatives. Anonymous FTP is replaced by HTTP. Mostly because HTTP transfer is simpler and easier to work around NATs and firewalls. (take a look at debain mirrors for example).

Authenticated FTP is just not secure enough for today's use cases. It is also replaced by S3 like file services that run over HTTP. For some reason FTP over TLS (which sounds secure enough) didn't catch on.

FTP uses a dynamic port for data, negotiated in the control channel. Nat/firewall traversal required deep packet inspection on the control channel in order to open the data port; TLS makes this deep packet inspection impossible.

Unlikely. EDI was introduced around the 70s and is still used today with no signs of going away. Those documents are being transferred over FTP.

I’m working on trying to abstract away retailer and sales channels’ methods of communicating with distributors (EDI/CSV files over FTP, REST/SOAP API endpoints), and the number of retailers using FTP, even Amazon and Wayfair, is mind boggling.

FTP directories are mostly protected by a password, so google can't search them. Removed from browser because not useful (even harmful) for the ad business.I don't see any other rationale for this action. An FTP client code is small and simple. TLS is already there for FTPS or SFTP.

Seems like a perfectly fine use case to me when a camera or a sensor wants to drop some files on the local network. The protocol is cheap to implement on microcontrollers unlike secure versions. So while FTP will still live long without a support for it in the Google browser(s), I don't understand why they would discontinue it and I don't understand why would it be harmful for the ad business.

I feel the only thing missing for HTTP to replace FTP is a MIME type for directory listing. Is it the only thing that would need to be adopted? Is there any format already doing that?

We'll always have ftp.funet.fi.

funet, sunet, sunsite/metalab, gatekeeper, rtfm, uu, lysator, winsite, cdrom.com, papa, csociety-ftp, ... what other old FTP servers am I forgetting?

wuarchive.wustl.edu

https://pasztor.at/blog/dont-use-ftp-heres-why/

https://tools.ietf.org/html/rfc2228

"FTP authorization is accomplished with a password, passed on the network in the clear as the argument to the PASS command."

FTP Fadeout? FRICCKKING FINALLY!

Reply on news.ycombinator.com