Remove built-in support for FTP from Chrome
Project Member Reported by firstname.lastname@example.org, Jan 13 2014
We should consider removing built-in support for FTP from Chrome and move it out to an app. Over a 7-day period, only .1-.2% of users end up navigating to any FTP URL (with slightly higher numbers amongst Linux desktop users). This has been fairly stable over the last year, so it doesn't look there are trends for FTP to disappear altogether. With the combination of the sockets API and the downloads API it may be possible to construct a Chrome App which handles this well. Also would need a way to be able to register an app/extension to handle a particular URL scheme so that navigations would be seamless for users of FTP apps. This isn't urgent priority, but might be a nice code cleanup for a little-used feature.
Loading detail... X
Jan 27 2014,
Jan 27 2014,
davidben+ellyjones are looking at this as a potential intern project.
Jan 29 2014,
We're going to need to be able to register Chrome apps as protocol handlers for this. We'll probably want to resolve that before the summer if this is to be an intern project.
Feb 9 2014,
The socket API is only available to apps, not extensions. How will (other) **extensions** be able to register a **content** handler when native support for the ftp protocol is dropped? Users don't care whether a file is served from ftp or http, they just want to view a file (in the browser).
Jul 3 2015,
I agree with removing built in FTP support. I'm having to go back to Safari because we use external programs for FTP and there's NO way to override the built in Mac protocol handler for FTP. Drives our developers nuts when they click an FTP link wanting it to open in YummyFTP.
Jul 13 2015,
Instead of dropping FTP support for chrome, you should really drop flash and discourage your users to not use it. There is literally nothing wrong is FTP and I bet it only uses less than 1 MB of user space. But Flash player is vulnerable, exploitable and propitiatory which means it is has greater risk to chrome users plus it uses more than 50 MBs of user space when installed. As I personally do not use Chrome for obvious reasons, this decision to remove FTP will impact negatively to those 1-2% userbase. There are lots of trades which require users to use FTP and those trades and their users will get hurt by this useless nonsensical decision.
Jul 14 2015,
Please be civil on the bug tracker. This is not a bug for discussion of Flash, and this bug is about moving Chrome's builtin support for FTP to an extension or app, not removing FTP support from the browser completely.
Jul 14 2015,
Please no. Please stop "me too" product development (un-development). It seems that FF is a continuous chain of removed functionality. Why not enable\disable ftp from about:config, then everyone could be happy.
Jul 15 2015,
Why force users to get an external ftp application when one can use chrome. And yes, this might be a feature that's not used very often. But the feature is stable and it seems it takes a lot of effort to create an app. So why put in the effort? Wasn't this a feature that wasn't used very much? So why remove it to add it later? Seems a bit silly.
Aug 26 2015,
Большей простите дурости не видывал. Там где надо олтладить алгоритм и поправить собственные баги исв качестве прапвки использовать кастацию. Ну постояльцы "палаты нромер шесть" довольны - их полку прибыло. "Не хочу учится - хочу женится!" /* Митрофанушка, Горе от ума, А.С. Грибоедов */
Nov 30 2015,
Dec 1 2016,
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue. The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Jan 25 2017,
Sep 14 2017,
Sep 14 2017,
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
WontFix. We investigated doing this and it turned out that FTP had too much usage to drop it, especially on mobile. Go figure.
Hrm. Really? Looking at `Navigation.MainFrameSchemeDifferentPage` for the past 7 days, I see 0.06% of stable users navigating to an `ftp:` page (0.003% of total navigations). Looking at `Download.TargetConnectionSecurity` for the same time period, I see 0.04% of users downloading a resource from `ftp:` (0.03% of downloads). If I limit the platform to Android, I see less usage: `Navigation.MainFrameSchemeDifferentPage` is 0.01% of users and 0.0003% of total navigations, `Download.TargetConnectionSecurity` is 0.01% of users and 0.003% of total downloads. We WONTFIXed FTP on iOS (in issue 810884 ). We're not investing in updating the WebRequest API to support FTP (in issue 770869). We apparently want to start allowing FTP subresource requests from extensions ( issue 904455 ). I'm uncomfortable with the current state. FTP is impossible to secure, and the data I see doesn't reflect the level of usage that would make it impossible to remove. Can we reevaluate our commitment to keeping this protocol around? +lassey@, with whom I've had threads on this topic before. +rbyers@ for a web platform perspective.
Going to open this back up, per 22. I do think we can at least make baby steps in this direction.
Sign in to add a comment