"The current FTP implementation in Google Chrome has no support for encrypted connections (FTPS), nor proxies. 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."
> Usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client
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.
That’s a powerful set of scare quotes around “legacy”. FTP, by any reasonable definition, is legacy, and if you need FTP, you have FileZilla, or the terminal.
FTP is legacy in the sense that it hasn’t hasn’t had the masses giving it love but it’s not dead by any stretch.
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.
> FTP could be the already widely-supported solution to the send a file between two devices problem
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.
HTTP also relies on a the filesystem abstraction, it doesn't stop web servers from presenting virtual versions.
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.
HTTP does not use filesystem abstraction. The path in HTTP requests is completely unrelated to files and just looks like a file path.
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
In case it wasn't clear: deprecating FTP in Chrome was temporarily deprecated for awhile, but then that deprecation was deprecated. In the end leaving FTP in Chrome as deprecated.
“Deprecate” is the most misused technical word I’ve seen in the last 10 years. A whole generation of engineers seem to believe deprecate means to “remove support” or to remove entirely. Like “I just deprecated that function and deleted 100 lines of code.“
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.
You’re not wrong, but the definition seems to have stuck at this point (and it’s been used this way for a lot longer than 10 years, more like double that).
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.
I hadn't heard about this as a synonym for abandonment or replacement before, only the "discourage use" definition, with a possible eye towards future removal.
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.
The fact that many think of deprecate and eol as synonymous does not make it so. There is a distinction and it's an important one. Developers should not just one day drop a feature out of the blue. The deprecation rolloff period is important for users, even if just to maintain trust.
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).
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'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.
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.
> 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
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.
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".
Browsers are slowly shifting away from being browsers and becoming exclusively locked down engines controlled by your feudal lord to run javascript applications.
Early on, through the early 2000's, I'd say yes. ftp:// links were often posted on web sites. There was some expectation that clicking those links worked and would download a file. These days? Why bother...
The big advantage of FTP is that server support for resuming partial downloads was generally supported, unlike HTTP. Of course the browsers never implemented the resume feature so there wasn't much incentive to use FTP in the browser. Plus Internet connections got better so the need to work around your shitty connection diminished over time.
When was having support for JavaScript really ever criteria for being a web browser?
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.)
I know there was at least one browser in the 90's that purported to be your one-stop shop for all things Internet - HTTP, email, and FTP client. When background Internet connectivity wasn't a thing that probably made more sense.
That being said as long as Chrome will launch an FTP client upon encountering ftp:// links, it's not a problem.
Netscape Communicator certainly had the email features, but I don't think it ever included FTP. At most, it supported a primitive sort of web authoring via HTTP PUT requests (!).
Do you mean something beyond being able to load and display resources from FTP sites? I remember Netscape, and I also remember having to open up Fetch to do anything serious with FTP.
The general population doesn’t easily install software. They’ll just lose access to FTP. PDF viewers got integrated into browsers because some users don’t have standalone PDF viewers installed, or they were broken, or they couldn’t find the PDF they just downloaded.
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?
I wager the majority has used ftp, but most of them sporadically and without even realizing they were using ftp.
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.
> 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.
I think you are overestimating this. I'd include that in my 1/10,000 number.
A lot of them. It wasn't that long ago when most large files were hosted on FTP sites. An absurd amount of drivers that I download are still hosted on FTP sites.
Most probably didn't realize that they were using FTP, which is the point of having it integrated into the browser.
> An absurd amount of drivers that I download are still hosted on FTP sites.
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"?
> What percentage of the "general population" do you think has ever used FTP.
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.
> As long as it does not impose significant costs to keep ftp support, they should keep it.
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.
That same average person is just as apt to have a failure connecting to that FTP server in the first place because of support issues going across their NAT router.
I'm a software engineer and I need to use FTP maybe once a year. Chromium hasn't had SFTP support. So it seems like there really aren't very many people at all that _need_ FTP, and nobody is actually losing access to proper FTP support.
> 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.
IDK, we should think if we would think its reasonable to add SMTP or IMAP protocol support in browsers, or if this move would be perceived as misguided, by bloating even more with things that should otherwise be optionally implemented in other layers.
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
The security problems with FTP extend beyond plain-text authentication.
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.
The same options are on Nautilus and forks (Caja, Nemo). FTWAI the GVfs API is utilized and resources are accessed via a URI but are also mounted on $XDG_RUNTIME_DIR/gvfs; usually /run/user/$USERID/gvfs.
I am irate at this news. I know ftp is not secure. Not even by a small margin. It is just like http, back when you could still trust network engineers like you could telephone companies. But it is MAD useful.
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.
Somehow I don't think crafting a link with a password in it is the best example for arguing for its place in the future :)
What sort of migration effort does this cause you?
Migration? You mean what other services I can use? If I have a 4 gb file, few services allow me to transfer such a heavy file. And when they do, it’s possible my client has that service blocked from their corporate system. Plus very few services allow me to send my clients a link where they can upload to. Again, if they do, it is 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.
I still find useful things with Google searches that are hosted on FTP, so this seems very odd and unfortunate. I'd say the "file-based web" is still very much alive. A lot of those files I've come across (usually old software and docs) are unlikely to be found anywhere else, as I'm not even sure if archive.org archives FTP sites. IMHO this is a significant part of the Internet that must be kept alive, because it holds invaluable amounts of irreplaceable data.
For the many people in this thread who seem to think somehow Google is single-handedly killing FTP everywhere for everyone, please refer to the first paragraph in the linked site. Here it is, for the lazy (emphasis mine)
> 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.
96 comments
[ 3.0 ms ] story [ 103 ms ] threadSays 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".
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.
https://en.wikipedia.org/wiki/Cyberdog
https://www.seamonkey-project.org/
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
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.
> 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.