FTP is an insecure protocol which Blink is considering removing. It seems like we're considering removing support for it on Android but perhaps we should go a step further and remove it completely?

FTP is still popular in some corners of the web. For example, a majority of the sites hosting the GCC source code use FTP.

It’s little known but all major desktop platforms support FTP with the built-in file manager (Windows: File Explorer, macOS: Finder, Ubuntu Linux: Files) so can we just open the external app?

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #3)

It’s little known but all major desktop platforms support FTP with the built-in file manager (Windows: File Explorer, macOS: Finder, Ubuntu Linux: Files) so can we just open the external app?

Yes, that would be the plan.

(In reply to Botond Ballo [:botond] from comment #2)

FTP is still popular in some corners of the web. For example, a majority of the sites hosting the GCC source code use FTP.

Downloading software source code over an insecure protocol is an extremely dangerous practice, FWIW.

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

If this is purely about encryption, then there has been the much longer standing request to add FTPS support. Most FTP servers also offer FTPS (either implicitly or explicitly) so the logical thing would be to add and prefer FTPS.
Also: redirecting a standard FTP request to "whatever the system file manager is" is likely providing less security than even leaving it as-is. There's usually a very good reason that people use a browser or a dedicated FTP client instead of their default file manager for FTP requests.

(In reply to Mark Straver from comment #6)

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

This is a hard question to answer since the content of your discussion with Doug wasn't documented on the bug. At this point all of the information available can be found at what's been linked to above so far. I'd expect all of the old objections will be taken into account by the module owners when we get to the point of making a decision here (not sure when that will be).

(In reply to Mark Straver from comment #6)

Has anything substantial changed since https://bugzilla.mozilla.org/show_bug.cgi?id=1174462#c25 ?

Most high-risk downloads are done via https today.

If this is purely about encryption, then there has been the much longer standing request to add FTPS support. Most FTP servers also offer FTPS (either implicitly or explicitly) so the logical thing would be to add and prefer FTPS.

FTPS and HTTPS are often not offered for the same reason. If server operators finally set up Let's Encrypt, they could offer both, if they want.
https://nginx.org/en/docs/http/ngx_http_autoindex_module.html is similar to what web browsers offered in the past.

Also: redirecting a standard FTP request to "whatever the system file manager is" is likely providing less security than even leaving it as-is.

They should add a strong warning and consider disabling insecure connections to public IP addresses by default.

I strongly support removing FTP support completely for security reasons.
FTP is an insecure protocol that we should strongly discourage people from using for anything.

The code is an attack vector and has a long track record of bugs and security issues.
It's very old and mostly written in low-level C code and we support truly archaic systems
by default - FTP servers running on 16-bit Windows etc:
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/ParseFTPList.h#61
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/ParseFTPList.cpp#1114

From a security standpoint, I agree with Mats. FTP code is very old, we have found bugs in it before and I don't think it is safe.

However, as long as people are using it, I don't think we should just remove it without having some kind of alternative. Another approach that was discussed before in Necko is to only partially remove support: As Mats pointed out, our FTP implementation supports a broad variety of servers, most of which are likely no longer seen in the wild. We could simplify our FTP implementation to only support was is actually currently used and remove a lot of old archaic code.

This would require a Telemetry probe that is more precise than just protocol usage and ties into the ParseFTPList code.

Isn't there a possibility to write some Javascript code to wrap the ftp connection to being a http(s) download? We would use a better maintained codepath then?

Handing the problem off to GNOME or some other environments doesn't seem to increase security. Those are rather smaller projects with little manpower. Firefox would be the one open source place with the knowledge and the manpower.

Hi. Just a Firefox user. I know this isn't the place for advocacy, but I'm kinda curious about how this bug is going. Google is apparently moving forward with FTP Removal according to this Computer World article [1] and will depreciate FTP with Chrome 80 and according to this gHacks article [2] will remove FTP in Chrome 82. After seeing this news, I checked to see Mozilla's stance on FTP and all I could really find focusing on FTP removal was this bug. I still use FTP from time to time, but if the FTP protocol died off due to security/maintenance concerns, I'm sure I would survive. My point in filing this comment is to ask if Mozilla is going to come up with a unified response on 'what' and 'how' FTP will be handled going forward. When Google does things with Chrome it moves the tech news cycle and it would be a nice thing if those boiler plate news stories could have a blurb at the bottom about Mozilla's plans along side anything from Apple and Microsoft (while its still on a separate code base from Chrome).

[1] https://www.computerworld.com/article/3378017/fast-forward-whats-coming-in-future-versions-of-chrome.html
[2] https://www.ghacks.net/2019/08/16/google-chrome-82-wont-support-ftp-anymore/

Google Chrome 80 disables FTP in February 2020, as per https://developers.google.com/web/updates/2019/12/chrome-80-deps-rems

Assigning to Mike for decision

(In reply to ValdikSS from comment #16)

FTP is still widely used

In Firefox, insecure ftp:https:// is almost unused. This is a web browser. Please use sftp or ftps e.g. with FileZilla for edge cases outside of the web.
If you see a public ftp server, please ask its operator to offer https (and maybe ftps). They need to offer it anyway for other browsers.

You can download and upload whole folders

With Firefox only via HTTP(S).

(In reply to Nhi Nguyen (:nhi) from comment #15)

Assigning to Mike for decision

Decision is made. Unassigning myself and assuming someone on Nhi's team will own this going forward.

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1636008

When it comes time to flip this pref permanently and remove the underlying code, please ensure that the conditional I just landed for the Windows installer in Bug 1629636 is handled concurrently.

After discussing with :mconca, we are extending FTP support in release until Fx82 due to Covid19. There are at least 600k monthly users who still use it, and Chrome has also re-enabled FTP due to the current situation.

When removing FTP support, please remove GetFTPFallbackEncodingDoNotAddNewCallersToThisFunction and localesFallbacks.

Perhaps when removing FTP support, someone should isolate the code and make it installable as a plug-in or add-on. Of course there should be a big security warning or something when installing it.
I know of several high-traffic websites that primarily use the ftp function of the firefox browser...
Here's an example: ftp:https://archive.ubuntu.com/
Ubuntu has already made the transition to https, but thousands of other archive sites have not. Browsing files with the ftp protocol is much faster than any webpage, especially since you can't just slap ads or theme garbage on the page.
I just think that it's an extremely bad idea to just dump a useful protocol without making any big announcements about it.

(In reply to Nhi Nguyen (:nhi) from comment #27)

After discussing with :mconca, we are extending FTP support in release until Fx82 due to Covid19. There are at least 600k monthly users who still use it, and Chrome has also re-enabled FTP due to the current situation.

looks like this did not actually happen as I can still access FTP sites with the recently released Firefox 82 beta
also Google plans to remove FTP support entirely starting with Chromium m88 as noted on this page:
https://chromestatus.com/feature/6246151319715840

(In reply to erpman1 from comment #30)

looks like this did not actually happen as I can still access FTP sites with the recently released Firefox 82 beta
also Google plans to remove FTP support entirely starting with Chromium m88 as noted on this page:
https://chromestatus.com/feature/6246151319715840

FTP support has been disabled by default for all Chrome 88 users.
FTP support will be removed from Chrome codebase on Chrome 89.

FYI Chrome's code removal of the feature is being deferred, for details see https://bugs.chromium.org/p/chromium/issues/detail?id=333943#c65 :

Due to this mistake, users who run Chrome without access to our backend infrastructure would've not experienced FTP being disabled until now. Other browser distributions -- notably Chromium -- that pull in //chrome/browser and ship with the default features states are also affected. Out of consideration for those users I'm going to push the code removal to M91. This means that the state of FTP will remain 100% disabled by default for everyone. But the --enable-ftp commandline flag will work for one release longer than originally planned.

(there is even more context at https://chromium.googlesource.com/chromium/src/+/f39d88f50fdcd59a1d6b34628dc2f769e25ce62e)

As of writing, the timeline is:

• Chrome 88 (released Jan 19, 2021) - disabled by default via a remote configuration (if the server backend wasn't reachable, then ftp was not disabled).
• Chrome 91 (planned release May 25, 2021) - planned removal of the feature.

(release dates available at https://chromiumdash.appspot.com/schedule)

We have small list of things to consider in extensions with the removal of FTP. It would be great if we had at least two releases between prefing off and removing code. That would give us one version on release channel with it disabled before the axe is dropped. Pref off in 88, remove code in 90, possible?

Certainly possible. I'd just like us to remove it before we branch off into esr91, so we don't have annoying merge conflicts when uplifting code.

Depends on D111245

Depends on D111246

Depends on D111247

Depends on D111248

Depends on D111249

Depends on D111250

Backed out for build bustages on moz.build

Backout link: https://hg.mozilla.org/integration/autoland/rev/ba0253bd3f98e08c5aed802f9bddca79211e8227
Log link: https://treeherder.mozilla.org/logviewer?job_id=337455250&repo=autoland&lineNumber=1287

Depends on D112906

https://hg.mozilla.org/mozilla-central/rev/b73a08f694ec
https://hg.mozilla.org/mozilla-central/rev/288c44b712b6
https://hg.mozilla.org/mozilla-central/rev/710df44e1a8d
https://hg.mozilla.org/mozilla-central/rev/ec8d54876941
https://hg.mozilla.org/mozilla-central/rev/918cd3aff322
https://hg.mozilla.org/mozilla-central/rev/961a320a1d45
https://hg.mozilla.org/mozilla-central/rev/851056a4d881
https://hg.mozilla.org/mozilla-central/rev/6e22d16b03a3

Docs for this mostly done in https://github.com/mdn/content/pull/5485 - essentially documents removal of feature, preference, and option in the proxy settings. Final work will be a minor update to browser compatibility.

I've set dev-doc-complete, but let me know if there is anything other than the above which needs to be done (a lot of this was cleaned up in FF88)

Is this worth calling out in firefox 90 release notes? (If yes, see https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla)

Not sure if it's relevant. We could mention that the prefs were removed. bug 1699222 might be worth being included in the release notes.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #51)

... We could mention that the prefs were removed

there's quite a few "dead?" prefs still lying around

AFAICT these do nothing anymore

• dom.ipc.plugins.flash.subprocess.crashreporter.enabled
• dom.ipc.plugins.reportCrashURL
• plugin.state.flash
• security.mixed_content.block_object_subrequest ? was this flash only?

Not sure on these ones, there may be others
dom.ipc.plugins.flash.disable-protected-mode ?
plugins.flashBlock.enabled ?
urlclassifier.flash* ?

Might be worth filing a separate bug for removing those.

so sorry, I don't know why I brought FLASH up on an FTP issue .. utter failure to read past the first F, lack of sleep, overworked ....

Anyway, filed Bug 1714549