Deprecate FTP support (deprecated)
chromestatus.com
chromestatus.com
Says it all right there
Investing into much more complex browser extensions such as eg QUIC has necessarily even lower usage. Basically, this rationale for removing FTP support is made up/self-delusional when the reality is that Chrome devs want to drop "legacy" features to focus on others.
ProFTPD, pure-ftpd, and vsftpd are all active projects that are shipped with every major Linux distro. It has first class support on Windows through IIS. Every platform has native clients for it.
FTP is guilty of not being cool anymore but letting it die completely seems like such a waste. FTP could be the already widely-supported solution to the send a file between two devices problem that has a million bespoke solutions. Oh well.
It really couldn't. It has no discovery, no active identity validation story, issues with NAT traversal, relies on filesystem abstraction, ... In sending a file between two devices the actual file sending is the most trivial part and the only part that FTP can do (in the old and clunky let's-split-control-and-data way). We deserve better.
The advantage that FTP has is ubiquitous and broad device support. FTP can provide the transport and authentication for a huge variety of devices and provide an instant user story of how to connect with older devices. Discovery and NAT traversal are external to the transport protocol anyway and would be just supporting _ftp._tcp records and the normal TURN/STUN servers.
FTP has actual stateful filesystem traversal commands. PWD / CWD / CDUP / ... . Of course it can be faked, but why bother?
I understood devices in the comment as personal devices for end users rather than servers. In that case discovery is really not external. Same with NAT - it's a difference between "kind of works sometimes" and "is designed to work with it". See Skype's initial success. Or how SIP documents NAT behaviour extensively https://tools.ietf.org/html/rfc6314
It actually means to “discourage use”. It’s the first step for a feature to be removed. You deprecate something and let the users know that they shouldn’t use it if possible and in the future it will be removed.
If you used a deprecated API, it means the API is no longer encouraged to be used, but it doesn’t mean the API is removed or that support is withdrawn.
I think historically it comes from the fact that when someone “deprecates” their API, they usually abandon it at the same time (because it’s replaced) making the 2 actions synonymous with each other in the tech industry.
It can't have been that well known. It isn't mentioned on the Wikipedia page https://en.wikipedia.org/wiki/Deprecation . That links to things like http://openjdk.java.net/jeps/277 which include quotes like "Very few deprecated APIs were actually removed, leading some people to believe that nothing would ever be removed. On the other hand, other people believed that everything that was deprecated might eventually be removed, which was never the intent either."
Or in Python, https://www.python.org/dev/peps/pep-0004/ " This PEP defines a procedure for removing modules from the standard Python library. Usage of a module may be 'deprecated', which means that it may be removed from a future Python release."
That terminology is still in use; in https://www.python.org/dev/peps/pep-0632/ published last month, titled "Deprecate distutils module" you can read "In Python 3.10 and 3.11, distutils will be formally marked as deprecated. ... In Python 3.12, distutils will no longer be installed by make install or any of the first-party distribution." That's a two year period where it's deprecated but not removed. Further in the text you can read "Deprecate but do not delete", telling me they aren't viewed as synonyms.
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.
But I don’t understand why FTP didn’t receive much love from the IETF+etc in the early 2000s to keep it relevant. I know many saw WebDAV as the future, but that was too idealistic imo. Why didn’t any of the FTP server vendors get-together to fix their collective shit instead of letting it die? (No, PASV-mode doesn’t count).
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.
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.
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 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
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.)
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".
It could even do upload which I've never seen a browser offer.
Back when MITM attacks were first becoming popular, FTP was a favorite target. Any executable or installer could be compromised to gain a foothold on the target system.
Never tried in Mac/Finder
Before file sharing went mainstream, before corporate networks allowed users to upload files to random websites, before file limits went away, before storage space became infinite, ftp was open and available to all people.
I actually had a client tell me that our corporate ftp server was blocked by their firewall. It turned out that they were just too lazy to type in the password. So I crafted a link with the password built in! That was how flexible ftp was!!!
And if I ever wanted someone to share files with me, I would send them the same ftp link with username and password built in, and tell them to paste it into windows explorer. And they could share files with me.
If the client wanted to send link to someone else for download, $he could!!!
That was how amazing ftp was. Everyone supported (except iOS). It was tried and proven.
I just don’t understand this idea behind letting it go.
Ftp is never blocked.
FTP isn't inherently insecure. The protocol supports TLS, Kerberos, GSSAPI. It is just that quite a few clients (including major web browsers) and servers don't implement those extensions, or even when they are implemented people don't know about them and don't use them. A lot of people are under the false impression that the only way to secure FTP is to move to SFTP.
Long time ago there was no JavaScript and later it was still possible to browse Internet with JS disabled.
JavaScript is something that clients and content producers wanted, but is only necessary to realistically use web because content producers decide their content should not be accessible without JavaScript running in the browser.
I, personally, still use browser to access FTP resources because I only use them read only and because it is convenient to browse them the same way as similar resources but using HTTP.
Ftp support, beloved as I think it is, was also never a requirement for being called a web browser. Nor gopher, even though some web browsers also supported them.
I believe the only requirements for being called a web browser are: 1) support for HTTP (in at least one of its various forms), 2) being able to render HTML (in at least one of its various forms, including XHTML) as something more presentable than raw text, and 3) an interface component letting the user follow at least some hyperlinks.
However, I think bastawhiz's argument is a bit dubious. Many people use "internet browser" as a synonym for "web browser", and indeed a DDG search for that phrase just now shows advertisements for Chrome and Opera. I also see that Sony offers an "Internet Browser" for their TVs which is a version of Opera. https://www.sony.com/electronics/support/articles/00014209
So had things been just a bit different, we could have been calling these things "internet browsers" instead of "web browsers". (Rather like when places offer "Internet access" only to find all non-http(s) ports are blocked.)
That being said as long as Chrome will launch an FTP client upon encountering ftp:// links, it's not a problem.
In the nineties i was in the bussiness of dial-up internet providers here in Brazil and remember how handy was Opera back then.
For instance, it was a great dial up manager back then, and it made the effort of installing dial up clients on Windows machines very easy.
Average people use what comes preinstalled. They might not be allowed to install software. Users get stranded on old versions that have to be supported. Install base, “it just works,” and lowest common denominator is crucial if you are working with anyone outside your household or organization. Internet downloads made software distribution much cheaper. App stores fixed the “first Google result is malware” problem. But people will still install an app at much lower rates than clicking something that loads in the browser.
FTP as a whole should be replaced but the average person doesn’t have an easy SFTP client installed.
What percentage of the "general population" do you think has ever used FTP. Even once in their entire life. I'd wager it is less than 1/10,000 users. If we look for people who use FTP at least once month, I'd wager it is less than 1/10,000,000. Where are these users that need FTP but would get stranded because they can only install a browser?
Like doing some research for a school project, googling, getting a link to a pdf document on some ftp, clicking the link. Or clicking the download link on some website, and the file is downloaded using ftp.
These things used to be very common, but are less common now.
I think you are overestimating this. I'd include that in my 1/10,000 number.
Most probably didn't realize that they were using FTP, which is the point of having it integrated into the browser.
Okay. You are one of the 1/10,000,000. What percentage of people have downloaded a driver through any means other than "plugged in device, it said "install driver" and the user clicked it"?
Access to a feature is a feature. I have not had to change a tire in over a decade, but my unused spare tire in my car's trunk is actually being used every time I drive, by being available.
What about nearly any accessibility feature? What about fire extinguishers? I know that support for the FTP protocol is not nearly as severe, but it is on the same spectrum. For the minority of users that use it the minority of the time, it is good to have it available.
As long as it does not impose significant costs to keep ftp support, they should keep it.
And as it happens, I have had to use FTP several times recently, because there are still active FTP links in some manuscripts and scholarly articles I've read.
But it does. This is explained in the docs. The existing FTP support is bad and updating it to make it secure is a ton of work.
Fire Extinguishers and Spare Tires are safety features. When they are needed, they become absolutely critical. It is also very difficult to predict when they will be needed because they are the result of errors rather than intentional behavior.
In-browser FTP is nothing like that.
If you're at the user level where you need FTP, then downloading an application is not an unreasonable request.
> Internet downloads made software distribution much cheaper.
This seems orthogonal to supporting FTP in a browser.
There have been a long time since I saw any FTP link in a page that random people are expected to visit. I'm not sure anybody will miss this functionality.
About people that can't install software, those are probably behind a firewall that prohibits FTP too.
But anyway, browsers are paranoid about never breaking anything, so this is surprising.
For me it just look like the right thing to do. I think we should be more suspicious when the parent company have some interest in deprecate some technology giving they interests clash with the technology being available or promoted.
FTP is becoming obsolete? yes
Google might have a clash of interest with some product over FTP? no
> Usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client. In addition more capable FTP clients are available on all affected platforms.
So chill, you'll still be able to get your stuff via FTP. They're not taking it out of search results or anything, and yes, maybe in 40 years people will still be using FTP for stuff. It's fine, you just won't be using Chrome for it.