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

Issue 333943 link

Starred by 35 users

Issue metadata

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


Sign in to add a comment

Remove built-in support for FTP from Chrome

Project Member Reported by cbentzel@chromium.org, Jan 13 2014

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 dxie@chromium.org, Jan 27 2014

Owner: phajdan.jr@chromium.org
Status: Available
Cc: davidben@chromium.org phajdan.jr@chromium.org ellyjo...@chromium.org
Owner: ----
davidben+ellyjones are looking at this as a potential intern project.
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 robwu...@gmail.com, 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 e...@web-jive.com, 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. 
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.
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 by Deleted ...@, Aug 26 2015

Большей простите дурости не видывал. Там где надо олтладить алгоритм и поправить собственные баги исв качестве прапвки использовать кастацию. Ну постояльцы "палаты нромер шесть" довольны - их полку прибыло. "Не хочу учится - хочу женится!" /* Митрофанушка, Горе от ума, А.С. Грибоедов */
Blocking: chromium:310456
Project Member

Comment 14 by sheriffbot@chromium.org, Dec 1 2016

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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 15 by mkwst@chromium.org, Jan 25 2017

Blockedon: 435547
Status: Available (was: Untriaged)
Cc: palmer@chromium.org

Comment 18 Deleted

Project Member

Comment 19 by sheriffbot@chromium.org, Nov 12

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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
WontFix.

We investigated doing this and it turned out that FTP had too much usage to drop it, especially on mobile. Go figure.
Blocking: 904455
Cc: lassey@chromium.org rbyers@chromium.org
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.
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.
Blockedon: 499063
Blockedon: 744499
Blockedon: 906133

Sign in to add a comment