New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 35 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Sign in to add a comment

Issue 333943: Remove built-in support for FTP from Chrome

Reported by, Jan 13 2014 Project Member

Issue description

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.

Comment 1 by, Jan 27 2014

Status: Available

Comment 2 by, Jan 27 2014

Owner: ----
davidben+ellyjones are looking at this as a potential intern project.

Comment 3 by, Jan 29 2014

Blockedon: chromium:86115
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.

Comment 4 by, 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).

Comment 5 by, 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.

Comment 6 Deleted

Comment 7 by Deleted ...@, 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.

Comment 8 by, 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.

Comment 9 by Deleted ...@, 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.

Comment 10 by, 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.

Comment 11 Deleted

Comment 12 Deleted

Comment 13 by, Nov 30 2015

Blocking: chromium:310456

Comment 14 by, Dec 1 2016

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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 - Your friendly Sheriffbot

Comment 15 by, Jan 25 2017

Blockedon: 435547

Comment 16 by, Sep 14 2017

Status: Available (was: Untriaged)

Comment 17 by, Sep 14 2017


Comment 18 Deleted

Comment 19 by, Nov 12

Project Member
Status: Untriaged (was: Available)
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 - Your friendly Sheriffbot

Comment 20 by, Nov 12

Status: WontFix (was: Untriaged)

We investigated doing this and it turned out that FTP had too much usage to drop it, especially on mobile. Go figure.

Comment 21 by, Nov 12

Blocking: 904455

Comment 22 by, Nov 13

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.

Comment 23 by, Nov 13

Status: Available (was: WontFix)
Going to open this back up, per 22.  I do think we can at least make baby steps in this direction.

Comment 24 by, Nov 16

Blockedon: 499063

Comment 25 by, Nov 16

Blockedon: 744499

Comment 26 by, Nov 16

Blockedon: 906133

Sign in to add a comment