Intent to Remove: Deprecate FTP support

1308 visningar
Hoppa till det första olästa meddelandet

Justin Tervay

oläst,
15 aug. 2019 19:13:492019-08-15
till blin...@chromium.org
asa...@chromium.org,ter...@google.com https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing n/a
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.
Yes No n/a https://chromestatus.com/feature/6246151319715840
This intent message was generated by Chrome Platform Status.

Dominic Farolino

oläst,
15 aug. 2019 20:59:442019-08-15
till blink-dev
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:

PhistucK

oläst,
16 aug. 2019 04:25:292019-08-16
till Dominic Farolino, blink-dev
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:

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.
Yes No n/a 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

oläst,
16 aug. 2019 05:57:012019-08-16
till Dominic Farolino, PhistucK, blink-dev
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

oläst,
16 aug. 2019 08:22:362019-08-16
till blink-dev
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

oläst,
16 aug. 2019 08:43:262019-08-16
till bay...@gmail.com, blink-dev
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.

Asanka Herath

oläst,
16 aug. 2019 09:45:522019-08-16
till PhistucK, Eric Lawrence, blink-dev
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:
asa...@chromium.org,ter...@google.com https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit?usp=sharing n/a
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.
Yes No n/a 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.

Asanka Herath

oläst,
16 aug. 2019 11:02:232019-08-16
till Daniel Bratell, Dominic Farolino, PhistucK, blink-dev
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.

J Decker

oläst,
16 aug. 2019 11:56:542019-08-16
till Asanka Herath, Daniel Bratell, Dominic Farolino, PhistucK, blink-dev
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?

PhistucK

oläst,
16 aug. 2019 13:03:522019-08-16
till J Decker, Asanka Herath, Daniel Bratell, Dominic Farolino, blink-dev
Internet Explorer can handle FTP on Windows.

PhistucK

PhistucK

oläst,
16 aug. 2019 13:05:122019-08-16
till J Decker, Asanka Herath, Daniel Bratell, Dominic Farolino, blink-dev
The Windows Explorer also seems to be able to handle FTP on Windows.

PhistucK

Chris Harrelson

oläst,
22 aug. 2019 16:41:362019-08-22
till PhistucK, J Decker, Asanka Herath, Daniel Bratell, Dominic Farolino, blink-dev
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

Chris Palmer

oläst,
23 aug. 2019 13:49:062019-08-23
till blink-dev, phis...@gmail.com, d3c...@gmail.com, asa...@chromium.org, bra...@opera.com, d...@chromium.org
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.
--
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.



--
/* 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.

--
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.

--
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

oläst,
23 aug. 2019 17:18:572019-08-23
till blink-dev, phis...@gmail.com, d3c...@gmail.com, asa...@chromium.org, bra...@opera.com, d...@chromium.org
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

oläst,
26 aug. 2019 14:32:042019-08-26
till Matt Menke, blink-dev, PhistucK, d3c...@gmail.com, Asanka Herath, Daniel Bratell, d...@chromium.org
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

oläst,
26 aug. 2019 19:59:092019-08-26
till Chris Palmer, blink-dev, PhistucK, d3c...@gmail.com, Asanka Herath, Daniel Bratell, Dominic Farolino
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.
Svara alla
Svara författaren
Vidarebefordra
0 nya meddelanden