Intent to Deprecate and Remove: Rendering FTP resources.

[Mike West]

(BCC net-dev@)

Primary eng (and PM) emails
mk...@chromium.org

Summary
Rather than rendering resources requested via FTP, we should download them. We should continue to render directory listings, but we will not render anything else. That is, ftp://ftp.hp.com/ will render the same, exciting directory listing you see today; while ftp://ftp.hp.com/pub/test2/test2 will result in a `test2` file being downloaded.

Motivation
FTP is a non-securable, legacy protocol. We've WONTFIXed FTP support on iOS, but its usage in Blink-based Chrome is high-enough that it seems difficult to remove all at once. This seems like a reasonable way of reducing its viability as an attack surface as a stepping stone to more complete removal.

Interoperability and Compatibility Risk
FTP is not terribly completely specified (Fetch, for example, leaves it as an exercise for the reader), and there's already some divergence in behavior between browsers.

Safari will render FTP resources, but will not render directory listings. Visiting ftp://ftp.hp.com/ actually punts out of Safari completely, delegating the work to Finder.

Firefox behaves similarly to Chrome today, rendering a directory listing, and rendering resources.

I tried testing Edge via Browserstack, but Browserstack doesn't support FTP (which is an argument in itself).

Alternative implementation suggestion for web developers
HTTPS. It's a thing. It's nice. If the Linux kernel can do it, you can too.

Usage information from UseCounter
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.

rbyers@ further noted that 0.2% of Linux users (and 0.08% of Windows users) download via FTP daily, and that 0.1% of navigations for Linux users are to FTP URLs. I find those numbers all surprisingly high, but there you go.

I hope we can drive them down over time via efforts like this one, with the final goal of removing FTP entirely from our codebase.

Entry on the feature dashboard
https://www.chromestatus.com/feature/6199005675520000

Requesting approval to remove too?
Yes. This seems like a reasonable stepping stone towards getting rid of FTP for most users, while still supporting the primary use case of accessing ancient resources that aren't easily available over HTTPS.

-mike

[bay...@gmail.com]

FWIW, at least some users (including famous ones :) already expect files to download over FTP rather than rendering inline. 

Today, Edge maintains the IE behavior of showing a generated directory listing for FTP sites, very similar to Chrome and Firefox's handling.

In general, having FTP-served resources download rather than rendering inline seems reasonable to me. The user experience probably will feel a bit strange in cases where the target file type ultimately goes back into the browser (e.g. PDF) because many users are unlikely to recognize that the displayed file was now copied locally.

Kicking FTP navigation out to the system's file browser (Finder, Explorer) worries me a little bit, insofar as those applications tend to run in much weaker sandboxes (or none at all) than the browser itself.

[David Benjamin]

I like this idea. It should largely knock FTP out of the web platform's attack surface. It's still in the net stack's attack surface, but that's a much smaller and simpler area to think about.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e525dfa3-864b-4cda-824b-65207d25d264%40chromium.org.

[Johnny Stenback]

Given it's almost 2019 this seems to be a step in the right direction, I'm glad to see this change happen!

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

[Chris Harrelson]

LGTM1

--
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/CAKXHy%3DfePJXeadH%2B0qdVyVrsHXnpJaZ21NOpsV81GMccjY%3DYgw%40mail.gmail.com.

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9tyx%2ByeG3zpGz-HVR%3DaEW4iBQwD2Ty1MozbQDEGLQ1UQ%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Dirk Pranke]

Won't this affect the way relative URLs in the fetched resource are rendered? For example, if I fetch "test.html" and it contains a href="../resource.html" in that, that'll have very different results if I'm rendering it by downloading the file and then opening it versus it being opened in the context of the right origin, right? I don't know that I'd expect the average user to appreciate the implications of that, I'd expect them to just be annoyed and click through (and then wonder why things aren't working).

Apart from that (and probably less important), this feels like just a generally unfriendly user experience, in the sense that I don't think anonymous FTP is less secure than HTTP (perhaps I'm forgetting something and am wrong here?) and, given that, it's hard for me to say that we should treat FTP differently from HTTP. It seems like that's exposing an implementation detail to the user in a particularly poor way. Given that we still have to support the network protocol, and we don't simplify any rendering code, this doesn't seem like a great win to me. Perhaps I'm not wise to the potential range of exploits we'd be excluding?

-- Dirk

On Thu, Nov 15, 2018 at 8:54 AM Mike West <mk...@chromium.org> wrote:

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

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

[Mike West]

Thanks for the feedback, Dirk!

On Fri, Nov 16, 2018 at 3:12 AM Dirk Pranke <dpr...@chromium.org> wrote:

Won't this affect the way relative URLs in the fetched resource are rendered? For example, if I fetch "test.html" and it contains a href="../resource.html" in that, that'll have very different results if I'm rendering it by downloading the file and then opening it versus it being opened in the context of the right origin, right? I don't know that I'd expect the average user to appreciate the implications of that, I'd expect them to just be annoyed and click through (and then wonder why things aren't working).

Yes. It will affect the way that relative URLs in downloaded HTML files are rendered, if those files are opened from `file://` URLs. The relative URL probably isn't even the biggest breakage folks would see, since `file://` URLs render with a more-or-less opaque origin, and can't do things like XHR that they might rely upon.

This change will certainly have the effect of making some subset of pages currently served over FTP less usable. The goal, really, is to get those pages to move from FTP to HTTPS, which is better in practically every way.

My claim here is that the usage is low enough to make that intervention possible and successful (I'd also note that we've already made an even stricter decision on iOS by not supporting the protocol at all; I don't feel like this is something that's stopping people from doing what they want to do on the web).

 

Apart from that (and probably less important), this feels like just a generally unfriendly user experience, in the sense that I don't think anonymous FTP is less secure than HTTP (perhaps I'm forgetting something and am wrong here?) and, given that, it's hard for me to say that we should treat FTP differently from HTTP. It seems like that's exposing an implementation detail to the user in a particularly poor way. Given that we still have to support the network protocol, and we don't simplify any rendering code, this doesn't seem like a great win to me. Perhaps I'm not wise to the potential range of exploits we'd be excluding?

From a network perspective, FTP is just as bad as plaintext HTTP. It's slower and less efficient, but just as legible and manipulable on the wire. From an ecosystem perspective, though, it's worse, for a few reasons:

* FTP doesn't have headers, which means it can't avail itself of the mechanisms that would allow it to protect users by upgrading them to secure transport. There's no `Upgrade-Insecure-Requests`, there's no redirect mechanism, etc.

* Even if there were headers, there's not a secure alternative to FTP that any browser supports. Indeed, Firefox WONTFIXed the 18-year-old request to implement FTPS, given that they "(sooner or later) would like to deprecate FTP completely)".

* Chrome doesn't support FTP via control mechanisms like the Web Request API (https://crbug.com/770869), or content settings (https://crbug.com/636981) and we're not investing in improving that state, which introduces some potential privacy risk.

I think it's better for us to spend our time working towards deprecating our FTP support, step by step, than to go through issues like these to find reasonable solutions.

-mike

[Dirk Pranke]

Thanks for the additional context.

For the sorts of resources that might be available over FTP, I'd be a lot more worried about the user impact from breaking relative URLs than things like XHR, but maybe I'm stuck in a mentality from 15+ years ago.

Apart from that, I agree that you shouldn't be trying to figure out how to add features for a protocol you wish to support, but otherwise I'd probably leave FTP support in as-is until you were also ready to remove plaintext HTTP, and then I'd remove them both at the same, thus removing FTP in a single step (or as part of the other step, depending on how you look at it). But, I don't have any insight into how much discussion we're getting around the features of the platform like the Web Request API not being available on some protocols, so I can't really say as to whether multiple steps is better or worse.

And, regardless, this definitely isn't my call either way :).

-- Dirk

[David Benjamin]

Another difference between FTP and HTTP is that I believe FTP isn't affected by HSTS. So while a site can disable plaintext HTTP, I don't think it can disable plaintext FTP. The lack of cookies in FTP avoids the immediate vector, but it would still be good to keep the FTP URLs out of, say, the omnibox.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEoffTBFt-8mX00u%2BgQS8pyhnZ0UtgNAxAvhe7iqJ5XgaQ-8Gg%40mail.gmail.com.

[Matthew Menke]

Even 15 years ago, using FTP to serve HTML wasn't all that common - and I don't think there are a whole lot of people who are going to try to download HTML over FTP, and then open up the file URL in Chrome, and try those relative links.  Note that FTP listings over FTP will still work (And have functional links to relative URLs), it's just HTML over FTP that won't.

Other problems with FTP are that it's underspecified - it has no directory listing format, no text encoding format (Do we use UTF8?  The local system's language?  Try to sniff a language?), and is also intended just for uploading and downloading files, which gives it some potentially problematic properties.  If an FTP server allows uploading and downloading to the same directory, anyone in the world can use your FTP server to set up a poor-man's website, which seems rather problematic.  Admittedly, if you really want, you can make an HTTP (Or even HTTPS) server do the same thing, but it's closer to the default mode of operation for FTP, rather than something you have to choose to implement, as it is with HTTP.

[Daniel Bratell]

I am also surprised by the number of users encountering ftp links, though the number of actual page loads is much lower.

Looking at the counter it seems like it includes navigations also to non-existing resources (strange "404" page) and to non-html resources. If speculating, it could even be that some/many loads were intended to be a download. For instance, trying to download html files (and images) from some web hotels would end up as navigations.

A question: It sounds like you plan to change navigations to non-html resources like ftp://ftp.sunet.se/about/graph.png - will that also affect pages (if any) that use images hosted at ftp sites?

I'm tempted to go along with this change. Given that ftp usage is going down (right?) it's more a question of now or later, and considering that some page loads will have been intended to be downloads (or be dangling links) the risk is smaller than it looks from numbers alone.

/Daniel

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/5a5416e1-ace5-4c20-b5d7-fe0bbcc9e11d%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Matthew Menke]

Quick response inline below.

On Monday, November 19, 2018 at 10:29:58 AM UTC-5, Daniel Bratell wrote:

I am also surprised by the number of users encountering ftp links, though the number of actual page loads is much lower.

Looking at the counter it seems like it includes navigations also to non-existing resources (strange "404" page) and to non-html resources. If speculating, it could even be that some/many loads were intended to be a download. For instance, trying to download html files (and images) from some web hotels would end up as navigations.

A question: It sounds like you plan to change navigations to non-html resources like ftp://ftp.sunet.se/about/graph.png - will that also affect pages (if any) that use images hosted at ftp sites?

Correct.  This affects all MIME types (images, PDFs, and any other types the MIME sniffer supports and then we handle in interesting ways depending on the results).  Chromium has never MIME sniffed SVGs, so those were already broken, I assume.

[Jochen Eisinger]

lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9cfe3d47-5dc5-4313-b35d-c3df3054095d%40chromium.org.

[ergonom...@gmail.com]

Tell me, who decided this? Disabling FTP is your personal decision?

Let's ban https? In some particular cases, it is also not safe.

[Daniel Bratell]

The idea here is not to ban FTP but to use FTP only as a pure download protocol. That is, not render resources from ftp inside the browser.

As for who decided it, the decision followed the normal process as outlined at https://www.chromium.org/blink#new-features . A couple of us (Blink API owners) are gatekeepers to ensure that we follow our own rules and don't harm the web and those are the LGTM statements you see.

At all times we make the decisions based on the information we have, which in this case indicated that the change would be compatible with the web. If you have more information, this is a good place to share it.

/Daniel

On Tue, 27 Nov 2018 16:50:10 +0100, <ergonom...@gmail.com> wrote:

Tell me, who decided this? Disabling FTP is your personal decision?

Let's ban https? In some particular cases, it is also not safe.

--
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/99a618da-5564-4f16-8e8e-6a3c91592693%40chromium.org.