Intent to Remove: Deprecate FTP support

[Justin Tervay]

Contact emails asa...@chromium.org,ter...@google.com Explainer https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing TAG review n/a Summary
Deprecate and remove support for FTP URLs.

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.

Google Chrome 72+ removed support for fetching document subresources over FTP and rendering of top level FTP resources. Currently navigating to FTP URLs result in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74+ resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76.

Remaining capabilities of Google Chrome’s FTP implementation are restricted to either displaying a directory listing or downloading a resource over unencrypted connections. We would like to deprecate and remove this remaining functionality rather than maintain an insecure FTP implementation.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No n/a Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6246151319715840

This intent message was generated by Chrome Platform Status.

[Dominic Farolino]

Regarding WPTs, it may be good to aim to close this WPT repo issue, or at least update that thread indicating that maybe this shouldn't be testable long-term.

On Friday, August 16, 2019 at 8:13:49 AM UTC+9, Justin Tervay wrote:

Contact emails asa...@chromium.org,tervay@google.com Explainer https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing TAG review n/a Summary

[PhistucK]

Does that mean that navigating to an ftp:// URL or typing it would just launch the built in handler of the platform instead?

☆PhistucK

On Fri, Aug 16, 2019 at 3:59 AM Dominic Farolino <d...@chromium.org> wrote:

Regarding WPTs, it may be good to aim to close this WPT repo issue, or at least update that thread indicating that maybe this shouldn't be testable long-term.

On Friday, August 16, 2019 at 8:13:49 AM UTC+9, Justin Tervay wrote:

Contact emails asa...@chromium.org,ter...@google.com Explainer https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing TAG review n/a Summary

Deprecate and remove support for FTP URLs.

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.

Google Chrome 72+ removed support for fetching document subresources over FTP and rendering of top level FTP resources. Currently navigating to FTP URLs result in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74+ resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76.

Remaining capabilities of Google Chrome’s FTP implementation are restricted to either displaying a directory listing or downloading a resource over unencrypted connections. We would like to deprecate and remove this remaining functionality rather than maintain an insecure FTP implementation.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No n/a Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6246151319715840

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95b403e5-fee3-43d3-876e-4108bde3f2fd%40chromium.org.

[Daniel Bratell]

On Fri, 16 Aug 2019 10:24:37 +0200, PhistucK <phis...@gmail.com> wrote:

Does that mean that navigating to an ftp:// URL or typing it would just launch the built in handler of the platform instead?

That seems to be the intention.

So the document mentions that 0.1% of users get something over ftp. Unclear over what time though. 0.1% of users is not a lot, but if it's 0.1% of users in a year then it's even less.

Also, this seem to be a straight removal of internal ftp support with no deprecation phase?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KGBuUz4QGBYS0YyeFP92E68GAyx-eDGd2hbUF0wpWjPA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[bay...@gmail.com]

Today, Chrome does not show any sort of "You've attempted to navigate to a protocol that isn't installed" prompt; a link click for a protocol that isn't installed simply does nothing at all. 

This seems like it might be confusing; would it make sense to show an interstitial if there's no system handler?

In EdgeHTML/IE, users get a "You need a new app to open this" prompt when attempting such navigations (tests https://webdbg.com/test/protocol/).

[PhistucK]

The intent mentions that all (supported) platforms have FTP clients (I assumed built in ones), so that should not be a problem.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5589ed7d-ba13-4472-b4c5-1a3cbcd0366d%40chromium.org.

[Asanka Herath]

On Fri, Aug 16, 2019 at 8:43 AM PhistucK <phis...@gmail.com> wrote:

The intent mentions that all (supported) platforms have FTP clients (I assumed built in ones), so that should not be a problem.

☆PhistucK

On Fri, Aug 16, 2019 at 3:22 PM <bay...@gmail.com> wrote:

Today, Chrome does not show any sort of "You've attempted to navigate to a protocol that isn't installed" prompt; a link click for a protocol that isn't installed simply does nothing at all. 

This seems like it might be confusing; would it make sense to show an interstitial if there's no system handler?

In EdgeHTML/IE, users get a "You need a new app to open this" prompt when attempting such navigations (tests https://webdbg.com/test/protocol/).

As bratell@ suspected if there is a registered handler for the ftp protocol, invoking that handler is the intended behavior.

 

In the absence of a system handler, Google Chrome will do a search instead. We may need to treat ftp:// as a special case to help with the transition. This is especially the case for folks who may have Google Chrome set as the handler for the ftp protocol.

On Thursday, August 15, 2019 at 6:13:49 PM UTC-5, Justin Tervay wrote:

Contact emails asa...@chromium.org,ter...@google.com Explainer https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing TAG review n/a Summary
Deprecate and remove support for FTP URLs.

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.

Google Chrome 72+ removed support for fetching document subresources over FTP and rendering of top level FTP resources. Currently navigating to FTP URLs result in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74+ resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76.

Remaining capabilities of Google Chrome’s FTP implementation are restricted to either displaying a directory listing or downloading a resource over unencrypted connections. We would like to deprecate and remove this remaining functionality rather than maintain an insecure FTP implementation.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No n/a Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6246151319715840

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5589ed7d-ba13-4472-b4c5-1a3cbcd0366d%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KciWz3tnHACKpZfq479Fn6o%2BMk6-K%2By892HEhCTcePGg%40mail.gmail.com.

[Asanka Herath]

On Fri, Aug 16, 2019 at 5:57 AM Daniel Bratell <bra...@opera.com> wrote:

On Fri, 16 Aug 2019 10:24:37 +0200, PhistucK <phis...@gmail.com> wrote:

Does that mean that navigating to an ftp:// URL or typing it would just launch the built in handler of the platform instead?

That seems to be the intention.

Yup.

 

So the document mentions that 0.1% of users get something over ftp. Unclear over what time though. 0.1% of users is not a lot, but if it's 0.1% of users in a year then it's even less.

The number is based on a 7 day aggregate of stable channel users on Windows which is an optimistic upper bound.

Increasing the scope to all platforms and extending the time period for 28 days gives us ~0.01% of users, and ~0.0008% of top level navigations hitting FTP URLs for the same group. These are FTP directory listings.

For the same 28 day period we see ~0.03% of users on all platforms downloading something over FTP -- which is the only other thing users can do with FTP URLs.

Also, this seem to be a straight removal of internal ftp support with no deprecation phase?

There's an interim phase where FTP will be disabled but can be enabled via a flag or enterprise policy. While the enterprise policy will be discoverable, the flag won't be surfaced in the browser UI. i.e. There's be a flag in chrome://flags, but there'll be no warning if one were to visit a ftp:// URL. The flag and policy are only meant as temporary escape hatches.

We are aware of a UX issue when the browser is set as the handler for ftp:// URLs.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z6l0kywerbppqq%40cicero2.linkoping.osa.

[J Decker]

When it's needed, there's no workaround.

Just a week ago, I was getting sources to build utilities on this ARM system... I'm fairly certain that some of those came up on the search results with an ftp:// link to a GNU source mirror.  But other than those, I've not run into a lot of FTP.  I did a quick search to see which ones showed up with http:// and ftp:// links on the search page; but then maybe that is why there isn't so much access (omission from search).

1) distros are often binary/rolling releases so individuals don't download

2) being linux there's probably wget or curl availalble to get the thing instead

3) this sort of thing wouldn't be downloaded by windows users....

4) Seems http(s) servers can provide the same functionality anyway, and be secure.

but, as far as I know, there isn't a FTP available on windows installed, that would be launchable by a protcol launcher; I suppose maybe Edge?  But won't that end up inheriting this same removal?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DuaOGnuYYg2eC6e_9am43xkkdGRQOV5_nmOR82tg8_N4U7yQ%40mail.gmail.com.

[PhistucK]

Internet Explorer can handle FTP on Windows.

☆PhistucK

[PhistucK]

The Windows Explorer also seems to be able to handle FTP on Windows.

☆PhistucK

[Chris Harrelson]

Some of the API owners (me, slightlyoff, bratell) met today and discussed this intent.

We concluded that since Chrome has already removed subresource rendering of FTP resources, and serves directory listings / downloads for non-subresources, FTP we can't see a way that FTP would still be "web-exposed", except to the extent users of Chrome (the browser) expect FTP to work, or developers expect FTP to work when linking to it. (If any one can see one please tell us.)

Therefore we concluded this intent does not require any LGTMs from us.

However, we did agree that it would be a good idea for Chrome to make FTP fallback to alternate applications as seamless as possible, and provide clear messaging when that is not. We thought about Android in particular (since Windows was covered on this thread) -- presumably FTP apps on that platform can capture those URLs via intents, and if there is none installed it would be nice for Chrome to suggest installing one.

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Jb2Atj0TUuq54tU%3DxM3oH_7DQP92zwF-Tsd3Q_UbiDiA%40mail.gmail.com.

[Chris Palmer]

Although you don't need LGTMs, and although I don't have one to officially give, I love this from a security perspective (reduced attack surface!). Thank you. :)

Did we ever handle the HTTP/0.9 problem? Last I heard we had to keep it for Shoutcast?

/Daniel

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/95b403e5-fee3-43d3-876e-4108bde3f2fd%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KGBuUz4QGBYS0YyeFP92E68GAyx-eDGd2hbUF0wpWjPA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z6l0kywerbppqq%40cicero2.linkoping.osa.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DuaOGnuYYg2eC6e_9am43xkkdGRQOV5_nmOR82tg8_N4U7yQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Matt Menke]

We still support HTTP/0.9 on default ports for HTTP and HTTPS responses, and we allow HTTP/0.9 on any port for HTTP responses when we see Shoutcast's non-standard "ICY" header.  We also still allow truncated HTTP/1.x headers, without the double-CRLF/LF at the end, though we only allow that for HTTP.

[Chris Palmer]

How much of that can we phase out, if any? Do we have histograms to measure the frequency of any of it? (I couldn't immediately find them.)

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/e1hkwUL4p3w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/97f91550-1bf6-4c0b-82ba-b3a837f9b8f7%40chromium.org.

[Matt Menke]

I added histograms back when I removed HTTP/0.9 support on non-default ports, but removed them long since, due to the whole histogram-eraser thing.  I can't remember the numbers, but I believe they were all above HTTP/0.9 on ports other than 80/443.  Since we weren't willing to drop ShoutCast support, I decided it wasn't worth pursuing.